PROJECT LIFECYCLES

DEMYSTIFIED!

DO NOT GET CONFUSED BETWEEN THE DIFFERENT

LIFECYCLE CONCEPTS

WHICH PROJECT LIFECYCLE ARE

YOU USING?

Are you using a project lifecycle or a project management lifecycle? Of course not, you probably are using a project delivery lifecycle! Or is it more an SDLC, a software delivery life cycle? Or perhaps, just a plain project delivery lifecycle, or you use a product lifecycle, or… … you don’t use any project lifecycle because you are working agile and believe that agile projects cannot have linear project lifecycles. Or just like me, you sometimes are just getting confused with all this different lifecycles and their terminology! In this article I like to demystify the concept of a project lifecycle and to explain you why it might be worthwhile to use a project lifecycle as part of your project management activities.

WHAT DOES THE PMBOK TELL US?

The Project Management Body of Knowledge guide confronts us in chapter 1, on page 19 with the project life cycle concept. Literally:

“a project lifecycle is the series of phases that a

project passes through from its start to its

completion.”

Taking that definition into account, it seems clear that the project life cycle relates to the timeline of the project. Indeed, its purpose is to structure the project’s timeline into smaller periods of time in which similar and related work will be planned for. See a project lifecycle of a project a little bit as the lifecycle of us, humans. We also have different stages in life with each stage, having different characteristics and different ways how we act and behave. Think here about: the baby stage, childhood, teenager, young adult, etc. We also know that we have to approach the human being in each stage of life differently. You don’t want to treat a teenager as a baby. You probably will agree with me on that!

FIVE REASONS WHY YOU WOULD

USE A PROJECT LIFECYCLE

The answer is in first instance quite easy: above all you implement a project lifecycle to manage complexity! An important technique in managing complexity, is a simple as: make the problem smaller. Decomposing the project’s timeline into smaller periods of time, makes it less complex. Actually, using a project lifecycle to “make smaller” doesn't make the project as such less complex, it makes it more manageable. A second reason is to have a guideline to align our project management approach and style to the stage in which our project is in. Remember the fact that a teenager does not want to be treated as a baby… The same principle is valid for the stages in project management. You will take different approaches for the realization stage and the start-up stage of your project for example. A third reason why you should use a project management lifecycle is to bring structure. Instead of having one blurry project, you already start to structuring its timeline with a project management lifecycle. And we all know, structure brings calmness and rest, because it reduces chaos and brings order for the work to be done. A fourth reason is to reduce the likelihood of having the student syndrome disease on your project. If you want to know more about the student syndrome and other possible project diseases, I can recommend you this video in my Youtube channel “About Project Management”. A fifth and important reason to use a project management lifecycle is to enable project management controls. The end of a phase can, after all, be arranged in such way that the work and deliverables of the phase are reviewed and approved. It is the typical application of the "validate scope" process. You could even organize formal sequencing of phases by organizing go/nogo control points between the phases, organized via Project Steering Groups.

DEMYSTIFYING THE CONFUSION

It seems there are a lot of different lifecycles. And how many would you need to use on your project, is a very valid question. But basically there is only one project lifecycle on every project, and let’s keep calling that our project lifecycle. Note that I am not using something else, like project management lifecycle or project delivery lifecycle, for now. However, this overall project lifecycle has probably two distinct levels. The first level is called the project management lifecycle and has the sole purpose to structure the project’s timeline into a small number of distinct blocks. It is quite generic and can be used on all kinds of projects, whatever their intended result, or project type is. Such a small block is according to the Project Management Institute (PMI) a project phase. A project phase is in the PMBOK-guide defined on page 20 in chapter 1, as:

“a collection of logically related project activities

that culminates in the completion of one or

more deliverables.”

The second level, below the project management lifecycle, and hopefully aligned with it as much as possible, is the project delivery lifecycle. The purpose of the project delivery lifecycle is to structure the timeline of the work to be done to realize the project product or result and not necessarily to structure the recurring project management work as is the purpose for the project management lifecycle. The project delivery lifecycle is highly related to the project at hand and as every project is unique, the project delivery lifecycle will also be different for and unique to each project. Which kind of project delivery lifecycle is taken as a basis highly depends on the realization approach that is taken. In a traditional approach, you might want to use a software development lifecycle, whilst in an agile project, you will rather go with the iterative sprints. In any case, on all projects, you will have one project lifecycle, consisting of two levels, the project management lifecycle and an aligned project delivery lifecycle

HOW CAN YOU CREATE A GENERIC

PROJECT (MANAGEMENT)

LIFECYCLE?

It is quite simple to create such a generic project management lifecycle that will be applicable on almost any project. So, the good news is, you only have to create it once and then reuse that generic lifecycle on all your future projects. A project always has five distinctive stages where related project activities are performed: A project is temporary and therefore always has a start and an end. So, there should be at least a phase that will combine all related activities to starting-up the project and a phase that organizes the ending of the project. Starting-up activities relates to getting the project approved whilst ending relates to the activities to close down the project, like for example documentation archiving, closing contracts, evaluating team members, and so on… In other words, you will need a Start-phase and a Stop- phase. But, once your project is approved, it should be defined. A scope or an initial backlog when it is an agile project, needs to be build. Some tools like document storage and or Kanban boards need to be organized. Also a decent schedule or sprint cadence need to be considered. Also identifying your project team members and their required involvement is a key activity. You can combine that all work into a kind of Study- phase. And once the study has been done, the “real” work can start. All the realization work is typically combined in a kind of Do-phase. Sometimes forgotten, but in all cases very crucial to the success of the project is that you also organize the transfer of the created project product or result to the client-stakeholders of the project. It is the phase of work where in a way of speaking “the keys are handed over to the responsibility of the owner”. Therefore, a kind of Transfer-phase is worthwhile to consider in your generic project management lifecycle. To summarize above, these five phases composes our high-level project management life cycle and looks like: You should “professionalize” that a little bit by giving it some more professional names, like: Sounds already better, don’t you think? It is very important to spend some time on naming the phases of the project management lifecycle, but that is a topic on itself for another project management article. The Project Mangement Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowned brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services. How to reference this article: Goeman, S. (2021, 1 March). Project Lifecycles Demystified!. GAPS BV. https://www.gaps.be/Mentor/pmart001- pmbok_projectlifecycles.htm.