How to Belong to the 30% Successful Projects (Part 1)

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:

• Selecting the required set of projects, each of them delivering outcomes needed to achieve identified benefits (end state).
• Defining these projects.
• Providing an infrastructure where projects can be run successfully.

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:

1. Divisions that have already switched to the future state,
2. Those that are in the middle of a roll-out (they are in project-mode), and
3. Those that have not yet been included into the program.

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:

• Program management and a network of BPO’s (Business Process Owners – functional) and BPA’s (Business Process Architects – technical architects in the case of technology driven changes) for each domain of expertise. For example, if you are rolling out a global ERP system and your warehouse system is in scope, you will need a global warehousing responsible to make functional decisions (i.e: the BPO) and one making the technical decisions (i.e.: the BPA).
• A support organization ensures the operations of the new organization (depending on the program, this may include 1st, 2nd and 3rd level support, a Change Advisory Board, a training organization, etc…)

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.

Project Chemistry

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:

• they have a deep understanding of what it takes to run their part of the business;
• they have the strength and intelligence to perform on the challenging deadlines and deliverables of a global program;
• they have the resilience to absorb new knowledge, work their way through and become an expert in no time

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.

• Before the program was rolled out in Italy, the local people were curiously anticipating the benefits and the requirements: this sparked their motivation to find out more. However, there was no initiative they could subscribe to; no chance to get involved upfront;
• When the moment was finally there and they received full attention, space and budget from the program, things really started moving. People got involved and thanks to some experienced project experts, project managers and high-potential Business Representatives the roll-out becomes a success;
• When the program moves on to France (the next stop on the program roadmap) all the attention is gone and the former Business Representatives are no longer valid and meaningful. Their impact is not endorsed and their talent and lessons learned all of a sudden seem to be meaningless

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:

• Talent Management: large scale organizational change programs are a great way to find and grow talent in the organization, but lacking a proper ecosystem to challenge and grow this talent is like dumping the love of your life after a one-night-stand;
• Benefits Realization: the program is not over until the benefits are realized. However, shortsightedness leads us to believe that optimizing every single project suffices to realize the benefits of the full program. Nothing is further from the truth: installing the change in each roll-out without leveraging what all other roll-outs learned in the mean time is only half the work.
• Program Exhaustion: It is clear that a top-structure of BPO’s and BPA’s cannot know all the answers by themselves. But lacking a community of knowledge – or rather: being blind to it – burns them out.

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:

• The community leader (i.e. the BPO/BPA) needs the maturity and vulnerability to tap into the community as often as possible;
• It is important to realize that community leadership does not work through authority. It is tribal in essence; not hierarchical;
• It is a layer on top of your organizational structure, but not a formal one. Rather than fitting into a job description and being obliged to occupy a position, membership of a community is considered a privilege to belong to a club;
• It is not restricted to the short lifespan of a local project, but rather it lasts until all the benefits are realized;
• It leverages knowledge, both horizontally (from project to project) and vertically (between program and projects)

In the next article I will dive deeper into the fabric of a social architecture and zoom in on what this means in practice.