4squareviews

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:   project life cycle, project phase, process group/knowledge area, process.   In the last post, I discussed the various types of project life cycle, from predictive, to iterative/incremental, to adaptive (agile).   In this post, I will discuss the next largest component, the project phase.

The formal definition of a project phase according to PMI is “a collection of logically related project activities.”   Projects are broken up into phases usually when they are very large and the amount of resources that will be expended on the project are very substantial.   A phase is like a mini-project, in that each phase goes through the five process groups of Initiating, Planning, Executing, Monitoring & Controlling, and Closing. In fact the very last of the 49 project management processes is called 4.7 Close Project or Phase for that very reason.

The reason for splitting up a project into phases is that at the end of each phase, there is a phase gate where a decision is made whether or not to go on to the next phase.   In this way, it at any phase gate, the organization decides the project is not viable, then the organization can decide to pull the plug then and there and not go on to the next phase.  This reduces the cost risk to the organization by limiting the expenditures on projects that will end up adding value for the organization in the way that they were originally envisioned.

Let’s use an example to clarify what the phases are.    I used to work for a Japanese automobile manufacturer, and before producing a new model vehicle, they would first put out a concept car.   So concept development would go first.   Then the requirements would be gathered.   Now these would include customer requirements, based in part on market studies about what kinds of cars various types of people were interested in driving.   But there would also be regulatory requirements, such as new safety regulations coming out of the NHTSA or environmental regulations coming out of the EPA.    There would be a solution development which would combine these requirements and adjust the original concept development into the design and production of a prototype, which would then be built, tested, and a transition made to those in manufacturing who would then take over mass production of the new vehicle.

Each of the groups of activities listed above could be made into a separate phase, with a phase gate at the end of each one where the organization would make a decision on whether or not to the go to the next phase.    There might be some event which changed the market and no longer made the concept car viable.   In which case, the organization might cancel further development.   Or a new type of regulatory requirement might make a certain car no longer feasible and require a change in the design.   Whatever the reason, the phase gate (sometimes referred to as a phase review or stage gate) is there to ensure that the proposed product, service, or result that will come out of the project is still in alignment with the business need and strategic objective of the organization.

The next post will cover the five process groups and ten knowledge areas that the processes of a project can be divided into.

Filed under: Uncategorized |