Requirements Closure - Stop being held Hostage
|
|
| Freedom from
Project Surprises Newsletter - Issue #59 |
March 2010 |
|
|
|
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!
Jeff Jorvig, IC NPD Coach
|
|
News of Interest to New Product
Development Teams
Leadership Quote of the month:
"Teams do
not go physically flat, they go mentally stale."
-- Vince Lombardi |
Getting a handle on
Requirements Closure
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.
|
| How I
can Help
"Providing solutions to the systemic project challenges that
quietly steal early revenue opportunity"
- Solving Issues
with Requirements closure and quality.
- Discovery
& Solution - Do
you need to find and remove the the barriers to a predictable and
streamlined new product flow? Maybe you need to understand the history
of past failed project activities. Our Discovery & Solution
services provide the results you need.
- Requirements
workshops
- I will facilitate the timely closure of a high quality set of
requirements for a specific product. If you have a complicated project
where requirements closure is critical, this would be an ideal
candidate for a workshop. More information can be found here.
-
Design
services - Digital & analog IC design, PC Board Design,
Firmware.
-
NPD Flow
Management - Web based best practices, flow, task, deliverable
& monitoring of the project portfolio. Details here.
-
Register
Management - Tool
for synchronization of register information between hardware, firmware,
validation and documentation. Delivers the RTL code, verification code
and documentation for common or custom bus interfaces.
-
NPD team one day workshop to improve planning, execution and monitoring skills for
design projects.
- Ready made downloads:
schedule, checklist, analog design guide.
- Increase management bandwidth via Virtual Design Manager.
- Full listing of common services here.
Contact me today via email, or phone at
480-895-0478. |
|
Feedback
To increase the value of this newsletter for you I would like
to hear your comments.
- What do you like or not like about this
newsletter?
- What subjects would you like to see covered in
the future?
- How is the format?
- Ask me a question related to new product
development and I will anonymously post and answer it here in this
section.
Please email me here with any questions,
comments or suggestions that will help me better serve my readers. I
would enjoy hearing from you.
|
|
|
