Many projects are plagued by the phenomena of "scope creep”
and some of that creep can be managed by prioritizing your project’s
requirements. Scope creep is a problem from the perspective of the project
manager and project sponsor because it inflates the cost of the project (more
work means more cost) and extends the schedule because the extra work can
rarely be done in the original window for the project. If the additional work
can be done to the original schedule, the extra costs incurred through overtime
or additional resources add additional expenses to the budget. Some scope creep
is due to project stakeholders wishing to add additional features or
functionality to the project’s product. These additional features may be due to
the stakeholder not being engaged properly during the requirements gathering
process or due to changing market demands, technology or other influences
outside the control of your organization. These new features are actually
changes and need to be managed by the project’s change management process,
regardless of the source.
The other source of scope creep, and it’s the one I’m
talking about here, is the phenomena of estimates for the amount of work increasing as more is learned about the features of the project’s deliverable.
Let me illustrate what I’m talking about here with an example. Let’s say you’ve
decided it’s time to remodel your kitchen. You’ll leave the original footprint
but you’ll replace the existing floor with slate, install new cupboards,
replace the existing counter top with a granite one, and replace the existing
appliances, taps, and sinks. You can estimate the cost in both materials and
labour for all these upgrades and so you estimate a budget and schedule for the
job. Everything looks good until you begin the work and find out that the slate
floor will require a considerably stiffer subfloor and joist system. The joist
system you’ve currently got is 2” by 8” joists on 16” centres. The one you need
is 2” by 10” on 16” centres. Now what you’re faced with is beefing up the
existing joist system to meet the criteria for the slate floor. You haven’t
added any new features (at least from your point of view) but you’ve added
considerable work and some materials you hadn’t envisioned when planning the
job. The effort required to do the renovation will increase by the amount of
effort required to beef up the joist system and the budget will increase by the
cost of the new joists. Or you could choose another floor that could be
supported by your existing joist system.
Just about any project you undertake is susceptible to this
kind of scope creep. No one is asking for new features, but you find out in the
course of building your house, refinery, or software system that you’ve
overlooked some work that is needed in order to deliver a solution that meets
all the goals and objectives stated in the project charter. In fact, this is an
especially common phenomenon in the business of building software systems and
the less experience the organization has in building systems using the software
tools and methods available the more likely they are to experience this kind of
scope creep. The addition of work and materials not originally planned could be
managed by the change management process but the additional work is not so much
a change to the project as it is a correction to the plans. If the additional
work and materials change the budget and schedule baselines, the change must
definitely be handled by a change request. Another solution must be found where
budget and schedule are constrained.
The solution required for constrained budgets and schedules
is to eliminate features or requirements so that the remaining work fits within
the budget and schedule constraints imposed on the project and prioritizing the
requirements as they’re being gathered can make this exercise a "no brainer” as
opposed to the political war that is likely to ensue if requirements priorities
have not been agreed upon ahead of time. So now that I’ve convinced you of the
need for prioritizing your project’s requirements, let me offer some tips and
tricks on prioritization.
Requirement priorities can be contentious; the more interest
the stakeholder has in the project, the more contentious priorities are likely
to be. Projects which have trouble engaging stakeholders will have a different
problem: stakeholders are reluctant to give you the time you need to gather
their requirements and priorities. Let’s tackle the first situation first. This
situation can produce 2 problems: stakeholders disagree on each other’s
priorities and some stakeholders will want to identify all their priorities as
"must haves”. By the way, these two problems are not mutually exclusive.
Here are some tips on reaching consensus on requirements
priorities. First of all, identifying priorities should be integrated into the
requirements gathering process, after all the initial set of requirements
should fit within the budget and schedule constraints identified for the
project so the stakeholders will have to agree on the set of requirements that
should be built. Some requirements will make the cut and others won’t. If you
make setting a priority for each requirement a part of the process, the
requirements will not be complete until a priority has been assigned to the
requirement and the set to be built has been agreed upon. A workshop can be an
aid to both requirements gathering and to priority setting. The workshop
collects all the stakeholders, or their designates, in one room for the purpose
of identifying all the requirements. There are two advantages of workshops over
other one-on-one methods: the duration of the process is shorter because
requirements are identified more or less simultaneously rather than
sequentially and a consensus decision can be reached on the priority of the
requirement on the spot. If a workshop is not possible some other form of
decision making may have to be used. Another approach to decision making is to
capture the priorities from the stakeholders but leave the decision as to their
priority to the project’s sponsor, or a subject matter expert they designate
for the purpose.
There are several ways of assigning a priority to
requirements. One is to use a numeric scale, say from 1 to 5 with 5 being the
most important requirement and 1 being the least. Another method is to use
high, medium, and low or must have, important, and nice to have. The descriptions
may make setting the priority easier. You can also weight the priorities by
categorizing the requirements. Let’s say you’re building an order management
system with components for capturing an order, creating the order, managing the
inventory, and reporting. You might rank these components using the same scale
as the one you selected for prioritization and then apply these weights to the
prioritization scores. Let’s assume that reporting is ranked as a low priority.
A high priority requirement for the reporting component would be a high/low
priority when weighting is applied and would not be as high a priority as a
high priority for an order capture requirement.
Some stakeholders that are passionate advocates for the
group they represent may be reluctant to give a realistic evaluation of the
relative importance of their requirements. To them each and every one of their
requirements is a "high” or "must have” and they may be very reluctant to
accept a lower priority. You will need to move them from this stance in order
to complete the prioritization process. For one thing their intransigence may
influence other stakeholders to take the same approach. If everyone adopts this
approach, there is no prioritization. One way of getting your stakeholders to
assess their requirements more realistically is to provide them with the
roadmap for the future which includes the upgrades that are planned during the
lifecycle. This means that even the lowest priority requirements are never
discarded; they will go into a queue with the other lower priority requirements
and new requirements and will be reconsidered for the next iteration of the
Prioritization is done for the purpose of determining which
requirements will be developed for the first iteration of the project and
determining which requirements will be jettisoned first if you discover the
identified requirements require more work than the budget can afford for the
first iteration. Let’s assume that you’ve identified the requirements that can
be developed for the project and have approved the scope, budget and schedule
based on those requirements. Now you’re developing your product and discover
that you’ve underestimated the work required for a requirement either due to an
unrealistic estimate or because you failed to identify all the work required.
You’ve also determined that there is no appetite for increasing the budget to
pay for the additional work or for increasing the schedule to accommodate the
additional work. You might do this by initiating a change request or by simply
asking the sponsor. Your alternative is to eliminate work from the project so
it fits within the budget and schedule constraints and this is where
prioritization goes to work. You’ll begin by dumping the lowest level
priorities; again these are not simply eliminated they will go into the queue
for the next upgrade. By this time, estimates should be refined enough so that
you know exactly how many lower priority requirements must be dumped before the
project fits within the constraints again.
There is an alternative to simply dropping a requirement.
You could revisit the requirement and the features required to deliver it;
sometimes by altering those features, the original requirement can be met
within the budget. Let’s look at our floor example. You want a slate floor
because of the way it looks, not because of its weight or rigidity. There is a
multitude of excellent stone substitutes available including imitation slate.
These substitutes tend to look like slate but are lighter and less brittle so
it is possible that a slate substitute could provide the "look” you want and be
light enough to use the existing joist system. By taking a little closer look
at a requirement it may be possible to identify a different way of delivering
it that requires less work, less costly materials, or both.
The last step is to implement the change in project scope properly and you’ll need a change request to do this. The change request will
ask that the identified excess requirements be removed from the plans and the
change management process will identify the work necessary to remove the
requirements and the necessary changes to the plans. Approval of the change
request should not be controversial given that the stakeholders have already
agreed on the requirements to be removed by prioritizing them. Once the request
has been approved, you need to inform all the stakeholders of this change in
scope. Don’t forget to identify the reason for the reduction, how the requirements
to be removed were identified, and what will happen to the removed
requirements. The scope reduction will be an easier sell if you can tell
affected stakeholders that the requirement you removed will be added to the
queue of requirements for the next release of the product.
Now that we’ve explored all the nuances of prioritizing
requirements and why they should be prioritized I’ll lay out 8 tips and tricks
for making prioritization work for your project.
- Make requirements prioritization a part of your
requirements collection process. Remember that if you don’t have a document
describing the process, you don’t have a process.
- Identify the decision making method for choosing
a priority for each requirement. This could be a consensus amongst
stakeholders, an executive sponsor decision, or some other method. Make the
method clear to the stakeholders.
- Choose a workshop to identify and prioritize
your requirements where timelines are tight. Workshops are not only a quick way
to collect requirements; they are almost mandatory where a consensus decision
- Capture the priority with each requirement and
also the stated reasons for the priority.
- Make acceptance of the priorities, as well as
the requirements, a gating criteria.
- Look for alternative ways of delivering a
requirement for less cost before dropping it.
- Identify each requirement and associate it with
its supporting features in the project’s design and test documentation. This
makes removal of the requirement much easier.
- Use your project’s change management process to
manage the removal of requirements from the project scope.
Using these tips and tricks won’t guarantee you won’t be
victimized by scope creep, but they will eliminate one of the major causes of
it and it. It will also show your sponsor and stakeholders that you have a well
thought out approach to ensuring your organization gets the maximum benefit for
their project dollars.