Programme vs. Project – the right Management Approach avoids Trouble

I have been often asked lately, what is the difference between program and project management. Indeed the borders are in practice often become blurred; structures, roles and responsibilities are not always defined well or lived correctly. And exactly here is where the program manager falls into the trap trying to fulfil his stakeholders’ expectations. That’s why I’d like to introduce an example today for visualization.

Too complex for project management methods

In this case I was called to a big, complex initiative, which was to develop, customize and implement the modules of a new IT system, included massive data capturing and migration, involved operating the step by step implemented system until hand-over, and finally supporting it after implementation.

Pretty clear: this was a program. The single components built upon each other and only together would deliver the intended benefits to the customer. Also the dimension and duration exceeded a normal project.

Not only deliver – maximize benefits instead !

Going “by the book” my program management had to allow for added value not achievable by the management of the single components. My responsibilities were: coordinating the components, managing the interfaces between one another and to the customer organization, and ensuring the benefits of the program for the customer.

A program manager (PgM) therefore needs on top of operationally leading the program, to feel the pulse of his customer. His view of the benefits differentiates him fundamentally from a project manager’s (PM) primary focus on delivery.

In reality, the framework environment was not optimal for this setup: the contact to the customer was claimed exclusively by the key account manager, changes to the contract were to be avoided, and the program’s focus, according to the supplier should have been on securing the milestones and margins. So, was this a PgM’s job, or that of a multi- or super-PM?!

With normal project management programmes get into distress

When I came aboard, the program was already troubled: the first milestone was missed, the customer refused approval of the deliverables, because although they contained all features, he felt the usability and performance were insufficient. Nothing in the contract pointed to this. And in the meantime, there were some new features the customer desired, but which the supplier wanted to develop only after closure of the first contract. Stale mate between customer and supplier, stress with the key account and in the legal departments, my predecessor left the program…

You won’t receive responsibility for such a big initiative if you didn’t show real exceptional results as a PM. But this mostly is not sufficient for a program, if not complemented by additional PgM methodology and action.

So I needed to convince my client to change his mega project to a program, mainly talk with the customer about his benefits and business case, and embrace beneficial changes as supporting the goal. The customer needed to accept change requests with cost impact although he was currently in the stronger position.

Programme managers need to think different than project managers

Only together and with a focus on the benefit the investment would give to the customer, does such an effort makes sense – True already with projects, but even more so with programs. In the rough daily business this might sometimes means bridging the gap as the supplier also needs to get profits.

Where in project management often two PMs from customer and supplier side complement one another very well, in program management a joint PgM as stakeholder manager, benefits maximizer and director often is the better approach. Or, as in my program, the key stakeholders of both parties sit together adequately often and negotiate, with regard to a common balance of interests, where the journey should go.

In that case the PgM becomes the board’s consultant, responsible for ensuring the achievement of the benefits, and coordinating the program’s components’ interfaces. It makes no sense to concentrate only on the latter function as a super/multi-PM, because the delivery and intended benefits will quickly drift apart.

Even a programme which is off track as a project can be recovered

The end of the story: The program under went a not completely painless remodelling, but was able to be completed successfully for all parties.

It took a little longer than planned, the supplier’s margin was reduced a bit, the customer is happy with more quality and features, and the investment was beneficial for all participants.

Certainly the supplier’s success would have been bigger if the initiative was managed as a program from the start, without the bumpy intermediary phase with unbalanced powers, and so more as partners than as contract opponents.

Well, you just need to understand what makes up a program…

Read more about this topic – click here …