18 May 2011

Projects are not Programs

[Start at the beginning]
In the previous post you saw the natural flow of requirements definition to project scope definition.  The natural flow on from this idea is that the work required is naturally defined by requirements definition.  And that logically budgets and schedules should be able to be derived from requirements definitions.

I believe that this is true.  However there are some caveats.

THe first caveat is that many projects are actually multiple projects in disguise.  Remember that a project is an endeavor to create a unique product or service.  If you have multiple products being constructed within the one project framework then you are really running a program.  We'll deal with that another day.  Today I just want to share with you that despite what your local project management framework says, more than one product or service = program.

And that goes for the combined projects of building a software product and rolling out a business process change.  These are two distinct and discreet projects.  There may be dependencies, but they are two separate bodies of work with two different sets of measurable outcomes.

More caveats tomorrow.


  1. Well said Craig.

    Just calling this out illustrates the gaping hole that is often left when Enterprise Analysis is neglected or forgotten. Many organizations do their analysis at the project level and miss opportunities to uncover dependencies, issues and cross-project work that can cause great problems when identified later.

    Thanks for another short and sweet post that hits the mark.

  2. Yes, and another issue is a lack of consistency in language. We have industry bodies that are a great platform for shared understanding and language.

    A personal frustration I have is when I seen groups re-inventing terminology in their own context with a resultant gap.

    Program v project is one. There re plenty of others.