The primary results of the Monitoring and Controlling processes are the project performance reports and implementing project changes. The focus for project management is the analysis of project performance to determine whether a change is needed in the plan for the remaining project activities to achieve the project goals. In my experience, almost every project will require a change to the plan at some point in time. Traditional projects are the most stable projects because the requirements and the activities are clear and well understood. Adaptive and Extreme projects are the least stable. They require very close control and will require numerous changes - if for no other reason the project manager will need to refine the activities of later phases based upon the results of early activities.
Tools and techniques that are used by project managers to conduct the Monitoring and Controlling of a project fall into one of four general categories. The first is the collection of project performance information. Techniques supporting this category are Pulse Meetings, Variance Reports, and Program Reviews. The second category is the analysis of the project performance to determine whether a project change is needed. Techniques that are used in this category are Technical Reviews, Project Forecasting and Problem Solving. The third category is reporting on project performance. Techniques that support this activity include the use of a Project Management Information System, Management Reviews, and Dashboards. The final category is the management of project change. The technique I commonly use in this category is the maintenance of a Change Management Log. There are two areas of project management tools and techniques that closely support the Monitoring and Controlling process but are also used more broadly throughout the project lifecycle. These are important enough to justify their own page.
Project Communication Tools and Techniques
Earned Value Analysis
Pulse Meetings
Pulse meetings are short team status meetings where the project management team is able to gather project performance information about the activities that are underway. These meetings should occur frequently and can either be face-to-face or virtual. Normally they are only a few minutes in duration. During the meeting, the beginning and completion of project activities is reported. In addition, the status of any activities that are underway is communicated to the rest of the project management team. Issues on any of the ongoing activities are identified, however, the issue resolution occurs at a separate meeting with the appropriate individuals present. The issue resolution meeting may immediately follow the Pulse meeting, but it is clearly a separate meeting and those project team members who are not needed for issue resolution do not need to attend. The frequency of the Pulse meeting is determined based upon the status of the project. When in an Extreme mode, the Pulse meeting may be happening several times a day. Projects that are running smoothly may only need to have a Pulse meeting once a week.
Variance Reports
Variance reports are formal reports generated by the PMIS, by the Earned Value Management System, one of the other business management systems - such as the quality control system, or by a project supplier. Variance reports compare what has actually happened on a project against what was expected to have happened on the project. A variance report typically indicates both the absolute value of the difference and a percentage representation of the difference.
The actual performance achieved on a project activity (such as cost or duration) seldom precisely matches the estimated performance set at the time of project planning. The page on Estimating explains why project estimates are seldom precisely accurate. However, since the estimates often aren't accurate, it is imperative for the project management team to identify the variances in order to know what is actually happening on the project. The variances can uncover both positive and negative project risk.
Project variance reports often are expressed with two references. The first reference is what was supposed to have happened since the last reporting cycle. This is often called the "Current Period" variance. It is an indication of how well the project resources were able to conduct project activities in accordance with the project plan in the recent past. The second reference is what was supposed to have been done on the project since it started. This is often called the "Cumulative" variance. It is an indication of how well the project resources have been able to conduct project activities throughout the project lifecycle. The cumulative variance will have embedded in it any previous variances - either positive or negative. The current period variance provides a clear representation of what is happening right now on the project. The cumulative variance eliminates the effects of any short term conditions, either good or bad, that effected the project during the most recent reporting period. Both variances provide useful information.
Program Reviews
Program Reviews are meetings with the project team members and sub-project leaders that review the current status of the program as compared to the original program plan. These are most often used on Full-scale and Complex projects. Unlike the Pulse Meetings which focus on day-to-day activities, the Program Reviews focus on the big picture and emphasize the integration between activities and between sub-projects encompassed within the program. The question being asked is whether the program activities and the sub-projects are likely to interfere with each other. In addition, when I have a supplier who is a major contributor on the program and is performing customized work on this program, I will conduct Program Reviews with the supplier for their portion of the program. Program Reviews are sometimes combined with Management Reviews. I do not recommend this approach. The danger with this approach is that key stakeholders and managers may intimidate some project team members from providing a frank and honest appraisal of the status of program work.
Technical Reviews
Technical Reviews are formal meetings conducted with subject matter experts who are not members of the proejct team. These are in-depth reviews focused upon a technical aspect of the project. Examples would be Desgin Reviews, Code Reviews, Security Reviews, or Production Readiness Reviews. The reviewers should perform an in-depth analysis of the project deliverables and activities to determine whether the project work has been accomplished completely and correctly. These reviews will normally generate a list of actions that must be completed. These actions may require additional testing or analysis. In some cases it may even require redesigns of systems, software, processes or products. The results of these reveiws are normally reported to senior management at the next Management Review. In many cases, the technical review must be completed before a project can proceed to a toll-gate meeting. When the Technical Review is linked to a toll-gate meeting, the action items do not need to be completed prior to the toll-gate. However, any open action item is listed on the risk register and the plan for resolving that action item is included in the project plan for the next phase.
Project Forecasting
Project Forecasting consists of taking the project status information and extrapolating the current project performance to the end of the project. Forecasts can be made with respect to project duration, overall project cost, performance/quality level of project deliverables, or any combination of these. A key element in forecasting is to review the risk events that occurred and the remaining risk triggers. A deeper discussion of this is found on the Project Risk Management page. A caution when doing forecasting, ensure you have adequate information to realistically forecast performance. My personal rule of thumb is that I wait until an activity, phase, or deliverable is at least 25% complete before I try to forecast. Prior to that point I stick with the original estimate, modified by any appropriate risk mitigation activities that have occurred.
When forecasting project duration, the key is to understand the schedule performance and schedule risk of the activities on the critical path. Those activities will be the ones that drive the project completion date. On a resource constrained project, or a project with unpredictable resource availability, this can be very difficult because the lack of resources causes the critical path to vary. I have not found a good robust tool for forecasting schedule in this condition. It generally comes down to expert judgment and gut feel. When it is vital for the project to complete by a certain date, I often will convert my schedule tracking to a countdown mode where everything is measured in terms of how many days before project completion. Also, I will Pulse the project more frequently in order to quickly assess when I believe we are falling behind. If that sounds like micro-management it is because that is micro-management.
When forecasting total project cost, I prefer to use the forecasting methods that are embedded in the Earned Value Management system. Unfortunately, many organizations do not have the financial systems in place that enable earned value management. When that is the case, I am forced to rely on trend forecasting - which is sometimes called "straight-line" forecasting. Trend forecasting takes the current project spending and extrapolates that rate of spending until the end of the project. This provides a rough forecast, but it does not take into account the effect that different activities may require resources that spend at different levels. The resources that perform the remaining activities may be higher or lower cost than the preceding resources. Also, it does not take into account that the project may be ahead or behind schedule. If the project is ahead of schedule, the spending done to achieve that condition inflates the extrapolated value of the project final cost. If the project is behind schedule, the lack of spending creates an extrapolated value of total project cost that is too low.
When forecasting the performance or quality of project deliverables, I rely heavily on prototypes and preliminary analysis. When the project does not have these, the risk that the project will not achieve the desired performance or quality established at the time of project planning is higher. If performance is the most important attribute of the project deliverables, then the risk of missing the forecast project duration or cost is much higher. The principle involved is the "Rule of Ten's." According to this principle, the cost to correct a technical issue goes up by a factor of 10 as the project moves from one phase to the next. Therefore it is imperative that performance issues be identified as early as possible.
Problem Solving
Problem Solving is a very broad topic. There are dozens of approaches to problem solving. My rule of thumb with respect to this technique is that if you have a process that works for you, use it! I recommend you have an agreement with your project core team members or key project stakeholder concerning the problem solving process that will be used. Will it be team-based or individually driven? Will you use a process that relies on data from past projects or only on data from this project? Once a root cause is determined, how will recovery actions be identified and approved? As I said, there are many problem solving methods and their answer for these questions and others is different. From my standpoint, the most important point is that you have a process to address issues, rather than jumping to conclusions or worse yet, ignoring the problem until it is a crisis.
If you don't already have a problem solving process, may I suggest this one that I refer to as CIV2:
1. Clarify: Clarify the problem. In which part of the project did it occur? Who was involved? When did it happen?
2. Investigate: Investigate the details about what happened. Gather data from both the project activity and the surrounding environment. Determine the root cause(s) of the problem.
3. EValuate: Evaluate the options to address the problem. Consider the impact on the project objectives that each potential solution would likely have. What new risks are associated with each potential solution.
4. Choose: Choose among the viable solution/recovery paths. If necessary, coordinate the decision with key stakeholders. This must be done whenever the solution will impact a boundary condition of the project.
5. Implement: Implement the selected solution/recovery path. Modify the project plan with respect to any changes in scope, resources, or scheduled dates of any activities. Update the risk register.
6. Validate: Validate that the solution/recovery path is achieving the desired results.
Project Management Information System
The Project Management Information System (PMIS) was discussed in detail on the Executing Tools and Techniques page. The PMIS is the set of communicating methods used by the project team to share plans and results of project activities. The PMIS can either be a physical system or an electronic system. Either way, the PMIS is used as the clearing house of information on the project including; project plans, project status, project risks, project changes, project meetings, and any other information that project management team believes is relevant to the project team.
Management Reviews
Project Management Reviews are formal documented meetings with the project team and key stakeholders that review the current status of the project as compared to the original project plan. Unlike the Pulse Meetings and Program Reviews which are data gathering meetings that focus on understanding the current status of the project, the Management Reviews are with key stakeholders with the emphasis being on whether the project performance is adequate for the project to deliver on the overall project objectives. Often if the project has encountered issues, such as resource constraints or scope creep, the stakeholders conducting the review are able to provide assistance to the project team to overcome these issues.
The format for these reviews is usually set by the stakeholders and addresses the topics that are most important to them. The review may be a formal stand-up meeting, it may be an informal discussion setting, a written report, or an update to an electronic dashboard. Regardless of the method used, these are formal status reporting meetings and need to be treated as such. The project manager should keep an Action Item list or Stakeholder Issue log for any questions that arise in these reviews. Also minutes from these meetings should be maintained as part of the project records.
Project Dashboards
Within a project team, Dashboards were used by project managers to focus the project team on the few key items that would drive project performance. Therefore the current critical path activity is tracked for schedule status, the current activity with the most uncertainty in resource requirements is tracked for cost status, and the most challenging activities are tracked for project performance/quality. This is an excellent use of dashboards, especially when working with a virtual project team.
As more organizations decided to manage their projects as a portfolio of projects, they have recognized the need to have a means of measuring the projects in the portfolio both against each other and with respect to their objectives. The dashboard offers that mechanism as each of the projects report on key metrics that are used by the senior management or Project Management Office to check the status of the projects. Often the dashboard measures the status through the "Red light - Green light" method. This type of scoring uses colors to indicate project status on the key measures. A "Green light" indicates that everything on the project is going according to plan. A "Yellow light" indicates that there are some problems, but the project team is working the situation and should be able to contain the problem. A "Red light" indicates that the problem is so severe, the project team cannot resolve the problem and achieve the project objectives without help from the stakeholders. The senior management team and PMO use the Dashboard to make resource allocation decisions and to call special Project Management Reviews.
Change Management Log
This tool is very straight-forward. The need for it increases as the project complexity increases. I can't imagine running a Complex project without one, but I have never used one on a Simple project. The necessity on a Complex project is because these projects are managed as a set of Focused and Full-scale sub-projects. The boundaries between these sub-projects will inevitably need to change as projects progress. Sometimes the changes are due to shifting milestones. Sometimes the changes are the result of activity deliverables that are passed between the projects. In any case, the changes in one sub-project cascades into changes in another sub-project. The Change Management Log tracks the implementation of the change across the sub-projects. It can also track the implementation of the change within a project, especially if the project activities are conducted in multiple locations or if there are multiple phases underway at one time. Using the Change Management Log is similar to using an action item list. Each item is tracked to ensure it has been completed.
