Son of Five Rivers Blog

For the advancement of Entrepreneurship, Sustainability & the Ecology of Everyday Life

Changing Requirements

I had a professor named Hooks who spent 21 years working for NASA and helped design the first space shuttle (The Enterprise).  One thing she focused on was the importance of requirements gathering.  She spent 12.5 years doing requirements gathering for the enterprise alone.  She followed by sharing the point that if we waited until we knew everything  we needed to know to build something, we would never get started.  So there is always a fine balance with collecting to much information, for those people with this issues product lifecycle models can help understand the entire process.

Here are a few things I’ve seen and experienced with changing requirements:  Even with a thorough requirement definition effort, change is sometimes inevitable so put together a change management process:

  • Establish a Change Control Process
  • Develop standard forms for collecting requirement changes that include justification (2 reasons)
  • Develop procedures for a thorough impact assessment
  • A system to communicate approved changes quickly to the people who need to know
  • Implement a procedure to ensure all documents are updated when changes are approved.

2 Changes to Avoid:

  • Rush Changes:  “It’s just a little change”  (Any programmer will know right off that bat what this means…)
  • Deferred Changes:  Approving it today and doing it tomorrow

The Change Management Sanity Check: (The Criteria for change)

  • Is it broken? (If Yes = Fix it)
  • Is it illegal? (If Yes = Fix it)
  • Is it unethical or immortal? (If Yes = Fix it)
  • If No = Consider leaving it alone

*Just remember the cost of fixing an error goes up as development progresses.

January 21, 2010 Posted by | Business Model | , , | Leave a comment