Project Management

Project vs Product Life Cycles: Integration, not Separation

From the The Critical Path Blog
by , , ,
Welcome to The Critical Path--the home for community happenings and events on! This is where you'll find community news, updates, upcoming events, featured member posts and more. We'll also be showcasing hot topics in the project management arena and bringing you interviews with industry experts. The Critical Path is our primary way of getting news out to members, so be sure to check back for updates!

About this Blog


View Posts By:

Marjorie Anderson
Kimberly Whitby
Laura Schofield
Heather McLarnon

Past Contributers:

Carrie Dunn
Danielle Ritter
Kenneth A. Asbury
Craig Dalrymple
Rebecca Braglio
Kristin Jones

Recent Posts

Principles and Performance Domains: The Foundation for Project Management Practitioners

May 2020 Community News You Can Use

Careers in project management – what does the latest research say?

Virtual Learning Opportunity from PMI

New PMI Volunteer Initiative: PMImpact

Categories: standards

by: Nader K. Rad, PMBOK® Guide-Seventh Edition Development Team member

What does product life cycle have to do with project management? Well, let me tell you about that with an example: Let’s say we have a project to build a plant. We will spend some time designing and building it, and then it will be handed over to another team for operations.

Our project is the main investment, and the agent for change – which in this case is the creation of the plant – and then the operations is where value is generated by using the product we have created. Operations continue until many years later when the owner decides to stop using that plant because it’s not justifiable, or for some other reason.

What do you do with the plant when you decide to stop using it? There’s always the option of just abandoning the plant, which may create good opportunities for photographers many years later, like this plant not far away from me in Charleroi, Belgium. In many cases, though, for safety, environmental, or economic reasons, you may want to disassemble useful parts of the plant, demolish the rest, build walls or fences, etc. In this case, these activities form a packaged change, which should be managed properly with a clear purpose. In other words, it can be seen as another project.

Is that everything, then? Hardly so. When the plant is in operation, many things change in the environment; the plant doesn’t stay exactly the same until it’s retired. In many cases, we make changes to the product (the plant) during its operation to adapt to the environment and increase our profits. Some changes are simple, and we just implement them. Some changes are bigger and more challenging, though, and need serious management. Those changes will be managed by a project.

Do we have to stop operations during the project? It depends: Sometimes we have to, and sometimes we don’t. In some cases, the project can be focused on changing one part of the product, while the other parts continue their operations normally. In IT development projects, it’s possible to deliver incrementally during the project: releasing a working version of the product into production while the team is working on the next release.

In some projects, the day-to-day operations and changes are so tightly coupled that they may look like the following and may even be done with mixed teams responsible for both aspects.

When we, as people involved in projects, think about the product life cycle, there are lots of things to consider; for example,

  • How can we match our project life cycle with the wider product life cycle?

  • Are we going to put the [new] product into operation at the end of the project, or are we going to have incremental delivery? In either case, how are we going to match our project management with that delivery approach?

  • How are we going to develop the product in order to match the delivery approach? Do we need a sequential development approach or a cyclical, iterative one? In each case, how are we going to adapt our project management method to better support the delivery approach

Put simply, there isn’t just one way of managing projects, and we should not force the one approach that we are most used to, or is the most popular at the time, onto all types of projects, regardless of their natures and needs. In other words, we should consider life cycle management as one of our performance domains in project management. The main focus of this performance domain is the project life cycle (the series of phases that a project passes through from its start to its completion), but it should also consider everything that impacts the project life cycle, including the product life cycle, development approach, and delivery cadence.

Posted by Laura Schofield on: March 31, 2020 09:56 AM | Permalink

Comments (10)

Please login or join to subscribe to this item
Sorry folks but this is a VERY POORLY researched article that tells us only PART of the story.

You have totally missed the role of the Asset Manager plays as the SPONSOR of CAPEX funded projects.

Also, you are misrepresenting projects as being ABOVE operations, when in fact, projects play a SUPPORTING ROLE to operations.

What you need to do is go back to the 1970s and look at the work of R. Max Wideman and you can see that long ago he portrayed ACCURATELY the role of the THREE actors in this play:
1) Asset Manager who is the SPONSOR of CAPEX funded projects:
2) Operations Manager who is the SPONSOR or OPEX funded Projects
3) Project Manager who plays a key SUPPORTING (Tactical) ROLE only during the planning, execution and closing processes of the project.

This article if FACTUALLY INCOMPLETE and you owe it to your readers to RETRACT it and REPUBLISH the full and complete story.

And Nader, you of all people should know better as I have provided you with the supporting references on more than one occasion.

Dr. PDG, Jakarta

PS While I have your attention, you also need to do more research on the History of Earned Value Management as your current EV standard is also poorly researched and incomplete, representing ONLY how the US Government uses EVM, not how the PRIVATE SECTOR uses it.

These two most recent papers will provide you with the full set of references you need to make the corrections, starting with the fact that it was NOT Walt Lipske or the US Air Force who "discovered" the concept of Earned Time.


The concept of "Earned Time" was the original concept upon which Earned Value was predicated, dating back to the factory floors of 17th and 18th Century Industrial Revolution.

Dr. PDG, Jakarta

@Paul, I'm afraid your comments are just not relevant.

In what way, Nader?

What have I stated that is not true?

What critiques have I offered that are in any way wrong?

Dr. PDG, Jakarta

@Nader you asked the following questions:

How can we match our project life cycle with the wider product life cycle?
[PDG] And I answered by providing you with the graphical illustration created by R. Max Wideman that shows how projects relate to asset managers (which PMI ignores) and operations managers. I also showed you how the life SPAN (where is there any CYCLE involved here) of one or more projects relates to the Asset life SPAN (again assets don't recycle)

Are we going to put the [new] product into operation at the end of the project, or are we going to have incremental delivery?

In either case, how are we going to match our project management with that delivery approach?
[PDG] I provided a graphic that shows the various Asset Delivery Systems any organization can choose from, that shows examples of which project management delivery system is appropriate based on the percentage of scope or objective that is defined AND the tolerance by the stakeholders for change. So what is wrong with that?

How are we going to develop the product in order to match the delivery approach?
[PDG] Very clearly based on the percentage of scope that was defined at the outset PLUS the tolerance by the stakeholders to accept change.

Do we need a sequential development approach or a cyclical, iterative one?
[PDG] It all depends on the Scope/Objective definition and the tolerance for change.

In each case, how are we going to adapt our project management method to better support the delivery approach?
[PDG] By selecting the Asset delivery system that is appropriate to the scope and tolerance for change.

The "problem" with PMI's approach is that the PMBOK Guide has NEVER recognized nor accepted the role that the Asset Manager plays nor did it recognize that contrary to what your graphics imply, that PROJECTS and PROJECT MANAGEMENT are a SUBSET of both Asset and Operations (Program) Management. (Using the GAPPS definition of Program, not PMI's)

Bottom line- why not just admit your model is incomplete, and make the appropriate corrections? Either that, or come up with something better to justify or explain your model?

Dr. PDG, Jakarta

@Paul, it's not about being right or wrong, but about being relevant. It's like saying "this article is all wrong because two plus two equals four and two multiplied by two equals five". Yes, two plus two equals four, and no, two multiplied by two doesn't equal five, but what does it have to do with the article?

@Nader if I have to explain it more than I have then it probably is a lost cause.

I answered your questions and backed them up with evidence used as the basis for my responses. If you can't figure it out by comparing your graphics to the graphics that I provided to you, then there is probably not much more I can do to convince you that what you are showing is an incomplete and poorly researched and documented explanation of "real life" project management in an operational environment.

Dr. PDG, Jakarta

Nader - I do not agree that Dr Giammalvo comments are irrelevant. In my view he is simply stating you left out a major part that influences the integration of project and product life cycles - the sponsor of the capital expenditure effort. Naturally the sponsoring group has significant influence on the project and the product.

I am not so hung up on whether you illustrate projects 'above' operations as I did not interpret your figures as saying projects drive operations.

I am more concerned about the lack of detail/discussion on how the project life cycle is influenced by the product life cycle. By illustrating the project as a single monolithic box there is no opportunity to show the nuances a given product life cycle would have establishing the project's life cycle, i.e, what kind of phases could occur..

I also see this deficiency in the Project Management Performance Domain chapter's write-up of the Life Cycle Performance Domain in the soon to be released PMBOK(R) Guide-Seventh Edition. Too much focus on product life cycle and not enough on project life cycle. As you state in your blog post title "integration not separation". I feel your post should have focused more on the integration aspect.

IF someone can explain to me how to insert the graphics in this blog, I will be happy to show the graphics to back up my position.

OR if you want to see the graphics as well as the written explanation, you can go HERE and look at figures 1-13.

Worth noting is that unlike PMI and AACE, the Guild makes access to this ~650 page book of "best tested and PROVEN practices" is FREE to both members and non-members alike. You do have to fill in a profile but that too is free of charge but will take you 15-20 minutes of your time.

Dr. PDG, Jakarta

I'm often surprised by people who don't know the difference between the two.

Please Login/Register to leave a comment.


"History may not repeat itself, but it does rhyme a lot."

- Mark Twain