The Antidote for Terminal Sameness

Everyone has something they would like to see different, some aspect of the development process that they know is causing continuous disruption in new product releases. The frustration is obvious; the major steps to make it go away rarely occur, often smothered by a battery of excuses that keep a complete solution just out of reach. The fact is that a solution that involves significant change enables the most basic instinct – fear. That unchecked fear is keeping significant new product execution improvements from being realized.

Does the following statement reflect your reality? “I want things to be different, but I don’t want to change.” If you are in alignment with the majority of the population then this is indeed a core belief of yours, although one that is definitely not publicly disclosed. This sentiment is the primary reason that new product execution stays pretty much the same. Maintaining an emotional bond to the comfortable known keeps valuable change out of the picture.

New product execution remains in a status quo state not because of technical reasons, but because of a deep-rooted fear based anchor. Organizations are technically brilliant while failing at execution, simply because they are dinosaurs when it comes to engaging real change. If things are to be significantly different, there needs to be significant change! There is no other way; recognize that, deal with it and move forward.

Harsh? Absolutely! Many organizations are perplexed by their inability to significantly improve new product efforts. In reality they have fallen into the pit of terminal sameness and are unable see the situation as anything but one of maintaining the status quo. The execution problems have consumed them. They are unable to get enough of a grasp on the big picture to see the major root issues that are siphoning off the teams productivity. So yes, I am being harsh, only in the hopes of jarring some brave souls to take a realistic view of the fears of change that are holding them back.

To the right is a list of the most likely fear based reasons that keep people from changing. See them for the de-motivating fears that they are and move on. Risk-averse types will see these as solid barriers and continue to thrive on crisis management as the norm. Risk-takers will see these as hurdles to be dealt with, knowing a better way is on the other side. Where are you?

Project execution stagnation is the norm today and the contenders for solutions have been an ever-increasing emphasis on the technical tools and methods for tweaking them to a higher productivity. How’s that been working out? Tweaking keeps the fear of change in check, while also failing to provide solutions that make a substantial impact in time to revenue. When ready to make a real difference it will require a real change, not a tweak.

It’s imperative to honestly ask yourself if you are keeping things the same out of a fear of change. If this is the case you are unknowingly suppressing substantial improvements, so be real in your personal assessment. If you want things to be better, really better, then you along with everyone else will need to embrace change. The new mantra for your organization must be “I want project execution to be significantly better and I am ready to accept substantial change as a solution”. There is no shortcut! Fail to embrace change and your new product execution will continue to be consumed by terminal sameness, expect nothing different.

“Again and again, the impossible problem is solved when we see that the problem is only a tough decision waiting to be made.” -- Robert H. Schuller

Tools are “a” Solution, not “the” Solution

The tools we have available today for producing chips have advanced a long way over the years. There is no question of the tremendous value they bring to new product development (NPD) teams. Even with all this capability at our disposal there are frequent problems in meeting new product revenue plans. How can this be?

Maybe our expectations have reached an unhealthy dependency on tools for project management, design, verifications, validation and even overall product management. We are a proud family of techno-geeks and it is our nature to depend on technology, a reliance that is blinding us to non-technical root issues. Maybe it is time to consider the possibility of gaps between what technology provides and the needs of the team. When a problem has shown itself during a project, how often is it pinned on the tools or the improper inputs to a tool? How long will we continue blaming tools and then wonder why a predictable path to new product revenue remains out of reach?

If projects have systemic and repeating barriers to predictable execution then there is something missing. There are issues just out of view that are not being addressed. In situations like this consider that the team members are not getting what they need to be individually successful. This unseen gap is rarely about a tool, but a lack in information such as project requirements, individual requirements, and deliverable expectations to name a few. Gaining insight into the individual success deficiencies that are quietly siphoning the teams effectiveness is essential.

How do you find them? Ask each member of your NPD team the following question in a one on one setting: "What changes in deliverables to you or additional information would improve your ability to complete your tasks?" Now learn by listening and “hearing” the answer. Continue digging deeper until you believe the root issue has been uncovered. Address what has been learned. This is an example of “Plain Old Management Style” (POMS) at work; no tool or methodology will provide the wealth of information that can be learned by this simple technique.

New product projects are not only about managing schedules, risk, technology, tools, budgets and data; they must also include management of the most variable, unpredictable and challenging component of all - the people. Recognize this and new product opportunity will flourish, deny this and become a dinosaur entombed in technology. New product execution excellence is a people thing and practicing a “Plain Old Management Style” is certain to produce positive impact, where a pure reliance on tools has not.

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.