pm-lotus by Howard Vaughan

Posts Tagged ‘Programs’

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?”

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

• 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’.