Is the Project Monitoring and Control Process Ares compatible with Agile?

Introduction

The Project Monitoring and Control area, a process area at maturity level 2, aims at understanding the project’s progress and taking corrective action when the project’s performance deviates significantly from the plan.

Below are the specific goals and practices:

SG 1 Monitor Project Against Plan

SP 1.1 Monitor Project Planning Parameters

SP 1.2 Monitor Commitments

SP 1.3 Monitor Project Risks

SP 1.4 Monitor Data Management

SP 1.5 Monitor Stakeholder Involvement

SP 1.6 Conduct Progress Reviews

SP 1.7 Conduct Milestone Reviews

SG 2 Manage Corrective Action to Closure

SP 2.1 Analyze Issues

SP 2.2 Take Corrective Action

SP 2.3 Manage Corrective Action

SG 1 Monitor Project Against Plan

This goal states that there should be a way to compare actual performance, against what was established in the plan. Among the things that are measured are project planning parameters,  commitments, risks, stakeholder’s involvement, progress reviews and milestone reviews.

I believe in Agile, there is a shift from traditional management in who does the monitoring, how it is performed, what is measured and also in the objectives of the monitoring. These changes should be reflected in the process maturity framework.

First, who does the monitoring and and how it is performed? In Agile, this is the not the responsibility of the Project Manager, but of the entire team. Agile has 2 main practices that enable monitoring that are very effective because they encourage self-organizing teams (increasing accountability and enthusiasm as a side effect). The first enables day to day monitoring and is called Scrum daily meeting if you come from the Scrum world or standup meeting if you come from the XP world (though in Argentina, most of the people call it “the scrum”). In this meeting, the team as a whole “monitors” how it is doing with the tasks, which are the blocking issues and how is the iteration progressing. It is important to stress that there isn’t a central authority to report to in this meeting. It is strictly a team’s meeting. The second monitoring meeting practice is the retrospective. This meeting happens after each iteration and enables to monitor how the team performed in the iteration and so far in the project. This meeting allows for a more thorough “monitoring” or introspection as we like to call it and bigger corrective actions can be taken. Another practice suggested for monitoring is the use of Visual Radiators which allow anyone to constantly monitor the project’s progress.

What is measured? As the Project Planning process area suggests an activity based project plan, the project monitoring suggests to monitor “the activities and milestones”. As previously said, Agile does not encourage activity-based plans. Basically, work products that don’t deliver business value aren’t really considered progress in Agile terms. So what should be measured? Certainly, the best measure of progress is to be able to measure how much business value has been delivered. Although this is really difficult (and I must confess I’ve never done it), there are techniques that allow to monetize the value of the features (see Value Point Analysis in Highsmith's Agile Project Management book). Another measure is effort, but it should be stressed that progress is made when running, tested and customer accepted features that deliver value are completed. Progress should be tangible. Intermediate work products don’t represent progress.

Finally, what about the objectives? A successful project is not one whose measures match the plan, but the one that delivers the value expected by the customer. Bjarte Bosgnes, in Implementing Beyond Budgeting asks a simple question, “What is the best performance: delivering 100 against a target of 100, or delivering 105 against a target of 110?”. Most people would agree that 105 is better than 100, however most performance measurements systems would call 105 against 110 target a failure [from Agile Project Management]. As Highsmith states in his book, I believe an agile process maturity framework should shift its objectives from the constraints (scope, schedule, cost) to delivering value.

There is another topic within this goal that I would like to tackle. CMMI suggests to record actual parameters to be used as historical data. Something I am afraid of when measuring actual parameters (actual times) is to use them as a pressure mechanism. I believe that measuring actual times of taks and comparing them to estimated times lead to dysfunctional behaviours that damage the project (like overestimation or cutting corners - dropping quality - to achieve those times)

SG 2 Manage Corrective Action to Closure

The second objective states that corrective actions should be managed to closure when project’s performance or results deviate significantly from  the plan.

What does it mean that corrective actions are “managed” to closure? It means there is a manager that assures that the actions take place. How do we get that assurance in Agile, inside a self-organizing team without a manager per se? People inside the team should be hold accountable for leading the corrective actions to closure. This, in my experience, is sometimes difficult as the informality of the process sometimes leads some people to not take the corrective actions seriously (specially in less mature teams, previously used to command and control structures). However, as CMMI states, corrective actions should be closed and there should be a mechanism that forces the team to do so.

Conclusion

Monitoring and taking corrective actions are necessary within any project. The way CMMI suggests to do it seems very oriented to traditional project management. Agile project management takes a big shift in what is measured, how it is measured and in the objectives of measuring. This should be reflected in the process maturity framework to be compatible with Agile.