Paying for Change

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 issue.

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.