top of page

Monitoring & Controlling a Project

Updated: May 22

Introduction

The Monitoring & Controlling phase is about keeping an eye on progress and actively adjusting strategies and actions to align with project goals.


The phase runs in parallel with Project Planning & Execution. Think of it like a background phase that checks on the others in a fatherly way.

Monitoring & Controlling helps project managers address potential risks proactively, manage changes, and ensure that the project adheres to its schedule and budget.


This is where the project manager will spend much of their time; checking and creating reports, managing the various logs, etc.


Key Objectives


  • Alignment with Goals: Continuous project oversight ensures that every aspect aligns with the initial strategic goals, adjusting as necessary to respond to internal and external changes.


  • Standard Compliance: Monitoring and controlling activities ensure the project complies with the set standards, laws, and regulations, which can vary significantly across industries.


  • Quality Assurance: Regular checks and balances during this phase help maintain the quality of the deliverables by identifying quality gaps and implementing improvements.


  • Stakeholder Satisfaction: The phase helps meet or exceed stakeholder expectations, fostering trust and confidence in the project management team by keeping the project on track.


The Monitoring & Controlling phase comprises several activities that ensure the project remains aligned with its objectives and can adapt to any changes or risks that arise. Here's a deeper look into these.


The Main Activities of Monitoring & Controlling a Project

 

Key Steps

Activities

Outputs

Generate Highlight Reports

  • Regularly produce reports on project status

  • Snapshot of project status

  • Informed stakeholders

  • Suggested actions and next steps

Maintain Project Logs

  • Keep logs for actions, issues, risks, decisions, and changes

  • Consolidate logs where appropriate (e.g., AIRAD report)

  • Comprehensive logs (e.g., Action Log, Issue Log, Risk Register, Decision Log, Change Log)

  • AIRAD report

Track Key Metrics and KPIs

  • Define and track metrics that matter for the project

  • Key performance indicators

  • Insight into project health and performance

  • Basis for decision-making

Manage Scope and Changes

  • Implement a change control process

  • Conduct impact analysis for proposed changes

  • Communicate scope changes clearly to stakeholders

  • Approved/rejected change requests

  • Impact analysis reports

  • Updated project scope and plans

Address Issues and Risks

  • Acknowledge problems early

  • Assess the extent and impact of issues

  • Implement corrective measures

  • Exception reports

  • Detailed problem statements

  • Corrective action plans and progress updates

 

Generating Highlight Reports

Highlight reports are pivotal tools in project management and the bane of a project manager's life. They are essential but annoying to create, and often, you get pushback when they go out if something is slightly incorrect, which can range from grammar to more important things.


Highlight reports regularly give stakeholders a snapshot of the project's status. Typically, these reports include updates on the schedule, budget, scope, and risks. They are crucial for maintaining transparency and informing all parties of progress and potential issues.


Tips for Effective Highlight Reporting:


Regular and Timely

Ensure reports are generated consistently, which helps in timely decision-making and keeps stakeholders engaged. Nothing is as irksome as sporadic highlight reports and not on a regular heartbeat. Also, don't mess with the format constantly. Settle on something at the start, and maybe have one or two iterations of style based on feedback, but don't mess with it constantly.


Clear and Concise

Avoid overloading the report with unnecessary detail. Focus on key metrics that indicate project health. With a lot of data, trying to capture it all is tempting. The simpler the report for someone to read and get the flavour of things, the better.


For example, if you have a significant issue with an aspect of your project, I'd suggest writing that up in an exception report and linking it to the highlight report. Not everyone will want that level of detail, but they will want to know, well… the highlights.


Action-Oriented

Highlight reports should present data and suggest actions and next steps. What is anticipated between this highlight report and the next one should be clear. Then, the following report can reflect on that progress.


Don't expect people not to read the highlight report and look at the details. In my experience, the project sponsors usually pick up on inconsistencies and where you might try to gloss over things, so be honest.


Maintaining Logs: Decision, Risk, and Change

Keeping comprehensive logs of decisions, risks, and changes is vital for traceability, accountability and arse covering. These logs help capture the rationale behind decisions, the management of risks, and the implications of changes.


For example, who decided that the project should be delivered only in French, and when? 


The logs I'd suggest every project maintains are;


  • Project Action Log: Records actions that need to be taken to resolve issues, who is responsible for them, and their due dates. The are records of workpackage issued, tasks, and other odds and ends.


  • Issue Log: Keeps track of ongoing issues, their impact on the project, and the steps taken to resolve them.


  • Risk Register: Documents identified risks, their severity, likelihood, and the strategies employed to mitigate them.


  • Decision Log: Captures key decisions made during the project, including who made the decision and the reasons behind it, ensuring transparency.


  • Change Log: Records changes to the project scope, timelines, or resources, along with the rationale for these changes and their effects on the project.


I'm all for consolidating these where you see opportunities. For example, I often consolidate the issues and risks logs because they are similar in structure. Heresy! People say. To hell with it, I say. I'm getting older and care much less what they think.


Sometimes, these logs are kept under one roof called the 'AIRAD' report (Actions, Issues, Risks And Decisions).

 

Key Metrics and KPIs

You may want to consider some key KPIs for your highlight report or dashboard and use them to track some of the aspects of your project. It will depend on your project and the value you put on them.


I'd suggest only tracking metrics that would make a difference or tell you something you can act upon. There are so many data points these days in various apps, etc., that it has become information overload, so choose carefully.


Here are some high-level suggestions.

Name

Description

What It Tells Us

How to Calculate

Schedule Adherence

Measures how closely the project follows the planned schedule.

Identifies delays and evaluates the impact of schedule changes.

Compare planned vs. actual project timelines.

Budget Variance

The difference between the budgeted cost of work and the actual cost.

Indicates whether the project is over or under budget.

Budget at Completion−Actual Cost

Scope Creep

Amount of unapproved changes or additions to the project's initial scope.

Controls the extent of additional tasks.

Track changes that are not in the initial scope.

Resource Utilisation

Efficiency in using available resources, including human resources, materials, and time.

Ensures optimal use of resources.

Actual Hours/Planned Hours

Quality Metrics

Measures the quality of deliverables through defect volumes, testing stages passed, etc.

Assures output meets required standards and specifications.

Define specific quality indicators and track failures.

Risk Management Effectiveness

Evaluation of how effectively the project identifies, manages, and mitigates risks.

Reduces the likelihood and impact of adverse events.

Evaluate risk incidents and mitigation success rates.

Stakeholder Satisfaction

Measures the satisfaction levels of key stakeholders with the project's progress and outcomes.

Maintains project support and aligns with stakeholder expectations.

Surveys and feedback scores.

Change Request Frequency

The rate at which changes are requested and approved within the project.

Indicates project stability and the effectiveness of initial planning.

Count of change requests over time.

Team Performance and Morale

Evaluates the efficiency and productivity of the project team, including morale.

High team morale and performance lead to better outcomes.

Assess through performance reviews and surveys.

  

Managing Scope and Handling Changes


During most projects, there will be requests for changes to the scope of the project's deliverables. There are a host of reasons, but typically, they will be due to;


  • Unclear or incorrect initial requirements

  • Stakeholders suddenly wake up and ask for something

  • Force Majeure (Translated as "Superior Force") means things that happen outside anyone's control. Floods, world events, etc.

  • A natural evolution of ideas and concepts occurs when we see them in reality.


Some of the above causes are controllable, and some are not. Some result from poor planning, which underlines the importance of good analysis upfront. Or maybe it was caused by not including the right people. It all underlines the importance of going through the earlier phases of the project in preparation for the execution phase of the project.


We call changes like this 'scope creep'. Sometimes it's clear and obvious, but often it's little things, tiny changes that add up and become project delaying 'death by a thousand cuts'. So, it needs careful management.


The ability to handle changes skillfully while your project is in flight can often be the difference between success and failure in delivering on time and within budget.


But what do you do when faced with changes that fly at you while you are knee-deep in a project?


Handling and Approval Processes for Scope Changes

Managing changes efficiently involves:


Ensure You Have a Change Control Process

Implementing a robust change control process ensures that every proposed change is evaluated, approved, or rejected through a structured process instead of just at the whim of someone who forcefully asks for something.


The change control system should outline who can approve changes and under what circumstances. It's not usually for the project manager to determine what is allowed in and out of scope, but rather the project owner/sponsor. However, it may well depend upon the nature and size of the change.


Carry out An Impact Analysis

Before any change is approved, its impact on the project's schedule, budget, and resources should be thoroughly considered.


An analysis of the change helps make informed decisions about whether the benefits of the change outweigh the costs. There must be a 'price' to a change. They don't come for free unless you are taking something out. Remember when we discussed the 'triangle of project management' in an earlier section? We can't change scope without an impact on time and budget.


Agile projects claim to embrace changes late into the delivery, which is excellent, but they only really reprioritise, pushing something down the to-do list of requirements. Agile can't magically change time and space to allow all changes to occur without some kind of sacrifice.


Ensure Scope Changes are Communicated

Transparent communication with all stakeholders about the implications of scope changes is essential. Make sure people know what and why.


This maintains trust and ensures that everyone understands the reasons for changes and their potential impacts on the project.


Sadly, I've run projects where the scope changes are agreed at a workstream level but don't filter down effectively to the people at the coalface, leading to confusion and disgruntlement. Or, a decision is made without consultation with the end-user or whomever you are delivering to, which has also been pretty bad.


Scope Reduction and the "MVP"

Virtually every project technique talks about scope creep like it's an increase in project deliveries, and to be fair, those are the ones that present the risk, but as your project gets closer to the delivery date and you realise that you aren't going to make it, then you may need to consider reduction of scope (among other actions).


In the latter phases of a project, you may need to lighten the project load like a hot air balloon trying to get over a hill, so you might try to drop some ballast.


I've done this many times, and it is a valid approach, but here are some things to consider;


  • Make sure you have approval from your project sponsor/team. Any project manager who makes decisions in isolation from those they deliver for will likely end up in hot water.


  • Consider your MVP very carefully. An MVP is a "Minimal Viable Product, " meaning "What's the most minimal solution we can go live with and meet our project's primary objectives?"


  • How does reducing scope impact future project deliveries? For example, you may have intended to deliver your project, high-five everyone, and go home, but if you say something is out of scope for go-live, you'll likely have to add another phase to mop up the loose ends. So, give it careful consideration and make sure the price is outlined to those making the decision.

 

What to do when things start to go wrong

Like so many of the concepts I've squeezed into this series of guides, I could write reams on this subject alone, but here are some basic pointers in the interests of brevity. 


When a project begins to veer off course, it can induce stress and uncertainty among the team. Effective management and strategic redirection can help salvage the situation and steer the project back to success.


Here are some strategic steps to consider when you find your project starting to go off the rails:


Acknowledge the Situation

The first step in addressing a faltering project is to acknowledge issues. Pushing your head into the sand and hoping things improve isn't an option.


Ignoring problems or delaying their acknowledgement will only exacerbate the situation. Early recognition allows for quicker intervention and minimises the risk of further complications.


Remember what I said earlier in another section? I hope so. There will be a test; "The problem is rarely the real problem. The response becomes the problem".


The sooner you advise your project sponsor and teammates of a problem, the sooner people can rally around and support a solution.


Assess the Extent of the Issues

Once issues are acknowledged, conduct a thorough assessment to understand their nature and extent.


This involves reviewing project timelines, budgets, resources, and the quality and scope of work completed. Identifying whether these problems are isolated or systemic will help determine the next steps.


Getting a good definition of the problem is also crucial. Be specific and write up a problem statement. In project talk, we call these 'exception reports' when something hasn't gone according to plan. You'll need to circulate it and ensure those nearest to the issue have an input in the report.


Communicate Openly

Maintain open lines of communication with your team and stakeholders.


Transparency about what's going wrong and what steps are being taken to address the issues can help manage expectations and maintain trust.


Regular updates and honest communication are critical in keeping everyone aligned and engaged during the troubleshooting phase.


Revisit Project Objectives

In times of trouble, revisiting the original project objectives is vital. This ensures that the project remains aligned with its initial goals and helps re-evaluate the feasibility of the existing timeline and deliverables. Sometimes, it's easy to get dragged off into a rabbit hole, but a little distance and perspective might show that it is not as critical as first thought.


Adjustments may be necessary, and defining what success looks like under the new circumstances is essential.


Prioritise and Focus

With a clear understanding of the current project state and objectives, prioritise tasks and focus on critical components. This might mean reallocating resources, halting less critical tasks, or revising the project scope to concentrate on core functionalities or deliverables.


Timebox assessments, actions, etc, so that it's clear when there will be updates and how much effort can be put into the assessment.


Implement Corrective Measures

Based on the assessment and re-evaluation, implement corrective measures. This may involve setting up additional resources, changing project management methodologies, or employing new technologies. Establishing clear, achievable milestones and enhancing monitoring are also valuable for keeping the project on track.


Learn from the Experience

Every project, especially those that encounter difficulties, provides a learning opportunity. Conduct a post-mortem analysis once the project is back on track or completed.

Discuss what went wrong, what worked in the recovery process, and how similar issues can be prevented or mitigated in the future.


Provide Support and Motivation

It's crucial to support and motivate your team throughout this process. Challenges can demoralise team members, so positive reinforcement, acknowledging their hard work, and celebrating small victories can boost morale and productivity.


Leverage Professional Advice

Don't hesitate to seek external advice or consulting if the situation is beyond the team's expertise. Sometimes, fresh eyes can provide new perspectives and solutions that internal team members might overlook.


Be Prepared to Adapt

Flexibility is vital in project management.

Be prepared to adapt your strategies as the project progresses. Responsive and dynamic approaches can help manage unforeseen challenges more effectively.


Comments


image.png

Play Crossy Chicken

Never miss another article.

About the author

Alan Parker is an IT consultant and project manager who specialises in IT governance, process implementation, and project delivery. With over 30 years of experience in the industry, Alan believes that simplifying complex challenges and avoiding pitfalls are key to successful IT management. He has led various IT teams and projects across multiple organisations, continually honing his expertise in ITIL and PRINCE2 methodologies. Alan holds a degree in Information Systems and has been recognised for his ability to deliver reliable and effective IT solutions. He lives in Berkshire, UK, with his family.

bottom of page