When is a Project not a Project?

Share This:

Successful large scale organisational change demands excellent governance – part of which means understanding the difference between a Programme & a Project

Organisations generally get hung up on whether or not a specific change initiative is defined as a project or as a programme. Whilst there are important and notable differences the specific definition is probably not important. It’s the specific size and scale of the initiative that should act as an indicator, and issues such as span of control and governance are both vital considerations.  Projects and programmes have many characteristics in common, for instance they are both Projecttemporary management constructs which will be dissolved once they’ve delivered. They are both time delimited and they both have a distinct beginning, a middle and an end.  One of the key differentiators is that essentially projects deliver tangible ‘products’, i.e. a piece of software, a new infrastructure or a new business process, whereas programme deliver strategic outcomes.

Traditionally it has been much easier to measure the success of a project because the expected tangible product is generally well defined and is ‘SMART’ (Specific, Measurable, Achievable, Relevant and Time Bound). More often than not organisations establish programmes from the ‘bottom up’, as logical (or illogical) groupings of projects.  In taking this approach leaders seem to expect that the sum of the products delivered by the various projects, and their associated ‘SMARTS’, roll up a level and make coherent sense. Sadly this is not the case, because large scale programmes of change have be designed and grouped from the ‘top down’, not the bottom up. Programmes absolutely need their own defined aims and objectives which are more than the sum parts of the projects contained within them.

Whilst both projects and programmes drive and facilitate change it is helpful to view a programme as being made up of a number of related and connected change initiatives which may be viewed as projects, but sometimes thought of as workstreams.  Programmes are understood to deliver ‘outcomes’ which are more strategic in nature, rather than ‘products’ as is the case with projects. Examples outcomes might be a new service, a new organisational structure or a set of tangible business benefits.

It’s fair to say that specific definitions are probably not as important as common understanding within the organisation, and it’s been my own experience over many years of leading and managing change initiatives that ensuring that everyone is talking the same language is essential. So when trying to understand how to structure large scale business change it’s worth bearing the following in mind:

  1. The governance of programmes is aimed at facilitating the delivery of strategic outcomes and meeting business objectives. It stands to reason then that a programme of change should be actively sponsored, governed and sponsored at the highest levels within the organisation.
  2. Projects should have their own project boards with stakeholders from the business included as appropriate. Generally speaking workstreams should not require management boards and are governed internally by the project.
  3. The organisation should agree on a specific taxonomy for change initiatives. I have found that the most common and understandable convention is as follows:

WBS

 

Figure 1 – Example Project & Programme Hierarchy & Taxonomy

Project & Programme Hierarchy & Taxonomy

Portfolio – A portfolio is made up of a number of programmes and/or projects.  Portfolio management is a strategic function concerned with effective investment and the tracking and realisation of benefits. Typically portfolios are managed centrally in the Portfolio Management Office.

Programme – The ultimate goal of a programme is to realise outcomes and benefits which are of strategic relevance. Programmes are a temporary organisational structure which are collapsed once outcomes and benefits are realised.  Outcomes and benefits are owned by business sponsors who are empowered to steer the programme. A programme consists of a number of projects.  Programmes are led by programme managers, who may report to a programme director or direct into a programme sponsor. The programme may be supported by a programme management office (PMO). For large programmes the Programme manager is generally full time.

Project – A project is usually of shorter duration than a programme and will be focussed on the creation of a set of specific deliverables within agreed cost, time and quality parameters. A project is led by a project manager who, if the project is part of a wider programme, reports into a programme manager. The project may be supported by a PMO. Depending on the size and complexity of the project the project manager may not be full time, and an individual could project manage two or more projects.  Typical timespan is months.

Workstream – A project is made up of a number of workstreams. The workstreams, when taken together, constitute the delivery mechanism for the project deliverables. A workstreams is led by a workstream lead, who is responsible for the progress and status reporting of the workstream. A workstream lead could act as a Subject Matter Expert (SME) within the workstream. An SME is responsible for the development of deliverables.  Typical timespan is months.

Workpackage – A workstream consists of a series of workpackages which are aimed at the development of specific deliverables. Workpackages characteristics included a defined start and end date, typically the end date being associated with a deliverable and /or a milestone. Typical timespan is weeks.

Activity – A workpackage can be made up of a number of activities, each of which can have a series of associated tasks, driven by a task list. Typical timespan is weeks/days

Tasks – The lowest level in terms of work management. Very specific in terms of duration, resource and output.  Typical timespan– days/hours.

Milestones – Milestones represent very specific moments in time (i.e. zero days).  For the purpose of control and progress monitoring each workstream should aim to detail at least one milestone per week. Milestones should be:

  1. Understandable – and should limit technical language;
  2. Owned/Sponsored – whilst the whole team will be involved in meeting a milestone, for example in producing a deliverable which feeds it, the milestone should have a named individual responsible for ‘signing off’/recognising that is has been met, and
  3. Logical & Significant – can be linked to the end of a stage, or a significant and meaningful achievement and should convey the progress made across the whole programme/project/ workstream.

Milestone Levels

Level 0 – The highest level milestones, agreed and ‘owned’ by the business;

Level 1 – Programme Level, typically ‘owned’ by Programme Director/Programme Manager;

Level 2 – Project Level, typically ‘owned’ by the project manager;

Level 3 – Workstream (sub project level), ‘owned’ by workstream lead;

PW

Post by Pete Wilson

Pete has worked in the technology and business change space for over 30 years. He's worked globally for large public sector and governmental bodies and for large private sector multinationals across numerous industry sectors.

Leave a Reply

Your email address will not be published. Required fields are marked *