How to Belong to the 30% Successful Projects (Part 1)
published by Luc Galoppin, on 02/01/2011
The number one reason why complex organizational change programs fail is not a lack of intelligence or hard work. There is a structural flaw in their design: the lack of social architecture.
By now we all know that 70% of the organizational change programs fail. But what can we do to prevent this from happening? What does it take to belong to the other 30%? In this article I will treat this question at the strategic level of organizational change. Hang on, because this is a long article. (but hey – we are talking big programs, so the potential savings are huge!)
Small Glossary: Operations, Projects & Programs
Before we start, let’s first make sure we have a shared understanding of the words ‘operations‘, ‘project‘ and ‘program‘. Bear with me because the differences are important in order to see what success looks like on the strategic level.
A functional organization cannot change its own ways of working because it is bound to execute its day-to-day operations. People are focused on “getting the day-to-day work done;” e. g., taking orders, preparing deliveries, production, collecting money, etc. They don’t have the time to question in depth the ways of working, or to come up with new ways of working to improve efficiency.
Projects are the most suitable vehicles of change, as they are temporary undertakings with specific objectives. To manage a project is to manage the movement from one state to another. Projects are an investment made by the organization in order to realize the change.
Organizational change projects differ from most other projects because they threaten operations in their current form. That is why a project approach is necessary but not sufficient. To succeed with such a heavyweight change, we will need a program.
A program provides a framework in which the delivery of benefits can be managed and followed up. This requires a management layer above project management, focusing on:
A program is successful when it realizes the benefits that the organization identified. But because projects are the building blocks of the program, if delivery fails at the project level, the overall program will eventually fail.
Program & Project Mechanics
Organizational change programs that are rolled out in multinational companies typically follow a roadmap that starts with a pilot project and then a multitude of roll-out projects. Managing such a program requires a complex organization on multiple levels:
On the program level you will need a governance structure that can cater for three different paces:
I can hear you sigh “what a mess”… And that’s not all, because the duration of some programs, like ERP implementations, may take up to 10 years or more. In these programs the following functions need to ensure sound governance:
On the project level you will need a local organization for every roll-out. Best practices show that such teams are composed of 50% experts who go from roll-out to roll-out, and 50% local people who represent their department on the level of the project. The latter are Business Representatives. For example: if the roll-out impacts a specific site in a certain country, the warehouse responsible of that site will most likely be the business representative for warehousing.
To see how a program and its projects link together during a roll-out have a look at the below example. The sample organization chart of this program and its project assume the de roll-out of an organizational change that heavily impacts three domains: Warehouse Management, Production and Finance.
As you can see, there is nothing wrong with this picture. Through the appointment of local Business Responsibles for each domain the local organization is represented during all the phases of the project. Moreover, the local project structure mirrors the global project structure. This is a solid design for roll-out, and it caters for the best results: the program provides the infrastructure and acts as a platform for the project to reach its objectives.
So far the mechanical part; now let’s focus on the chemistry. From a human point of view, the most important thing on this drawing are not the boxes, but everything that happens in the white space and the dotted lines between them.
It’s always exciting witness the on-boarding of Business Representatives to the project team – not fully grasping what it is they are committing to. Business Representative are the linchpins who are the first ones to dive deep into the new territory of the program. In most programs these people are cherry-picked from the business because:
This goes without saying that some people drop out of this challenge, while others flourish. What’s more, the Business Representatives who go through this experience are exposed to an intensive project experience where they have real impact and influence of the future of ways of working of their organization.
The learning curve of a Business Representative during the phases of a project-roll-out is very steep and it is always a fantastic experience to witness them outgrowing their own potential in such a short time. They learn, they connect, they grow.
Program Pitfalls: Tunnel Vision
Managing complex programs is not a mathematical exercise; it’s a balancing act. Programs balance between the the initial design as it was conceived in the beginning of the program on the one hand, and the local specificities and reactions to the prototype on the other hand.
Half of the requests for enhancements that come from the local roll-outs are crap and the other half represent a real improvement for the program. The hardest part is figuring out which half is good half. This is the real challenge of managing organizational change programs: when should we say ‘yes’ and when should we say ‘no’ to a local request for enhancing the prototype?
Have a look at how a program typically operates in the long run – that is: a multitude of projects, most of them rolled-out in parallel. The example in the drawing builds on the above mentioned situation of a change program with a scope of Warehouse Management, Production and Finance. Let’s assume that the program roadmap deploys from country to country: last year Germany has been involved, at present the focus is on Italy, and France is in the scope of next year.
Here is what typically happens: the pressure on time, budget and standards is so high that the program creates a tunnel vision and only focuses on the present project (in this case: Italy). The previous project is stabilized by pushing every request or complaint to the 1st, 2nd and 3rd lines of the support organization.
For a country that was involved in an earlier roll-out, there are no links anymore with last year’s operating structure: the German Business Representatives did their job; they were congratulated and applauded, and now it is time to move on. BIG MISTAKE…
The Talent Massacre
Have a look at this program lifecyle from a human perspective and you will see a perverse effect on the learning curve I mentioned earlier. To keep it simple I will build further on the above example.
The pattern is quite clear and it happens over and over: first, we ignore talent, then we grow it on steroids, and then we waste it. The results of this mechanism are devastating at three levels:
This is the real reason why large scale organizational change programs do not return the benefits they intended in the beginning: the failure to design a social architecture – an ecosystem to sustain the program – in the first place; and the failure to leverage learnings from roll-out to roll-out in the second place.
Social Architecture: A Talent Ecosystem
Although this looks like a complex stinking problem, the solution is fairly straightforward and simple. You just need to stay with the problem long enough to discover that the solution is already there. We need to change the way we look at things and reframe the question: the one thing to focus on is sustainability of the program in the long run.
Instead of copying the talent massacre pattern that I describe above, the focus should be on what ecosystem is needed before during and after a project-roll-out in order to make sure the benefits of our program get realized and sustained? In an earlier post on how consultants should raise the bar for their profession I mentioned the need to cater for a social architecture. The point here is to focus on: What will people be creating when you are gone?
Social Architecture is about building a platform in order to sustain the change. The optimal platform turns out to be the community of Business Representatives, as illustrated in the example below:
The best part is that this community of Business Representatives exists already. The only thing they lack is a platform that is facilitated by a tribe leader: the BPO or the BPA. in order to make this community work, there are some requirements:
In the next article I will dive deeper into the fabric of a social architecture and zoom in on what this means in practice.