Creating Change in the Requirements Process
|
|
| Freedom from
Project Surprises Newsletter - Issue #47 |
March 2009 |
|
|
|
Requirements
Closure - It's a common problem for most teams and is easily one of the
top three contributors to project failures. Back in the January
newsletter I wrote an article that emphasized the need for a change, a
dedicated effort that looks at making a difference in requirements
gathering for projects. This month I want to build on that theme and
generate some thoughts on what could be different for the requirements
process in our industry.
The first article is a look at the
typical flow of the requirements process, one that is surprising common
across most organizations. The second article is some ideas to inspire
a thought process that will take requirements to a new level.
Jeff Jorvig, NPD Process Consultant
|
|
News of Interest to NPD Teams
- Looking for an economical solution that enables
progress on execution improvements during this tight budget period? See
the Virtual Design Manager.
- In need of a simple yet effective way to manage
and monitor your new product workflow? Check out this web based solution to managing your NPD/NPI
process here and be in control of your
development activities.
- Check out our quick
start instant downloads for managing design
projects.
Leadership Quote of the month:
"Enduring
setbacks while maintaining the ability to show others the way to go
forward is a true test of leadership."
-- Nitin Nohria |
A Snapshot of Today's Requirements
Process
In
the semiconductor industry today the requirements process for the
majority of teams is structured into a serial sequence that looks
similar to the diagram to the right.
Project complexity may drive a different number of hierarchical
requirements levels within the engineering domain, however the diagram
concept is the same. In the interest of getting projects started there
is usually a parallel component (denoted as the red urgency line) that
cuts across all levels of requirements. This parallel short cut path
allows the detailed engineering requirements to begin, often without a
solid understanding of the top-level system or customer application
needs.
Requirements details are typically captured in a word
processing document for each level. This document has multiple reviews
and iterations before being released to the next lower level of detail.
Within the engineering domain the written specifications are often
complemented with some degree of high level modeling of the IC
component or an IC family of components.
The task of keeping the
customer requirements aligned with the engineering implementation
details is a manual, error prone process. The engineering level
requirements details are usually held close to the vest and typically
not shared outside of the company. This separation of what is shared
vs. what is kept in "secret" further complicates the alignment of
engineering and customer requirements.
The ownership of the
requirements process changes as the requirements march towards finer
engineering level detail. The high-level customer requirements are
usually managed within marketing/applications engineering. The
engineering level details are managed within the design team and may
have different owners for each level of detail. Note - This
requirements ownership and management handoff is a major source of
confusion, leading to a lack of clarity and focus.
So, how's this process working for you?
Based
on inputs from many of you, requirements at both the project level and
individual level is a big problem. Couple this with non-ideal scope
change control (Feature Creep) and this makes requirements a huge deal
for projects. Organizations are not achieving the requirements results
they desperately need, so it's fair that the current approach is just
not working.
In reality the requirements process is the one item
in the development process that has not evolved, while the design flow
and tools have seen significant advances. The existing requirements
process is an antiquated system that is impacting our projects to a
significant degree and the industry continues to accept this, project
after project. I believe most will agree that a change in the
requirements gathering process is long overdue!
|
Are
you Ready for Changes in the Requirements Process?
If
you are ready for some changes to the requirements gathering process I
would like to share a number of possibilities that can be explored.
It's best to start out defining a set of objectives to describe what
needs to be different. Items such as time, synergy, quality (i.e. less
rework) and clarity would probably be the areas where objectives should
be established. Also, keep in mind that this is a business level
change, not only marketing or engineering.
Focus, focus and
focus
The
simplest place to start and make a difference is emphasizing management
of the entire process. Have one individual responsible for managing the
requirements details that spans across the customer, marketing and
engineering domains. The domains typically manage their own
requirements activities, but there is often nothing in place to drive
the technical process through all domains. This leaves the project open
to the cross-domain blame game where one domain is locked waiting for
inputs from another. A single person that focuses on total requirements
actions and manages the cross-domain synergy should make a significant
difference. The person tasked with this must be skilled in requirements
gathering.
Workshops
This
would build upon the focused management aspect to fast track the entire
process for a project through a series of concentrated workshops with
all the key players. This emphasizes the necessary focus while
providing an environment to accentuate closure of specific actions and
sub-deliverables. There is an art to facilitating such a process,
however, when one does this well the results can be rather impressive.
The facilitator of such a workshop must be an individual skilled at
focusing a team and enabling synergy while maintaining an unbiased view
towards any specific requirements.
Modeling
In
my opinion modeling at all levels would be the most advanced form of
requirements gathering. This removes the mindless and error prone task
of reviewing written documents. Modeling is very common within design
but must be advanced into the marketing domain via an industry common
language such as UML or more precisely SysML.
Other possibilities in modeling platforms exist and the decision on
which is best will be left to your organization. The key model platform
decision factor should be accessibility outside of design while
maintaining the ability to directly interpret the model within the
designers world. An emphasis on early modeling over written
documentation also yields access to Agile methods, a very successful
iterative approach in software product development. The key question to
ask yourself is this "Can modeling in the customer domain bring relief
to the requirements closure process?". I believe this is easily a yes.
The
most important step to a better requirements process is to take an
honest look at how the process is working in your organization. If your
organization falls in with the majority, you believe the process is
broken. Are you going to
justify why it is the way it is or are you going to do something about
it?
Continuing only to talk about the requirements problem is
justification; organizing, defining objectives and taking action is
doing something about it. Contact me when you are ready to remove
requirements as a disruption to projects and I will work with your
organization to provide the results you need.
|
| How I
can Help
"Providing solutions to the systemic project challenges that
quietly steal early revenue opportunity"
- Re-engineering
the Requirements Process -
I look forward to working with a team that is ready for a new way to
pull the requirements together for a project. I will bring the passion,
the knowledge and the leadership to bring about change.
- Requirements
Templates - I take a hierarchical approach to requirements
documentation, thus minimizing the amount of shared information at each
level.
- Requirements
workshop
- I will facilitate the timely closure of a high quality set of
requirements. 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.
- NPD team one day workshop to improve planning, execution and monitoring skills for
design projects.
- Web based NPD workflow management.
- 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, 480-442-6730 |
|
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 a question 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.
|
|
|
