I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public. Our topic was Software Requirements Management.
Requirements Management is perhaps the most controversial topic in software development. Everyone seems to have their own technque. It is also the most important skill-set–statistically more important than development skills–to the overall success of a software project (Standish CHAOS Report, 2009).
Let me say that another way because this principle is not intuitive…if you want to improve the performance of your development projects, improve the skill-sets of your business analysts who generate requirements. Statistically, this has more of a performance boost on a projects outcome than any other skill-based area.
Many published requirements management techniques exists, and yet in a $220 Billion industury with a project failure/delay rate of 64%, it appears that most of these published techniques are not embraced.
Our seminar covered Eliciting, Prioritizing, Validating, and Documenting a requirements baseline. We discussed the progression of system context diagrams, UML actors, use cases, data-flow diagrams, High-Level Overview diagrams, High-Level Design diagrams and finally the Software Requirements Specification document. We talked briefly about a Concept of Operations document and a System Design Description document.
We discussed the difference between a plan-based documentation stack, and a minimized Agile-development documentation stack–which would be generated during a Sprint-Zero. (Yes BTW, you DO create documentation for Agile projects!)
We discussed techniques to control scope creep after the requirements baseline, and then discussed techniques for dealing with what I call ‘approval noise.’
What puzzles me the most about this topic is an entrenchment I encounter occasionally, as expressed by one of the seminar participants. He stated, after the seminar, that all of this was interesting in a textbook-like manner, but that he felt none of it was pratically applicable.
I asked him to explain how his company performs requirements practices and he said “Well, we have nothing written. We have everything in our head and we just talk across the cubicles.” He then told me he was frustrated at some additional items he was asked to add to his project that morning because it was supposed to be completed two weeks ago. He also told me that the owner of his organization wished they had a structured approach to software project management, and that–oh, by they way–many of the programmers were given layoff notices at the beginning of the week because the company is failing.
Hmm, it’s almost as if the problem is not properly in focus. Downstream problems are caused by upstream actions or omissions. I mean no disrespect, I just wish to point out the obvious that if companies like this would adopt upstream structure they would benefit from downstream success.
You see, the problem proper requirements practices solves is not at the development effort level, it is at the project management, estimation, budget, and strategy planning–or business level.
Software centric business level practices become predictable and executives can be proactive if their projects properly consume the time estimated.
Projects will consume the time estimated if they include all of the functionality needed for a desired level of business value, and those functions are identified in whole, at the beginning of the project. This way the software project time-frames and feature-sets can be included accurately in the estimation, budgeting, resource planning, and strategic planning of a company. This way, scope creep will be minimal, and the whole company will benefit from a predictable project delivery process.
Without proper requirements skills, entire feature-sets get missed upstream and need to be added ‘at the last moment’ downstream, the risk of re-work increases drastically, and recurring cycles of this erode project managers and the development team’s credibility in the eyes of the executive team and the waiting customers. In worst case scenarios, this can lead to layoffs and finally company failures.
If you haven’t been trained on proper requirement management techniques, you are holding your organization at risk. Attend our next three-day Software Requirements Management training course held September 7-9 in SLC.
Mike J. Berry, CS, CSPM
www.RedRockResearch.com
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.
