If you have experience managing a project you know the importance of the Project Initiation Document (PID), but did you know the importance of a similar document when starting a Business Process Improvement (BPI) effort? While you may not consider a BPI effort as large a project as a system implementation, you do require the same type of information if you want to stay on track and avoid scope creep.
In BPI work, I call this document the Scope Definition Document (SDD) and consider it the most important step towards successful process improvement.
Whether you lead a regular information technology-type project and use the PID or a process improvement project and use the SDD, you should consider these reference documents key tools that you never skip.
A PID includes information such as the business case, deliverables, timing, risks, budgets, and resources.
In BPI work, the SDD provides the blueprint for the process you want to improve, and it provides you with a vehicle to gain agreement on the following areas:
- Process Owner: person responsible for the end-to-end process
- Description: definition or purpose
- Boundaries: breadth (start and end)
- Process Responsibilities: major tasks the process delivers
- Client/Customer and Needs: recipients of the process and what is important to them
- Key Stakeholders and Needs: other areas or departments affected by the process and what they require
- Measurements of Success: what the business should measure to ensure the process meets the client/customer/stakeholders needs
Several of the SDD components warrant additional information.
Description: When writing the description, pay special attention to the terminology used and avoid using technical, unusual, or cultural terms without explaining what the word means - after all, a definition should define, not confuse. How often have you found yourself thinking a word meant one thing, while someone else had a totally opposite understanding of it? This becomes more of a problem when you work for a global company whose employees reside in different countries.
It may seem easy, but I have seen this task alone consume significant time. Use an example if necessary to further define a process, and if you want to specifically exclude something from the scope of a process, this is a good place to identify the exclusion.
Boundaries: Clearly identifying the boundaries will save you time later in the project and help you to avoid scope creep. The boundaries may seem obvious to you, but once a project team starts talking about where the process begins and ends, you will appreciate the clarity the SDD brings to the work.
There is no right or wrong answer to where a process begins and ends. It all depends on the project team's discussion and the sponsor's approval of the process boundaries, so that you can stay on track. The "boundary" decision becomes evident when you move to mapping the process.
Measurements of Success: When identifying the measurements of success, focus on the client/customer needs and identify measurements that address those needs. At this point, focus on what you should measure, not how you will measure it. Save the "how" for later (step 7 of the 10 steps). If you spend time at the beginning of a process improvement project on how to measure something, the project team will get sidetracked worrying about the difficulty of the metric itself.
The Scope Definition Document should fit on a single piece of paper so that everyone can use it as a quick reference guide. The temptation to add a second page will surface, but the effectiveness of the document is its apparent brevity while actually providing considerable depth.