Solving the Change Request problem

Problem Statement:

1) How do we minimize the no. of change requests during development of an application?

2) How do we reduce the friction between software service vendors and customers on what constitutes a change?

Two ways to solve the problem

Solution 1: We will give you as many change requests as the budget permits – Change requests are a contentious issue because the vendor thinks he is spending from his budget and the customer from his. Planning a change request budget right at the beginning and making it transparent will assuage this issue. That way the money, schedule and effort variance is accounted for upfront. The plan is no longer a fixed one, but a fixed one + anticipated changes. This gives breathing room for both the vendor as well as the customer during the execution of the project.

Solution 2: We will show you the working application once every week – Change requests are a contentious issue because we deliver much too late in the game, when the business has changed or better ideas have evolved after looking at the actual software. Frequently showing a working demo of the application will go a long way in minimizing change requests. Even changes that come are easily accommodated during to the still evolving nature of the application.

How do we implement Solution 1?

Arrive at the requirement change index. A collaborative
process where Vendor assigns a requirement clarity index (VC Index – Vendor Confidence Index) to each requirement. The higher the clarity/confidence index, the clearer it is for Vendor to implement it. This is Vendor’s confidence in the way the requirement is defined/stated.

1. The customer assigns a requirement importance index (RI
   Index). The higher the index, the more important the requirement is.


2. The customer assigns a “I Know How To Implement It” index
   (IKHTII Index) to each requirement. This is the customer saying that they have already visualized how this requirement should be implemented. The higher this index, the better the feature’s visualization in the customer’s mind.


3. The customer assigns “Likely To Change” index (LTNC Index)
   to each requirement. This is the customer assigning a probability of some requirement not changing in the future after its features have been defined. The higher the index, the more likely the customer thinks this feature will go through changes after the first implementation.

All these indices are calculated on a scale of 1 to 5.

At the RFP stage, only (a) is used to arrive at the change
request budget, if the customer refuses to do (b), (c) and (d). So, at the RFP stage the vendor gives a project estimate (fixed bid) + (change request budget) that the customer should account for right upfront. The change request budget may or may not be used; it is a reserve budget for the project.

At the contract stage, the change request budget becomes part of the contract. The vendor does not put any buffers (most of the times these are gut-feel arbitrary ones which is why the problems start in the first place) in the estimate because of this safety net that the customer has accounted for.

During PDW, (b), (c) and (d) must be completed. Based on (a), (b), (c) and (d), we arrive at a change index (CI). This will determine the change request budget assigned at the beginning. This budget will be in addition to the initial project estimate made by Vendor and accepted by the customer.

An illustration of this concept is provided in the table below:

The Total CI is calculated using the formula:

((6-VC)/5)*(RI/5)*((6-IKHTII)/5)*(LTC/5)

The change budget is calculated using the formula:

Effort Estimate to Implement Feature X Total CI

Thus, we are now getting into the project knowing or anticipating a certain degree of change that is planned. The factor of change in a project is now a scientific guess and planned.

How do we implement Solution 2?

The most common reason given by development teams to refuse starting work until there is a concrete functional specification and/or technical design is that the application needs a framework to build on. The other is of course that the requirements are not clear and the fear of requirement change without a proper document (we have addressed this second part in Solution 1). This framework is frequently required to define a standard way of exception handling, logging, authorization, authentication, auditing, data access/ORM, handling business rules and objects etc. However, these are most frequently repetitive in similar projects. If there was a readily available framework (or a reference architecture) for building a particular
class of application (say web-based applications), then the development team could directly get down to implementing features for the requirements rather than waiting for some functional specification being built and the technical design being completed.

Sure enough, this may lead to some problems later on because
we are using a generic framework that may or may not have fully addressed the unique requirements of the application being built. For this, we need to have a refactoring budget again planned.

Again, we could calculate a refactoring index right at the beginning of the project. This is the vendor saying given a requirement, how much of the implementation is already existent in the framework. The higher this index, the more the refactoring required to implement the requirement.

An illustration is given below:

The Refactoring Budget is calculated using the formula:

(RI/5)*Effort Estimate

Note that the refactoring budget is necessary to be calculated when we are using aggressive iterative methodologies that do minimal requirements planning/functional specification writing, but instead relying heavily on directly getting to develop the application in week 1 or 2 of the project. This refactoring budget may not be necessary for traditional waterfall models.