Unformatted text preview: the last stages of a project life cycle, rather than at the beginning. Producing a user's manual late in a project life cycle is usually a bad idea, but it often occurs that way. So developing a work plan from a user's manual often sounds like putting the cart before the horse. There are a number of advantages of using the user's manual as the requirements specification for a project that I have explained in some of the papers referenced in the back of this book. One of them is that for software development projects, this approach improves control of the software development process, because on software development projects there is usually a natural flow of activity from the capabilities described in a user's manual into the high-level decomposition of the system into subsystems. The same thing also holds true for many other types of products, especially projects with a high level of technical complexity. Transition from the requirements specification into the design phase has historically been a problem, especially when the requirements specification is developed by one organization while design and implementation are done by a different organization(s). Page 250 Using the user's manual as the requirements specification emphasizes the mode of delivery of the product's capabilities, which can be used to extend this method of requirements specification into the design activity. This approach facilitates requirements traceability for projects that require traceability, since the mode of delivery of a capability is easier to recognize and trace in a design than is an abstract statement of the capability. Also, specification of the mode of delivery of capabilities facilitates the understanding of how the design proceeds from the requirements. The preceding discussion indicates how this approach facilitates the translation of the product specification (of requirements) into a product design. We still need to discuss the transition of the design into a project plan. Before proceeding to the transition from a design into a project plan, it is worthwhile to reflect for a moment on the specifics of the situation we are in at this point. The failing project may have started with a design that was produced in a manner entirely different from transitioning from a user's manual description of the project's product (outcome). In fact, this may be one of the underlying causes of failure. The production of that design may have itself been the result of a significant project. What the new project manager might be faced with is a total redesign of the product in a manner that is suitable for translation into a project plan (i.e., one that is producible). The cost involved in such an undertaking may in itself be reason to abandon the project. 10.4— Replanning TE
Team-Fly® AM FL Y Once a validated specification of what is to be accomplished on the project is available, a new project plan can be built. A new WBS usually needs to be constructed that defines in broad terms how the work is going to proceed. Often, a reduction in the scope of the work can be achieved when...
View Full Document
- Spring '10
- Project Management, project manager