1. ICS 442 Software Project Management Unit 6 Project Monitoring and Control

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 Assessing progress
responsibility
authority
Assessing progress
formal
informal
Communication

4. The project control cycle

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

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

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

8. 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

9. 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

10. 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

11. 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.

12. 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.

13. 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.

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

15. 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.

16. 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.

17. 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.

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

19. 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.

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

21. 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.

22. 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.

23. 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.

24. 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

25. 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.

26. 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.

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

28. No Quality system and change 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).

29. No Quality system and change 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.

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