Archive for the ‘Program’ Category

PostHeaderIcon Program Management Essentials

The world is (slowly) moving toward a shared understanding of the term “program”. There are still widely varying interpretations of project vs program but the most common themes are that programs typically drive significant strategic change, involve the integration and coordination of multiple component projects (and sometimes non-project work too), and focus on outcomes rather than outputs.

Alignment and Integration

Where all these criteria are fulfilled, major problems arise when the program is treated simply as a large project, meaning that planning and oversight is overly tactical to the detriment of the more strategic activity necessary for program success (see Big Programs, Basic Flaws).

Seven Key Elements

Ensuring the program delivers what was intended requires special emphasis given to areas such as strategic alignment, stakeholder management, scope and schedule integration, and benefits planning.

The following major elements of program management help provide appropriate focus:

1 – Business Case

Programs should have a well-articulated justification for the investment, that centers on the estimated costs of implementation and ongoing operations against the anticipated benefits to be gained and offset by the associated risks.  The business case lays out the strategic context of the program and shapes its overall mission and vision. Once approved, the business case provides a point of reference throughout the program (updated as necessary) in order to ensure a continued business rationale for the initiative.

2 – Program Organization

This should comprise a single program manager with unambiguous reporting lines to an executive steering committee (program board) that adequately reflects major stakeholder interests, budgetary control and resourcing. Other advisory committees may be set up to review and guide specific aspects of the program but the board always has ultimate decision-making authority. The program manager should have ready access to an individual program sponsor to resolve issues and obtain guidance not requiring involvement of the other board members.

3 – Stakeholder Alignment

The sheer scale of a program will usually infer involvement of many parties with vested interests. Stakeholder analysis will help to identify individual concerns and parties needing the greatest attention, and subsequently define appropriate response strategies. It also assists in identifying risks associated with (real or perceived) negative outcomes. Properly managing relationships with key stakeholders requires detailed communication plans and, (sometimes forgotten), ensuring adequate time and effort is expended in acting on those plans.

4 – Benefits Realization Plan

Since programs focus on outcomes (vs. projects which focus on outputs), a core element of program setup is the development of a plan that (a) assigns metrics to identified benefits, (b) forecasts when and how those benefits will be realized and (c) maps program deliverables to the benefits which are in turn linked to program objectives. This helps ensure that assumptions in how each benefit will be realized are validated and that all required deliverables are clearly identified.

5 – Program Architecture

The program architecture identifies component projects and the major interfaces between them. A vital aspect of developing the architecture is scope integration, whereby the boundaries of each component are validated to ensure that program objectives can be fulfilled without gaps or overlapping effort among the constituent projects. A high-level program roadmap is an important tool in depicting anticipated sequencing of the projects, target dates for key interfaces, review/approval gates and other milestones, and successive stages of funding.

6 – Integrated Master Schedule

An effective integrated master schedule (IMS) consolidates all component project schedules and links them at the task level with specific, clearly defined interfaces with explicit completion criteria. Depending on the schedule criticality, the use of simulation tools and optimization techniques are often essential tools to properly manage schedule risk and greatly increase credibility of the plan and confidence.  The IMS re-validates the program roadmap and benefits plan and together with an interface tracking log will therefore provide the basis for much of the program manager’s performance monitoring focus during program execution.

7 – Tiered Governance

While project managers within the program will typically track progress against schedule, cost and technical performance, the program manager needs to ensure not only proper roll-up of this data (possibly via a program office) to control overall program progress but also to implement tracking of benefit metrics, as per the benefits realization plan. A well-designed program dashboard reflects both types of metric to provide the board with a holistic view of both the strategic and tactical performance aspects of the program.

PostHeaderIcon Big Programs, Basic Flaws

Flaws cause failures

Conducting and reading through assessments of  various programs highlights how complexity in large scale initiatives can distract and divert focus from doing the basics. Several factors can contribute to this but the end result is the same- an out-of-control program with impacts exacerbated by its sheer size.

For example, recent audits of half a billion dollars worth of government programs in the state of Queensland (AUS) highlight a multitude of major issues resulting in spiraling costs, runaway schedules, unrealized benefits and irate stakeholders.

Its a sobering read; particularly striking, given the nature of the initiatives, is the apparent failure to attend to program management fundamentals. Here are a few summarized findings from the various programs assessed:

No Business Case

An approved business case that clearly identified the benefits to be realised could not be identified. There was no periodic review of the business needs.

Lack of Proper Governance

A program board with adequate stakeholder representation, that had the authority to drive the program forward and to deliver the outcomes and benefits, was not in place since the program began.

No Benefits Management Plan

There was no benefits management plan to consolidate benefits measures for all stakeholders impacted by the program. There was no method of identifying, recording, tracking and reporting demonstrable benefits for the program.

Lack of Integration

From a program perspective, it appeared to be a series of separate projects rather than a coordinated program.

Inadequate Program Metrics

Many of the controls within all three programs were typical of a project management scheme to manage schedules, capabilities and costs. The baselines, recording, monitoring and reporting of benefits did not form part of program documentation.

Program Management Fundamentals

While these findings relate to a few specific programs, they are symptomatic of common issues in program management, namely, that program planning and oversight is often at too tactical a level. Successful program management is founded on the themes of:

  • Strategic Alignment
    Ensuring a clear and ongoing linkage of program objectives and scope with the organization’s strategic objectives
  • Stakeholder Management
    Aligning the expectations and interests of all key stakeholders to promote their ongoing support and ensure success criteria are unanimously understood
  • Program Governance
    Developing an integrated program master-plan that links all component projects both tactically (tasks) and strategically (business goals), implemented within the framework of an unambiguous program organization structure
  • Benefits Management
    Defining anticipated benefits early and mapping them explicitly to program scope and objectives, and subsequently forecasting and tracking their realization.  

Ignoring these core considerations is to disregard the fundamentals of good program management.

PostHeaderIcon Project or Program?

Is my project actually a program? Its a question sometimes asked by project managers unsure of whether their project has the right management approach. Oftentimes it is the lack of a clear distinction between the terms “project” and “program” that causes confusion. While “program” is usually associated with an initiative of larger scale, size alone is an inadequate differentiator – there are plenty of large projects that do not necessarily require program management practices.

The Project-Program Continuum

In reality we cannot easily draw a line between the two since the project-program transition occurs on a continuum, not a discrete point of separation.  Also, this continuum really comprises a number of parameters beyond natural considerations of size and cost – the graphic below may help to clarify:

Mapping an initiative against each of these factors may provide some guidance as to how it should be managed.  The more scores to the right side, the more likely that program planning, control and oversight methods would be appropriate.

Ultimately, a key question to ask is: “Can we obtain better control and better outcomes by managing as a program?”

PostHeaderIcon Interface Definition – The Essentials

PMI gives only scant coverage to interfaces (inter-project or external dependencies) in its Standard for Program Management. However, mis-managed interfaces have the potential to cause days or even weeks of delays and consequently wreak havoc with schedules – and often do.

Effective interface management involves full and complete interface definition. A good list of defining attributes would include the following:

Outputs don't always match input requirements

Outputs don't always match input requirements

  • Interface name
    (unique naming and identification)
  • Interface description
    (nature and purpose of the interface)
  • Output source
    (which sub-project supplies the output)
  • Output owner
    (who is accountable for the output)
  • Input receiver
    (which sub-project is the ‘customer’ for the output)
  • Input owner
    (who is accountable for receiving the input)
  • Completion criteria
    (what the interface ‘looks like’ when its done)
  • Date constraints
    (if applicable)

The completion criteria should be defined as a checklist of requirements from the input owner. He/she will then use these as the basis for full acceptance of the interface as ‘done’ or ‘not done’.