Phases Vs Project Management Processes

In this post I will be focusing on one of the very basic concept in Project Management.

This is related to how this concept is defined by PMI in its PMBOK, but that is only incidental. The purpose of this post is not with respect to passing the PMP exam and getting certified, though this will definitely help, but to bring clarity on Project Management itself. The idea that is being discussed, is central to the way we need to look at Project Management, regardless of which certification or methodology we are following.

During my workshop, as a simple exercise I ask participants to list down the Phases in their current project. This, or a slight variation, is what a typical list looks like

• Feasibility Study
• Requirements
• Planning
• Design
• Execution
• Testing
• Closure

Terms like ‘Planning’ and ‘Closure’ and sometimes ‘Initiation’ show up in many such lists. Some participants who may or may not have gone through any formal Project Management certification but aware of the terms end up writing the following phases

• Initiation
• Planning
• Execution
• Monitoring and Control
• Closure

Clearly, they are aware of these terms and think of these as logical phases. These are NOT.

‘Any Project could be(& should be) divided into one or more logical Phases for better planning, execution and control of the project.’ The Project Phases are dictated by the Engineering Process of what product is being created. These phases are usually sequential (though some of them could be executed in parallel) in nature.

For example, a Software Project development would have the following phase

• Requirements Gathering and Analysis
• High Level Design
• Detailed Level Design
• Coding(Programming) and Unit Testing
• System and Integration Testing
• Performance Testing and Performance Optimization
• User Acceptance Testing
• Warranty Support

Similarly, a project to construct a building could be divided into the following phases

• Requirement and Site Survey
• Detailed Plan(not a project management plan but the actual Architectural Plan of the Building to be constructed)
• Excavation and Foundation
• Construction of the Structure (Concrete Edifice)
• Brick Work Etc (Interior Walls, Electrical Layout, Plumbing, Elevators etc)
• Exterior Finish
• Interior – Furnishing and Furniture
• ….

As you can see the Project Phases will be decided by the nature of the Project. Also, you will notice, that the same project could have different phases when executed by different organizations. For example, a software company may have ‘System Integration and Performance Testing and Fixing’ as one phase.

So where does it leave the ‘Initiation, Planning, Execution, Monitoring & Control, Closure’ ? If these are not Phases, what are these and where and when do we do them.

Going back to the Phases again, a Project when divided into Phases, essentially creates individual Project that each needs its own Initiation, Planning, Execution, Monitoring & Control and Closure.

This is best depicted in the diagram below

For example, the Feasibility Study and Business Plan Phase of a project itself will need to be initiated, planned, executed, monitored & controlled and then closed.

Initiation, would mean you will do some of the following:

• Get a ‘Go ahead’ by the sponsor to start the Phase. This is a formal approval that allows you to spend the budget.(sometimes in subsequent phases this ‘go-ahead’ may be implicit, but need not always be the case.)
• Identify the relevant Stakeholder

Planning

• Plan out all the sessions that are needed with various peoples and focus groups
• Plan the communication with the relevant stakeholders
• Re-plan midway if the time is not enough as you realize you will not be able to complete the entire requirements sessions within the time you had planned initially

Execution

• This is the actual execution of the plan, i.e. the actual task of gathering information, doing the feasibility and creating the business plan. Some sessions like White Board discussions may also have been planned for this phase.
• The output of this will be the Business Plan and any Prototype or Document that you may have planned.

Monitoring & Control

• Seldom do projects go as per plan. Some users who were suppose to be available in the 2^nd week may somehow not available in that week. Or a white-boarding session that was expected to finish in one week now needs 3 more days.
• This monitoring information will feed back into your planning.

Closure

• This is to officially close the phase, when the sign-off on the Business-Plan has been obtained and all objectives of this Phase(Project) have been either met or in discussion with stakeholders decided to be discarded as they may not be needed or cannot be done.
• Documenting the lessons learnt is an important activity.
• As you can see from the above two points, Closure activity need not happen sequentially at the end, you can and you should document the Lessons Learnt as soon as you can i.e. If you have realized that user sessions would need 4 weeks and not 2 weeks for this type of project, this should be documented as soon as this is realized. If you document it in the end of first week itself, a new project starting in the second week can benefit from this learning. So, do not wait till the end of the 4^th week to document the lesson. The activity of documenting Lessons Learnt is part of Closure process.

The 5 points mentioned above are not Project Phases, but are described as ‘Project Management Process Group’. Planning itself is a group of processes which includes Schedule Planning, Cost Planning, Risk Planning etc.

The main point is that there is NO SEQUENTIALITY associated with these 5 process groups. Activities related to these processes happen throughout the project. To emphasis again, Risk Planning, like any other planning happens through out the Project.

(From PMI PMBOK 5th Edition)

Remember you could be Planning the project even in the last month of a 15 month long project. The above graph from PMBOK gives an idea of the Non-Sequential nature of the 5 Process Groups.

Why this understanding is important?

One may ask, is it really that important to distinguish between Phases and Process Groups.

The answer is an emphatic YES. It’s all about Clarity.

Project Phases are ‘Engineering’ in nature. Project Processes are ‘Management’ in nature and definitely Non-Sequential. You could be Planning and Learning Lessons at the same time.

I have observed that Project Managers who mix the two, end up with a hodgepodge project plan. The lack of clarity reflects in the poorly crafted Execution Methodology (Engineering methodology is an important part of this. Waterfall or Agile which method do you want to adopt for your software development?) and how they fundamentally view and implement the Project Management processes.

Also, the 5 Process Groups are constant regardless of the nature of the project. The Project Phases of course depend on the engineering endeavor.

The 5 Process Group themselves have their own history though. Initially there were only three distinct Process groups that were identified

• Plan
• Execute
• Close

Later it was realized that ‘Initiation’ even though requires a relatively small amount of overall effort, is sufficiently distinct and deserves to be dealt separately (and not clubbed and lost with Planning). So too the need to separately deal with ‘Monitoring and Control’ processes along with Execution.

Regardless of which framework you may be using, separating out the Engineering Phases from Project Management Processes is very important for clarity in vision and creating a clear plan for your project.