I was recently reading an essay by the evolutionary biologist Richard Dawkins. In it, he observes peoples’ inclination to assign information into discrete ‘pigeon-holes’ (my phrase not his) and calls this the ‘discontinuous mind’. His argument goes:
We’d all agree that a six-foot woman is tall and a five-foot woman is not. Words like ‘tall’ and ‘short’ tempt us to force the world into qualitative classes, but this doesn’t mean that the world is really discontinuously distributed. Were you to tell me that a woman is five feet nine inches tall and ask me to decide whether she should be called tall or not, I’d shrug and say ‘She’s five feet nine, doesn’t that tell you what you need to know?
I think this natural tendency to place people and things into qualitative categories is also prevalent in PPM. So many published guides define projects and programmes as being two entities that are very different and mutually exclusive. It seems that initiatives have to be either one or the other.
It’s not uncommon to see discussions on LinkedIn where people ask the question “what’s the difference between a project and a programme”. Responses tend to fall into two camps. There are those that quote popular guides and say deterministic things like “programmes deliver benefits but projects don’t” and there are those that take a more flexible approach and answer “it depends”.![\"Button\"](\"https://www.projectaccelerator.co.uk/wp-content/uploads/2014/05/Button.png\")
I am very much in the latter camp. While researching the Praxis Framework I compared the definitions of project and programmes from various sources. It struck me that they all revolve around one thing – the complexity of the scope of work.
I believe that if the relationship between outputs and benefits is non-complex (typically one-to-one) then the work can be run as a project, it doesn’t have to be called a programme just because it includes some benefits management. Also, complexity is independent of scale. A programme can have complex interactions between outputs and benefits but be much smaller than a large project that has non-complex scope. So just as ‘tall’ and ‘short’ are simply points on a continuum measured in feet and inches or metres, projects and programmes are just points on a continuum of scope complexity. Choosing whether to govern a piece of work as a project or a programme is not a checkbox exercise, it’s about understanding the nature of the different approaches and choosing which is best in the circumstances. Pick the best approach first. If the project management approach is more suitable then call your work a project, if the programme management approach is more suitable then call it a programme. In reality, the chances are that you will always end up applying elements of both.
Hi
Thank you for useful posts.
I appreciate if you give an example in this regard:
1- relationship between outputs and benefits in non complex and complex work.
2- What is the PPM guides
sincerely yours
Hi Hooman
1. I would say that if a piece of work had a single output (a simplistic example may be to build a garage next to your house) and a single benefit (putting your car in the garage means you pay less for your car insurance) then its scope is non-complex and could be run as a project. If a piece of work had multiple outputs (e.g. a company reorganisation) and multiple benefits (e.g. reduced costs, greater operational flexibility, better communications) then its scope is complex would be run as a programme.
2. I use the term ‘guides’ to refer to publications such as PRINCE2, the PMBoK, ISO21500 etc.
Adrian
The other element which I believe is an essential component is that of stakeholders. Whether it be the culture (as per the recent discussions on LinkedIn) or whether it be as functional or dysfunctional individuals it makes ones work much more complex. An example of this is a ‘simple’ project in that of a funeral. There is a methodology, scope, timeline (albeit brief and intense), cost, quality, risk, communication, procurement etc. The one variable are the stakeholders. The goal of the project will be achieved; yet the outcome may be entirely variable due to the nature of the stakeholders. On one hand they may recommend your services to all and sundry, whilst on the other hand their personal experience (often due to their interaction with stakeholders) may have the opposite effect.
David – There is no doubt that the complexity of stakeholder involvement is a significant issue in managing projects and programmes. However, would you necessarily call something a ‘programme’ just because it has high stakeholder complexity?
I would argue that projects can also have high stakeholder complexity and the area of complexity that has the greatest impact on whether we choose to manage something as a project or a programme is scope.