The Ultimate Guide to Project Management

Welcome to the EPM Ultimate Project Management Guide. In this guide, we hope to get you successfully running your own projects in the quickest time possible. This guide is both a primer and a complete guide to managing projects.

Ready? Let’s get stuck in…

Who Is This Project Management Guide For?

Maybe you’re trying to build a new software app with your small team? Perhaps you’re trying to build a new house? Or perhaps you’re trying to build an important component of the first consumer-oriented space-going vehicle.

Whichever it is, if you need a plan to get it done, but you’re new to project management, then this ultimate project management guide is for you.

Before we get into the detail, we need to cover a couple of basic definitions. First, we define what a project is:

• A project is a temporary undertaking designed to create a unique product, service, or result.

By temporary we mean that a project has a start and an end. Because of this, it must also have a scope (list of things it is trying to get done).

When we say that a project is unique, we mean that it is not a routine operation, but a set of interrelated tasks designed to achieve a single goal.

The interrelated nature of tasks means that projects often involve different types of people working together who wouldn’t normally work together, for example, plumbers and plasterers in the case of a house, or the development team and marketing in the case of launching a new software app.

Projects can be large and complex beasts with the potential to go wrong, and because of this, they must be expertly managed so they are delivered on-time, on-budget, and as specified. This is the role of the project manager.

Broadly speaking, there are two main parts to this project management guide. The first part looks at project management methodologies, and the second part looks at the hard tools and skills you need to succeed as a project manager.

Why Project Management?

Some of the greatest achievements of mankind have required project management. Think of The Great Pyramid at Giza (circa. 2500 BC), or The Great Wall of China (circa. 210 BC), or to give you a more recent example, the Apollo 11 mission that put a man on the moon (1969). You can read more about the history of project management here.

All of these undertakings require huge amounts of people to work in an organized fashion in adherence to a plan to achieve an objective.

Let’s look at the Apollo 11 mission in a bit more detail. This project took a finite period of time to complete – a little less than 10 years, and at its peak over 300,000 people were involved in making it happen. It would be impossible get anything done with 300,000 people if you allowed them to self-organize so a plan would have been in place. For such a huge project, it would have been broken down into a number of projects and programs and come under the umbrella of one huge overarching program.

Despite the fact that project management as a role has been around for thousands of years, as a discipline it is still evolving, with new tools and techniques being developed all of the time. Some of the major recent advances in project management include the invention of the Gantt Chart in 1910, the Critical Path Method in 1957, and Waterfall Lifecycle in the 1970’s. More recently, project management has been changing with adapting to the movement towards Agile.

Don’t worry if these terms are new to you, by the end of this project management guide you’ll not only understand these terms but be able to apply the techniques too.

Project Management Terms

Before we get into the meat of this project management guide, we need to define some terms which will appear again and again in this article.

Feel free to skip this section and refer back to it as you encounter terms later in this article.

• Agile – a project management methodology involving an iterative approach to project planning.
• Assumption – a set of formally stated constraints or limitations upon which the project plan is built. They are believed to be true but are formally stated as there is no real guarantee that they will be true in the future.
• Business Case – a documented justification for undertaking a project, usually based on a commercial benefit being realized after completion of the project.
• Burn Down Chart – Often associated with Agile, these charts show a graphical representation of work left to do versus time remaining.
• Critical Path – is the sequence of tasks defining the minimum time necessary to complete the project.
• Customer – the business units that defined the need for the project. There can be multiple customers and they can exist at multiple levels with the organization.
• Deliverable – a tangible or intangible thing that is delivered by the project that either is the final product delivered to the customer or a part of it.
• Dependency – for a given task (A) its dependencies are those tasks which must be completed before the task (A) can be completed.
• Issue – an issue could be any issue that arises during the execution of the project that might have a negative impact on your project. Issues are often handled via an Issue Management Process.
• Key Performance Indicator (KPI) – a measurable metric showing where your project stands for that metric. Projects usually monitor several KPIs.
• Milestone – A key date during the project when a set of tasks are due to be completed. A project can have a number of milestones over its lifetime.
• Project Kickoff Meeting – the initial meeting of a project team to begin a new project.
• Project Team – the group of people who work alongside the project manager to implement the project.
• RAID – A document used during the project to capture risks, assumptions, issues, and dependencies.
• Risk Management Process – a framework for managing and mitigating risks to the project schedule, quality, cost, or benefits, as they occur during project execution.
• Scope – defines exactly what the project will cover, know as “in-scope”. Anything not defined within the scope is considered “out-of-scope”.
• SDLC (Software Development Lifecycle) – is a framework for capturing requirements, designing, creating, and testing software.
• Stakeholders – all individuals, business units, and interested parties with an interest in the outcome of the project. Note that stakeholders can be internal or external to the organization.
• Steering Committee – is a group of people (usually from senior management) from key parts of the business who provide project oversight and control.
• Work Breakdown Structure (WBS) – a hierarchical decomposition of the work to be completed. The WBS defines the total scope of the project and is often represented as a tree structure.

PART A

Project Management Methodologies: Waterfall, PMbok, Prince2, Agile, Kanban, Lean & Scrum

In the same way that we people speak different languages, and programmers write software in different programming languages, and people drive different brands of car, so too there are multiple methodologies for managing projects.

In this section of the project management guide we’re going to go through each methodology one by one, so at the end of this section, you’ll be able to select the one that is right for you.

Ready? Then let’s jump into the meat of this project management guide.

Waterfall Model

The Waterfall Software Development Lifecycle (SDLC) was introduced by Winston W. Royce in 1970. This is probably the best-known model you’ll learn today.

In this model, each stage must be completed before you can move on to the next stage. There is a formal review (sometimes called a gate) at the end of each stage to check that everything in the current stage has been completed and that the business case is still valid before the next stage is started.

You’ll sometimes see the Waterfall model referred to as Traditional Project Management (TPM). This is because it’s the oldest model in the list and it is typically the first model everyone learns.

The stages of the Waterfall model are Requirements, Design, Implementation, Verification, and Maintenance. Note that some articles and textbooks will use variations on these names.

• Requirements: The first thing done in this phase is to put the project team together along with the mechanics of running the project, such as identifying stakeholders and defining the risk management plan. After this, this stage is all about capturing and clarifying everything that needs to be done to complete the project.
• Design: Now that the requirements have been captured, in this stage design decisions are made as to how to meet the requirements, for example, if wood or brick should be used to build a house, or if Java or PHP should be used to create a company’s software. Once the design is in place, the project plan can be put together/update.
• Implementation: With all the pre-work done this is the stage where we actually build the product.
• Verification: Now that the product has been built, it’s time to test that it meets the requirements that we’ve specified in the requirements. If we were building a car, the quality standards would include such things as that the car didn’t leak, and that it’s possible to see out the drivers’ window when sitting in the driver’s seat. In practice, implementation and verification often happen alongside each other, with final verification done once implementation is completely finished. Once the verification phase is complete the product can be delivered to your customer. Yay!
• Maintenance: This phase represents the ongoing work that’s needed even after the customer has received the product, for example, post-launch bug fixes or changing sales tax because of change in government policy.

The Waterfall model works best where it’s difficult to complete tasks in parallel or where it’s important to emphasize design and planning before beginning the actual work, for example, building a house.

Advantages of Waterfall

• The biggest advantage of the model is that it’s very easy to understand.
• The model works very well for projects in which the requirements can be well understood and are unlikely to change during project execution.
• Because the model is so strict (everything in the current stage must be complete before we can move on to the next stage), using this model as a project manager is fairly easy, as it’s easy to enforce.

Disadvantages of Waterfall

• If a defect is discovered during the testing phase it can be very difficult and expensive to rectify it.
• Doesn’t work well for projects with a high degree of uncertainty, for example, startup software development, or for projects where the requirements might change during execution.

In a nutshell, the Waterfall model doesn’t cope well with change once the project is underway.

When to Use Waterfall

Use the Waterfall method when the requirements can be well understood and are unlikely to change during execution, for example, it’s ideal for a construction project.

PMBOK Model

PMBOK stands for Project Management Body of Knowledge and was created by the Project Management Institute (PMI). The basic process of PMBOK is as follows:

At first glance, this looks very similar to the waterfall model, but there is more to PMBOK that what you can see in the diagram about, which I’ll explain shortly.

• Initiating: This phase happens at the beginning of the project and its key output is the Project Charter. This document may well be written by the project manager but it is formally issued by the project sponsor and formally authorizes the project to begin. All the key top-level information is contained in the project charter, such as business case, stakeholder list, identified risks, and assumptions/constraints etc.
• Planning: This as the name suggests is the planning phase of PMBOK. In this phase, the project scope will be finalized and created as a Work Breakdown Structure (WBS). Milestones will also be identified, and the risk management plan and communication plan finalized.
• Executing: This is where the product is built and it’s the project manager’s job to control the execution of the project. The project manager will update the schedule as necessary, keep tracking metrics up to date, organize status meetings etc.
• Controlling: In this phase the project manager with monitor and control the scope, budget, and quality of the project. They will also perform change control – keeping track of requirements changes that happen mid-project in light of time and budget constraints.
• Closing: This is the final stage of the project where the project is shut down and the project team dismantled. A Project Post Mortem is typically carried out in this phase.

Having just described the PMBOK process now is the time to tell you that PMBOK isn’t really a process or methodology! Instead, it’s a body of knowledge build around project management. Because of this it also tells you how to do: time management, scope management, integration management, cost management, quality management, human resources management, communications management, and risk management.

Advantages of PMBOK

As a plan based approach to project management, the advantages of PMBOK are similar to those of the waterfall model.

• PMBOK works great for projects where the requirements can we fully understood at the outset of the project and won’t change much during the project execution.

Disadvantages of PMBOK

• PMBOK is not really suited to projects where there is a high degree of uncertainty, or where it is likely that a significant number of requirements will change during project execution.

When to use PMBOK

Just like the Waterfall model, use PMBOK for projects such as build a house or a plane, where the requirements can be easily understood at the outset and are unlikely to change much over the course of the project.

PRINCE2

PRINCE2 stands for PRojects IN a Controlled Environment. I often think of PRINCE2 as being the UK equivalent to PMBOK. It was created by the UK civil service and the first release of PRINCE2 and its associated certifications was in the mid-1990s.

• Directing a Project: This process is aimed at the steering committee with input from the project manager. The steering committee directs the project via exception reports, status monitoring, and at meetings associated with Managing Stage Boundaries.
• Starting Up a Project: This is the very first phase in PRINCE2, where the project team is put together and the plan for the next phase is created.
• Initiating a Project: In this phase, the business case is created to ensure the project is viable. It is important at this stage that the steering committee takes ownership of the project. The main output of this stage is the Project Initiation Document (PID), which contains key project information such as the project team structure, the project plan, the project controls, and the business case.
• Managing Stage Boundaries: This stage exists to ensure everything is formally authorized so the project to move from one stage to the next. The steering committee needs to see that the agreed deliverables have been delivered, they need to review the updated business case to confirm it still makes sense to continue with the project. Finally, they give formal authority to move to the next stage of the project.
• Controlling a Stage: This stage begins by authorizing the work to be done. During this phase the project managers will regularly monitor and report on the latest situation, taking corrective action as necessary as issues arise.
• Managing Product Delivery: Here the project manager will ensure deliverables are delivered as agreed and that they meet the required quality standards.
• Closing a Project: This is the last phase of PRINCE2 and it is here that we formally close the project and produce the End Project Report. A Lessons Learned exercise is performed at this stage to ensure mistakes are learned from and good ideas are carried forward into the next project.

Just like PMBOK, PRINCE2 doesn’t just define the phases it also defines Components and Techniques.

The Components of PRINCE2 are Business Case, Organization, Plans, Controls, Management of Risk, Quality in Project Environment, Configuration Management, and Change Control.

The Techniques of PRINCE2 are: Product Based Planning, Change Control and Quality.

Advantages of PRINCE2

PRINCE2 has similar advantages to the other planning based project management processes we’ve looked at (PMBOK, and Waterfall):

• It’s a very controlled way to run a project
• Clear communication channels are defined at the outset
• Contrary to popular belief, meetings with management are kept to a minimum.
• It works well where the requirements can be well understood at the start of the project and don’t change that much during the execution.

Disadvantages of PRINCE2

The drawbacks of PRINCE2 include:

• Whilst very popular in the UK, in the US and Canada it is virtually unheard of.
• It isn’t a methodology that adapts well to projects with a lot of change and uncertainty.

When to Use PRINCE2

A construction project is an ideal candidate for PRINCE2 as the requirements can be understood upfront and aren’t going to change too much during the lifetime of the project.

Agile

First, let’s get something straight. Agile isn’t a project management process. It’s more of a concept as to how projects could and should be managed.All the methodologies looked at so far in this project management guide have been plan based; Agile is reactive. Agile is a set of principles encapsulated by the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile promotes short iterations to produce working software that is then shipped to the customer. This allows Agile to be a far more reactive way of delivering projects.

As already mentioned, Agile isn’t a project management process but instead a series of principles, however, there are a number of frameworks build on these principles to help manage the development of software, including SCRUM (which we’ll look at next in this project management guide), XP, and DSDM.

Advantages of Agile

The principles of Agile lead to the following advantages:

• Customer satisfaction is rapid because of the continuous delivery of useful software.
• Daily cooperation between the business and the software people leads to software the most closely meets the businesses need.
• As an adaptive planning technique, even late changes in requirements are welcome.

Disadvantages of Agile

• There is a lack of discipline/emphasis on documentation and up-front architectural design which in some cases is desirable.
• If your customer keeps changing their mind about exactly what the end product should be then it is easy to disrupt an Agile product.
• If the end deliverable is extremely large, Agile can cause planning problems for the business as it can be very difficult to estimate when the final product will be ready. This can cause a problem if, for example, the company wanted to use a TV advertising campaign for the new product, but this campaign needs to be booked months in advance.

When to Use Agile

Agile works really well for software development but not so well for projects such as construction where there is a long inventory lead time.

Unlike the other models we’ve looked at so far (PMBOK, Waterfall, and PRINCE2) there is very little planning needed to get started and useful working software can be delivered almost immediately.

SCRUM

SCRUM is named after the scrum/scrummage term from rugby. SCRUM is based on the Agile principles and involves small close-knit teams work in an intensive but independent manner. A SCRUM team usually consists of around 6-8 people who work together in short iterations, known as sprints, but with time for review and reflection built into the process.

Before we give an overview of the process, let’s define some terms from SCRUM:

• Product Backlog: You can think of a backlog as a list of things that need to be done in priority order. A product backlog then is a list of all the features to be built in order of priority to the business. Each item on the list should contain a rough estimate of development effort and business value.
• Sprint Backlog: A priority order list of things the team things they can get done in the current sprint.
• Product Owner: Owns the product backlog and is responsible for ensuring the team is working on the right things.
• Scrum Master: Definitely not a project manager, but someone who shields the team from outside interference and removes blockers so that the team can be as productive as they can.
• Sprint Planning: This meeting creates the Sprint Backlog and happens on day 1 of a sprint.
• Daily Scrum: A short (less than 15 minutes) huddle where each team member describes what they did yesterday, what they’re going to do today, and any issues or blockers in their way.
• Sprint Retrospective: This meeting happens at the end of a sprint and gives the team to reflect and learn lessons from the current sprint. This information can then be used to improve the next sprint.

Now that we’ve got those basic definitions out of the way, an overview of the SCRUM process is as follows:

• The Product Owner will create and prioritize the Product Backlog
• The team pulls work from the top of the Product Backlog to create the Sprint Backlog. It’s a pull system as management can’t push work direct to the team as this would slow the team down, so they have to get it on the backlog first.
• A Sprint (where the work is done) will usually last two to four weeks.
• Each day the Daily Scrum is used to synchronize everyone within the team.
• At the end of the Sprint, the team will have produced a working product (or more likely part of a product), that they can then choose to ship or not.

Lean

The Agile principles state that you should break your work down into small manageable parts involving lots of customer interaction. SCRUM then tries to turn this into practice by adding a process, regular meetings, and team roles. What Agile and SCRUM don’t do is specify how you should manage the building of each of these smaller chunks.

This is what Lean tries to fix by adding a standardized workflow to the creation of each all the chunks.

Lean doesn’t actually specify what this workflow should be, but it does say that it should contain the following 7 principles:

• Eliminate waste: The lean folks whet into detail here and identified 7 types of waste: overproduction, unnecessary transportation, inventory, motion, defects, over-processing, and waiting.
• Build quality in: because it’s wasteful to fix problems and defects later.
• Create knowledge: by creating and sharing knowledge the longer term productivity is assured, for example, a situation won’t arise where a single person holds all the knowledge about an important system or process.
• Defer commitment: where decisions are difficult to reverse, defer these decisions to as late in the process as possible.
• Deliver fast: continually work to deliver chunks more quickly.
• Respect people: Empower people to make the right decisions. Ask employees what is wrong with how their job is done and what can be done to fix it.
• Optimise the whole: optimize the whole value stream, not just an individual team or process.

Advantages of Lean

The advantages of Lean included:

• Improved productivity, through improved throughput and value added per team member.
• Fewer defects and rework lead to improved quality.
• Reducing moving times and waiting times reduces waste

Disadvantages of Lean

The disadvantages of Lean include:

• Lean can actually increase waste if the team spends too much time tracking productivity.
• Lean is a relatively new way of working, where employees work under their own direction rather than having managers tell them what to do. Lean is relentlessly focussed on results and this can lead to frustrated employees if you don’t strike the right balance.

When to Use Lean

You can use Lean right across the organization, not just in software or manufacturing systems.

Note: If you are interested in applying Lean principles to the startup world, we have a complete summary of the Lean Startup book by Eric Ries, available here.

Kanban

Kanban is in widespread use today amongst Agile teams, but it isn’t a project management process, nor is it an Agile tool or framework. Kanban grew out of the Lean manufacturing movement mostly derived from the Toyota Production System. Kanban is a workflow tool that businesses can use to help them work on projects of any size.

The work of all Kanban teams revolves around a Kanban board, which can be either physical or virtual (a good, free, Kanban board tool I like to use is KanbanFlow). The key thing that a Kanban board must achieve is to visualize the work of the team, ensure their workflow is standardized, and that all blockers and dependencies are found instantly and immediately resolved.

Each entry to see in the diagram above is called a Kanban Card. Kanban cards contain important information about each piece of work being done, including who is responsible for the work item and how long it is estimated to take.

In practice for teams who need to get things done Kanban works as follows:

• The team pulls the next item to be done from the top of the backlog
• Provided the product owner keeps the backlog in priority order then the team with always be working on the most important item to do for the business. This means there is no need for the set length iterations you find in Scrum
• A metric to be optimized over time is Cycle time. Cycle time is the time it takes for an item to get from one side of the Kanban board to the other from the moment the team starts working on it.
• Finally, it can be a good idea to limit the number of cards allowed in a given column, for example, you might choose to limit the number of cards in the “in review” to a maximum of 3 to focus the team on finishing code reviews and peer reviews.

Advantages of Kanban

The advantages of Kanban include:

• It’s very flexible and doesn’t require fixed-length sprints like SCRUM.
• By setting a maximum number of items that can appear in a particular column you can reduce bottlenecks
• For software teams, Kanban and Continuous Delivery complement each other really well, allowing new product features to be delivered to customers very frequently – daily or even hourly.

Disadvantages of Kanban

The disadvantages of Kanban include:

• The fact that Kanban is totally adaptive is its great strength but also a disadvantage. Using Kanban when will the project be finished? How does senior management understand timelines and review points?
• It doesn’t work well if a huge change is needed, such as re-architecting a system, where a surge in demand is created.

When to Use Kanban

Scrum is said to work best when you have a team of 7 people, or very close to this number. When you have teams half this size, say, 3 people, SCRUM is often too formal. In this case, Kanban can often be ideal, as you can still keep quality, and by reducing meetings you can increase the time available for productive work.

Now that you understand the most important project management methodologies, the attention of this project management guide will switch to look at the tools and techniques available at a project manager’s disposal to manage projects.

PART B

Introduction

By now you should understand the different project management methodologies that are on offer, but what range of skills does a project manager need to be successful? Broadly speaking a project manager will require technical project management skills, interpersonal skills, and some business and leadership skills. This is shown in the diagram below:

The goal of this project management guide is to teach what you need to get up and running with your first project, so we’re going to be concentrating on the technical project management skills. In fact, we won’t be covering interpersonal and business skills everyone reading this article will be coming from a different experience level in those areas, so those are best learned elsewhere.

However, if after completing this Ultimate Project Management Guide you’d like to learn more about interpersonal and business skills then fear not, we provide some points as to where to start with these topics at the end of the guide.

Project Management Skills: Tools & Techniques

Now that you’ve seen the different methodologies for running project’s we’re ready to learn some of the hard skills in this project management guide, that is the tools and techniques that project managers actually use to manage projects.

We’re going to look at:

• Defining the Project
• Planning the Project
• Risk Management
• Stakeholder & Communications Management
• Managing the Project
• Completing & Closing the Project

Let’s roll up our sleeves and look at each one in turn. But before we do that, there are a couple of things we should try to have in place immediately:

A. Project Governance

The simplest way to understand project governance is to think of it as the team that the project manager will report to with ultimate accountability for the success of the project. Another part of governance will be defining the relationship between the project manager and the steering committee, for example, sending weekly status updates, presenting a deep-dive status update monthly.

B. The Project Business Case

It is worth having at least a draft version of a business case in place. After all, how are you supposed to understand what is important to the project and what isn’t if you don’t know what commercial or organizational impacts the project is supposed to have?

1. Defining the Project

The scope of the project defines what the project will do and won’t do.

In this phase a project manager will typically:

• Collect requirements from stakeholders: This can be done by a number of methods including interviewing stakeholders and customers or sending out surveys.
• Define the scope: Here the project manager will analyze the requirements and write a project scope statement defining exactly what the project will and will not do. The project scope is not a static document but is constantly updated as requirements change or new requirements arise.
• From a scope a Work Breakdown Structure is created: You can learn more about this here.

Note that the about works really well for traditional projects using planning based project methodologies such as PMBOK and Waterfall, but it doesn’t work well for planning projects based on reactive methodologies, such as Scrum. For projects based on Agile methodologies, a better way to manage requirements is to use this simple scope management process.

Sometimes in a new project, it can be really difficult to get a project off the ground as there are lots of conflicting opinions about what should be done. Well, it’s your job as the project manager to worry about not only what gets done, but when it gets done and does this requirement help us achieve the business case. A great tool you can use to get everyone on the same page quickly is to use this fast project planning technique.

A key part of project management is managing risks, issues, dependencies and assumptions as they arise in a project. Most project managers will do this using a RAID log. It’s worth setting one up right at the start of your project so you can keep on top of risks and issues as they arise.

Another approach to beginning a project is to have a project kickoff meeting, which you can learn about here.

2. Planning the Project

Planning the project is an important step towards ensuring the timely completion of the project. This step will include:

• Defining Activities: Here the WBS is further broken down into individual deliverables.
• Sequencing Activities: Now we begin to sequence all the activities that need to be performed. To do this we need to identify all the task dependencies. To find a dependency ask your team, “what task or tasks must be performed before this task can be performed?”. At this point, it’s a good idea to start using a project management tool such as MS Project to create the beginning Gantt chart.
• Estimating Activity Resources: Here the project manager estimates what resources (usually people) are required to complete each activity.
• Estimating Activity Durations: Find how long each element in the plan will take with the help of the assigned resources. The minimum activity size you should be looking to record in the plan is 1 day; anything smaller than this and you’re recording things on too fine a granularity. Anything activity longer than 5 days should probably be broken down into smaller deliverables.
• Developing the schedule: here we develop the schedule by applying leads and lags, manual dates, crashing, fast-tracking, and manpower leveling.

It’s worth noting that before the project manager assigns dates to activities, they will define the activities, sequence them, and estimate their durations. This allows the project manager to better understand the activities and their constraints before scheduling them.

Also worth noting is that planning is iterative – the first time through the planning process there may be lots of things that can’t be scheduled, but you take and action to find out what’s missing and you update the plan as the information comes in.

3. Risk Management

A risk is anything that hasn’t yet happened but which might impact your project. For example, if you specialize in auto insurance then there is a risk to your business when self-driving cars are introduced, as individual car owners will not need insurance and more, or at least need a different type of insurance.

Because risks can so hugely impact a project, we’ve devoted a whole section to manage it. The process of managing risks looks something like this:

The article here explains the risk management process in much more detail. It also provides a risk management process you can use if you’re managing risks on an Agile project.

4. Stakeholder & Communications Management

Stakeholder management and communication is a very important part of a project manager’s job. The key here is making sure that the project engages with the right people in the right way.

We’re not just looking to ensure our regular project reports go to the right people, but we’re also looking to see that their Win criteria are met by the scope of the project.

This article explains this concept in more detail. Another tool which can be really useful here is a RACI matrix. We will look at this tool in more detail later.

Once you understand your stakeholders you’ll be able to put together your Project Communication Plan.

5. Managing the Project

You will manage your project through a series of meetings which will happen at a particular cadence, for example:

• Your immediate project team might meet every Monday
• The risk management meeting might happen every fortnight
• The issue management meeting might happen daily
• You might meet the steering committee only at milestones unless something exceptional happens

When assigning responsibilities to your team it can be important to think about how you delegate tasks to them – this will change from person to person based on their working style and the relationship you have with them.

In this phase, you will need to adjust the plan as new issues and requirements arise or are removed.

Some really useful tools you can use during this phase of the project are:

• Using Milestones: You can think of these as mini-deadlines as we work towards getting the project to completion, for example, in housebuilding, making the house watertight is a common milestone and means the next phase of work on the interior can begin.

• Raci Matrix: This is a great tool for making sure that everyone in the team understands their particular responsibility on that task.
• RAID Matrix: Keeping the RAID Log up to date helps you to track all the risks, assumptions, issues, and dependencies. This is one of the key documents in keeping track of all the moving parts in your project.

In this phase, you will also communicate progress regularly (daily or weekly) on the progress of the project. It is likely you’ll need to send different reports to different groups of people, as for example, it doesn’t make sense to send the same report to external suppliers as it does to your steering committee.

As well as doing all the planned meetings a skilled project manager will meet with individual stakeholders from areas that could potentially affect the project schedule (time, quality, and cost) to really dig into the details, and understand the real detail behind the numbers, and think about if certain mitigations are needed. This article on scenario planning explains this in more detail.

6. Completing & Close the Project

This phase usually culminates in a detailed meeting with the steering committee where the final deliverables are signed off, and official approval is given by the steering committee to disband the project.

In this meeting, any major issues will be discussed, for example, where work was postponed in order to meet a deadline – for example, perhaps a wing of a building wasn’t completed to hit the cost target. In this meeting, the plan for these issues will be agreed.

In this phase, a Lessons Learned meeting is held to analyze what went well and what went badly. Actions are then taken from this meeting and assigned owners to ensure that these mistakes and issues are learned from and do not happen again. More information on how to perform a lessons learned review can be found here.

Finally, the project team is officially disbanded and the project is closed.

Summary

That’s it! If you’ve made it this far and also read the articles that are linked to from this article then you should have a really good idea as to how to manage your next project. We really hope you’ve enjoyed this project management guide and can use some of your learnings for your next project.

Further Reading

In this Ultimate Project Management Guide, we’ve provided lots of hard skills (tools and techniques) that are very useful when running projects.

There are also other skills which are important but which we haven’t covered in this project management guide:

These Business and Interpersonal skills make a good place to investigate next on your journey to project management mastery. Here are some topics to consider investigating for each area:

Interpersonal Skills:

• Impact & Influence Skills

  • How to influence anyone
  • Building relationships

• Management Skills:

  • Coaching skills
  • Mentorship skills
  • Teamwork skills
  • Delegation skills
  • Assertiveness

• Presentation Skills:

  • KPIs

• Cognitive Skills:

  • Analytical thinking
  • Critical thinking
  • Problem-solving

• Emotional IQ:

  • Self-confidence
  • Self-control
  • Commitment, and leading by example

Business & Leadership Skills:

• Big Picture:

  • Leading through envisioning
  • Strategic positioning

• Business Acumen:

  • Competitor awareness
  • Environment understanding
  • Knowledge of different functional areas

• Gravitas:

  • Political awareness & acumen
  • Presentation skills
  • Scenario Planning

• Execution

  • Commanding respect
  • Laser focus
  • Rapid team building

Image: Gérard Métrailler