COM369 Project Monitoring and Control Unit 8

1. COM369 Project Monitoring and Control Unit 8

2. Monitoring and Control • Introduction • monitoring and control will help to ensure projects stay on target • it can also help to get projects back on target that has gone off target

3. Management framework • Reporting structure • responsibility • authority • Assessing progress • formal • informal • Communication

4. Data control • Reporting of progress • staff activity • time sheets • risk reporting

5. Monitoring progress • Utilising planning tools • Gantt charts • PERT and CPA • showing slippage • critical path progress

6. Costs • Cost monitoring • staffing cost • material costs • delay costs • Earned value • Budget and cost variance

7. Prioritizing monitoring • Critical path activities • Activities with no free float remaining • Activities with less than a specified float • High risk activities • Activities using critical resources

8. Prioritizing monitoring • Critical path activities • Any delay in an activity on the critical path will cause a delay in the completion date for the project. Critical path activities are therefore likely to have a very high priority for close monitoring

9. Prioritizing monitoring • Activities with no free float remaining • A delay in any activity with no free float will delay at least some subsequent activity even though, if the delay is less than the total float, it might not delay the project completion date. These subsequent delays can have serious effects on the resource schedule as a delay in a subsequent activity could mean that the resource for the activity might become unavailable before that activity is completed because they are committed elsewhere

10. Prioritizing monitoring • Activities with less than a specified float • If any activity has very little float it might use up this float before the regular activity monitoring brings the problem to the project manager’s attention. It is common practice to monitor closely those activities with less than, say, one week’s free float.

11. Prioritizing monitoring • High risk activities • A set of high risk activities should have been identified as part of the initial risk profiling exercise. These activities will be given close attention because they are most likely to overrun or overspend.

12. Prioritizing monitoring • Activities using critical resources • Activities can be critical because they are very expensive (as in the case of specialised contract programmers). Staff or other resources might be available only for a limited period, especially if they are controlled outside the project team. In any event, an activity that demands a critical resource requires a high level of monitoring.

13. Getting back on target • There are two principle options • Shorten the critical path • Reconsider precedence requirements

14. Getting back on target • Shorten critical path • The overall duration of a project is determined by the critical path. • Things that can be done to shorten critical path • increasing resource levels, • improving resource efficiency, • and how such means can shorten critical path timescales to bring a project back on target.

15. Getting back on target • Reconsider the precedence requirements • The original project network will probably have been produced for an ideal situation. Therefore, there is often scope to revisit activity constraints and precedences.

16. Getting back on target • Reconsider the precedence requirements • Things that can be considered (cont.) • Altering them to help bring the project back on target. • Do unstarted activities really have to await the completion of other activities before they can start? • If an activity has to wait for the completion of other activities, can that activity be broken down into sub-activities and some of the sub activities completed at an earlier date.

17. Change control • Also known as configuration control • Configuration librarian • can have other names • Change control procedures • Changes in scope of system

18. Change control typical elements • Everyone involved in the project should be aware of the change control system. • Anyone should be allowed to request a change. • Change procedure should be clear an unambiguous. • Request for change should be checked by a suitably qualified person or persons.

19. Change control typical elements • Change options should be explore. • Preferred change option should be decided. • Change option should be approved. • Change should take place.

20. Change control typical elements • Results of change should be monitored to check that it worked as expected. If this is not the case then review if change control procedure must be restarted. • All things to do with the change control procedure must be documented.

21. Change control system • The change control system should be designed so that it is relatively easy for to request a change. • Such a system will not put people off making change. • Changes that will benefit the project have a greater chance of taking place if system is easy to use.

22. Change control system • People are less likely to try and short-circuit the change control system if it is easy to use. • A friendly system will have no more bureaucracy than absolutely necessary.

23. The poor change control system • Changes are often not requested. • The consequence of not requesting a change could be that: sub-standard product is delivered to the customer, design anomalies are not corrected. • Changes can get lost in bureaucratic systems, with adverse affects on the project

24. The poor change control system • Bureaucratic systems can hold up changes and the project, with implication for delivery time and cost. • Non user friendly systems encourage people to try to find ways to beat the system, often with adverse consequences for the project.

25. Quality system & change control • A good quality management system would ensure that all procedures and work instructions are in place to cope with changes effectively and efficiently. • Changes will be documented. • Changes will be made in the best interest of the project.

26. Quality system & change control • Proposed changes will be fully investigated • Changes will be communicated to those who need to know

27. No Quality system andchange control • An organisation with no quality management system may have to rely on an ad-hoc system hastily thought up when a change is required. • Or worse the change will be implement without any system or checks of what the consequences may be (good or bad).

28. No Quality system andchange control • The project manager may have no idea of changes that have been made to the project that he is managing. • This has the potential for serious problems especially if other changes are made that assume the project is still at the original specification.

29. Conclusion • Monitoring and Control • management framework • communication • utilising planning tools • data control • costs • prioritising monitoring • getting back on target • change / configuration control