Unformatted text preview: the new specification is being developed, making it more feasible to continue. It is often the case that the original specification called for more Page 251 than was actually required. Replanning represents an opportunity to rethink the scope of the project. Requantification and reestimating must proceed in the same manner as explained for quantification and estimating in Chapter 2. In reestimating, we include resequencing and rescheduling the newly requantified work. When these are being redone, it is possible that some of the work will not have to be quantified or estimated, such as work that has already been accomplished that forms a useable part of the newly validated design specification. While we want to preserve as much of the finished work as possible from the failing project, it is often tempting to assume that some of the finished work will fit into the redirected project's work plan when it really will not. It is often the case that all the existing finished work should be requantified and reestimated and then the finished work should be compared to this in detail to determine if the seemingly finished work is really finished. The requantification and reestimating should be used to produce a new project plan that begins where the failing project ended. Modifying the failing project's plan to form a new project plan is usually not a good idea. If the original plan was a good one and it can be determined that the reason for failure was inept management, then it might be possible to stick with the original plan. But project failure is usually caused by many shortcomings that add up to the failure. Once a new or revised plan has been prepared, it can be decided if the expenditure (and risk) to save the failing project is worthwhile. Not until a new or revised plan is available can an informed decision be made. Replanning a large project in midstream can be a significant effort, and work may not be easily stopped and started again. The uncertainties associated with the cost of replanning alone, on very large projects, sometimes lead to their cancellation. It would be far better if the problems were discovered earlier and replanning could continue in parallel with the work. An experienced project manager can often turn a poor project plan into a workable plan if enough time is left in the project lifetime. Page 253 References
Boehm, B. Software Engineering Economics, Prentice -Hall, Englewood Cliffs, N.J., 1981. Burgess, A. R., and J. B. Killebrew. ''Variations in Activity Level on a Cyclical Arrow Diagram," Journal of Industrial Engineering , Vol. 13, No. 2, March-April 1962. Galbreath, R. V "Computer Program for Leveling Resource Usage," Journal of Construction Division, proceedings ASCE , Vol. 91, No. CO1, May 1965. Howes, N. R. "Project Management Systems," Journal of Information and Management , Vol. 5, No. 6, pp. 243– 268, 1982. Howes, N. R. "Managing Software Development Projects for Maximum Productivity," IEEE Transactions on Software Engineering , Vol. SE - 10, pp. 27– January 1984. 35, Howes, N. R. "On Using the User's Manual as the Requirement Specification," in Software Engineering Project Management , R. Thayer (Ed.), IEEE Computer Society Press, pp. 172– 177, January 1988. Howes, N. R. "On Using the User's Manual as the Requirement Specification II," in Systems and Software Requirements Engineering, R. Thayer and M. Dorfman (Eds.), IEEE Computer Society...
View Full Document
This note was uploaded on 01/11/2011 for the course ACC 9 taught by Professor Yeetan during the Spring '10 term at Sunway University College.
- Spring '10