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.

It goes go on and on and on…

How true is the following statement for you? “We are having problems with closure of requirements, some of our projects should have never been started, project scope control is out of control and of course we are missing production dates. Everyone misses dates and it’s not something we have any direct control over anyway because ….”

I hear something like the statement above on a regular basis and it is always is followed up with some sort of validation as to why the situation has been this way for a long time. There is acknowledgement of a problem, there are unverified reasons for the situation, there is unwarranted acceptance and there is blame; action towards a solution is what’s frequently missing.

I know, I know; everything is actually going fine, or at least OK and there is ongoing work for improvements in some areas. Here’s a test – pick a problem in your new product development process that is a nasty thorn for you. Now think back a year, did the problem exist then? Do you believe that 365 days from now that same unpleasant barb will be causing you aggravation? If you answered yes or maybe to both of these you are dealing with a known problem that has a lifetime of at least two years; now tell me why that isn’t totally unacceptable?

Here’s what’s going on - the unresolved long-term problems continue disrupting projects because they are allowed to. Sure there are reasons, everyone has a reason and it will be one of money, resources or time. These are only excuses, the real reason is that an owner does not step forward and take action to make a known new product development issue go away. Issues lacking owners continue to thrive, creating frustration and impacting projects for a long time to come. I came across this quote recently that captures the ownership dilemma beautifully:

“If it's never our fault, we can't take responsibility for it. If we can't take responsibility for it, we'll always be its victim.”
-- Richard Bach

When we stop trying to ensure new product development execution inefficiency is someone else’s responsibility and own the path to a solution, we will stop being victims of what is rarely fixed and often talked about. It’s well past the time to stop talking and take action to get one of those two year old plus problems off the table; you know just the one I am talking about. Are you ready to step into the light and own the solution or will you continue to be a distraught victim? It is a choice.

Why your Internal IP Reuse Strategy is not Working

Internal IP reuse is something that every business wants, although the current scorecard indicates these objectives are not being met. A fairly large gap exists between leadership's vision of an ideal internal IP reuse strategy and the implementations in place today. Management views IP reuse as an essential ingredient of quicker time to market while the design communities perceive it as a road plagued with dangerous potholes. Reality - continue overlooking the designer's needs and internal reuse will remain a distant vision.

Every organization has some type of reuse activity going on. For some, they are content with their current approach in handling reuse. However, for the majority there is more effort required to achieve anything approaching an ideal set of reuse objectives. At the low end of reuse strategies, what I affectionately call Whack and Plop (WAP), is where IP blocks are excised out of an existing chip and dropped into a new design.

A more desired implementation of reuse includes a full repository scheme where the designer can eagerly shop for IP and download it with a full suite of documentation, test benches and characterization data. This ideal vision of reuse is where most want to be, some form of WAP is where most are today.

So what's keeping reuse in the dark ages? It is simply that the needs of the re-user are not being attended to, technology is in charge instead of the needs of potential end users. The fears of reuse are not being addressed and the design community is pushing back because the deliverables associated with IP are not mitigating these concerns. Without proper IP content designers will only reuse what they are comfortable with, either their own work or someone else's work that they respect and have easy access to. The major hurdle today is in achieving a level of IP deliverable content that will diminish the fears of reuse, thus allowing designers to develop the confidence to favor formal IP reuse over WAP or the initiation of a new design.

First Rule of IP reuse - Content Rules
It's not the repository that will cinch reuse; it's the content deliverables for specific IP. If a designer digs through a wonderfully crafted repository, downloads the deliverables and finds a deficiency in IP content, you have lost them for a very long time. Start with content, not a fancy repository; content is the foundation of any IP reuse growth strategy.

The worst implementations will be those that are developed solely by a team of non-designers that are great with software. Keep in mind that reuse enablement is not a software or EDA task; it is a deliverable content development task to provide the essential design collateral designers must have to be able to validate and gain confidence in another designers work.

Second rule of IP Reuse - Address Reuse Concerns
Know what the concerns of reuse are and address them. Talk to your design community and make sure you understand both what would enable them to reuse and what would turn them off. This is as simple as listening and applying what is learned. Leave this vital process out and you may as well stay with a WAP reuse strategy; you will be wasting time and money trying to make it work. You can lead a horse to water but you can't make him drink; the solution is finding out what will make him want to drink.

Third Rule of IP Reuse - Marketing Strategy
Develop a marketing strategy to define and roll out the internal reuse implementation. Consider this as a product with customers that need to be wowed. The designer's are not generally a captive audience where reuse has been legislated, therefore it is essential you properly market IP as a product. A proper marketing strategy will also drive closure on the first two rules of IP reuse - giving customers what they need.

Consider the following:

• Appeal - Why would someone want to use it?
• History - Has it been used before? Where? Any data?
• Features - Overly complex or not enough bells and whistles.
• Options - Does it need configuration options to cover a broader design space?

Fourth Rule of IP Reuse - Only Quality in Repository
After the first three rules have been addressed it's time to put the IP into a repository. I suggest something pretty simple since there is not likely going to be a large initial offering. The repository can be enhanced over time as you get feedback from the users. A word of warning - don't put anything in the repository that does not meet the first two rules. Any perception of garbage in the repository will ruin your efforts for a long time. Remember - Content rules! The repository leaves a short term impression, what the designers receive from it leaves a long term impression.

Closing thoughts on Internal Reuse

• The end user will make or break your reuse strategy. It is paramount to understand what will "make it work" for them.
• Think first about what is needed... the deliverable content.
• The repository will leave a short-term impression on the end users. The IP deliverable content impression will last a lifetime. Focus on what matters!
• Creating reusable IP should not be much more effort than a good, high quality design effort!
• Reuse content will need to be kept current based on silicon usage and tool updates. Don't ignore or underestimate your work here.
• Reuse enablement requires the matching of re-user needs with cataloged content.