Requirements Closure - Stop being held Hostage

New Product Requirements Closure - something that everyone has hopes would go smoother, however inevitably drags on longer than planned and is often lacking the quality that prevents frequent revisiting of items assumed to be closed. Crisp requirements closure is one of the most significant issues I hear about, yet it receives the least amount of attention to resolve. Cost associated with delayed and/or low quality requirements should command significant attention, nevertheless organizations continue to be held hostage as the new product team battles it's way out of gridlock. It's time to release the new product requirements hostages!

First off, when you consider requirements closure what comes to mind? It has multiple definitions and the one that you are most familiar with generally depends on which functional area you are supporting for a new product. There are typically several types of requirements that are strung together, providing a roadmap from product scope through production release. Examples of the most common requirements forms include customer, system, engineering, test, chip and module. Further complicating the situation is the fact that there are several owners supporting closure of each level of requirements.

Critical to on time product release is one strategic concept - all the various levels of requirements must be in alignment early in the development cycle and stay in synchronization throughout it. The cost associated with requirements confusion is huge and most organizations are in denial about the level of impact this has to new product execution. Once the reality of requirements confusion influence sets in there are several approaches that can be considered to address this.

Manage the Requirement Process
Are you sure the process is being managed the best it can? If you really look into what's going on you will find that those responsible for a set of requirements are frequently in a holding pattern for one of two reasons. The first is that they are waiting for another set of requirements to be completed enough so they can get started. The second is that they are waiting for a decision.

Waiting is the primary requirements closure killer and these nonproductive periods must be managed to keep things moving. Here's a question for your organization: Who owns "the" requirements process? Most likely the answer is many people and that is simply not working well, is it? There must be someone that owns the entire requirements process, a "requirements architect" if you will. In short - someone must manage the wait states, bring structure to the overall process, establish both a decision-making and change management procedure and use them religiously.

Analyze and Fix what's Broken
If requirements closure is dragging on and on there is clearly something broken. Do you know what it is? Where are the wait states and why are they there? With so many people involved there are ego issues, communication breakdowns, missed expectations and generally a lot of confusion and blame; all generating misguided reasons to wait.

There must be an effort to find out what the systemic barriers are to smooth requirements closure and then remove them. Investigate and repair what is found. Nine times out of ten the largest contributors to closure will be people issues; yes it's not technology but good old communication difficulties between individuals that is enabling the need to wait.

Consider a Workshop Approach
A requirements workshop is an agile approach that brings much needed focus and gets everyone together to hash things out in an environment conducive to attaining prompt closure - the wait states are eliminated. A winning workshop is a well-planned event with pre-work, ground rules, a defined decision process and the right people getting together. A workshop is not throwing everyone in a room to roll up their shirtsleeves with orders to "figure it out" because the schedule is in jeopardy.

Quality facilitation is the primary enabler of a workshop that meets expectations. Don't skimp on the skills of the facilitator; they must fully understand the process, drive the planning and pre-work, ensure proper attendees and guide the team through the decision process and ground rules generation. For a workshop that hits the mark, planning will be everything. The facilitator must in no way be a decision maker on any specific requirements; their role is to strictly keep things moving forward.

Tools
There are a number of tools that can help with the requirements process. I caution you in making any assumption that tools will be a fix-all for the issues you may be having. Any tools will augment a good requirements strategy; however will not fix what is broken. Most tools I am aware of target the software industry but could also be a great value to the semi biz. Here's a few links to get your started in your research:
http://www.volere.co.uk/tools.htm
http://gatherspace.com/
http://www-01.ibm.com/software/awdtools/reqpro/
http://www.accompa.com/index.html
http://www.sparxsystems.com.au/

Modeling
Writing and reviewing written requirements documents is pretty archaic in these days of high technology. We must get to electronic requirements (modeling) through the entire thread of requirements. Modeling is very common within the design domain but must be advanced into the marketing domain via an industry common language such as UML or more precisely SysML. An emphasis on early modeling over written documentation also yields access to Agile methods, a very successful iterative approach in software product development. Isn't it time it time to advance the art here?

Final Thoughts
The requirements process can be improved significantly, although only if someone is in the drivers seat to make changes. I must emphasize again the need for a single point of requirements ownership, a requirements architect. This is the individual responsible for eliminating the wait states by enabling the flow of information and establishing focus for all requirements types. Skimp on responsibility here and closure will just float along as it has in the past. There is a better way and it begins with an owned focus on the full suite of new product requirements.