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 big a project as a system implementation, you need the same kind of information if you want to stay on track and avoid scope escalation.
In the BPI work, I call this document the Scope Definition Document (SDD) and consider it the most important step towards successful process improvement.
Whether you’re running a regular IT-type project using the PID or a process improvement project using the SDD, consider these reference documents as key tools you should never skip.
A PID includes information such as the business case, deliverables, time, risks, budgets, and resources.
In BPI’s work, the SDD provides the blueprint for the process you want to improve and gives you a vehicle to achieve agreement in the following areas:
- Process owner: person responsible for the end-to-end process
- Description: definition or purpose
- Boundaries: width (start and end)
- Process Responsibilities: main tasks delivered by the process
- Client/Client 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
- measures of success: what the company must measure to ensure that the process meets the needs of the customer/customer/stakeholders
Several of the components of SDD 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 that a word meant one thing, while another person had a totally opposite understanding? This becomes a bigger problem when you work for a global company whose employees reside in different countries.
It may sound easy, but I have found that this task alone is very time consuming. Use an example if necessary to further define a process, and if you specifically want Exclude something from the scope of a process, this is a good place to identify the exclusion.
Boundaries: Clearly identify the boundaries it will save you time later in the project and help you avoid scope creep. Boundaries may seem obvious to you, but once a project team starts talking about where the process begins and ends, you’ll appreciate the clarity that SDD brings to the job.
There is no right or wrong answer to where a process begins and ends. It all depends on the discussion of the project team and the approval of the limits of the process by the sponsor, so that you can stay up to date. The “boundary” decision becomes apparent when you move on to mapping the process.
measures of success: When identifying measures of success, focus on customer/customer needs and identify measures that address those needs. At this point, focus on what you need to measure, not how you will measure it. Save the “how to” for later (step 7 of 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 sheet of paper so everyone can use it as a quick reference guide. You will be tempted to add a second page, but the document’s power is its apparent brevity, while actually providing considerable depth!
Laying the groundwork by developing an SDD is the second of ten steps to improving the effectiveness, efficiency, and adaptability of your business processes, so spend some time focusing on it. Create the blueprint to guide your work.
Copyright 2012 Susan Page