Chapter 11. Monitoring and Controlling
11.1 Monitoring and Controlling Project Work
Before the project gets approval to continue, business (or systems) analysts, or a team of analysts and product owners combined with representatives of business units and other relevant stakeholders create a business case and benefits realization management plan. Project managers may also participate in this process if the organization has a PMO (see Chapters 2 and 3). At the very beginning of the project, that is the initiation phase, the project charter is prepared, and with the approval of the project sponsor and the client, project plans are built upon those documents and processes in order to elaborate on the main pillars of the project (i.e., scope, schedule, cost, quality, risks, resources, and stakeholders). While establishing a strong baseline is a key factor in project success, ineffective monitoring and controlling can spoil all the efforts that were done to establish this strong baseline. Let’s remember the causes which lead to project failure to meet the project activities as discussed in Chapter 1 under “1.4 Project Success”. According to the PMI 2020 Pulse of the Profession report[1], the factors responsible for the failure were listed as a lack of clearly defined and/or achievable milestones and objectives to measure progress (37%), poor communication (19%), lack of communication by senior management (18%), employee resistance (14%), and insufficient funding (9%). The monitoring and controlling process relies on clearly defined milestones and objectives to measure progress. One of the key responsibilities of a project manager is to monitor and control all the project work and ensure that everything is on track. This process consists of tracking, reviewing, and reporting the overall progress to meet the performance objectives defined in the project management plan[2].
It is important to note that it is much easier to monitor project success on small projects. Due to far fewer team members, stakeholders, and complexities to consider, the project’s progress is more easily observed. However, on higher complexity projects that require many people, who are often spread out over different locations, project leaders are unable to use simple observation to assess progress. In these instances, it is important to have more robust tools and techniques (see sections 1.2 and 1.3 for qualitative and quantitative monitoring tools) that monitor the success of the full project team.
The project team evaluates its performance against the plans that have been developed. Every project requires a monitoring and control system. This system considers the following:
- What information is needed and how should it be collected?
- When (and with what frequency) should this information be collected?
- Who should collect and analyze this information?
- How should this information be represented from a reporting perspective?
- Who should prepare the reports?
- Who should receive the reports?
Monitoring and controlling project work allows stakeholders to understand the current state of the project, recognize the actions taken to address any performance issues, and have visibility into the future project status with cost and schedule forecasts[3]. It is important to note that it is much easier to monitor the progress and performance issues on small projects. Due to far fewer team members, stakeholders, and complexities to consider, the project’s progress is more easily observed. However, in more complex projects that require many people, who are often spread out over different locations, project leaders are unable to use simple observation to assess progress. In these instances, it is important to have more robust tools and techniques that monitor the success of the full project team (see Sections 11.1.2, 11.2, and 11.3 below).
11.1.1 The Difference between Monitoring and Controlling
Although the process is traditionally named “monitoring and controlling”, we should know that there are differences between these two concepts. Controlling cannot be carried out by the project team if monitoring has not been done properly or at all. Thus, monitoring leads to controlling while controlling may require more monitoring if controlling determines that sufficient information couldn’t be derived from the monitoring process.
Let’s clarify the distinction between monitoring and controlling.
Monitoring[4]
- Collecting project performance data
- Producing performance measures
- Reporting and disseminating performance information
Controlling[5]:
- Comparing actual performance with planned performance
- Analyzing variances
- Assessing trends to affect process improvements
- Evaluating possible alternatives
- Recommending appropriate corrective action as needed
As seen above, we collect the data and analyze them to create performance measures. For example, our project dashboard can indicate our current status regarding the schedule and budget. We can also have a detailed Excel file exhibiting our day-to-day activities and actual costs. If this data is produced properly, we can continue with the controlling first by comparing the actual performance with planned performance, that is the project baseline. After we evaluate the variances and trends, we can evaluate possible alternatives to recommend corrective actions.
Monitoring and controlling process involves regularly measuring progress on a project to ensure it continues meeting objectives and addressing current organizational needs. It involves determining what corrective action is required, when it must occur, and who must do it. Monitoring begins at the very beginning of the project (initiation) and increases in density in the planning phase because it is easy to get off track with planning efforts (Figure 11.1). Besides, the execution of project activities would need a considerable amount of attention from the project manager and team to monitor and control activities and performance measures (Figure 11.1). When the traditional predictive/waterfall development methodology is used, the team monitors performance against the timeline, budget, scope, and quality objectives for the entire project. When an adaptive approach is used, progress within the iteration is assessed (see Chapter 12).
11.1.2 Tools Utilized to Conduct Effective Monitoring
Effective monitoring requires an effective system that allows the project team to collect performance data accurately and with minimum errors. The commonly collected information includes the status of the project budget and the project schedule. The work completed to date, what has yet to be completed, and the likelihood of completing the project on time and within budget are of particular interest. How this monitoring is performed quantitatively will be detailed below in 11.3 “Earned Value Management”. In addition, it is important to identify the risks and issues that require attention. Whenever possible, information technology should be used to collect and analyze the information and distribute the reports. Different organizations require different roles to collect and analyze the project information. In organizations with a project management office (PMO), PMOs may be accountable for progress reporting in an “end-to-end” way, meaning they would be involved from information collection all the way to report distribution. Organizational policies (from a formal perspective) and organizational culture (from an informal perspective) influence who and how progress monitoring is performed.
One of the common methods used to monitor progress is team meetings. Team meetings are highly collaborative and serve many purposes, including information sharing and team development. Depending on the nature of the project, these meetings may be focused exclusively on sharing the status of tasks underway. It is also possible for status discussions to lead to team planning. The individuals who participate in these meetings vary depending on many factors, such as development methodology in use, organizational culture, project complexity, and status of the overall project. The frequency of team meetings is pretty higher in agile (adaptive) projects than the traditional (predictive/waterfall) projects in order to ensure agility, flexibility, on-time interventions, and timely feedback from team members and the product owner. For example, agile teams, in particular Scrum teams, have daily standups to discuss what has been completed since the last standup meeting, what is planned to complete until the next meeting, and what the impediments, risks, and problems that members may encounter are (see Chapter 12, Section 12.2.2).
Project teams typically develop different reports for different stakeholders. Stakeholders who have a high interest and high power/influence will receive more information, more frequently (recall the stakeholder power/interest grid presented in Chapter 5). Depending on the priority and duration of the project, the reporting frequency could be daily, weekly, monthly, or quarterly.
We can mention three different types of project reports as follows:
- Status reports – where the project stands at a specific point in time
- Progress reports – what the project team has accomplished during a certain period
- Forecast reports – future project status based on current project status and known trends
Tables 11.1, 11.2, and 11.3 exhibit short examples of status, progress and forecast reports, respectively, based on our example of the overall case discussed throughout the book (see Section 1.2.4 “Case Study 1.2: Characteristics of Another Project Undertaken by Grocery LLC (M-Commerce Project)”).
Table 11.1: An Example of an Overview based on a Status Report[6]
Period | May 27, 2022 – July 7, 2022 | ||
Team Name | Grocery LLC M-Commerce Project Team | ||
Status Report Prepared by: | Project Manager | ||
Overall Status: | Green — On Track | Yellow — Caution | Red – Problem |
Table 11.2: An Example of a Progress Report[7]
Activities/Deliverables Completed Since Last Reporting Period
WBS # | Activity Name | Duration | Date Completed | Comments |
2.1 | Review needs analysis based on the business case | 3 days | Tue 5/31/22 | The review has some issues due to the missing key points in the preceding activities. However, the team worked very well to compensate for the delay. No delay was experienced. |
2.2 | Elicit requirements from stakeholders | 10 days | Sun 6/10/22 | It finished two-day earlier than its planned 6/14 schedule. |
2.3 | Draft preliminary stakeholder specifications | 7 days | Tue 6/21/22 | An additional two days were added from 2.2. |
2.4 | Review specifications with team and stakeholders | 5 days | Tue 6/28/22 | Finished on time. |
2.5 | Incorporate feedback on the specifications | 3 days | Fri 7/1/22 | Finished on time. |
2.6 | Develop a preliminary budget and delivery timeline | 3 days | Wed 7/6/22 | The one-day delay was experienced due to the absence of a representative from the budget department. |
2.7 | Obtain approvals to proceed (concept, timeline, budget, resources) | 1 day | Wed 7/6/22 | The meeting with the sponsor took 3 hours. The sponsor was convinced that we could proceed with the activities under the third component “Design”. |
2.8 | Analysis complete | 0 days | Thu 7/7/22 | Milestone achieved. |
Table 11.3: An Example of a Forecast Report[8]
Activities & Deliverables for the Next Reporting Period
WBS# | Activity Name | Duration | Date to be Completed | Comments |
3.1 | Review preliminary stakeholder specifications | 3 days | Mon 7/11/22 | Stakeholder Z (high power, high interest) notified us of some serious conflicts in the preliminary stakeholder specifications. We may expect a 2-day delay. The sponsor should be informed immediately. |
3.2 | Develop solution (functional and non-functional) specifications | 5 days | Mon 7/18/22 | Developer 1 may not be available during this activity. Therefore, a developer must be kept as a substitute to ensure attendance. |
3.3 | Develop transition requirements | 2 days | Wed 7/20/22 | No delay is expected. |
3.4 | Develop design mockups based on specifications | 5 days | Wed 7/27/22 | Stakeholder Z may have some objections. Project member 2 will be assigned to communicate with this stakeholder. |
3.5 | Review specifications | 2 days | Fri 7/29/22 | The same issue with Stakeholder Z. |
3.6 | Incorporate feedback into specifications | 2 days | Tue 8/2/22 | The same issue with Stakeholder Z. |
3.7 | Finalize project management plan | 8 days | Fri 8/12/22 | Based on the stakeholders’ feedback, we may experience delays. |
3.8 | Design complete | 0 days | Mon 8/15/22 | No comments. |
- PMI (2020). Ahead of the Curve: Forging a Future-Focused Culture. Pulse of the Profession. Retrieved from https://www.pmi.org/learning/library/forging-future-focused-culture-11908 ↵
- Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. ↵
- Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. ↵
- Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. ↵
- Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. ↵
- Interthink. (n.d.). Project HEADWAY Project Team Status Report. Retrieved from https://www.projectmanagement.com/deliverables/235123/project-headway-project-team-status-report ↵
- Interthink. (n.d.). Project HEADWAY Project Team Status Report. Retrieved from https://www.projectmanagement.com/deliverables/235123/project-headway-project-team-status-report ↵
- Interthink. (n.d.). Project HEADWAY Project Team Status Report. Retrieved from https://www.projectmanagement.com/deliverables/235123/project-headway-project-team-status-report ↵