Complexity Creep
What if your company only had one product? One feature in a product? What would life in that world be like? Then, as an excercise, slowly add one feature and one product at a time, and see how that world changes, which processes are added, and how complexity begins to accumulate. Lean and Six Sigma that are implemented on the shop floor often do not help because the problem with proliferate and unmanaged complexity begins with the product, not after.
Let’s assume that the costs of complexity is not trivial. Let’s further assume that complexity — in all its faces — is absolutely stealth and not easily known or recognized. Let’s think about it: when product management — in concert with sales and marketing — plan together for a new product and do all their market sizing and research, there is typically very little thought as to the effects through the value chain that might cause. For example, new products, features, or extensions of existing products usually require a new process, change in current processes, or similiar changes in the value chain. These changes are often forgotten or ignored, because the emphasis at that stage in the business game is growth, not really operations. So, what are we to do?
Keep Things Simple
First, we need to keep things simple, and avoid complexity and proliferation of products and processes as we can. To tactically do that, the following might help:
- Control the arbitrary additions of products and their consequent processes. To do that, make the requirements for marketes and product managers higher, thereby creating a higher barrier-to-launch. A higher return on investment might be a requirement, or a net present value calculation, where appropriate. This would ensure more careful consideration of processes, and make operations more in alignment with product and marketing.
- Institionalize simplicity. Amazon has become very, very good at this. In their product development approach, internally dubbed as "working backwards", a focus on the customer weaves simplicity throughout the product development process. Specifically,
The product development process at Amazon is also absolutely centered on the customer. Amazon follows a process called "Working Backwards", which means that the first deliverables created are the documents at launch, then work backwards towards the items closer to the implementation. Defining a product this way adds clarity and simplicity — you know at the front-end what the customer can expect, and working backwards allows the team to build it. Here are the general steps followed in this process, and I take it directly from Werner Vogels:
- Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists – what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product – not just how we think about it internally.
- Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
- Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.
- Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.
Following this process reduced so much "front-end" time — that is, the cycle time from concept-to-delivery (brainstorming, discussions, and arguments) was significantly reduced because the team and peripheral stakeholders agreed earlier rather than later on what the product would look like in the end. Moreover, because of the bias-for-action core value, people naturally want to produce, rather than have long, drawn-out discussions: at the end, people want working code, manifested in a store that is launched and adding value to the top-line.
- Find the balance between Operating Complexity and Product Innovation. I submit that there is likely an inflection point such that complexity and costs are minimized while innovation is maximized. That relationship might look like the following:
Notice how complexity and costs are shown as a percentage of revenue (% of revenue), and how as product variety increases, complexity and costs begin to rise exponentially, with a likely optimal point preceeding the exponential climb in (% of revenue). A balance can be reached. What’s the right balance for your firm?
Conclusion
Complexity is a silent killer for the firm. Recognizing complexity is the first step; managing complexity and then finding the right balance between complexity and innovation would ensure a more thoughful approach to your Lean and Six Sigma projects, more success for the firm, better costs containment, and more profitable relationships with customers.
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Additional comments powered by BackType
I found a really useful Lean Healthcare blog at http://www.leanhealthcareservices.com/blog