Introduction
A critical role of the Project manager is determining how well a project is performing against the project plan. The outcomes established in the project plan need to be monitored constantly . It is not as easy to establish when a project is going well sometimes because everything is ticking over like clockwork. It is when a project is not performing well that it becomes obvious with time delays, cost overruns, and other issues.
Project Monitoring and Project Control
Anything requiring monitoring needs a robust system to collect the information and provide the analysis of what is happening. The structure of the system should remain constant throughout the project so any changes do not create false flags compared with previous data. The system must also be reliable enough to help identify information that may indicate the project is not going well.
Any project monitoring system needs to identify three particular categories of data:
- Who will collect the data?
- How and when the data will be collected
- What analysis and reporting is required?
Larson and Gray (2020) identify four steps in the process of project control. These are:
- Establishing a baseline plan
- Measuring the progress and performance
- Comparing the plan against actual performance
- Taking action
Monitoring Time Performance
When it comes to projects, there are two basic performance measures which are time and cost. The original project plan establishes estimates of all times, costs and resources along the critical path of the project. Using a Gantt chart is one easy method of doing a comparison of the planned progress against actual progress.
A Control Chart simply monitors the difference between actual and planned performance. Although the Gantt chart considers completed task durations, the Control chart only shows any difference that exists between the projected and actual. Both have their place, but the Control chart indicates performance trends more clearly and allows the addressing of issues before they get out of hand. The Gantt chart demonstrates these trends, but not as clearly.
Figure 1: Gantt Charts for Tracking Project Activities
Figure 2: Project Schedule Control Chart
Earned Value Management
Development of EVM Cost/Schedule System
A project manager needs to know the costs incurred in project delivery during the project. Earned Value is the concept of project costs over a particular time frame. The Earned Value is the amount of money you can expect to be paid as a project manager based on what work has been completed. The payment is based on the budgeted costs of the project, not actuals. Earned value amount is a cumulative figure that increases over the life of a project.
The Earned Value Management model uses several acronyms that are worthy of note for reference.
Figure 3: Glossary of EVM Terms
A Project Cost/Schedule graph as shown in the Figure below, plots the actual project costs, the planned baseline costs and the earned value at a particular point in time. Using the graph, the schedule variance can be clearly seen and also the cost variance against the earned value. The project shown in the Figure below would appear to be experiencing cost overruns and issues with time.
Figure 4: Cost/Schedule Graph
The video below goes through an explanatory process of what makes up Earned Value Management.
Developing Status Report for Progress Monitoring
A status report contains details of a project’s progress at a particular point in time. The text cycles through the development of a status report using various images.
Figure 5: Work Breakdown Schedule with Cost Accounts
The WBS above shows the project broken down into six deliverable components and the five cost departments.
Figure 6: Digital Camera Prototype Project Baseline Gantt Chart
Figure 6 then breaks the project down into a Gantt chart showing the project allocated over a time frame of 11 units, which could be days, weeks or months.
Figure 7: Digital Camera Prototype Project Baseline Budget ($000)
Figure 7 demonstrates the project based on an early start and the effect that has on the budgeted baseline.
When developing the status report, tasks are in one of three states:
- Not yet started
- Finished
- Work in progress
Calculating the earned values for the first two states are easy in that any work not started equates to zero and those completed equate to 100% of their PV. Any work in progress is calculated on the basis complete to the PV baseline and this is used to calculate the EV.
Forecasting Final Project Cost
Projects will have variations in costs as the project progresses. For this reason, it is important to have an ongoing idea of what the total projected project cost will be on completion. Such work is always performed by experts in this area. However, for clarity, there are two methods for calculating the final project cost. The first is the revised Estimated Total Cost At Completion (EACrev). This method depends on expert calculations of any remaining activities on a project. However, because of the complex nature of applying such work to hundreds of tasks, it is limited to smaller projects.
The second method used is the Cost Performance Index (CPI) method to forecast the Estimated Total Cost At Completion (EACf). If a project is running at a cost overrun of 15%, then this amount applies to the total budgeted costs on completion. The rate can be changed as the project progresses to reflect the current situation.
Other Control Issues
Other control issues include scope creep, changes in the baseline, and data acquisition problems. Scope changes can impact a project significantly as changes to the project can cause variations to many of the tasks. Baseline changes are the result of changes to the scope. Data acquisition has become more efficient with the development of more powerful computer programs, but it still comes at a significant cost. Data acquisition costs cannot be skimped on because it is the data that will alert the project manager to problems and help ensure the success of the project.
Project Closure
Generally speaking, project closure begins when all the tasks on the project have been completed and accepted by the client (Gido, Clements & Baker 2017). In some cases however, the project might be closed for some other reason and there are five alternate cases listed by Larson and Gray (2020).
Normal Closure
Normal closure is when the tasks are all completed and accepted by the client as being satisfactory.
Premature Closure
A premature closure is when a project is closed early, with some deliverables being removed from the project that were in the scope. Premature closure may be because of time to market pressures, but should be carefully reviewed by all major stakeholders before a decision is made.
Perpetual Closure
Some projects simply never close. There are add ons always occurrng and scope creep. It can make project management difficult to operate under such circumstances, and at some stage, the best option is to close the project and initiate a new one.
Failed Project
If a project has failed, then it could be closed. The failure may well be for valid reasons beyond the control of the project manager or stakeholders. Either way, the reasons for the failure need to be investigated and documented, particularly when external circumstances have caused the failure.
Changed Priority
An organisation may choose to shift its priorities and cancel a project prior to completion. This is obviously at their option as the customer.
Project Closure Checklist
Larson and Gray (2020) detail six major activities that should be undertaken to close a project. These are:
- Getting delivery acceptance from the client
- Shutting down resources and releasing them to new uses
- Reassignment of the project team members
- Closing of all accounts and ensuring they are all paid
- Delivering the project to the client
- Creating a final report
Although these are six major tasks, some organisations can have checklists involving hundreds of items to tick off according to Larson and Gray (2020).
Post Project Evaluation
Post project evaluation simply involves considering the performance in every aspect of the project.
Project Evaluation
The project evaluation assesses the project. This would include the performance against estimates, scheduling of tasks, budget to actuals, relationships with the customer/s and stakeholders, communication standards, identification and handling of any issues and what lessons may have been learned (Gido, Clements & Baker 2017).
Team Evaluation
Team evaluation should be completed based on predetermined criteria established prior to the commencement of the project. The evaluation should cover the obvious aspects of time and cost management, but should also look at soft skills used in people interactions. These include teamwork, communication, problem-solving abilities, leadership and management style, among other relevant criteria. Such evaluation should also include input from the client and stakeholders where possible to assess their evaluation of team members involved with the project.
Individual Performance Reviews
Individual performance reviews provide feedback that can be used in several places, including professional development, promotions, bonuses and salary reviews. The manner in which these are done can vary between an informal interview to a detailed form requiring completion and subsequent interview with the team member.
The traditional form of staff review is being challenged by the more popular 360 degree review, which the text describes:
“One process that appears to be gaining wider acceptance is the multi-rater appraisal, or “360-degree feedback,” which involves soliciting feedback concerning team members’ performance from all the people their work affects. This would include not only project and area managers but also peers, subordinates, and even customers.” (Larson & Gray, 2020, p. 550).
This process provides the opportunity for everyone involved in the project to have input into the project team member’s performance.
Lessons Learned
Apart from the project team reviews, it is also important to review any lessons learned as a result of the project. The term “lessons learned” is defined in the text’s glossary as “An analysis carried out during and shortly after the project life cycle attempting to capture positive and negative project learning.” (Larson & Gray, 2020, p. 658). Despite organisations being aware of the importance of such a review, it would appear that many do not apply the lessons learned to improve project performance. To overcome the barriers of applying the lessons learned, there is a methodology called “Retrospectives” that can be used. This methodology, is defined in the text’s glossary as, “A methodology that analyzes a past project event to determine what worked and what didn’t, develops lessons learned, and creates an action plan that ensures lessons learned are used to improve management of future projects.” (Larson & Gray 2020, p.660).
Retrospectives Methodology
Using this methodology assists organisations in learning from the past and should prevent repeating the same mistakes in the future. The text includes a summary of the tasks in a tabular form (Larson & Gray 2018, pp. 528-535):
Figure 8: Retrospectives Checklist
Benefits Realisation
Project success is not just about the performance or efficiency of the project. Shenhar et. al. (2001) suggests that there are additional aspects to consider, including the benefit and impact to the client, the success of the business and preparation for the future. These aspects contribute to a focus on the stakeholders in the project.
Here we will discuss Benefits Realisation Management (BRM), and the manners in which it can deliver the expected value and benefits to stakeholders.
The Project Management Institute (PMI) (2016) defines BRM as a, “Collective set of processes and practices for identifying benefits and aligning them with formal strategy, ensuring benefits are realised as project implementation progresses and finishes, and that the benefits are sustainable—and sustained—after project implementation is complete”.
From this definition, it should be obvious that BRM is not something that relates to the end of the project life cycle, but is a continuous process throughout. It is arguable that the Benefits Life Cycle and the Project Life Cycle can be connected (Levin, 2015). He also divides BRM into five main processes which are:-
- Benefits identification
- Benefits analysis and planning
- Benefits delivery
- Benefits transition and
- Benefits sustainment.
There is an additional stage suggested called “post implementation” where the transition and sustainment component of the benefits take place which was suggested by Mossalam and Arafa (2016). In order for organisations to implement the practice of BRM in their project management systems, the Project Management Institute (PMI, 2016) developed a framework. The framework is discussed below.
Benefits Identification
Benefits identification intends to establish the expected benefits that a project will deliver to an organisation. Mossalam and Arafa (2016) consider that the benefits life cycle and project life cycle are aligned at this point in time. The benefits to be identified to the organisation include both tangible and intangible. Tangible benefits are much easier to identify, but intangible ones, such as brand recognition, for instance, may not be specified. All benefits should be documented so they can be subsequently measured.
Benefits Analysis and Planning
Levin (2015) considers that at the present point in time, with the benefits life cycle and project life cycle in alignment, that the project benefits should be analysed and a BRM prepared. The PMI (2016) defines a project realisation plant as “a document outlining the activities necessary for achieving the planned benefits. It identifies a timeline and the tools and resources necessary to ensure the benefits are fully realised over time”. The plan should include details of what metrics are to be used and how benefits will be measured. The plan would also detail who measures and manages the benefits, particularly prior to the closure of the project. With any such analysis, a comparison between the project deliverables and the contribution to organisational benefits should be considered (PMI, 2016). Tekes and Cavarac (2013) comment on benefits mapping being a technique for the documentation and analysis of the dependencies between project deliverables and organisational benefits.
Benefits Delivery
Benefits can be delivered throughout the project life cycle, but are generally delivered when the project has been closed (Levin 2015). The monitoring of benefits delivered through the project life cycle are managed by implementation of the PMI’s (2016) realisation management framework. Utilisation of the framework can monitor risks that may impact on delivery of benefits and also identify new benefits throughout the project life cycle.
Benefits Transition
On project completion, everything is handed over to the organisation (PMI 2016). The transition of the benefits should occur under a benefits transition plan, which would involve the utilisation of a benefits register recording the transition process to stakeholders. Any lessons learned should be documented.
Benefits Sustainment
Shenhar et al. (2001) considers a project successful if it delivers long-term benefits to an organisation and positions it well for the future. Sustainment of benefits from projects are best managed with the establishment of a Benefit Sustainment Plan (Levin 2015) which should also include details for documenting any benefits that occur that may not have been expected.
Conclusion
This module has been the largest in the subject to date. There is a considerable amount of technical information contained that would no doubt be the province of the specialist project manager.
The areas around benefits realisation, however, are of particular interest to any executive in the capacity of a client or stakeholder. The notes here document the importance of capturing a detailed Benefits Realisation Plan prior to implementing the project. Such a document would be critical in ensuring that a project is consistent with the organisation’s strategic plan
