CHAPTER 4
,How to Scope a TPM Project
Prediction is very difficult, especially about the future.
— Neils Bohr
Define the problem before you pursue a solution.
— John Williams, CEO, Spence Corp.
CHAPTER LEARNING OBJECTIVES
After reading this chapter, you will be able to:
- Understand what managing client expectations really means
- Explain the Conditions of Satisfaction (COS) development process
- Develop the COS document
- Recognize the importance of maintaining the COS throughout the entire project life cycle
- Plan and conduct the Project Scoping Meeting
- Build the Requirements Breakdown Structure (RBS)
- Use facilitated group sessions, business process diagramming, prototyping, and use cases to decompose requirements
- Define the basic parts and function of the Project Overview Statement (POS)
- Write a saleable POS for your project idea using the language of your business
- Understand the role of the POS in the project management life cycle (PMLC)
- Write clear goal and objective statements
- Establish measurable criteria for project success
- Identify relevant assumptions, risks, and obstacles
- Discuss attachments to the POS and their role in project approval
- Understand the approval process for the POS
The Scoping Process Group defines all of the tools, templates, and processes needed to answer two questions: “What do you need to do?” and “How will you know you did it?” If you don't know where you are going, how will you know when and if you ever get there? If I had to pick the Process Group where most of the project failures originated, it would be the Scoping Process Group. Not only is it the most difficult of the five Process Groups, but it is also the most sloppily executed of the five Process Groups. It probably has a lot to do with the feeling that good planning is a waste of time and effort and the desire to get on with the work of the project. So many times I have seen projects get off to a terrible start simply because there never was a clear understanding of exactly what was to be done. A definition of completeness or doneness was never documented and agreed to. In this chapter, you learn all of the tools, templates, and processes needed to get you started on the right foot with a series of activities that lead to a clearly defined and understood definition of what the project is all about.
After you have learned how to put an initial project scope in place, you learn how to maintain that scope. It may change as you learn more about the solution during project execution, but that is the nature of complex projects. In my experience, if there is no change, there probably won't be a satisfactory outcome either.