In my opinion, completing the product life cycle is not that easy in real life.A bunch of people who are
experts in their fields and are working together to complete a project, will have to overcome many minor
issues with in the team to achieve the target. For instance, the PM might not be on the same page with the
the designer of the product and that leads to friction between the two. Then sometimes, the PM can
be an arrogant person who thinks he/she knows everything and undermines the work of his team and is not open to new ideas. Or he creates an unrealistic deadlines for his team members to work on. In all these above mentioned cases, it creates a frustrating environment.

In my experience, one generally starts following the process ideally: Initiating Processes, Planning Processes, Executing Processes, Closing Processing. While trying to follow the process, problems usually occur that may require you to revisit a previous step. For example, during the executing process you might run into problems that require you to go back to the planning process and review and reassess your plan to mitigate risk and problems. I don't really see this as a failure but more of a learning experience. One can learn about problems and risk from past similar jobs that have documented lessons learned but sometimes, the project is completely new. When the project is completely new, this is the nature of the work. You are going to try things and usually, you will learn about problems/risks during the executing process and have to reassess your plan to further mitigate other problems and risks.

In my opinion, even if the initiating and planning process was extensive and very detailed, there are always some details, risks or problems that were never apparent until you reach the executing phase. In theory things might fit and seem perfectly put together and during the planning phase it is all about theory. It comes down to past experiences in the same fields that makes problems less. However, I still believe that that no matter how much you try to avoid there will always be something that can come up and change things around, otherwise the concepts of change documents wouldn't exist.

At my current job, the Project Management processes of Initiating, Planning, Executing, and Closing were both generally not easy to follow and generally not as clear cut as I had originally thought. Occasionally, one of these phases would be considered completed by upper management and have to be revisited if a critical design change or problem with the instrument was detected. This mostly occurred in response to deadlines approaching putting pressure on the PM to complete a certain phase of a project by a deadline. I have heard of, in the past, a phase being declared completed only to result in the next phase encountering a magnitude of unsolved issues that should have been accounted for previously. In this particular case, it was a minor software issue which should have been resolved much earlier, however, was pushed through to meet a deadline. In the end, excess time, money, and jobs were sacrificed in order to catch the back up to date. Basically, politics gets in the way of an ideal stepwise progression of the PM processes more than it should.

From what I experienced in the industry, ideally the project should follow Initiating, Planning, Executing, Closing process but as the project continues you'll find yourself still going back and forth - but not to a degree that will significantly cause delays. If you think about it, it's really hard to plan everything before execution and sometimes you'll find that the plan that you thought was perfect failed execution and you have to go back and re-plan. Sometimes there are issues with pressure to meet dates which can cause these mistakes. While the general framework is still there, the transition is a bit more gray.

I do think that a pathway such as the one you mentioned is followed most of the time. However, no matter how hard you try there will always be delays. From personal experience, our team was providing electrical power to a community far from the city in my original country. We planned everything to the point that the utility poles would be placed next to the main street that connects the community. When we were about to execute the project, a big flooding occurred which made a river close to the community disappear the main street and therefore the project was initially where we started. We had to change our schedule and location of the utility poles. It took us way longer than what we planned. We never thought a natural disaster such as that would occur, but it did. I think we as engineers have to accept that something delays are cause for reasons that are out of our control, but they key is how we respond to those delays, with responsibility and good quality work.
Let me know what you think.

Sincerely,
Roberto Pineda.

My experience has been similar. It seems that a great deal of the process is rushed and results in having to repeat steps. I believe if these processes were completed adequately, it would save a great deal of time and changes. However, because of changing requirements this is difficult to do right on the first iteration. Establishing better input/ requirements help to reduce the number of these iterations in the project management process.

I think in general IPEC is always the framework for projects. What I've been told is that this cycle is typically disrupted when other people (usually higher-ups) hand you unexpected challenges and force you to do something.Speaking as something who's worked under a rather lax project manager, I can say that a project with a very short planning phase can definitely be done, and will shave off some time if necessary. This does increase the risk however, and luckily for us it panned out with very few setbacks. I can't say the same for the people who picked up where our project left off however, considering they had very little documentation to read up on.

In my past experience with project, it is very hard to see the complete process as they are very detailed. I have seen a project follow the normal process of, Initialing, planning, Executing, and Closing. However, I was mostly involved in the Executing phase of the project. Upper management and Directors might have a broad vision of the entire project and thus they might have seen all the phase of the project process. As I was working under the Executing phase, we noticed we needed to revise the planning document. As a result, the PM provided us resources to support the change process. All in all, the complete process is followed, but it’s so detailed that it’s hard to differentiate

In my opinion, those general processes are the intent or basis for any project. Of course not everything works out like that in real life. A project may start off following this guide but there are many unforeseen variables that can throw off any stage be it problems with funding, problems with the team, or just problems with the company in general. Personally I have been working in the monitoring and controlling part of a project, running with a project that has been closed and handed over to manufactoring. But because I see how they now open new sites and locations as brand new projects, it is interesting to see that they still follow the same general processes where the initiation is the looking for a new client, the planning is the pitch to the new client, the executing includes on site visits and presentations to this new client, and hopefully the project closes landing a new contract and a chance to start the process all over again.

As I would see it, regardless of the possibility that the starting and arranging procedure was broad and extremely point by point, there are constantly a few subtle elements, dangers or issues that were never evident until you achieve the executing stage. In principle things may fit and appear to be splendidly assembled and amid the arranging stage it is about hypothesis. It comes down to past encounters in similar fields that makes issues less. In any case, despite everything I trust that that regardless of the amount you attempt to maintain a strategic distance from there will dependably be something that can come up and change things around, generally the ideas of progress reports wouldn't exist.

I think in real life project life cycle would not be easy. Planning and execution phase is the one of the most important phases in the project life cycle. These phases need to be integrated with the organization project. In real life there is need to know if the project going to be technically feasible or not, will it have required outputs or not. There is need of proper resources sometimes getting proper resources is important and consumes time. Execution phase is one the most time-consuming phase since here there is implementation of the project and the necessary output should meet. The team has to cordial as the final result is important. There is need of constant communication with the team members.

From what I have seen these processes are followed pretty closely in terms of project management. What does not always stay consistent is the difficulty of the processes and how long they will take, particularly in the execution phase. Many times, issues arise in the execution stage where an expected process that was thought to be easy or have no problem is actually not possible.This would require remediation plans or a strategy that solves the problem. Other times, a wrench just gets thrown in the whole process, stalling out the project for unavoidable reasons. I've worked on a project before where a change to a product was being made, but then it got stalled out because another project was making changes already to it before we could, meaning we would have to wait until they were done updating it (they took months!).