In recent time I’m frequently asked about the difference between project and programme management. I have already spoken elsewhere about the nature and way of thinking and acting of programs and program managers vs. those of projects and project managers (https://eobz.de/?p=600). Today, therefore, I would like to present an example from my restructuring practice to illustrate this.
Too complex for project management methods
In the following case I was called for an expert judgement on a big, complex initiative which was, in multiple “sub projects”, to develop, customize and implement several modules of a new IT system, involved an extensive data capturing and migration, should operate the system’s subsequent releases, and was planned to overtake the support after the implementation’s completion.
Pretty clear: this was a programme because the single components were interdependently built on each other and lastly would only create the desired benefit for the customer together as a whole. Also it exceeded a normal project by far in terms of dimension and duration. This was bound to go wrong, even if you wanted to manage it with good project management.
Not only deliver, but maximize benefit
“After the books” my programme management (PgM) should create additional value not achievable by managing the single components only. So my tasks in particular were to coordinate the components, focus on the interfaces between each other and with the customer organization, and to ensure the programme’s benefits for the customer were realized.
In program management, this strategic view on benefits for the customer differs fundamentally from the view of a project manager (PM), which is primarily characterized by operational delivery.
In reality the frame conditions for this role image didn’t turn out to be ideal: the key account manager claimed all customer contact for himself, changes to the contract were to be avoided, and from supplier perspective the programme’s focus should have been on ensuring the milestones and margin. So not PgM but multi or super PM?!
Programmes run into distress with normal project management
When I boarded the programme it was already off track: first milestone not met, the customer rejected partial approval though all features were delivered because he claimed insufficient usability and performance. There was nothing about these criteria mentioned in the contract. Additionally there were some new features which the customer desired to get but which the supplier preferred to pick these up after closure of the first contract. Deadlock, hectic at the key account and the legal departments; my predecessor left the programme…
Well, you won’t receive an assignment of responsibility for such a mega initiative if you didn’t show some real good performance and results as a PM before. But that’s insufficient in most cases for a programme if you are not familiar with additional PgM methodology and action to take.
So I needed to convince my client to change the mega project INTO a real programme; to talk with the customer primarily about his benefits and business case, and to anticipate benefit creating changes as being target leading. In return the customer had to accept to be charged for the change requests though he was in the better situation from the current contract perspective.
Programme management only works together
Only together and with an eye to the benefit to be achieved for the customer by the investment the same makes sense – already with projects and even more with programmes. This might be some kind of balancing act in the rough daily business because it needs to be also profitable for the supplier. So, I had to resolve the impasse between the parties (and also the claims that had already been fixed) and lead them back to the common interests in the initiative.
My client’s response to the customer’s wishes to change and expand the scope according to the current state of business needs on the one hand and the development of new available features and modules on the other hand, as well as the customer’s willingness to pay an appropriate fee for this, to allow the required time, and to provide resources, finally broke the knot. Whereas before they had argued about the content of the contract and “spyed” on each other, they were now pulling together again and in the same direction.
Even a program distressed as a project can be recovered
After the recovery the story met its “Happy End”. The programme went through a not totally painless restructuring, but it could be completed for all parties successful.
It took a little longer than initially planned; the supplier’s margin was a little lower. In return the customer paid a little more, is happy with the scope delivered with more quality and features, and the investment was profitable for both sides.
Surely the supplier’s success would have been bigger if the initiative would have been managed as a programme from the start without the kind of bumpy intermediate phase with impartial balance of power, and thus continuously more as partners than as contract opponents.
That’s why you certainly need to know what makes up a programme – and how you manage this right…
Read more about the topic Program Management…