Monitoring and Control
In this phase of the project, the project manager is a bit like a chef in a test kitchen. In the same way that a chef will follow a recipe, measure ingredients, taste, and adjust; in this phase, the project manager is measuring progress, analyzing the results, reporting on the progress, and taking corrective action to address any issues that arise. Close monitoring at the beginning of the project is essential because issues can be identified with enough time for the schedule and budget to be adjusted. This may not be true later in the project when timelines and budgets are nearly exhausted.
Tools and Techniques
Monitoring involves tracking the activities that were planned using the tools and techniques found in the implementation phase of the project—such as project status and individual meetings, Open Task Log, Change Log—and communicating that information to people at every level of the project. Project managers should use the protocols laid out within the Project Charter and Communication Plan (see “Implementation” section) to effectively get the information to the team members and leadership, within expected timeframes and using the agreed-upon methods of communication.
Tools to display progress on the schedule, such as a project dashboard or a Gantt chart, will help visualize the progress for team members and leadership in the state or territory. However, individual check-ins give the project manager insight into the progress of individual activities within the Work Breakdown Structure. Additionally, peer reviews or buddy checks can be used to check on work that requires subject matter or technical expertise that the project manager does not possess. These should be used as a friendly review rather than an opportunity to second-guess the work of a colleague.
It’s important to have both the high-level and close lenses so that details aren’t missed but managers and leaders aren’t bogged down by minutiae. Project management software often allows for tracking at a detailed level and feeding that information into visually pleasing status dashboards that are easier to digest for leaders within the agency.
Change and Risk
Some organizations have protocols for change management within a project that outline what type of changes to a project may trigger a level of decision above the project manager. The change management protocols often include the formation of a “change board,” which is a group of people who meet regularly to review and consider changes to a project within a certain limit of authority. If such a practice is utilized in an organization, the project manager must research and follow the established protocols for establishing a new change board or utilizing the existing change board for each project.
A record of all modifications to the project called a Change Log (see Table 5 for an example) should be kept to document adjustments from the original plan. Keep a close eye on the changes and their impact to the overall budget and schedule because small changes can result in Scope Creep, which is “adding work, little by little until all the original cost and schedule estimates are completely unachievable.”[4] Additionally, some state or territory protocols require the original charter or Statement of Work to be amended if there are significant changes to the project.
Table 5. Change Log Example
Change Log for Licensor Training Project
Change #
|
Description
|
Requested
By
|
Approved
By
|
Date
Approved
|
---|---|---|---|---|
1 | Addition of new chapter in training manual on protocols for coronavirus disease 2019 (COVID-19) | Geri | Saul | 11/1/2021 |
2 | Purchase of duplicate handbooks for training pilot | Nina | Deena | 12/15/2021 |
3 |
Decreasing the number of participants in the pilot training | Saul | Sally | 1/15/2022 |
When dealing with the risk of an issue arising, the project manager can use four strategies:
- Avoid: Modify plans to avoid the risk completely. For example, avoid the risk of a contract being delayed in procurement by doing the work in-house.
- Transfer: Move the risk from the agency to another entity. For example, some organizations may transfer the risk of holding a workforce training event that includes child care by contracting with an outside entity to provide the care rather than take on that risk themselves.
- Mitigate: Create strategies to address the risk, should it arise, such as a Plan B. For example, the plan may be to implement a program as soon as the budget passes. However, if the legislature delays the passage of a budget, a contingency plan is made for late implementation.
- Accept: Some level of risk will always be present within projects. The level of tolerance to this will vary by agency. For example, on any project, there is always a risk of key staff people leaving the state or territory Lead Agency. This level of risk may need to be accepted.
The best way to address risk is to plan thoroughly and account for some variance in the schedule, and budget through contingency.
Cost and Schedule Variance
When monitoring a project, data must be collected on both cost and schedule progress. Spending on the project does not equate to completed work. A simple calculation can be used to measure the variance for the cost and the schedule. See the example in Table 6.
Table 6. Cost and Schedule Variance Example
Task |
Budgeted Cost |
Budgeted Time (in days) |
Actual Cost |
Actual Time (in days) |
---|---|---|---|---|
Task A | $1,000 | 10 | $1500 | 7 |
Task B | $2,000 | 15 | $2000 | 15 |
Task C |
$10,000 |
5 |
$9,500 |
6 |
Task D | $500 | 1 | $1,000 | 1 |
Total |
$13,500 |
21 |
$14,000 |
29 |
In this example, the project manager is looking at the difference between the budgeted versus actual costs and work one month into a year-long project. The actual costs are only over-budget by 4 percent, which may not be cause for alarm since the project is only one month in, and they may be recouped later in the project. However, the schedule is 38 percent behind expectations, which is significant. For projects, these calculations can be used to set benchmarks for elevating issues to higher levels within the project.
For example, an organization may set a benchmark variability of 5 percent. A project that is within 5 percent of budget and schedule may allow for the project manager to continue without adjustment. However, if it hits a threshold of 6 percent, that may be cause for escalation to the next level of management. The specific threshold for escalation can be set either by project or by the agency as a rule to give a more tangible measure of project progress than simply the expert judgment of the project manager. In any case, both the spending and the schedule must be viewed in tandem to get a complete picture of progress.
Once an issue is identified and a plan to respond is formulated and approved at the appropriate level, the project manager must then go back into the planning documents and adjust the schedule, budget, and Work Breakdown Structure to account for the variance to the plan. They must also add it to the Change Log and communicate the change to all players involved in the project to ensure continuity on the project.
[4] Fair, J. (2012). Agile versus Waterfall: approach is right for my ERP project? [Paper presentation]. PMI Global Congress 2012—EMEA, Marseilles, France. Project Management Institute. https://www.pmi.org/learning/library/agile-versus-waterfall-approach-erp-project-6300