Guide

Ultimate Guide to Project Management Processes

Olga Drobysheva

CSM, PMP

Get a pre-made project plan based on this how-to guide.

This is the ultimate guide to Project Management process. It is suitable for and applicable to any methodology. Any project you manage, you will go through this steps.

Just in case, let’s set some basics

Most probably you know it all but it never hurts to repeat.

Worth defining what is a project first. Project is a time constrained endeavor to produce a result (product or service) It means that project has a start and an end, it works towards a particular deliverable, has a set of goals and objectives. It’s different from operations, or business-as-usual procedures, or product management. Though they can include projects or be “projectised”. Basically, anything that has a start, an end and a goal is a project. And if you are managing that activity, you are a project manager (officially or not).

Project management is a combination of processes aimed at delivering that result within given constraints: time, budget and scope (quality). This love triangle of constraints is the Holy grail of Project Management. You cannot have a project without those three and you cannot change one without influencing others (one or both).

That’s what project management is all about: navigating muddy waters of deliverables, schedules, unknowns and risks, stakeholders and contractors, to achieve a result. It’s easy to get overwhelmed and lost on that expedition. That’s why we’ve put together this guide for you.

Every project or its phase goes through a set of stages or Project Management Process Groups. Why I say “project or phase”? - that depends on the methodology you are using. I mentioned before that this guide is applicable to any methodology. Phase can be an iteration, it can be a deliverable that is part of a bigger program of work, it can be a section of your waterfall activities. Not every phase may include all the processes but it will include all the process groups. Project on its own will include all the process groups as well as its phases. Before I confuse you even more, let’s define those process groups:

Initiating
Planning
Executing
Monitoring and control
Closing

1. Project has the beginning and the end.That’s your initiating and closing. Both of them can be phases on their own which means they’ll include initiating, planning, executing, monitoring and control and closing on their own. If the project is big it may take quite some time if it’s a smaller one - it can all happen in PM’s head and take like 15 mins combined.

2. Planning never stops.It’s heavier in the beginning and reduces towards the end. But you always go back and refine and update your project plan with new details, discoveries, risk mitigations, etc.

3. Execution of a project (development) may be iterative, which means it will have its own phases - sprints, for example. But each sprint is nothing but the representation of those process groups:

Initiation
Sprint planning
Sprint itself - execution and monitoring and control
Closing - Retro and review

4. Monitoring and control is similar to planning as it doesn’t really stop and starts almost together with planning. It get’s a lot of input from planning and feeds its outputs into project management plan. 5. Depending on what methodology is used, project can be broken down into phases that may have all to some of those process groups TOGETHER with project on its own Waterfall-ish:

Initiating
Planning
Design
Infrastructure
Development
Integration
Close and hand-over

Agile

Sprint zero or planning
Sprint 1
Sprint 2 Etc...

Every sprint will have all the process groups as well.

Whatever breakdown is there, all the phases will be under the umbrella of major project process groups as you progress towards the goal. It is something that happens at the background (or better over and all around) project plan, Gantt charts, sprint plans, backlogs, etc.

PMBoK identifies 10 knowledge areas that exist across those process group. If process groups are stages and more or less define sequence of events, knowledge areas are, in layman's terms, things that Project Managers need to deal with and activities they need to perform to achieve goals (processes) throughout the project grouped by area of expertise.

Check project management process groups

Process groups and knowledge areas interact as matrix system. Each group doesn’t necessarily cover all knowledge areas. Knowledge areas in their turn can cover all or some of the process groups. Simply put, there are phases when you just don’t need to do certain things :)

You don’t need to memorize all processes and knowledge areas unless you are planning on passing a PMP exam. In this guide, we’ll go phase-by-phase and discuss (in human language) what needs to happen and how at each stage.

1. Initiating process group

This is when and how you start your project. Normally when the project is initiated you receive some specification, business case, business request or contract. It will be first input to your scope and Project Charter. It will also give you an idea of who your stakeholders are. Those are two most important activities:

Create project charter
Identify Stakeholders And those activities run in parallel.

What it really means:
When you create Project Charter you understand the scope - problem that this project supposes to solve (or an opportunity to explore). It is the essence and the base of your project, it’s backbone. All further decisions will be based on this.

While you understand the problem you realize who is involved in your project (directly or indirectly), who is interested in it or affected by it. This may refine your scope or add some criteria to it. Understanding people and the problem will help you set goals and objectives for your project as well as identify high-level constraints. Those become your project frame (or canvas) to work within. Understanding goal and constraints will help you to set primary expectations with your stakeholders.

Depending on nature and size of the project, this process can take awhile or it can happen during a couple hours kick-off meeting. Once you’ve set up the frame you can start creating a plan of attack.

2. Planning process group

This process group (or phase) is the most activity-heavy for a Project Manager. It may not be the most time consuming, though it requires the most effort and hands-on work from Project Managers themselves. It also means that there’s variety of things to remember, take care of and plan for.

Some may think that this approach is contradicting Agile or lean methodologies that deny long planning and advocate for build-measure-learn cycle instead. It is not exactly so. In any methodology you have your planning step. In Agile it means that your “grand project plan” is being refined based on learnings that come from prototyping and development sprints. You have your sprint planning and “Sprint Zero”, and what is the backlog and its grooming if not planning. So in fact you are doing a lot of planning.

The most important outcome of this stage (and its iterations) is Project Plan. It’s a living document, you never stop updating it. All the learnings and changes go in it throughout the project:how everything started and why, who was there on the journey, how you thought it would be and what were your plans and ideas, fears and aspirations (risks and opportunities) and how you were planning to deal with them, what happened on the way, your learnings and experience, changes and adjustments you had to make that crafted the final result.

Project Management Plan is a plan of a plan. It also tells you HOW you are going to plan (seriously) and how you are going to deal with different aspects of the project, what are processes and procedures.

Project plan contains a description of all the areas of project and all project information. It can be a lengthy book-like document or a set of Wiki pages. Whatever form it has, it is the ultimate reference for Project Manager and everyone involved in the project. It should be written in a way that anyone who wants to understand what is this project about and what’s happening at any point of time should be able to do it from Project Plan. Anything happens, Project Management Plan should a reference on how to deal with it, who to contact, what are the options available. To know what to cover in Project Plan - look at knowledge areas (it’s pretty much is contents of your plan)

Let’s dive deeper in each one of them. But before we do, I just want to highlight once again: these processes are not one-off activities they happen in iterations as you go through the project and discover more details, you keep refining them and add more details. They also run in parallel as there are many dependencies among them, they contribute and support each other and add more details.

Scope

First of all, you decide how you are going to approach it. This is your little plan of a plan within a plan. It may happen just in your head, or you write notes in your planner, or (in a case of a bigger project) you actually create a plan for it. But you start with a plan for defining scope. This is a PM’s life - you should have a plan for everything, even for a plan :)

I mentioned that you define scope at initiation and state it project charter. That’s your high-level scope based on a problem to solve. During planning, you refine that scope and add more details to it by collecting requirements. That’s where a list of stakeholders comes handy. Those are the people you ask questions to, run workshops with, etc. This is the right time to introduce any changes based on your learnings. Later it can be only details and updates, but the main direction should stay the same.

Detailed scope and requirements will help you to define your high-level deliverables or Work Breakdown Structure (WBS), or Backlog. In the very beginning, your breakdown can be on feature level but you’ll quickly identify smaller items as you go further.

Schedule

Again - plan. And again it can be as simple as a mental note or as complicated as the project requires.To create a schedule you need a list of activities - smaller items that can be delivered by one person. In a case of Scrum, if your WBS is a backlog (or at least its most groomed, upper, part), your activities are your actual tickets that are identified at sprint planning. In a more waterfall model, you consult specialists and break down your features further into activities that you can schedule later.Every schedule is based on the following prerequisites:

Sequence (what should go first based on logic and priorities)
Time estimates (how long it is going to take to deliver that activity)
Resources required (human or else)These three aspects will define activities dependencies on each other and on external factors. The rest is like collecting a puzzle.

For example, you need to set up a database, design and build front end and then connect the two through the features.You cannot build front end before designing it so that is you logical dependency. But your designer can start only in two weeks and it’s going to take them a month. So front end dev won’t start before 6 weeks time and they’ll need another month for implementation. But you have all you need for database and it is going to take 2 months. It means that your back end dev can start at the same time as a designer.

Of course, you’ll refine this as you go through iterations but what it means is that your front end guy doesn’t have to be on this project full time just yet, but only as an advisor. It will help you optimize your work.

High-level scheduling helps you immediately identify where gaps and risks are, where you can optimize your schedule and resources.

Resource and procurement planning have a huge impact on schedule as well. That’s why it’s important to understand what resources are required for each activity (human or material) and what is their availability. It may change priorities or start and end dates, estimates, and dependencies.

Cost

They say if you don’t manage the budget, you are not a true Project Manager but a Project Coordinator. Though, even if you don’t have a budget (you’ve truly been blessed, by the way), it’s still good to know what your costs are as it may influence a lot of decisions.

Don’t forget to plan how you manage your costs! ;)

Cost estimates are mainly based on your activities resource requirements. Once you counted them and your gross total doesn’t meet your allocated budget, you may have to roll back to your schedule estimates and resource requirements or even scope. Even if you don’t have budget limits, sometimes you just realize that it is not sensible to acquire such an expensive resource.

You can consider hiring less qualified cheaper stuff, outsource, use different finance scheme for your equipment, extend or reduce time of work (depending on payment schedule). It even may be escalated to scope change. This is the last resort but it may happen as the budget is one of the major project constraints.

It’s also good to have a fork estimate and a reserve. Just in case.

Cost estimates is something that happens every time there’s a change or new addition to the schedule and activities, new risk or opportunity involved. As all the other processes it goes through iterations. Update your Project Plan with new details every time.

Quality

Another major constraint of any project. The quality level is defined based on requirements. It happens somewhere after you’ve defined your scope and during scheduling and costs. It is also your acceptance criteria. Requirements may state the highest level of quality, but as far as cost is concerned, it may change. You simply may discover that it is too expensive to maintain. Another possibility - you may realized it takes longer to deliver a particular level of quality which will change your schedule and, as a result, costs. As you see, everything is connected.

Team

This is your hiring or acquiring plan. At this point, you need to identify what kind of specialists you need, with which skill-sets and proficiency level. And very important - when.

Another decision you may need to make is whether you hire, acquire the company or outsource. If it is a new hire - is it a contract based or full time? If it is outsourced, what are conditions and contract?

Communication

As part of your project, you may be communicating with a lot of people: your team, stakeholders, contractors, suppliers, customers. It’s best to plan how to do it.

Yet again, it can be as simple as setting up weekly calls and a slack channel. But in some cases, project area can be sensitive, so that you may need to define what kind of information is communicated through which channels and how it is stored, what level of security is required.

For example, the simplest one, don’t send login and password through one channel and don’t store them in a text file on your computer but use an encrypted method. We all know how that went down for Sony Pictures.

Cultural aspects and remote teams may add more complexity to your communications plan.

Risks

Risk is often perceived as something negative. But in Project Management it can be positive as well. Simply put - an opportunity. Main idea here is to decide what to do if something (good or bad) happens. It will require you to think few steps ahead and play scenarios in your mind “what if”. It can be fun! You can switch negative and positive hats and then imagine that you are Super-project-man that comes and saves everyone. How? - this is your risk mitigation plan. Risk mitigation strategies (it can be a completely separate topic, but I’ll cover the bases):

Accept: if it happens we’ll have to be philosophical about it and pay the price.
Transfer: buy insurance or get a contractor
Explore: something good happened, let’s milk the situation
Mitigate: ok, if this goes wrong we have a plan B

Risks and risks strategies may influence your budget (add or increase reserve), schedule (let’s add some buffer as this resource is not reliable), quality (too risky to maintain high or low quality).

Risk register becomes part of your Project Plan. It is as simple as a list of potential risks and what to do if it happens. It can be your thoughts in your notebook or mental notes, but you better have it, trust me.

Procurement

If you require any equipment or materials - plan for how when and where you are going to get them. Quality and schedule requirements are good inputs to it. And they are your constraints as well together with cost.

Procurement conditions may add risks, increase cost, change quality and schedule. Not my favorite one.

Also decide how and under which conditions you are going to source materials. It’s also time for buy vs lease/rent decision to make.

Stakeholders

Planning phase is a good time to get to know your stakeholders better. Don’t underestimate their potential influence on your project.

There are different types of stakeholders based on their influential power and level of involvement. Those with high influence and involvement you want to keep engaged early. You would want to avoid a situation when an executive walks in the room in the middle of a project and starts changing your scope. h

Least affected and with little influence you want to keep informed. Well-thought through the list of stakeholders will save your project from a lot of troubles. Think who is involved but also who can be affected by any change introduced by your product.

Let’s say you are building a pipeline through a particular area. People that live in that area may suddenly protest and delay your project. North Dakota pipeline project manager is very unhappy right now.

There’s also a human aspect of this process. You get to know people better, how to communicate with them, what are their concerns and if they can create roadblocks or help you resolve an issue. Project management is also a lot about people skills and dealing with people, don’t forget that.

Details you discover during this process may add to your communications and risk plan.

3. Executing process group

That’s where the “real job” gets done. It’s implementation of your plan.

As a Project Manager you, obviously, manage the work and all that’s happening in between. You are making sure that everything’s going according to the plan and if there are changes they are thought through and everyone’s aware about.

First things first, you need a team. That’s when you actually acquire/ hire people based on decisions made earlier. To make sure that team is productive, work is being done, a PM should be acting as a leader to build that team. It may not feel like your primary responsibility, but it is. PM’s main focus is project success that is directly dependant on team performance. Means you need to build the team, build relationships with people and manage that team, resolve conflicts, etc.

Same goes for stakeholders. Follow the plan, keep them engaged, updated, build relationships. It’s a lot of human skills and a PM should learn that.

It ties up with managing communications. It’s not only sending out regular updates though, it also means making sure that “not-sanctioned” communications don’t happen (from your stakeholders don’t talk directly to the team overruling your decisions, to somebody talking to the press who’s not supposed to).

During execution phase you also need to make sure that your team has all the resources and equipment they need delivered on time and within requirements.

And finally, you always check that the quality of work is up to requirements.

All the processes are iterative and/or continuous. You never stop working with team and stakeholders, managing comms. QA’s happen for every deliverable, at every iteration.

4. Controlling phase

We, PMs, are all control freaks, aren’t we? :)

This phase can be separate, but often it overlaps with execution phase and kind of tails it. Activities performed here are based on your Project Plan. You literally make sure that every part (or knowledge area as per PMBoK) we mentioned runs according to the plan. You monitor the project to ensure that it is on schedule, within budget, quality is good, resources allocated, everyone’s happy.

In reality, as you progress, you discover new things and realize that changes are required. That’s what controlling phase is also about - implementing the change.

It’s in human nature to feel concerned about any change. That’s why it is important to go through a process:

Collect as much information as possible, support the rationale by data and information
Account for consequences potential risks and their mitigation
Get all the approvals required, make sure that all legal work required (if any) is done
Keep everyone (your stakeholders) informed and their expectations in check.

Update your Project Plan with changes.

5. Closing phase

And it’s a wrap!

...of a project or of a phase (e.g. sprint) only.

Before you pop a bubbly and celebrate, take few moments to make sure that proper closure is done (some puns may follow ;) )

Before you hand over project result, make sure your procurement contracts are closed and fulfilled.

Handing over project result (product or service), get all the signoffs required, conduct a training, provide all supporting documentation. It often means notifying and training support team as well.

Run retrospective: discuss what went well and what could be done better. It shouldn’t be open and safe environment, shouldn’t be uncomfortable. It’s an important step as this is your learning curve. This is how you improve and get better with every new project. Learn on your (and others) mistakes.

As to project documentation, you want to keep it nice and tidy, stored somewhere for future references. Often projects are similar. Collecting information and finding patterns to automate and streamline the processes as well as avoiding past mistakes is a great practice and that’s why documentation is important.

Well done! Time to celebrate!

To sum up

It’s very important to remember that this guide (as any guide) is a framework. It means that you will need to understand main principles and then, following it, adapt it to your situation and nature of your project.

Main principles are:

Project management process groups are iterative. There are constant updates and refinements during the project as you learn more, so you may need to repeat and refine certain activities as you go.
Project Management Plan is at the heart of your project and it’s a living document. You update it every time as you refine or learn something.
Project phases and knowledge areas interact as a matrix system. However not all knowledge areas should necessarily be covered in each project phase.
Follow common sense. Don’t overcomplicate but also don’t skip important steps
Project manager’s role is pull things together and make it work as a well-tuned mechanism. In PMBoK it is called Integration knowledge area. It’s how you plan, manage, monitor and control project work. We spoke about it earlier throughout this guide
Project management is not only steps, techniques and procedures. It’s also a lot about interacting with people, building teams and relationships. It’s a journey.

For more information on Project Management I’d recommend to go through PMBoK by Project management Institute as this (and any) guide will be one way or another based on it.

Other resources:

I personally like PM Podcast, hosted by Cornelius Fichtner.

If you’d like to go more niche in different project management approaches, go for Agile or PRINCE2. However, note that PMBoK describes all different approaches and covers it all regardless of the approach you’d like to take. So in my opinion, hardcore PM’s come to it sooner or later ;)

Happy project management!
Olga

Story by

Olga Drobysheva

CSM, PMP