Defining Project Scope
This step establishes a commonly understood scope of the process to be renewed and examines its interfaces to other processes. It documents the nature of the major inputs and deliverables to ensure that critical areas receive focus and that everyone understands valid constraints.
Figure 12.4 shows an example of the knowledge produced as a result of this step.
Figure 12.4. The scope for Global Software, Inc.’s process of assigning human resources.
Techniques
The techniques for setting project scope clearly define the edges of the project. Techniques include
Scope modeling
Ins and outs analysis for included and excluded aspects of the project
Workshop facilitation
Negotiation
Lessons Learned
Process scoping starts with the process architecture diagram and descriptions produced in the architecture and alignment phases. However, a project’s scope might not coincide exactly with one process. A project might cover more than one related process or only a portion of one. It might cover the entire process but only for certain customer segments, products, or locations.
Gather an understanding of the types of triggering events, the conditions associated with them, and the desired outcomes for the renewed process. Then determine the inputs, guides, outputs, and enablers (the IGOEs) of the process and draw the model. An input is utilized, consumed, or transformed by an activity (process); it connects to the left side of a process box. A guide provides knowledge or direction on how or when an activity occurs; it connects to the top of a process box. An output is produced by or results from an activity; it flows from the right side of a process box. An enabler is something (a person, facility, system, tool, equipment, asset, or other resource) utilized to perform the activity; it connects to the bottom of a process box. Guides and enablers are not consumed or destroyed.
Map the IGOEs to source and destination processes, if the IGOEs are internal, or to stakeholders, if they are external. Analyze the current health of each IGOE, as relates to its role in the process. Identify the constraints each interfacing IGOE delivers to the process under renewal or places on other processes.
Commonly, the process scope will be closely aligned to interface points with other feeding or receiving processes. Examine all interfaces in and out and ask whether incoming interfaces are adequate; examine their supply as well. Ask if the receiving process gets good results and optimizes the use of what it receives. Include in the project scope those interfaces that can be accommodated without risking the project’s success. Exclude from the project the analysis of interfaces that don’t make too great a difference or those that can’t be handled politically right now.
Think through and test the scope model by posing sample business scenarios to describe the process in a way that all stakeholders will understand.
Remember to include other aspects of scope such as locations, information types, organizational units, products, and transactions. List “What’s In and What’s Out” for each factor; be specific, especially with what’s out. Present this and get consensus before starting analysis. You will be sorry if you don’t.
Scope determination isn’t an exact science—judgment is a key asset. Get some political support from the process owner or project champion at this point.
Compare the scope with the stakeholder expectations and the target levels of performance improvement. Ask yourself, “Do I feel confident that, with the currently planned scope, I can deliver the expected results for those who care?” If the answer is “No,” something has to change until the scope, expectations, and target improvement levels are in balance.
Be prepared for the scope of the initiative to change as key milestones are encountered later. It might also be necessary to have a scope of analysis greater than a scope of design and of implementation. Otherwise, missing key aspects of connectivity could necessitate adding more locations or information or product types later. Be sure that the participants know the difference between what might be analyzed but not designed or implemented.