Number 6 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”

1. Short-change Time Spent on Software Requirements or Don’t do Them at All
2. Don’t Listen to Your Customer’s Needs
3. Don’t use Models
4. Use Weasel Words
5. Don’t Prioritize Requirements
6. Don’t  Baseline and Change Control Requirements
7. Don’t do Requirements Traceability

You have done a great job eliciting, prioritizing and documenting the requirements for your project. Your requirements have been approved by the stakeholders. You are now home free and can rest on your laurels for the rest of the project. Wrong! You can still shoot yourself in the foot. In fact, your project can still fail miserably due to lack of requirements change control. The business reality will constantly change even after requirements are “signed off” and the project continues to move through the software development life cycle. Are you prepared to deal with this change?

“Why would a project team not perform change control for requirements?” you might ask. I think for the same general reasons a project team would not do effective change control on other important project artifacts: a false assumption that change control is more expensive or more of a hassle than the benefit it provides. That it gets in the way of “real work”. Let me give you a personal example of the disastrous effect of this type of thinking I experienced many years ago when working at a large company. I was asked to investigate a project in trouble. It was originally a skunk-works project done by a team outside of development that was established a few years earlier after lobbying management “that the development team was too slow”. The team no longer existed. The few remaining members had quit or been fired over growing quality complaints from the customer base. I discovered in the first couple of days that the main reason this team was “faster than dev team” (and also had no repeatable quality control) was because they did no change control for requirements or code changes. Even worse, there was no formal source management! The entire source code base was on the team manager’s computer and after he left, his computer was erased and re-assigned to another employee. There was no back up. The source code was lost. There was no formal defect tracking. Every fix was done as a “one off” on demand. There was no tracking of what fix was done for which customer, when it was done and for what business reason it was done. It was possible but too expensive to reverse engineer from the object code and our company had to abandon this legacy product line. The company lost money and angered the customers that were using the product. This is an extreme case, but I think more often companies shortchange managing changes to requirements thinking they are not important after development begins.

In Karl Weiger’s article, “Karl Wiegers Describes 10 Requirements Traps to Avoid”, trap #8 is “Inadequate Change Process”.  Karl Weigers lists some of the symptoms of inadequate change process as follows:

“The most glaring symptom of this trap is that your project doesn’t have a defined process for dealing with requirements changes. Consequently, new functionality might become evident only during system or beta testing. Even if you have a change process in place, some people might bypass it by talking to their buddies on the development team to get changes incorporated. Developers might implement changes that were already rejected or work on proposed changes before they’re approved. Other clues that your change process is deficient are that it’s not clear who makes decisions about proposed changes, change decisions aren’t communicated to all those affected, and the status of each change request isn’t known at all times.”

Change happens and you need to be prepared for managing this inevitable change. Mr. Wiegers goes on to suggest some solutions:

“Define a practical change control process for your project. You can supplement the process with a problem- or issue-tracking tool to collect, track, and communicate changes. However, remember that a tool is not a substitute for a process. Set up a change control board (CCB) to consider proposed changes at regular intervals and make binding decisions to accept or reject them. (See “How to Control Software Changes” by Ronald Starbuck in STQE, November/December 1999, for more about the CCB.)The CCB shouldn’t be any larger or more formal than necessary to ensure that changes are processed effectively and efficiently. Establish and enforce realistic change control policies. Compare the priority of each proposed requirement change against the body of requirements remaining to be implemented.”

Note that the last item is greatly helped if you prioritized the requirements in the first place by business value. (See my previous blog on prioritizing requirements.)  A good system for managing requirements is more than helpful, it is a necessity. If your requirements artifacts are in document form, you can use a document management system or a more general system like SharePoint. Even better is using a requirements management tool to give more fine-grained control at the individual requirement level and also to provide for traceability. Don’t forget to do regular backups of whatever systems you use to control important project artifacts and actually test the backup/restore mechanism. (Another company I once worked for had several of their servers stolen during a Christmas Eve break in. One of them contained important project artifacts and it was discovered there was a bug in the backup routines with time stamp checking resulting in entire directories not being backed up. No one had ever tested the backup/restore program for accuracy…)

Don’t shoot yourself in the foot on your next project! Resolve today to effectively management requirements changes and to do it by business value. The choice is yours.

Next time I will look at “Don’t do Requirements Traceability”