We all know that there is a cost attached to adding to
project scope. The cost is manifested in 2 ways: money or budget, and time.
Additional scope means additional budget and lengthened schedule. Or do they?
There are actually ways in which the project manager can help accommodate the
addition of functions and features to the software system being developed
without spending any additional money or delaying the delivery of the system.
Bear with me and I’ll tell you how.
The primary reason for change, at least the type of change
that tends to improve the outcome of the project, is the changing market place
or business environment. Changes to the wants and needs of potential customers
or changes to the business processes the new system will support can be a
powerful incentive to change the project. Conventional project management
wisdom will carve the approved requirements for the project in stone. The only
way to change existing requirements is through a change request to reduce
scope. It’s at this point that the important change usually bumps up against
budget and schedule constraints. The product has to get to market by the
original planned date or your organization loses market share, or you are
working within a budget cap that can’t be increased. It’s at this point that we
should question whether the requirements initially defined for the project must
always be the ones delivered in the final product. Can the market place or
business environment change in such a way that a function or feature of the
system is no longer necessary, or no longer important? Of course it can. Some
changes may completely obsolete an existing feature and others may make the
feature much less important than it was initially. Now, you can see where I’m
going with this. The objective is to identify a way to add the new feature or
function to the system without having to increase the budget or delay the
delivery of the system, so why not eliminate an obsolete feature or function to
make room for the new one?
The first step in this exercise is to identify a feature or
function that is obsolete and has approximately the same cost as the feature
proposed by the change request. We need not look at a single feature; we could
identify several candidates for elimination whose total cost is the same as the
new feature. Start by analyzing the proposed feature against the design for the
system. Are there any features that it replaces? Are there any functions that
are duplicated by the new feature? If the answer to either of these questions
is yes, you’ve found a candidate for elimination. If the answer is no, you’ll
have to dig a little deeper. Would altering the new feature slightly make it a
replacement for existing features? Could a slight alteration of the process
obsolete any existing features? The goal here is to eliminate features or
functions that are no longer needed, not to reduce the value of the new system
so don’t force the issue. Review the features and functions against the current
market place or business process. Have recent changes in either made any
features or functions obsolete? Again, the goal is not to reduce the system’s
ability to meet market demand or solve a business problem, so don’t force the
You may not be able to find a feature or function in the
system that can be eliminated without impairing its marketability or its
ability to address the business problem. You’re still not stumped though. There
may be features planned for delivery that deliver much less value than the
feature proposed in the change request. To make this comparison, you’ll have to
start with a prioritized list of business requirements. This can be done duringrequirements gathering exercises with the business team. Scoring can be done in
a number of ways: the requirements can be given a ranking within the set of
requirements, they can be given a cardinal value of high, medium, and low, or
they can be given an ordinal value from 1 to 10. The important thing here is to
rank the requirements so time isn’t wasted on evaluating all the requirements
each time a change is requested. Look for low priority requirements that have a
total cost equivalent to the requested new feature. Ultimately, this boils down
to making a business case and the business case is based on the business value
of the low priority requirements relative to the value of the proposed feature.
The business case is made when the feature proposed in the change request has a
higher value than the low priority feature, or features.
It is helpful to review the Business Requirements Document
periodically to determine if any of the requirements it contains have become
obsolete. Doing the ranking exercise periodically through the course of the
project will also be helpful. You may want to re-visit the Business
Requirements Document at other points during the project, such as when major
changes occur in the market place, when your company experiences a
re-organization, or undergoes a Business Process Re-engineering exercise.
Maintaining an up to date, prioritized list of requirements will help speed up
the formulation of your business case.
The identification of a feature or set of features, with a
cost equivalent to the proposed new feature should trigger the update of the
change request. The request now becomes a request to drop the obsolete or low
priority features and add the new feature in their place. This is the change
request that should go before the Change Control Board (CCB) and that group
should decide on the business case the change request makes. Approval of the
request triggers implementation and your Change Management process should be
followed, including risk identification and management, and the update of your
scope baseline. The budget baseline will not be changed, as the money that was
to be spent on the dropped features will now be spent on the additional
feature. The schedule will change to delete work on the dropped features and
add work to develop the new ones. Don’t forget to update your QM plans to drop
testing of the dropped features and add testing for the new ones.
You must communicate the approved change to the project’s
stakeholders so that no-one is surprised by the elimination of the features identified
in the updated change request. Communication is not complete until every
stakeholder has been made aware of the change. Updating the Business
Requirements Document and other designs and plans is not sufficient. You will
need to communicate the change in your status review meetings, status reports,
and any other communications vehicle used by the project.
The tips in this article are not meant to replace a tight change management process. You'll gain much more from these tips if they are added to a solid project management knowledge base. The best way I know of to get that base is through project management training. Investigate becoming a certified Project Management Professional (PMP®) if you haven't already done so. There are a number of excellent PMP® Exam training products available, including ones on this web site (classroom and on-line). If your budget can accommodate a bigger expense, investigate some of the excellent PMP® courses available.
is not a "silver bullet” solution by any means. There may not be any features
in your plan that are obsolete or have a lower value than the one proposed by
the change request. At the very least your business sponsor, and the
stakeholder asking for the new feature, will know that you’ve done your best to
accommodate the change. They will also know that you are capable of thinking
outside of the box.