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

Give a man a fish and he’ll eat for a day, teach him how to fish and he will eat forever.
Chinese Proverb

Successful programs don’t just coordinate local roll-out projects. They provide a platform for the network of relationships that is built during each roll-out. It’s called Return On Relationships.

In the previous article I have discussed the strategic level and I argued that we need to plan for social architecture in a large scale program. In this article I will discuss the tactical level and zoom in how programs should be designed to allow for co-creation.

Once again a long article, so buckle-up. This topic is simply too important to cover in half an article.

The Anatomy of a Fiasco

But first things first: before we jump to tactical conclusions, let’s have a look at the problem from the tactical point of view: the inability to build a social architecture during a large scale program will result in a situation where there is no community that the organization can count on.

For example, in the majority of all ERP programs we find that Business Representatives do not belong to a community when the project is over. Here is how that typically goes:

Stage 1 – Long before the project: the program is heard of and sometimes there is an update in the quarterly newsletter of the CEO. Other than that there are no expectations. People take on a wait-and-see attitude, not knowing that there are a lot of design issues on the table that will impact their work. But the program has a budget and a calendar to perform against, so why should sites be represented that are currently not in scope?

Stage 2 – Right before the project: People are nominated as Business Representative. A declaration that will change their life for as long as the project will last. They have no clue what they have committed to, but one thing is certain: they have jumped and now they will have to swim.

Stage 3 – During the Project: Business Representatives work very intensively with real people: the experts onsite, the central program team and the support team. This phase is very motivating because there is a sense of purpose (representing their department in the program) and a sense of progress (their voice is heard and their participation makes a difference).

Stage 4 – Right after the project: the local deployment of the expert team ends as soon as the operations have stabilized in the new mode (a new system, a new way of working, etc.). Sure enough, there are metrics for knowing when it is time for the expert team to go. The Business Representatives stay in charge for a short period and they make a difference in the battle to get ‘back to normal’. Thanks to the knowledge they have built up and the relationships they have within the network of program experts they are valuable troubleshooters. Most of the times they also have super-access rights to solve problems or to unblock certain situations.

But their status is short-lived, like the superhero in a videogame possessing supernatural powers until the magic elixir he drank has stops working.

Stage 5 – Long after the project: “Business what?!”,… the term Business Representative is forgotten as soon as it came. After they returned to their jobs, they were still asked to solve problems for their colleagues, but they were no longer capable of solving them: their super-access to the system has been withdrawn and on top of that all the relationships they have built up with the experts, the program team and the support team are reduced to submitting a ticket in an anonymous ticketing system.

Paradise Lost

So far for purpose and progress. Time and again organizational change programs invest lots of energy in the development and commitment of great Business Representatives. And time and again they miss out on the opportunity to connect these teams to a community of BPE’s and BPA’s.

Here is an example of the local tragedy: last week I met a Business Representative who just got back to his former job after the project had stabilized.  Returning to his job means that he does his job as he is supposed to – but the “exceptional” part that we saw during the project is now buried until another personally engaging project comes along and gives him the same sense of belonging to something bigger than his nine-to-five job.

In the mean time, have a look at what happens centrally: major programs are full of overworked and burned-out people on the central level. They are trapped in the illusion that they need to know and do everything themselves. Next, they are worn out by the resistance they get from people as they implement enhancements, patches, upgrades etc. without having involved the target audience upfront.

By cutting the relationships between the program and its projects after each implementation a double spiral of negative effects is set in motion:

1. Overexposure of the central program team. They are overworked and saturated. This results in a loss of talent as people will either hide or resign;
2. Underexposure of the Business Representatives as they return to their jobs. This results in a loss of talent as people will either return to a smaller version of themselves of try their luck elsewhere.

Don’t Just Coordinate!

In order to inverse this negative spiral, let’s have a look at what sets successful programs apart from unsuccessful programs. The short version: Successful programs take care of the 3 C’s.

The three C’s is a concept that I borrowed from Charles Handy. In his 1994 book The Empty Raincoat, Charles Handy introduces the three C’s of learning. They are conceptualizing, coordinating, and consolidating. according to Handy they are the essential mechanisms underlying personal, organizational and societal learning.

Successful programs don’t just coordinate their projects well – the second C, they also take care of their conceptualization – the first C, and a consolidation after the project. This is what sets a social architectures apart from a one time effort: they are learning organizations in the first place.

The only way to activate all of the three C’s is by building a platform for the program’s community that acts as a membrane, or a matrix capable of integrating what it learned from previous projects into future roll-outs. The result to look for in this case is the return on relationships.

The Three C’s and the Program Lifecycle

Take few minutes to look at the below schedule. It represents the typical roadmap of a program, starting with the Program Initiation and ending with the Benefits Realization. Each step on the left side of the drawing finds its equivalent measuring point on the righthand side. For example: the Program Setup is done in order to ensure a Return On Investment; or the act of Testing is done in order to obtain a Flawless System.

Next, focus on the red dotted line I have drawn. Below that line are all the actions that happen within the cycle of a single roll-out. This is the cycle that is repeated every time a local project kicks-off. This is the second C: Coordination.

Regular readers of this blog will note that this shape resembles the flipped triangle that I have introduced in an earlier piece on learning. Above the red line is the Why level of a program and below the red line is the What & How Level of a program; the part that is repeated with each roll-out.

Finally, the three C’s (Conceptualize, Coordinate, Consolidate) are also drawn on this schedule. You will note that the first C (Conceptualize) and the third C (Consolidate) are the ones linking the Why of a program to the What and How. On a tactical level this is the essence of social architecture: conceiving the project roll-out from within the program community and consolidating it back into the program community.

The Program Community

Crossing the red dotted line requires you plan for a community before you even start the program (conceptualize). Co-creation is the key word here, and you can only get there by building a platform for the community of Business Representatives and program experts.

I have shown a blueprint of this community in the previous article and you will find it once again below. The point I want to emphasize as we are tackling the tactical level is that this community already exists.

This is why almost every attempt to “create” a community will not work: the failure of acknowledging a community (i.e.: a network of relationships) that already exists. Instead of trying to create a community from scratch against all odds, we should focus on being a platform.

How to be a Platform

Once we have recovered from the shock that we should be a platform instead of creating a community, it is time for action. Action in this case starts with a declaration of the program’s sponsor. The sponsor is the one and only person having the power to declare a community into existence. She endorses and honors the community in the first place.

Next it is time for the program to start being the platform by honoring and recognizing the community:

• ask them for help;
• ask for advice;
• present them the next big challenge and ask for their input;
• give them a stake in the decision process;
• grant them extra power, not only as a trouble shooter, but also as a co-creator;
• Above all, listen to them with your ears, and not with a ticketing system (because, let’s be honest, would you give the very best of yourself to a ticketing system or to a community that matters for you?).

Turning the Tide

The choice really comes down to this: will you take this challenge from zero with a new project team or will you honor the community that is already there? Honoring the community is tapping into their talent and getting a return on relationships.

Honoring the community also means working on retention without having to throw in a bonus or a reward. There is no bigger reward than honoring the talent that is already there. This is ultimately more rewarding for the Business Representatives than financial rewards. Psychologists call this intrinsic motivation: a sense of progress, a sense of contribution and a sense of belonging to something bigger than you are capable of by yourself.

Then – and only then – will people be sparked and make use of the platform you are providing: when their talent is being honored. This results in dynamics that inverse the double spiral of negative effects:

1. Overexposure of the central program team is balanced out in the community;
2. Underexposure of the Business Representatives disappears as we honor them by making use of the community.

Sure enough, this requires a certain level of maturity from the community leaders – the BPE’s and the BPA’s. In the next and final article of this series I will zoom in on this aspect when I cover the operational level.