Are most projects single phase or multiple phases?
We ask this question because we often hear: “I am working on an IT project” or “I am working on a construction project”. Is there such thing?
To properly answer this question, we have to clarify the definition of a project. Even more, we have to understand the context. This is critical since not everything we call a “project” is a project; it could be only a phase or a sub-project.
First, what is the definition of a project?
Most of us probably subscribe to a definition of a project that says it is temporary, meaning a beginning and end (to distinguish it from routine – repeated operations) and unique output.
- Well, life has a beginning and an end – but life is not a project.
- A task has a beginning and end, but a task is not a project, although some might say so.
- An activity has a beginning and end, but it is not a project.
- Finally, a phase or stage has beginning and end but it is not a project.
Then how do we make the distinction? Here we have to consider the second part of the definition, the “unique” part. This is very ambiguous and can be debated since we can repeat the same comments that we listed in the above bullets about unique.
Then, how do we differentiate? What is implied (not stated) in references such as the PMBOK® Guide is that the project has to deliver value to the organization. There have to be benefits that we realize upon project completion. Recent project management publications are starting to talk about this point more and more.
In other words, we see the PMBOK® Guide definition of a project is incomplete, although many will not agree with this statement. See the next two sections.
Second, Project Owner Perspective
If we consider the project owner perspective, then the PMBOK® Guide definition of a project is definitely incomplete.
Who is the project owner?
The project owner is the organization that is paying for the project, will own its product, operate or use the output of the project, and realize the outcome (benefits realization) of the project.
For these organizations, it is hard to think of a single phase project. We cannot think of one example, although they may exist. In these organizations, projects have a life cycle that span a period of time from start to end. Some might have a different view of the start and end but regardless. In all cases, there are many phases or stages of a given project.
- A company wants to launch a new application to document lessons learned. There has to be a concept phase (to clarify the business case, feasibility, and gain authorization. Next there has to be a stage to define the project requirements, then the project management plan, then a detailed plan, leading to implementation, getting ready for operations, testing, and closure. In this project, there is an IT component to developing the application. Some call this an IT project – but it is not. It is a business project that has an IT component. IT work is happening in a couple of stages (+/-).
- A hospital project also requires many components, stages, and phases, including the construction of the hospital. Is this a construction project? NO, it is a “business” project with many stages where construction is only a stage. PMI does not help here (as usual) when they publish a supplement to the PMBOK® Guide calling it Construction Projects.
There are many examples like this. Therefore, unless a project is driven by IT, as an IT security project, there are no IT projects. For the IT security project, it is a business project (driven by IT).
The following is an image of a standard project life cycle with multiple phases and stages.
Third, Service Provider Perspective
Now, let us shift the perspective. Since many readers might be working for a service provider, like an IT vendor or construction company. Then these people have IT or Construction projects. Further, their projects are single phase projects. Well, maybe. Their projects are a single phase from the project owner perspective. But, are they single phase projects from their own company perspectives?
To read more, refer to this article from the past.
We are not trying to be the terminology police here. People and organizations can do what they see best and use a terminology that they are comfortable with. What we post here is to try to have clarity, so when we discuss project management matters, at least we have a basis.
Why this conclusion?
Because quite often, when we pose questions in these blogs on in online groups – many respond from their own perspective, which is perfectly acceptable. However, it is important to understand the context before answering. Here I am reminded of something that was posted online. “Would you jump from an airplane?” Think about this for a minute, would you jump?
How about if the plane is on the ground?
It is critical to understand the context.
Until next time