At some point in your career you will be running a project that for some strange reason does not behave like a project. It has too many dependencies, its duration seems too long & every time you resolve one part of it another part changes. Most of us manage that work as a project anyway, because it is what we know & what the organisation has asked for. But then we end up wondering why the usual tools are not working & why we are getting increasingly stressed & drawn into unnecessary detail. More often than not the reason is that what you have been given is a programme rather than a project.
The problem is that projects and programmes exist for very different reasons
- A project delivers a thing - a defined output with a start, an end and a scope. You have succeeded when you deliver it on time, on budget and to scope.
- A programme delivers a change. It is a group of related projects, coordinated together, which only create value when they come together. You have only succeeded when the benefit is realised rather than when the last project ends.
Running a programme as though it were a project can accidentally set you up to fail. You can tell a project should have been a programme when the project ends & it looks like a success on paper…but then a year later very little has actually changed, because no one focused on delivering the benefits of the programme.
So how do you know when the work in front of you needs to be run as a programme? Try asking the following questions
- Do several related projects only deliver their value when combined rather than individually?
- Is there a shared benefit that no single project can deliver on its own?
- Do the projects have complicated interdependencies that need coordinating centrally?
- Will the change be delivered in stages & over an extended period?
If the answer is ‘yes’ to 2 or more of those, then you probably need the structure a programme brings: a clear picture of the end state, someone accountable for the benefit after handover & planned coordination between the projects.
The real problem is that running a programme as though it were a project is exhausting. As the Project Manager, you end up holding all of the interdependencies in your own head because there is no structure holding them anywhere else. That makes you the single point of failure, and you carry the stress of coordination that others might not even see.
At the start of any project, we should be asking – is this a project, or is it part of a wider programme? Getting this right will help determine the right governance, ownership & structure that the work needs. So if something on your desk feels too big and overcomplicated for the tools you are using, it is worth asking whether you are really running a project at all, or whether this is actually part of a programme & needs to systems that correspond.