Does this sequence sound familiar? Customers talk to Sales. Sales makes requests to Marketing. Marketing talks to Product Management. Product Management writes requirements documents and presents them to Development Engineering. Development builds a product and informs the Documentation Department. The Documentation Department creates documents and gives them to Customer Service. Customer Service starts to support the new product sales. And no one is happy!
Of course, other departments including Strategy, Finance, Legal, Manufacturing, and Purchasing, and maybe even the Quality organization are involved in the process. It doesn’t matter; the result is always the same: no one is happy.
You may laugh at the above scenario or think of it as the old way of doing business. Perhaps the description is over-the-top. However, the underlying theme still exists in many organizations including small, agile, highly focused startups. The root cause is the notion of the division of responsibilities. The article in this collection, “Silo Is a Four-Letter Word” describes this issue. In essence, companies assign specialized tasks to specialists who invariably focus on “their” deliverables. With no malice intended, those deliverables may or may not align with the overall goal of the entire organization. Even with very flat organizations, operating in a highly collaborative environment (a “new” word), the trap is often sprung and individual goals take precedence over company-wide goals.
This situation is, unfortunately, inevitable. It is caused by the very nature of activities performed as processes. A process starts with an input request, work is then performed, and an output is produced which becomes an input to the next process. A company simply cannot survive without following this model. Even cooking a meal at home or changing a baby’s diaper follows these simple steps.
The problem occurs when the output of one process is “thrown over the wall” and becomes the input to the next process. With the transition, it is assumed that responsibility, along with authority, shifts as well. In a perfect world, this model is OK. However, we do not live in such a place. Process variation can always occur. Similarly, the earth is not static. The environment is constantly changing. Sometimes those changes are obvious and drastic, while at other times they are subtle and occur gradually and almost imperceptibly. A human example graphically illustrates this point: To new parents, a baby may not change from day to day, but for a grandparent who only sees the new born weekly, the changes are obvious. The rich uncle who visits monthly is even more surprised at the changes. However, when the new mom discovers that the perfectly fitting clothes from last week are now too tight, she becomes aware of the changes occurring right before her eyes.
The key to managing the ever-changing events during the entire product development life cycle is the constant application of attention across all disciplines. The article in this collection “Change Needs Constant Attention”, discusses the concept of entropy. (Please bear with me!) That concept, part of the study of thermodynamics, can be described as a system left alone, without the constant application of energy will move to a state of disorder. In the case of product development, disorder can be thought of as the development of the wrong product, perhaps at the wrong time, that might cost too much. There are many other attributes that may be wrong. They could stem from changing customer requirements all the way through new field implementation constraints. No element within the organization or outside source is immune from this situation.
The only way to minimize, but never totally eliminate, the amount of disorder is to have a constant flow of energy or involvement by all elements involved in the entire product life cycle. The day of static, written in ink, product requirements is gone. No rigid fences with sequential acitivites thrown over the wall, can be tolerated. Instead, fluid boundaries need to exist to ensure that the right amount of factual information is available to the right people at the right time.
To a methodical developer, this approach will seem totally foreign and frustrating. To be fair, it is; but it is the reality of today’s highly competitive, fast moving, global market. As one graphic illustration, it wasn’t too many years ago that it took two or three years to develop a new mobile radio. Once complete, it was announced with much fanfare to an eagerly awaiting sales organization by uncovering the product from beneath a cloth on a stage. Compare those days to today with cellular phones, which are more feature rich and complicated, announced every several months. To be fair, breakthrough products, even in the cellular industry, take longer to develop than refreshed models. But, they too, are the result of constant revisions of the requirements.
As a word of caution, great care must be taken to ensure that the organization is responding to the apparent need for change instead of reacting to events. This differentiation is so important that an entire chapter in this collection, Responding versus Reacting, that contains eleven articles has been included.
The application of energy from each element needs to be bi-directional. It is not sufficient for groups involved earlier in the cycle to merely stay involved with their downstream counterparts. The downstream element can provide valuable insight into what is possible to the groups involved with the initial gathering of requirements. New manufacturing techniques, new technologies, or changing field conditions, can provide unique capabilities that customers, sales reps, or marketers may be unaware of due to their lack of exposure.
The underlying concept behind developing a culture of no fences is two-fold, the free flow of information bi-directionally and embracing Principle Four: Promote and Maintain a Positive Response to Change. The inevitable alternative to not taking a no fences approach is to have the fences torn apart during a panic when it is discovered that the new product is not fulfilling its intended role and, perhaps, the company’s survival is in jeopardy. As discussed in Principle One: Stay in Business, everyone must adapt or die.