What is a Change Request?
Or, how I learned to stop worrying and love continuous change.
By: Brad Einarsen
June 29, 2005
Why do Change Requests Exist?
If there is one element of software development that causes the most friction and uncertainty between the business and technical people it is the change request. The change request is a documented deviation from, or addition to, the project specifications in whatever form they are found on a particular project. To understand the change request we must first understand the project specifications.
A project in the world of Internet development is generally the construction of a new site, or expansion of functionality of an existing site. This creative process starts with the business process owners describing a future state and ends up with the Internet developers creating a set of functionality to create that future state. This vision of the future is often expressed in a proposal or project scope document. This document is open, vague, and expansive. It is designed to stir the imagination and get people excited about the project by seeing the benefits that will be enabled.
It is at this stage, when the specifications are vague and the excitement for the project is high, that 3rd party developers are asked to quote on pricing. Because the risk of project failure is highest at this point, the management of imagination is critical. The developer is trained to imagine the simplest solution that meets the business needs while the business owner is more likely to imagine new features and functionality every time he or she returns to the topic. The fluid nature of the business requirements, need for firm project budgets, and general optimism at this stage of the project all create an environment where miscommunication is likely and potentially expensive for both parties.
Once the project scope is set there is the task of documenting the specifications. This document should be where the differences in technical imagination and business imagination collide. If reviewed thoroughly, this document will show all parties where their imaginations are divergent and will allow them to come together and develop the best solution. Naturally, it doesn't always work that way. At this stage in the project the business owners have begun to get impatient with the talk and want to see some results. This impatience can lead to specifications that are vague and to reviews that are rushed or skipped entirely.
Imagination is (nearly) Infinite, Budgets are Not
The control of change requests is critical to the success of most projects. Without a good change request process the number of enhancement ideas will quickly outstrip the amount of resource available to do the work. The insidious problem here is that the resources get committed before the realization that they are already at capacity. This is a result of the technical team wanting to do a good job and satisfy the business needs and being overly optimistic on how long changes take to implement. Meanwhile, the business group will happily keep piling on "just one more clarification" as long as they are allowed. They aren't trying to make the project fail, they simply have good ideas every day that could make the system more helpful. Unfortunately, this "scope creep" is the number one killer of technical projects. It's not the technology that fails, or the skills of those programming the system, it's the interface between the business and the technical team that causes the most grief.
It is important to reiterate this point: no one is trying to make the project fail. It is just that the dynamics of most IT projects are predisposed to failure.
Time, Knowledge, and Requirements
Even when the project specifications are well written and well reviewed there is still a phenomenon called "memory drift". This drift works in different directions for the business owners and the technical team. The business owners will experience a subtle change in memory toward more expansive requirements because this reflects the best future world for them and the more they think about it and talk with others about it the more it seems like it is part of the project. The technical team will experience a subtle change in memory towards more restrictive requirements because this removes workload and complexity from the project and makes it more manageable. This is especially important for the technical team when deadlines are looming and time is running out.
Memory Drift
Often, this drift manifests itself as side conversations in hallways. After these conversations are complete they can leave very different impressions on the participants. The business owners feel like the requirements have been fully communicated and accepted by the technical team because "we talked about it." The technical team feels that no changes have been made because the specs are not changed and "we only talked about it."
The most important thing to remember is that neither group is doing this on purpose - these changes in memory are a side effect of the pressures of the project.
The solution to this problem is a clear understanding of all parties that, "if it's not written down in the specification document(s), then it doesn't exist." This is not to say that change cannot happen, actually the opposite is true. Having a change request process and document means that change can happen and, better still, all parties can participate to ensure that the right change happens.
Anatomy of the Change Request
The change request is a relatively simple document and needs only a few pieces of information:
- Description of the functionality being added or modified written to the same level of detail as the system specifications (this varies by project).
- Implications, if any, for other parts of the system. Sometimes a change request will trigger changes elsewhere in the system and sometimes it is just imperative that the users understand that the system may operate differently.
- Resources required to make the change. For internal groups this is usually time and for external groups it is usually money.
- Schedule of when the changes will be available.
- Contact on the business side with sign-off authority to determine when the change request is done.
The change requests should be kept in the same place as the system specifications. The idea is that another person reviewing the documentation years from now should be able to see all of the specifications in one place.
Valid use of Change Requests
The change requests we have been discussing so far are what I would refer to as "valid" change requests. This means that they are close to the project (not completely new projects on their own) and they come from one of the common sources of new functionality:
- New requirements based on new knowledge of what is possible
- New requirements based on a changing competitive environment
- Uncovered or assumed requirements not exposed for the technical specification
- Extended or clarified requirements based on different interpretations of written specifications
The first two are easy to agree on for most teams but the last two can be more problematic. Change requests always imply more resources; money in the case of 3rd party development groups such as HKS, or internal credits in the case of internal IT groups. Uncovered requirements were often hidden in the early stages of the project because they were "tacit knowledge" for the business experts. This tacit (or unconscious) knowledge is assumed to be common by the business experts but is not known by the technical group. If the business group does not see that the technical group had no way of knowing the tacit knowledge then they may assume that the technical group is either "stupid" (they should have known) or "evil" (they willfully ignored the knowledge).
Neither situation is good, although "stupid" is probably a little less damaging than "evil" since that one tends to indicate that trust has been destroyed between the groups.
Invalid use of Change Requests
There is also a class of change requests that I class as "invalid" change requests. These are willful misinterpretations of or exclusions in the specifications that drive up the price of a project, often because it was underbid in the first place (See also: Choosing a Web Developer). The best defense against unethical change requests is a thorough analysis of the project proposal and specification documents. If you know exactly what is being built then there is a much greater chance of determining an invalid change request from a valid one.
Which is it?
The problem is that whether a change request is valid or invalid is often strongly influenced by the background and team allegiance of the person making the call. There will be disagreements on change requests in every project but as long as there is good trust between the stakeholders then a satisfactory result can always be found.
Limitations of Language
In general, once a developer and a client have been working together for a while, they will get a "gut feel" for what is a change request versus what is included in the project simply by keeping track of the spirit of the original request. This is based on the development of trust between the parties and of shared language and expectations.
The words used in the proposal, specifications, and change requests can mean very different things to the different parties. Any "imagination gap" between the groups is often highlighted in the definitions of these words.
For example, a "report" on the current status of the web application can take on very different meanings based on who you are. Some sample definitions might be:
For the business owner:
A report is the set of key performance indicators, updated continuously, that shows the health of the organization and allows us to drill down to the individual items that are shown on the screen.
As we can see, the above definition could result in an almost infinite range of possibilities for the drill-downs and the "key performance indicators" could easily change over the life of the project as more information becomes known. The term updated continuously may even mean that the business owner wants to see change on the screen while it is being viewed.
For the developer:
A report is the current values of a set of 10 pieces of data collected into a view and displayed on the screen.
In this case the set of 10 pieces of data may or may not correspond to the key performance indicators and the report is limited to only one set of data, no drill down functionality is assumed and no change or movement on the screen is envisioned.
And this example is for one word that could appear many times inside any given proposal or scope document. Only in the technical specifications are these things made explicit, and even then getting a thorough review can be like pulling teeth.
Solutions to Tame the Beast
Here are a few techniques that can be used to tame the change control beast.
Documentation
The project should consist of the following documents. Shortcuts can be taken if the client and vendor have a standing relationship, but even in this scenario there can be trouble if the expectations are not managed.
Documents to focus on:
Project Scope: defines the desired outcome in broad, sweeping terms, usually written by the client, often as part of the RFP.
Project Proposal: defines the general method of meeting the requirements in the RFP or project scope.
Technical Specifications: defines the precise deliverables and is generally considered exhaustive… that is, if the technical specifications are silent on a feature then it does not exist.
Change Requests: the documented changes to the system as requested by the client and updated by the vendor. These documents should be kept with the specifications.
Project Contact Solidarity
At the beginning of the project the major players need to come to a common understanding of what is being built, regardless of what is written on the paper. They need to fully buy into the project as a whole without reservation because they will be asked to defend the other side to their constituents when push comes to shove and the deadlines are looming.
If there is a change in project contacts then the handoff should be open, publicized, and highly communicative. It would not be unreasonable to ensure that the three people met offsite so that they could communicate the project details free from any interference.
Change is Constant
Do not become discouraged because change requests are appearing on a project. This does not mean that the initial specification was too limited, it means that there is enough interest in the project to create the change requests.
There is Always Phase Two (or Three, or Four, or Five…)
You cannot "boil the ocean" and have everything happened all at once. If you could, then we wouldn't need the concept of time. Sometimes it is best, especially late in the development cycle, to push change requests onto a Phase Two plan. This way they can be reviewed after the site is running and more usage details are known.
Read the Documentation
This advice is equally relevant for the business owners as the technical team. If there is documentation then read it, understand it, and maintain it. The written word remains our most valuable asset on Internet development projects.
