Programme vs. Project – the right Management Approach avoids Trouble

I am often asked what the difference is between programme vs. project management. In fact, the boundaries are often blurred in practice, and the structures, roles and tasks are not always clearly defined and lived. And that’s where the pitfalls for a program manager to meet stakeholder expectations lie, which is why I’d like to contribute a little bit to illustrate this.

Too complex for project management methods

Programmes are large, complex initiatives that are designed to create, adapt and introduce individual modules of a new outcome in several “sub-projects”. This usually requires large-scale data collection and migration or conversion or installation of existing plants and equipment. Furthermore, it is often necessary to operationally run the system (plant) that is to be introduced in several steps and to (continuously) support or maintain it even after the (incremental) implementations have been completed. In other words, a program comprises several individual components that build on each other and only together result in the ultimately desired benefit. In addition, it generally goes beyond a normal project in terms of dimension and duration.

And there’s another special feature: Programs often start with a vision that no one yet knows how it will become reality. This means that, unlike in projects, there is no description of content and scope that can be worked through, but this must first be developed: Many sub-components must first be conceived and defined within the program in order to be able to be integrated into the common target result at a later date. Also, the duration of a program is not always fixed due to its complexity, and the changes that occur along the way can even influence or even change the goal.

A vivid example is the first moon landing, propagated by J.F. Kennedy in 1962 to be realized in the same decade. What it took (launch pad, launch vehicle, lunar module, life support systems, flight calculation and control, etc.) had to be conceived and invented. All flights in the Apollo program before Apollo 8 were exclusively for the exploration and testing of the system before the actual moon trip. And the program was far from over but continued for further research and improvement.

Maximizing strategic Value

Going “by the book”, program management must create added value that cannot be achieved through the management of the individual components. The tasks lie in particular in the coordination of the components, the consideration of the interfaces with each other and with the (customer) organization, and in ensuring the benefit of the program for the customer. In addition to the operational management of the program, a Program Manager (PgM) must first and foremost feel the pulse of the client and weigh up what best fits into the strategy of their business. His strategic view of benefits fundamentally distinguishes him from the view of a Project Manager (PM), which is primarily characterized by delivery.

The focus on maximizing the (customer) benefit also means that changes are not a “necessary evil” to the originally defined (project) content and scope, but are implicitly foreseen, as the necessity, e.g. in the form of additional components, and/or an additional benefit arise over the lifetime. This also distinguishes PgM from Multi- or Super-PM, where the delivery services and periods are determined at the beginning.

Programme managers need to think different than project managers

Only together and with a view to the benefits that the investment should bring to the customer does such an effort make sense – already in the case of projects, and even more so in the case of programs. This is certainly sometimes a balancing act in the tough everyday business life, because it should also be profitable for the contractor. Whereas in project management two PMs, one from the customer side and one from the supplier side, usually complement each other well, in the program a joint PgM as stakeholder manager, overall benefit maximizer and director is often the better setup.

Moreover, the main stakeholders of both sides sit together often enough and discuss where the journey should go with a view to achieving a common balance of interests. The PgM then becomes an advisor to the Board, responsible for ensuring the benefits and interface coordinator for the program components. It doesn’t make sense to limit yourself to the latter function as a Super/Multi-PM, because then delivery and the desired benefit quickly decouple.

Success is already decided during the Setup

However, this also makes it implicitly clear that the setup of an initiative is already decisive for whether it can be managed correctly or not. Down-sizing programs into large or multi-projects will not be successful any more than trying to bring a program to its objectives with project management tools and thinking. The right management approach from the outset avoids imbalances later on – and if it has already happened, a change can be the means of choice for stabilization. Well, but you just need to understand what makes up a program…

Read more about this topic – click here …