Project managers might have a lot of responsibility, but little authority to get the job done. They require relevant skills do make others do things willingly. This means that they might have to understand the motivations in order to influence others.
Project control is the act of comparing progress to plan so that when deviations appear, corrective actions can be taken.
When controlling, we use information and not power.
The best way of controlling of project is have each team member control their own work. This means that we must set up conditions under which every team member can achieve control. This includes:
- A clear definition of what they need to achieve - clear objectives
- Individual plan on how to do the required work
- Adequate skills and resources to perform the tasks - give training if required
- Feedback on progress going directly to the individual
- When deviations occur, authority to make relevant corrections, perhaps less approvals can be a solution to some of the issues.
The project control system must be based on the project objectives. What is important to the business and the work? Which aspects of the work are critical that we must control more closely? Where controls should be placed? Generally we will control the Scope, Time, Cost and Quality.
Corrective actions
Deviation data might be used to initiate action. We do not need to go into control state and start micromanaging the project to get it back on track. The most important is to ensure that the response is exercised in a timely manner.
Information on project status should be available on a real time basis, so the actions can be taken in a timely manner. Ultimately, we want to know how many hours people work on a project and compare it with planned tasks estimations. We need people to provide accurate and timely data of their work. This needs to be done on a daily basis. T
his is the only way to get the true picture. With delayed data we might be making the situation worse with actions.
If every team member works daily on their tasks, reports can be prepared weekly. That is the best point of action.
Any control data which is not essential should be eliminated. We must keep things simple and smart. To keep control simple it might be worth checking whether the generated reports are actually being used. We might only believe sometimes that information might be useful to others, but in reality, no one uses it.
It might be a good idea to send a memo asking people on whether they want to receive further reports. If no one uses them, they should be dropped off completely.
The maintenance control tries to keep the project on track. But at times, we need to exercise improvement control which will help team to keep the project on time. Therefore we often have meetings and review:
- The project status (where we are),
- The project process (how things are done) and lessons learned, as well as,
- review the project design.
We evaluate the project against this criteria to check that the work in progress is acceptable. We compare the scope, cost, time and quality to what was originally planned. This assessment provides a background to any decision and actions that might be taken.
The purpose of review is to learn lessons to avoid negative effects in the future. Therefore, the review is often called a lesson-learned review. We intentionally do not use the word audit, but technically it is what we do. Good control of projects can give a competitive advantage as it ensures that the cost, quality and time is on track.
When running projects periodic reviews should be arranged. This is to improve the project performance, ensure of the quality of project work, discover and reveal problems, identify where project should be managed differently, keep all on a project status and finally, reassure commitment.
The process of project review should be conducted in a spirit of learning and not blame and punishment.
If people are afraid they will be punished for problems they will hide them.
Some organisations still exercise rather punishing and blaming culture. Perhaps the questions we ask should be designed for improving the culture. Firstly, we ask "What have we done exceptionally well?" and secondly "What we want to improve in the future". We are not punishing anyone for doing things wrong.
The results of the review should also be published. Others might benefit from the lessons learned.
Project report should consist of the following:
- Current status using earned-value analysis,
- Future status - what is expected to happen,
- Status of critical tasks,
- Risk assessment,
- Information relevant to other projects,
- Limitations of the review.
The simpler the report, the better.
Change Control
When issues are found, change control should be implemented. These changes may modify project policies and procedures, scope, cost or budget, quality or schedule. When changes occur we need to reassess the project. Project plan might need to be revised.
Changes might come from all different directions. We must keep the Scope, Quality and Time on budget when they happen.
Scope change might include changes to other projects, merging projects or requirements might be changed. There might also be shift in conditions or engineering problems occurrence.
Schedule changes might include acceleration of delivery dates, pressures from competition or a request to early delivery.
Budget changes might involve cutting some parts of the budget, price raise for raw materials or additional team members might be required.
There are steps we can take for managing change:
1. Enter change control information to Change log which are all actions taken regarding change requested
2. Decide if the change should be processed - sometimes we do not need to accept a change just because it was requested. If the change doesn't add value that it probably should not happen. We need to request clarification, only if the change is accepted we can start assessing an impact on the project plan.
3. Submit recommendations for approval to customer.
4. Update the project plan.
5. Communicate the updated plan. This is critical.
6. Monitor progress against revised plan. All the Scope, Performance, Time and Budgets should be checked to ensure they stay on track.
It is a good idea to have a plan for change management as a documented procedure.
Project change control form template is presented below.
We might want to quantify the impact of the change on the project.
Some changes, however, might not be significant enough to trigger the entire project. Sometimes the changes are minor and have minimal impact on the project. The project plan can easily absorb the change. £5 million project facing £5 change might be small enough to trigger the process. But if the project deadline will be changed to another 5 months, it should be a good reason to trigger the change.
A change control log might look as below.
We must be disciplined enough to keep the project change log. Small things might impact the project significantly.
Sometimes, however, changes are so severe that require complete replanning of a project, recruitment of the entire new team or even closing it. We have to have a firm grasp of the impact of them on the Scope, Budget, Time, and Quality (Performance). We than review the information, plan and continue with the project life cycle as appropriate.
We shouldn't fear change, but embrace and manage it.
Changes are often necessary adjustments to the projects. It might help us to deliver it on time.
Earned Value Analysis
When deviation occurs in project plan we will take corrective actions. But, what should be done about a deviation?
We might cancel the project, ignore it, take corrective action or revise the plan.
When the project is too far from the plan, the best point of action might be to cancel it. In terms of ignoring it a % tolerance would be helpful here.
In terms of corrective action we might take different approaches. Sometime working overtime, or adding more people, cut scope or change the deadline.
Project cost control is concerned with whether it stays within the budget while getting the job done on time and of the correct quality.
There is a system for doing it, called Earned Value Analysis. We evaluate:
- Cost variance
- Schedule variance
- BSWS - Budgeted Cost of Work Scheduled
- BCWP - Budgeted Cost of work Performed
- ACWP - Actual Cost of Work Performed
Cost Variance = Budgeted Cost of Work Performed - Actual Cost of Work Performed
Schedule Variance = Budgeted Cost of Work Performed - Budgeted Cost of Work Scheduled
Variance = any deviation from plan
Variances are often plotted using spending curves. We might also present it in bar charts as example below.
We must then track the performance comparing it to the plan.
If we show it on the graph, below example will show that the Actual Cost of Work Performed is above the Budgeted Cost of Work Scheduled as well as, the Budgeted Cost of Work Performed is below the Budgeted Cost of Work Scheduled. This means that the project is running behind the schedule and over the budget.
In another example below the Actual Cost of Work performed and the Budgeted Cost of work performed meet at the same point. This means that the project runs ahead of schedule and on budget. In this case we are ahead and spending correctly.
Example in the figure below, the Actual Cost of Work Performed and the Budgeted Cost of Work Performed meet below the Budgeted Cost of Work Scheduled. This means that the project is behind the schedule and under the budget. It might mean that we have not applied enough resources and when we try to catch up, we generally overspend (either overtime or additional costly resources).
Example below, the Actual Cost of Work Performed is below the Budgeted Cost of work Performed. The Budgeted Cost of Work Performed is above the Budgeted Work Scheduled. This means that the project is ahead of schedule and underspent. This will usually happen then the original schedule was too conservative (padded for safety). But it might also happen because people were more efficient then expected. This could tie up resources that could be used on other projects.
It will depend on what would be the acceptable variance. 3-5% in well defined construction job might be good enough. In research and development the percentage generally increase to 10-15%. We generally develop tolerances through experience.
Percentage complete
The most general way of measuring performance is, however, using % complete. This is the Budgeted Cost of Work Performed measure. With the difference that it is not a nominal value.
Below figure shows how percentage complete curve is plotted over time.
It generally raises to 80-80% and turns horizontal. It stays this way for a while and than goes up again when the work is completed. The reason for it is that problems are normally encountered at the end of the project.
댓글