PAUL VAN ESSCHE & ASSOCIATES
  • Home
  • Industries
  • Services
  • Contact

Principles of Collaboration

12/13/2014

0 Comments

 
I'd like to share some interesting lessons learned from an exercise in improving collaboration conducted recently in a large public-sector organization. This précis is not short, but it really just scratches the surface, so contact me if you want to chat about it in more detail - I'd be happy to share. 

The order came from the top - find out why we're not collaborating enough and fix it! True, people were working in isolation much of the time, hiding work from others, re-inventing the wheel continuously, especially when possession of that work's outcome (a) gave them power over co-workers and/or (b) gave them value in the eyes of seniors. But in general the nature of the work lent itself well to collaboration, and most people really wanted a better quality of interaction with colleagues. And yet, despite efforts to fix the situation, such as the development of thematic portals, and the installation of IM and video chat facilities, really effective collaboration remained low. What we found out was this:

1. To improve collaboration, define it in a way that brings value to your organization, and aim for that definition.

"Collaboration" in the abstract is just too nebulous to go out and "improve" on. In our context we defined it as actions of cooperation between colleagues that improve outcomes, provide learning experiences, and institutionalize knowledge. In other words, working together (a) produces deliverables that are better than if done alone (greater than the sum of their parts), (b) allows information and techniques to be transferred from one person to another, and (c) through that transfer allows knowledge to permeate into the fabric of the organization - its people and its products. Of course we know that  committees can produce outcomes that are poor compromises, so it's not just about getting in a room together - its about collectively aspiring to better quality through a sense of common purpose. And please note that purpose is a key word here - collaboration efforts need to be centred around a real business purpose or they won't take hold. 

2. Collaboration must be built on a solid infrastructure

What is this infrastructure? We divided it up into four layers of "foundational elements":   
Picture
Starting bottom left and working up:

Incentives: Be careful how your organization* is incentivized - too many large organizations have periodic evaluation frameworks which favour individualism, while smaller companies are ad-hoc. Group collaboration must be part of any incentive/reward structure.

Practices and Policies: Practices are the informal but engrained ways of doing things that make their way into the way we work, until we think they are actual rules. Once entrenched, they're difficult to break away from, but any working practices that favour individualism need to be identified and changed. Policies are the actual written rules, and also need to be identified and changed.   

Leadership: The biggest success factor of all. The senior most people in the organization need to demonstrate collaboration and require it of their reports, ensuring permeation through the ranks. Interestingly, the leadership isn’t all senior: natural leadership at all levels needs to be nurtured too. Some call them "Champions", but either way, find the individuals that will run with a new concept and pull others along with them, and make sure they get your full support – and get rewarded. 

Integration: Organizations structured in silos will always work that way, and information systems that are disparate and support the silos with little to no inter-connectivity will exacerbate the problem. Collaboration thrives in environments that are integrated both structurally and informatically. Yes, that’s now a word! 

Connectivity: Global organizations need the tools and telecoms bandwidth to communicate fast and effectively. If it's hard to speak or IM with someone far away, or even ten cubicles away, people will tend to try and solve problems alone. 

Desktop and Mobile: All elements, including hardware, desktop programs and mobile apps need to be of quality and performance comparable to that which employees now enjoy in their personal lives. Hoping that people will connect and collaborate with the aid of a lousy phone or tablet app is a dream, not a hope. The quality of experience out there is too great now for anything less than excellent to take hold. 

The Data Layer: Whatever your business, the information supporting it needs to be of high quality and highly available. Information about financial and material resources, about projects (the things we're working on) and about people (the skills and other characteristics of our staff) are primordial to generating collaborative links that would not otherwise have occurred. For example, "Oh, I know a guy in sales who can do that..." just isn't enough any more. We need to consult our internal skills base and find the best person, anywhere in the company, whether for a quick piece of advice or longer-term assignment. 

The Tools Layer: As soon as we say “tools” everyone thinks about an enterprise-social tool like Yammer or any one of its 100-or-so (literally) competitors. We'll come back to that shortly but for the time being the tools infrastructure elements we're talking about include: a mature portal structure, a comprehensive enterprise search facility, and the established use of (what should be) core technologies in your business such as workflow engines and wikis. Plonking in a "Facebook for companies" without being able to search your own company's information with an engine at least as effective as Google is not going to support your definition of collaborative value.  

Bottom line: Any fundamental weakness in any of the foundational elements will critically hamper collaboration.

3. The Three Biggest Issues

Once we'd figured out our foundation model and experienced its relevance, we realized that there were a couple of other pieces to the puzzle that merit separate mention:

A. The biggest enemy: EMAIL. Email is the quintessential necessary evil. While we can no longer live without it, it's also one of the biggest barriers to collaboration - in our definition. Email so nicely compartmentalizes exchanges, with the power of inclusion and exclusion, the politically charged order of addressees and cc's, and the real sting in the devil's tail, the blind copy. Email also fosters the ridiculous proliferation of documents through attachments, making a complete mess of versioning and any reasonable control. Email is a barrier, a cage, a hole to hide in, a place to plot in and a weapon to wield, all over and above its clearly valuable uses and the positive-transformative effect it's had on our lives. Unfortunately it has over-stepped its usefulness into double-edged sword territory, and behaviours need to be changed for it to support real collaboration, and that means NOT using for many of it's current purposes. 

B. Poorly configured Office Space is a collaborative killer, whether rooms or cubicles are overly compartmentalized (rabbit-warren style) or so open and uncontrolled that all privacy and the right to think quietly are destroyed. This is not the place for an architectural treatise, but there are good solutions out there, and organizations would be well advised to examine this issue closely. See for example http://myturnstone.com/blog/21-inspirational-collaborative-workspaces/ and the link therein, http://myturnstone.com/blog/office-zones/.

C. Culture is so difficult to define and to change, yet so essential to understand and to tackle. Like people, organizations develop habits, good and bad, and for their own health and well-being, the bad habits need to be turned around. Parts of our framework address this (incentive, leadership..) but it's worth being aware of culture as a single and large piece of the puzzle. It’s also a large enough subject in and of itself for another post!    

4. Degrees of Social

In the Facebook age, we tend to think of collaboration in Facebook terms. So let's return to "Facebook for companies" as promised. Firstly we need to recognize that different kinds of collaboration require different levels of sociability to be effective. For example, great collaborative work has been done by scientists across continents exchanging handwritten, sail-ship-carried letters. Was that efficient? Maybe not, but was it any less effective? No, it was arguably just as effective or even more so, as it allowed for pause and reflection in between communications - something we do so rarely now. Anyway, the point is that social can be good, but needs to be applied in line with the objectives. Consider the five elements in this diagram (yes the elements are pretty random, but hopefully no less illustrative)
Picture
A high-social environment is like a party: conversations are active, traffic is all over the place, nothing is moderated or structured, and most everything is transparent, music volume permitting. A low-social environment is like our inter-continental scientists, but imagine them being careful about how much and what they share. The question is this: according to our definition of collaboration, how social do we need to be? Of course there is a time and a place for everything (every party eventually winds down and we have to sleep) but we found that one of our major issues was that we were not social enough, and were stuck on the lower end of this scale. Even the tools I mentioned above (IM and the like) were under-used because they were too disconnected, and didn't "get the party going". With obvious pieces of the analogy aside, a good party is like good collaboration in that it needs leadership to happen in the first place, has energy and enthusiasm, helps form new relationships, and can be a lot of fun! The difference of course is in the outcome - we want a good product, a result we can be proud of, and not a hangover.   

Can Enterprise-Social tools help here? Can they make the truly collaborative conversations and interactions happen? Yes they can, but they will also fail without the right culture and without ticking all the boxes we've mentioned above. Correctly implemented, they can support our objectives, and, for example, get colleagues to know more about each other, and to "meet" and work with colleagues that they might not otherwise have known about. But they remain a tool amongst others, and not a single means to an end, and it’s with that in mind that we’ve taken the leap with one in particular – which one is not important, it just has be the right one for the context.

5. Quick A-B-C-D

We’re still in the early days and I’ll publish more later about the longer-term results. But in the meantime this is how I suggest you proceed if you are contemplating a similar adventure:

A. Get your ducks in a row. The ducks are described in some detail above.

B. Don't jump into tools for their own sake – work out what degree of social is appropriate first, and what functions you really need the most. Treat it like any other well-run software selection, but put that social element high on the list.

C. Find enthusiastic pilot communities to get things going; learn from their lessons and adjust as you go. Also, consider letting the first pilot run the tool selection, and be prepared to switch tools if the one you choose isn’t absolutely great, especially in the early phases. Treat the early days as a “collaboration lab”.

D. Lead, lead, lead. Get the seniors on board and offering incentives and showing the way, while you enable the natural leaders at all levels.

I hope this helps the many CIOs and others who I know are being asked to tackle the collaboration question, and who are under pressure to implement something, anything, which makes the organization more “social”. Unless you understand exactly what kind of social is going to do it for your organization, social will remain a buzzword, and likely become a bad memory too. Please beware of the software vendors (as usual) who promise that their solutions will have you all collaborating in no time, regardless of other factors. It just isn’t true.

Two footnotes for enthusiasts:

1. The way we learn is changing

Let’s remember again that information transfer and sharing can indeed be done off-line, and formally (“low-socially”), but the issue is that behavioural evolution in our societies means that we take much less time and care to sit down and read or write. Therefore the more interactive and social learning and knowledge transfer paths are gaining importance, and in general people will learn more in an interactive session than alone. When you think about it, that's not really new: it's why we go to school as opposed to sitting at home reading books! But classrooms too are evolving, and on-line experiences are now part of them, and the best schools are evolving away from a lecture format into a round-table "learn from each other while you discuss" style. See for example http://en.wikipedia.org/wiki/Harkness_table. (One of our self-imposed challenges was to create a Harkness-like environment, both on-line and in person.) If the goal of collaboration is to promote information sharing and the institutionalization of knowledge, we have to look carefully at learning and information transfer mechanisms as processes.

2. Knowledge transfer and repositories: man vs machine

This study led us to believe that “knowledge-bases” and “institutionalized knowledge” live primarily within the employees of an organization and not in databases. Computer programs, document and audio/video repositories, wikis and yes, collaboration tools, are all helpful pieces of the support structure. But in the end, the most meaningful transfer of knowledge happens not in writing/reading or recording/listening, but in the interactive telling of and participation in stories and experiences one person to another. Leveraging this reality in the pursuit of collaboration (and our defined benefits) means supplying a “high-social” experience, and that's part of what our solution aims to deliver. 

* For “organization” please always read “company or organization”
0 Comments

Why "IT Projects" Fail

11/4/2013

3 Comments

 
There's an awful lot of talk out there about the failure of "IT Projects", and how much they've overspent and run late, and under-delivered and disappointed. The subject has been given new energy recently by the disastrous go-live of the US Government's new on-line Medical Insurance system. As a company that spends a lot of time rescuing failed projects, we tried to encapsulate our experience in the shortest format possible, the three points below, in the hope of shedding some light on the subject. So, in our humble opinion, why do these projects underperform so badly, and so often fail outright?

1. They’re not IT projects. 

An IT project replaces wired computer networks with wireless ones, or upgrades email servers for greater speed and capacity, for example. Overhauling the way in which social security benefits are managed and paid is a business project, and needs to be managed as such. Managing business projects like IT projects will invariably cause them to fail because the skills, methods and tools required for each are significantly different (see 2. below). Rather, they should be branded, managed and supported as “business transformation” projects, which is exactly what they should be if they are worth doing at all. Why would you invest in a project in the first place if you weren’t expecting significant beneficial change, and bottom-line impact? IT can make that change possible, but it doesn’t make it happen. 

2. Fundamentals are not respected.

The fundamentals of any operation or project, whether you’re making shoes, or growing potatoes, or computerizing a national health service, have a lot in common, even if the execution (obviously) varies. They require the management of the same three primary asset classes: people, process and technology. Unless conscientious, skilled farmers (people) prepare their fields appropriately (process) with well-maintained ploughs and the right fertilizer (technology), their crops will fail. Failed projects in general, and failed business transformation projects in particular, have insufficiently experienced, qualified and/or motivated people, using inadequate and/or inappropriate methods to implement the wrong and/or wrongly configured technology. It defies reason, but this mistake is made repeatedly: non-specialized people, capable only of muddling through, are expected to execute strategically critical projects with the same technology that everyone else bought (and mostly failed with), without adequate support. Imagine if the same approach was adopted by your surgical team, or even your garage...    

3. Partners are mismanaged. 

Arguably this element would fall under process or method in the fundamentals area, but it is so critical, and such a major cause of failure, that it requires its own mention. In addition, clients are often over-reliant on their partners, particularly management and IT consulting firms, to provide the people, processes and technology for their projects in the first place, as well as all the advice and knowledge relating to these assets and how they should be deployed. Note that “managing” partners means keeping them honest and getting good if not excellent value from them. This may sound simple but it’s far more difficult than anyone who has never attempted to do so could possibly imagine.

4. Recipes replace Leadership

Somehow we've come to believe that 10'000- to 100'000-line project plans are the recipe for success, and that all we need to do is execute to the letter and all will be fine. Nothing could be further from the truth. Even in complex projects, if your plan goes over 1000 lines, you're in trouble. Keep it simple, don't treat the project as a sausage-making exercise, encourage creativity and adaptability, and provide your team with continuous reminders of the higher goals, motivation, encouragement and support. Of course, "leadership" is one we could talk about for hours, but that's a subject for another post...

Bottom Line

So, the bottom line is this: manage a transformation like a transformation, not like a hard-disk upgrade. Decide what you want to achieve, and keep aiming for it and working towards it -unwaveringly. Make sure senior people are responsible for and tied into the success and the benefits you expect, every step of the way, and put them under pressure to deliver. Staff the effort with competent, experienced people, put them under pressure too, but support them and the mission purposefully and energetically. If you need external help, find the very best - remembering that big names don't guarantee you the best result - and push them relentlessly to deliver fair value, possibly giving them some skin in the game too. 

Clearly this précis is only the tip of the iceberg. Please contact us to get into more depth - we'd be delighted to learn about your challenges and share our experience, and hopefully help map a path to success! 
3 Comments

Tom Puglisi joins the Leadership Team

7/1/2012

0 Comments

 
vE&A is happy to welcome Tom Puglisi to the Leadership Team. Please click here for his short bio. Tom and Paul have been collaborating on projects on and off since 2002, and finally decided to formalise the fruitful relationship. Tom will lead activities in the D.C. area, while also collaborating on a number of other projects in the US and abroad. Tom is the founder and CEO of Rock Spring Consulting, and in some cases will continue to execute under that brand. 

This new arrangement establishes a partnership between the two business entities which increases the reach and abilities of both, bringing a wider range of skills and even better value to clients. 
0 Comments

An article from Edition 23 of "In Black and White" by Paul van Essche

5/4/2012

0 Comments

 
"In Black and White" is a magazine with news and information about Old Hiltonians, published by the Old Hiltonian Society. The article below was written on request from the school and published in issue #23, April 2012. 

This article is an account of the three years, from mid-2008 to mid-2011, that I spent at the United Nations in New York, as director of “Umoja”, the UN’s global, administrative reform program. More importantly, it is a personal tribute to Hilton College, as the challenges I faced in this role reminded me of the immense value of the education and moral grounding I received at our fine school.

The UN is an organization that exists, not because of our humanity, but our lack of it. If it hadn’t been invented yet, someone would no doubt do so. But sadly, despite the best efforts of many selfless humanitarians, the UN is struggling more than ever for relevance and impact. For instance, despite many billions of dollars spent on peacekeeping in Africa over the past few decades, millions of people have died in atrocious conflicts, most that continue to this day.

Such failings are traceable to the ineffectiveness of diplomacy, governance and administration. Weak leadership and partisan interests prevent the organization’s re-purposing from a post-war parliament to a 21st century tool for peace, development, and the protection of human rights. In tandem, the creaking bureaucracy has resisted all attempts at modernization, and cannot serve global operations adequately. In short, the UN has become badly dysfunctional and has needed a major overhaul for some time. 

From 2002 to 2005 I had already tried to address the problem in my own small way. Based on private-sector experience in management and operational efficiency, my consulting firm helped implement significant improvement to the administrative functions that underpin humanitarian programs at three UN-related organizations: the High Commissioner for Refugees, the International Labour Office, and the International Organization for Migration - all headquartered in Geneva, Switzerland. 

In 2006, the UN GA (General Assembly - made up of 193 member states) mandated the Secretary General to undertake a broad administrative reform program, covering all major functions of the UN across 40 countries, including the massive business of peacekeeping. Fascinated by this opportunity, in 2007 I applied for, and in 2008 accepted, a three-year contract to create the program, and begin modernizing the murky labyrinth of the UN’s accounting, budgeting, payroll, procurement, supply-chain, logistics, human resource and facility management functions. It was a daunting assignment: as I discovered, this 43’700 staff, $18-billion-per-year, paper-guzzling behemoth takes months and sometimes years to perform the simplest of functions. Using post-war practices, thousands of redundant and contradictory policies, and at least two thousand outdated and non-connected information systems, the UN’s bureaucracy is likely the world’s most broken.   

The first hurdle was to show the GA that Umoja could indeed save the organization hundreds of millions of dollars annually, and obtain adequate funding in the middle of a global financial crisis. Even this preamble tested me more than I could have imagined: facing the budgetary and finance bodies of the UN and of the GA is no picnic, and I was grilled every which way for several months in formal committees, in briefing sessions and in dark corridors in between. I was hugely thankful for every ounce of public-speaking experience I had ever gained, going back to Hilton institutions such as the Debating Society, the Ten Club, and many class presentations besides. Actually it was at my prep school Cordwalles that I was first introduced to the dark arts of public debating and the amateur Shakespearian stage, and it’s funny how relevant that was too: the UN is a showcase for real-life irony and melodrama!

In 2009 the $315.8 million I requested were approved, an amount that would cover costs for staff, consultants, premises, computer hardware and software, travel and sundries, for up to five years. Starting with a team of 20 professionals of the 200 required, the many tasks began, the primary example of which was the redesign of all business processes. Hundreds of workshops were conducted all over the world, involving thousands of staff. Every last administrative function across the organization was dissected, analyzed, debated, and eventually reassembled and catalogued. In many cases, the exercise shrank administrative processes from months to minutes - literally. Despite inadequate resources and invasive scrutiny, the team eventually created and documented 318 re-engineered business processes that described the future workings of a new, efficient and effective UN administration in exquisite detail.  

While the work may appear simple in this precis, the daily challenges were immense. In trying to hire staff, procure goods and services, and just get things done, the team was severely hampered by the antediluvian system it sought to change. The major battle was not technical but cultural: we had to persuade senior administrators and clerical staff alike to work in new ways and think differently about the organization and its mission. Again my education and experience served me well, as my leadership, teamwork and organizational skills were tested to the limit. Some lessons learned on the rugby field came in handy too - like recovering from a tackle quickly and then making one, and not panicking when being crushed at the bottom of a collapsed scrum!    

As we progressed nonetheless, the true purpose of Umoja became clear to the organization: far more than simply upgrading administrative procedures, it would bring hitherto unimagined transparency and accountability in a radical shift from tradition. Many people were thrilled, but some were not: in any large bureaucracy, the obscurity of technical and procedural obsolescence is perfect cover for back-room deal-making, which is well ingrained at the UN, but which Umoja stood firmly against.

As a result, creative attempts were made to discredit me and my senior staff, and stall the program, including fabricated accounts of corrupt practices being leaked to auditors and the press. Although cleared of any wrong doing, it wasn’t much fun to have my integrity questioned on the front page of the Sunday papers. Fortunately the slander only steeled the team’s resolve, and we powered through the unpleasantness until the culprits either gave up, or were identified and stopped. 

In such difficult moments, I could picture Raymond Slater, on the stage of the Memorial Hall, making it very clear that leadership and morality are not popularity contests. I wish I had a quote of his, but perhaps Winston Churchill will do: “You have enemies? Good. That means you’ve stood up for something, sometime in your life.” In championing unprecedented change at the UN, I hope I did just that. 

By the end of my contract, the Umoja solution was by and large designed, and the major functions had been prototyped in a brand-new, global computer system. This major milestone was a natural segue-way for leadership change, and my part being complete, I handed the reins to my deputy - a peacekeeping veteran well qualified to take Umoja to the field. Now in phase two, the team is preparing for global deployment that will likely last through 2015. The magnitude of this endeavour cannot be underestimated, and I follow progress with keen interest, still advising from time to time. If the Umoja spirit can be maintained, then it really will help the UN become a more effective tool for a better world, if not by its logic and technology then by its culture of transparency, collaboration and good sense. 

At no other time have I been more grateful for my education than during this massive test. I doubt I could have applied for the job, much less achieved anything, had I not benefited from four critically formative years at Hilton. In addition to my dear parents and family of course, and some excellent friends and mentors along the way, the Hilton community taught me reason and humour, passion and compassion, perseverance and the courage to stand up again when knocked down, belief in both myself and others, and the ability to see right and wrong as clearly as day and night. I had to draw deeply on all these lessons and no doubt would have crumbled without them.

Going forward, I continue to pursue my interest in the improvement of processes, systems and culture in the service of organizations that, in turn, try to do something positive for humanity. I am currently working on an overhaul similar to Umoja at the Inter-American Development Bank in Washington D.C. - another enthralling experience where both my schooling and experience allow me to face new challenges daily.    

In conclusion, I’d like to record my gratitude to the Hilton community, and in particular these good men, who gave me so much, and whose wise words still sound in my ears after 33 years: Raymond Slater, Paul Cannon, Doug Anderson, Gordon Crossley, Mervyn Gray, Ant Lovell, Andy van der Watt, Brian Goodwin, David Pickstone, Ken Franklin, Robert Hofmeyr, Andy Ward, Bill Jarvis and Rob Dickson.

Paul van Essche
Brooklyn, New York
March 2012

Footnote: Umoja is Swahili for Unity

0 Comments

    Scroll down for more...

    Ideas, articles and discussions on life, work, business and consulting.

    Categories

    All

© vE&A 2021
  • Home
  • Industries
  • Services
  • Contact