Should this project be a project?
When a project is really large and long-lived, it’s natural to ask the question of whether the project should be a project.
A project is a unique, transient endeavor, undertaken to achieve planned objectives defined in terms of outcomes.
Transient is the first key word in the definition, meaning “lasting only for a short time; impermanent.” So what’s a short time? Is a 3 year project transient? A 7 year project? A 10 year project?
As a rule of thumb, I like to think of it in terms of the planning horizon of the organisation. If the organisation has a 3 year planning horizon, I think of any project up to 3 years in long as being transient. If the project extends beyond the planning horizon of the organisation, I think it’s worth looking at how to make the endeavor into a non-project.
For a lot of organisations, that will be 3 years. For some capital-intensive organisations, that will be 10 years or even 25 years.
Recommended by LinkedIn
Often the work starts as a project because the organisation does not have the capability of delivering the endeavor through its normal operations. If the work is going to extend beyond the planning horizon of the organisation, it’s worth planning on how to embed the work in the core organisation’s capability rather than keeping it as a project.
Unique is the second key word in the definition, meaning “being the only one of its kind.” If the work is going to be repeated, or there are numerous teams each going to do the same work in a sequence, there’s an argument to say that this work should be a non-project.
Often the work starts as a project because this work is unique, has never been done before and it’s not clear how to do the work. There is experimentation and learning required. If the work is to be repeated, there is value in looking at how to embed this work, once learned, into the core organisation’s capability.
If your project is not unique, or not transient, it’s worth reframing the outcomes of your project. The outcome should be to embed the capability into the organisation such that the project can be disbanded but the work can continue.
Agree with the general ideas here, but the challenge is how we define things like repeated activities. A good and typical example is system upgrades - often a major upgrade will happen on the same system every 2-4 years, and while for simple systems this will be part of BAU, at some level of complexity an upgrade is going to introduce a lot of change, and may differ enough each time that it really has to be a project, but where do you set a line between those two situations?