The Scoping Problem in Complex Environments
I have scoped many projects – but mainly software applications. In most cases, these applications were standalone or had very specific integration points. However, more integration can lead to much greater challenge in scoping the project.
Here’s the rub. When a system of some sort, especially if it involves both hardware and software, has many integration points, the challenges of scoping it get multiplied.
This can potentially be extreme!
There are many points of integration, not necessarily seen from the onset. I find that there are four key areas responsible for this troublesome type of scope creep.
- Inputs - Inputs include the data and processes that necessarily precede the process which is represented in the scope of your project. Identify them as "interfaces" so as to not absorb the scope of the prior process into your project. It is very easy for these inputs to grow as the project proceeds. Document the inputs from the beginning, and treat any new inputs, and their effects on the scope of the work, as Change Orders.
- Business Strategy - This represents the strategic direction of your organization regardless of whether it is a commercial enterprise or not. This could thus include your company's strategy, within which the project must live, or it could be the strategy of your business unit, department, division, agency, etc. Make sure that your project fits within the strategy of your organization, and resist any push outside of it.
- Constraints - This can be a tough one and must be managed carefully. It includes Rules and Regulations, laws, and other constraints both inside and outside your environment. Security rules have become a particularly vexing challenge in recent years, but also included constraints in the areas of environment, complexity, usability, etc. Of course there are always quality and financial constraints. some of these things - security constraints in particular - can potentially be booby traps that can really undermine your project, as they are managed by gatekeeper functions that have no other stake in the outcome. Your work up front in setting the boundaries - and establishing that anything more represents a Change Order - will go a long way to protect your project.
- Outputs - Whatever the product of your project does, it will produce an output of some sort. Everything does. In fact, everything usually produces multiple outputs. Usually, your project is about a finite number of outputs, but often others find that they can use it too - with a few tweaks, or more support, or more capacity, etc. It may seem very logical - and take it as a compliment that it's a worthwhile project. But be mindful of the costs involved and of the scope creep implications.
What's the solution? I alluded to it within these four areas.
But it starts with diligence, diligence, and more diligence!
Diligence is hard work - questioning, documenting, communicating.
And it needs to be followed with one more critical thing: "push back". You need to be able to say "No" in order to limit what is included and excluded in the four key areas above.
You can at least limit scope creep by limiting these things from the beginning, with an acknowledgement that more factors - and thus requirements - will arise over time. But you need to come to agreement with stakeholders that you will log them and maintain them as potential Change Orders, to be handled at some later time. You can always order them by priority, and execute on them sooner - but always as signed Change Orders, as they were not part of the original scope.
Remember that you are not required to accept a scope of "whatever comes up along the way". While it's true that you need to try and expect the unexpected, expecting scope creep is something that needs to be management with a strong Change Control system.