In operational excellence, and in life, setting a goal without fully understanding its scope can turn a project into a frustrating effort to deliver the impossible. Think of these examples:
- An auto mechanic is authorized to change the oil in a customer’s car but discovers that the oil is so dirty he’s sure the engine has been damaged.
- An operational excellence practitioner plans to implement a waste-tracking project and soon finds that the organization expects its entire flawed accounting system to be reengineered.
- A surgeon makes an incision into a patient for a simple appendix removal and finds a large cancerous mass that would have shown up with an appropriate scan.
While unexpected events can always happen…unexpectedly…having a good definition of scope at the start of a project and adhering to the scope during deployment can provide immense help to ensure that project can be delivered successfully.
What is Scope?
Scope is one of the elements defined as an organization starts to deploy its vision. Scope deals with two basic projections for a project or program: How large is it? How much manpower and other resources will be needed for the project? These break down into multiple elements.
Size relates to breadth, depth, complexity, and duration. For example:
- Breadth: Will the project address concerns in one department or broadly across the organization? In one value stream or in many or all of the operations? In one plant or in multiple plants around the world?
- Depth: Will the project deal with surface issues that assure operations can continue or will it dig much deeper, creating a major reengineering of operations?
- Complexity: Is the issue involved straightforward enough that immediate focused effort will solve it or is the complexity so great that intense problem-solving efforts are needed? A related question: Has something like this ever been done (or attempted) before?
- Duration: Will the project last for several weeks or go on for years? Once completed, will operational resources be able to sustain the project without continuing OpEx support?
Manpower and resources have several considerations as well:
- How many and what types of human resources are needed? Are they more on the brawny side or the brainy side? What specific skill sets are needed?
- What is the concentration profile for resource needs? Heavy upfront and then declining? Limited early requirements and intense needs as the project reaches completion?
- What, if any, resources are needed that have limited availability or are on the critical path for delivery for project success?
- How much funding is required to cover this outlay of human and other resources?
Generating a high-level deployment plan with milestones and resources needed can help to combine these two parts of the scope considerations. Address major mismatches in early contracting to be sure stakeholders and practitioners share expectations.
An OpEx Scope Example
As an example of vision versus scope, consider the quality program of Zero Defects that was promoted by Philip Crosby in the 1960s. The vision of zero defects can be extremely helpful in prompting creative thinking about changing systems to remove both process waste and structural waste. Many companies benefited by putting programs in place under this operational excellence umbrella.
At the same time it’s likely that not one manager committed to 100% perfection in his or her annual plan. Instead, they and their OpEx leaders established program goals and project scope that aligned the size of achievable projects with the resources they would have available.
A Few Words About Scope Creep
Scope creep is a deadly problem that can turn an otherwise achievable program into a giant resource-sucking swamp. This can happen in the definition stage of a project. Stakeholders may ask for the sky, trying to have every problem they’ve ever had with a system corrected or wanting to add every bell and whistle to a new product. It’s a bit like legislators adding unrelated line items to a bill just because they have the opportunity to work something in. One helpful way of addressing this issue is using the Agile/Scrum methodology developed in the software world: a project is broken into time-bound stories with a limited set of deliverables to be completed in a short, focused sprint. After that milestone passes, the next story is developed and delivered.
Even if the rather formal Agile/Scrum series of stories is not followed, project leaders can define scope to include a pilot approach with specific early milestones toward project completion in order to demonstrate early success, identify bugs, and refine and update project scope for the full effort.
Scope creep also occurs as the project continues, gains momentum and becomes more visible. Stakeholders may start to see opportunities that weren’t evident in the original definition and they want to get on board or they may now realize that the path toward completion is not exactly what they want. It needs to be tweaked to better meet their needs.
While scope changes are not ideal, they may at times be necessary. In those, hopefully limited, cases, the project manager can use a formal change management process to accept specific changes in deliverables and contract any necessary changes in scope considerations of resources and timing.
