This is a very common question. There are various reasons.  Some we have control over and some we don’t.  A key point is that we want to avoid changes that are a result of having poorly defined requirements.

In this blog we address major reasons why requirements change. In our blog “Controlling and Managing Change”  we  discuss what you can do to help control or at least manage change.

Why requirements change:

1. Poorly Defined Requirement Development Process: A major reason for change is a poorly defined or ignored requirement development process. This can result in defective requirements, incorrect requirements, and missing requirements.  The further in the development life cycle you go before discovering these problems, the greater the impact on cost and schedule.  Developers find major problems and issues with the requirements and so the changes begin.  Those doing verification find requirements that are ambiguous and unverifiable and so change continues.  Remember the minute we start making changes, more and more changes come out – it is like opening Pandora’s box – it is not a good plan to start with a bad set of requirements.
2. Ignored Requirements. Another thing that could have happened is that the developers could have just ignored some of the original requirements.  Either they didn’t understand the requirements or the requirements were too complex or the developer just chose to ignore the requirements.  End result, the developers designed the product without reference to one of more of the requirements and now we have to go back and fix the problem via changes
3. Immature Technology: The flip side of the technology issue is that projects sometimes base their ability to meet stakeholder expectations (or set stakeholder expectations) based on a technology that is not mature enough to use at this time.  Doing so adds risk to the project as well as the potential for change if the technology does not deliver.
4. Unforeseen problems.  Unless you are an oracle, you can’t see into the future to predict the unknowns and unknown unknowns.  Unforeseen problems occur.  Budgets get cut.  Delivery dates are moved up. Problems in testing result in schedule slips.  A system that you interact with (interface with) changes unexpectedly. All of these things can result in change.
5. Need Changes.  Sometimes the “problem” that your product is to address and the basic Need for your product changes.  If this happens, the whole project needs to be rethought.  All the deliverables you have prepared to date as base on meeting the originally stated Need.    If the Need changes, you may  have to redo a lot of the work you have done thus far in order to meet the new Need.
6. Missing Stakeholders: Key stakeholders were left out at the beginning of the project.  .  Stakeholder represent requirements.  Missing stakeholders result in missing requirements.
7. Overly optimistic budget or schedule:  Promising something that cannot be delivered with the available resources or in the time allotted.
8. Interfaces not adequately defined.  A key interface was overlooked.  Without addressing the interface, the product cannot be integrated into the macro system of which it is a part.
9. All product lifecycle stages not addressed:  A key product lifecycle was missed (test, verification, validation, transportation, storage, transition, upgrades, maintenance, etc.).  Unique requirements to address that lifecycle will need to be added.
10. Changing needs: Changing needs is often perceived as the major reason for change.  Perhaps the customers keep changing their minds – they don’t know what they want.  This could be the case, but often the customers weren’t challenged or helped to find what they really wanted to begin with or to understand what was really needed.    But in some cases, the needs really do change.  Changing needs happens more often on projects with a lengthy  development cycle.

Why needs change:

1. Some people don’t know what they want until they see  it.  They say: “Show me some rocks, and I will tell you if it is the right rock!” You may have developed something, like a GUI interface or a report someone wanted, and when you deliver it they say:  “no, that is not what I wanted, that’s not what I meant.  What I really meant for it to be is ………..”  That is one of the problems we have and that is why we encourage prototyping and modeling and other things so we can let people see things while we are writing the requirements instead of making them wait until the product is developed.  Some other tools you can use to help your stakeholders communicate what they really expect and need are use cases, stories, and scenarios you can use to develop a set of system concepts that address the expectations of all the stakeholders, for all lifecycle stages, and for both nominal and off-nominal cases.
2. Changing Expectations: Another reason for change is that stakeholder’s expectations change over time if not managed.  If you are not constantly going back to those stakeholders and setting those expectations to let them know what to expect, other people could be influencing them and changing their expectations.  So, to thwart changing expectations, communicate, communicate, communicate to set and reset stakeholder expectations and minimize potential changes.
3. Changing technology: Another reason for change is the technology is changing so fast.  We have this rapidly changing technology, which means everyone wants the latest and greatest.  If you have a very long development time, and many products do (space projects, airplanes, automobiles, and even accounting software can take years to develop), the technology will be changing and we are trying to scramble and keep up.  We didn’t ask for some things in the past because we didn’t have the technology, but now that technology is available, we want those things included.
4. New and changing Stakeholders: Some stakeholders may not exist at the beginning of the project.  Over time, some stakeholders leave and are replaced with new stakeholders.  Each of these new stakeholders could see the problem and desired solution (end state) differently.  Because of this they may want to change or add new requirements.

Impacts of Change
Many studies have been conducted that show that over 80% of the defects found during verification were introduced during the requirement development stage of the project.  Other studies show that a 30% change in requirements after baseline, can double the cost of the project.

It doesn’t matter what kind of product is in development: government, commercial, or in-house projects;  hardware, software, or integrated Hardware/software projects. Managers do not like to hear that the cost to develop the product is going to be double what they were told at the beginning!  Especially when the reason for the overruns were because we did a poor job in defining the product requirements and as a result we had a lot of rework which drove up the costs.  Marketing doesn’t want to hear that the product introduction date has slipped.  Customers don’t want to hear that a product release date has slipped.

As stated at the beginning of the blog: There are some reasons for change that we have control over and some reasons we don’t.  We decide if we are going to do these activities or not.  We decide if requirements are important or not.  We decide if we are going to develop defect free requirements or not.  We have control over the quality of our requirement development process and our requirements. Failing to do so can result in massive cost overruns and schedule slips, unhappy customers, lost profits, and can even be career limiting.

In our next blog we will discuss what you can do to help control or at least manage change.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.