Program Management

... things learnt while managing a large infrastructure program

Program Management, a discipline that has been around for a long time (as in 'social programs'), is gaining wider acceptance as IT projects become more complex, inter-related and closer to the actual business processes that they help to run. In other words, projects may fail to deliver their benefit due to no intrinsic failure of the project itself. The project delivers a product, whereas the program delivers the benefit.

Introduction

Program Management is the art of providing a total benefit out of related projects -- at a certain cost and at a specified risk tolerance.

Let us look at an example, the repaving of a road for two kilometres is a discrete project that can be executed by a contractor in return for a certain payment. However, the funds and schedule for that project may have come from a 'City Infrastructure Improvement Program'. Ten individual road may have been fixed, but did the infrastructure of the city actually improve? Was the benefit of 'infrastructure improvement' actually realized? How can it be measured?

Why Programs?

Here, we can make a rebuttable assumption that programs are initiated due to one of these three reasons: a vision, a business need, or regulatory compliance. A vision can be justified as a business case, but it remains a vision due its specificity. A town aiming to become the 'tourist capital' of a state is a vision - it could have just as easily made a business case for becoming a 'festival capital' or an 'education capital'. A question I am fond of presenting is: why should we build Ugly Bridge over Muddy River? The King thinks another bridge will look pretty, or the capacity of the current bridge has already been exceeded, or the public safety authority is about to condemn it because it is not safe. Each of these reasons belongs to each of the categories: vision, need, or regulation.

Isn't this just Business as Usual?

Well, if program management is sounding almost like running a business, it may well be. Let me present another hypothesis: every transition in the state of a business is a program. A static business that is not growing or shrinking, and where every day is BAU (business as usual), is not in need of a program. As soon as it embarks on growing its customer base (going international) or shrinking (downsizing), a bunch of inter-related projects appear out of nowhere. What about translation, re-training, customer service levels, IT systems etc. Now, all of these projects may be individually successful, but the benefit of international expansion or downsizing may never be realized. This is where Program Management comes in.

So, Program Management is part of Business Transition Management or Change Management.

Quite a few companies have adopted Program Management across their organizations. A recently launched bank (that used to be my client) have based their entire organizational structure under the umbrella of the Program Management Office. The structured and rigorous methodologies of Program Management drove their launch, their expansion, and the transition of their core processes to different types of financial service offerings.

Methodologies

There are two main methodologies that are widely followed:

1. PMI PgMP Credential Exam Methodology builds on PMI's PMBOK-based methodology of phases, planning and control, and naturally lends itself more to quantifiable change management (need and regulation drivers).
2. OGC Managing Successful Programmes builds on the PRINCE2 document-centric methodology of management by exception. Its planning approach is iterative and more conducive to programs where the start is just a one-sentence mission statement (vision driver).

The following roles and responsibilities are common to both, and to others as well:

• Sponsor - to put it blungly, the person who may lose their job if the benefit is not realized
• Advisory Board - members with insight into various business areas affected
• Program Manager - the executor of the program with an eye on projects and benefits
• Change Co-ordinator - facilitates the adoption of the changed products and processes

Program Management in IT

While Program Management is a generic discipline, its recent emergence has fulfilled a growing need. Around the turn of the century, projects building or improving modern complex and distributed computer systems were experiencing a very high rate of failure. The situation has improved somewhat in the last few years, primarily due to a focus on infrastructure and software architecture, solid program and project management, Internet-enabled information sharing, the open-source movement, and iterative software development methodologies. Program Management for software systems is particularly useful over multiple systems, disparate geographies and disjointed business units.

With distributed systems, especially those based on, or transitioning to, SOA (Service-Oriented Architecture), it is now possible for business process applications to be the composition and orchestration of discrete services, put together by relatively non-technical people. This business agility and flexibility comes at the cost of inter-dependent services and systems that form a grid-like virtual business world that is perhaps equal in nuance to the real business processes that it drives. The responsiveness of systems to business change goes the other way too: the business is now ulta-sensitive to change in systems. Implementing and changing such systems cannot be big-bang, and cannot be simple projects, they need to be programs.