The Most Difficult Discipline

Thu, 08/15/2013 - 12:38pm
Alan Nicol, Executive Member, AlanNicolSolutions

Why is it that the most important, most powerful, most effective methods, tools, or practices are also the most difficult? Answering that question might be a challenge to keep the philosophy professors busy for a good, long time. For now, accept your grandfather’s axiom that what is worth doing, is worth taking our time to do.

That axiom applies to business, process improvement, and product development. It takes time and effort to do something correctly, the first time. There is more. Not only can we be concerted in our effort to do right the first time, we can be deliberate in our efforts to prepare for future efforts, to make our upcoming efforts come out optimal.

Preparing for the future, setting up future success, requires an even deeper level of discipline. That discipline is simply patient planning. Unfortunately, business pressure often drives urgency and impatience, discouraging careful planning. It doesn’t change the fact that many times the best way to produce quickly, grow quickly, or develop quickly is to plan and design slowly.

It sounds philosophically counterintuitive when put into those words, and yet, intuitively we know it to be true. It is built into our favorite process improvement and product development methodologies because it is true.

In the Lean methodology planning is value-added because it prevents the waste of defects and rework. The Six Sigma methodology is built around the idea that we must first carefully define our challenge, measure it, and analyze it before we take any action to address it. Likewise, our popular gated product development methods and the Value Engineering methods also advocate careful analysis and planning before designing and developing.

With the advent and adoption of these many process improvement and product development disciplines we have all felt first hand how difficult it is to stick to the discipline under the pressure of business. After all, the time spent in development is time that the solution is not implemented and not improving profits. We don’t want to waste time.

There is a deeper level of the patient planning discipline, however, a more strategic instead of tactical level. It involves planning not just for the product or process in question, but for the next product or process that will be developed. Planning for a long series of future developments is the most difficult.

This time my example for discussion is my own. I’m working with a friend and colleague to design a new product. We have an idea that, if we can successfully prototype and field-test it with an audience, might turn into a viable entrepreneurial opportunity. The vision of the product, however, depends upon our ability to provide nearly limitless possible combinations and configurations.

Like it is with most inventors and invention processes, the further we get down our design path, and the closer we get to a working prototype, the more excited we are. The temptation to just put it together and get it working is almost too much to resist, and we don’t have investors or business leaders breathing down our necks (yet) telling us we are taking too long.

We know though, that if we just throw it together, even if it works well, we will set ourselves up for painful and even crippling future development and a production nightmare. We must be very careful in the development of our first design to enable, and make room for, future features, capabilities, and options. Some of those features and options we think we already know. Undoubtedly, we haven’t imagined what some of our potential customers will and we don’t know what all of them might be.

So, we are carefully, painfully slowly, designing our solution around enabling future potential. It means that on any given day spent in collaborative design we accomplish, I’ll say, about a tenth of what we might accomplish if we just moved forward without the planning. Nine tenths of our discussion and effort is centered around carefully writing our development rules, plans, and cross checking our elements against the others to make sure that we aren’t creating dead ends.

We know we are doing the right thing, but it doesn’t change the desire to have a working version ready to play. It requires a great deal of patience and discipline. The planning is not near as much fun as the designing or building. It’s far less fun than the testing, and when we look at our rate of progress we worry about how long it is going to take us to get to our field trials and whether the window of opportunity will remain.

However, the alternative is even more frightening to us. If we proceed to field trials or, worse, to production and we don’t have all of our planning in place, we could find that we cannot achieve the limitless potential of the product because we didn’t enable it. We might need to redesign the base system or design each follow-on system from scratch. Interchangeability of design is crucial to our success and we can’t afford to disable it. Our whole vision might collapse if we have to redesign after launch.

Our scenario is not uncommon these days. Compare it to the introduction of key business processes such as Enterprise Resource Planning (ERP) systems or the construction of a new manufacturing line. Today’s product strategies often include future models, features, and capabilities that will not be available in the initial launch.

It is obvious in our electronic product designs, but we don’t always consider if the integrated circuit components, memory chips, circuit boards, or physical cases allow for the capacity we will need for future functions. It may be more expensive for the initial launch to include the extra capacity, but what of the expense of redesign or new design to include future features?

 If we choose to power functions with solid-state electronics, we need to redesign the product to change those functions in the future. However, if we power functions with firmware, a function change might be possible with a download. In high-volume production, the firmware strategy might be more costly to manufacture. So we should decide, is it better to plan ahead, or to redesign and redevelop?

What might be more profitable for the initial launch or initial product of a product line, might not be the most viable or profitable way to drive the entire product line through the life of the entire system set. This is true for mechanical designs and production systems just as it is for electronics.

When we design mechanical elements, might we consider if they might be useful or used on other designs? Can we anticipate and design in the features they will need for other designs?

When we design our production systems, do we design them with the possibility for adjunct product features or options that we know we will develop? Do we choose plants or locations and design the floor layout with future business growth and product potential in mind?

A corner of product design industry where careful planning for the use of components, subsystems, or system architectures for limitless future use, reuse, or interchangeability is an ever-present necessity is the field of software design and development. When developing software we should always consider what code should be part of the core program or a subroutine that can be re-used or interchanged. Our architectures must assume that customers will demand new features in the future and be designed to enable “plugging” them in.

It may not always be more profitable to leave room for future developments in current designs. The key is to intentionally, knowledgeably make an educated decision. If our designs don’t include the ability to adapt to future needs it should be because we strategically decided that they should not. It should not be because we didn’t think about it when we had the chance or didn’t take the time to do so when we should have.

Whether it is a new product design, mechanical, electronic, or software, or a production process, or a business system, strategically planning for an entire string of potential future needs is a difficult discipline. It requires some idea of what the probable future is and it requires an acceptance that we will spend a great deal of time and effort in patient planning before we begin making tangible progress.

Furthermore, we must somehow overcome both the perceived and likely potential that we get caught in a perpetual planning process without ever moving into an execution phase. The defense for that failure mode is clear and unwavering design vision and requirements. We get caught in never-ending planning when the needs or expectations are forever changing.

We must be careful to put such planning efforts where they are truly important. It is easy to over-plan simple solutions. The key is to apply it to strategic opportunities. Any time we are instituting a solution that we know will touch a great many other systems, products, or functions, we should take a step back and design around both the immediate need as well as future potential challenges and needs.

It’s difficult to carefully plan today’s processes and designs with tomorrow’s solutions in mind. Like a game of chess it requires strategic thinking, tactical response, and a great deal of what-if consideration. Consider the potential it unleashes. What if you could enable the next five years’ worth of features and functions with today’s core design, eliminating the need to redesign or design-from-scratch the next several solutions. Over the next several years, how much time, effort, risk, or resource consumption might that strategy eliminate?

Take a look at your current efforts. Are you and your team tackling some of them tactically when you should be considering a long-term strategic potential? Take the time today to patiently, carefully plan your key designs so that future developments will happen quickly, with greater potential effectiveness.

Stay wise, friends.

If you like what you just read, find more of Alan’s thoughts at


Share This Story

You may login with either your assigned username or your e-mail address.
The password field is case sensitive.