Processes such as designing and developing new products do not require the same effort or produce the same output every time we execute them. However, we can manage runaway efforts and improve our planning practices by pacing certain activities.
In the field of design engineering we have a self-inflicted joke. “If it ain’t broke, it don’t have enough features.” Engineers also battle a stereotype that I don’t believe was caused by the character Scotty from the original Star Trek TV series, but was certainly well portrayed. That is, “an engineer will not finish designing until you tell him he has to.”
Where do these jokes and stereotypes come from? Well, as much as engineers might speak them, we don’t create the phenomenon. It’s purely natural.
Some activities are simply endless. They don’t come to a conclusion until we decide we have done enough. Following the axiom, “Knowledge is power,” those trying to execute these activities will tend to seek more knowledge and understanding with an aim for producing the best possible outcome. However, others, particularly those in charge of schedules and budgets, tend to follow the axiom, “Time is money.” Thus, we conflict.
In particular, creative activities and research activities tend to fall in the “endless” category. We can dream up ideas or search for more information for as long as we are permitted. Related activities also include experiments, prototyping, testing, de-bugging, and analysis.
These activities, focused on gathering or creating information, data, or understanding, are often the activities that drive run-away schedules, though not always. They are also the activities that are most difficult to plan and schedule and, therefore, the ones we argue most about when planning our development efforts. These creative and information-gathering activities are the ones we should pace.
Pacing is merely making a decision, preferably an informed one, concerning how hard and fast, or how long, we are going to drive a specific action. It is a major concept in Lean manufacturing for managing processes. It is also a significant concept in Six Sigma for reducing variation. We’ll discuss it here as a means to stabilize the typically unpredictable, ever-changing business process of product development. Of course the idea can be applied anywhere we like.
There are two basic parts to pacing activities.
- Allocate a specific amount of time for the activity
- Know how long it takes to do the activity well
The first is pretty straightforward, though we will circle back around to it shortly. The second is often the part we argue about most and is the most difficult to pin down. Following are some suggestions.
First, collect data. This doesn’t have to be complicated. Review some recently completed projects with the teams that executed them. Examine how long the activities of interest took, whether enough time was spent or too much time and why. Mark it down and start identifying some expected time frames and reasonable resource needs. Reasonable, informed estimates are better than wild guesses. Your conclusions don’t have to be statistically predictable.
Second, allocate decisions. The processes we want to pace are all about information and knowledge. We need the knowledge so we can make decisions. The best way to determine how much time is needed for creative and informative activities is to examine how much effort is needed to get the information needed to make a decision.
Begin by working with the team to list the critical decisions that must be made to determine the design or execute the development. Then, identify the key supporting decisions that must be made. For example, we must select a concept to develop for prototype and testing. That concept selection/decision must be based on performance and manufacturability/cost. We must investigate a short list of material options, manufacturing processes, and design ideas.
Generally, problems are easy to solve when they are broken down into bite-sized pieces. The same goes for plans and schedules. Once you have the decisions and bits of information listed, it becomes easy to allocate their investigation and decisions to team members.
Make a single team member responsible and accountable for each piece of information and each decision. A team member can be responsible for more than one, but the more the wealth is spread, the better the focus will be. Of course, if we are going to make someone responsible and accountable, we must also enable him or her. Assign the resources and time necessary. Otherwise the failure is ours, not the team member’s.
Based on the data we gathered from previous projects and our understanding of what is required for the activity in question, we can make some very reasonable estimates for what will be required. Set a time limit to make the decision. Be sure that, at a minimum, there is enough time to get the most essential information for making the decision. Then discuss the gamble of additional time and information driving more, better options or decisions. Make a determination and put a hard stop on it.
With the decisions lined up in order of how one enables another and hard stops established we could very confidently pace the otherwise never-ending activities within our product development plan. This kind of paced planning addresses the battle of axioms described above on both fronts. It enables us to put a limit to the limitless and launch our products as quickly as reasonable. It also ensures that our creative and informative activities are enabled to produce the information we need to execute well and decide wisely.
There is too much business to be lost by launch delays and run-away projects. There is also too much opportunity to be sacrificed if our design is not well thought through. By carefully pacing our “endless” tasks and using reasonable and judicious planning, we can draw a solid balance between time and knowledge.
The long-term benefit is not just a legacy of better products developed efficiently, but a better feel for how long it takes to develop products of varying complexity. The ability to estimate and plan product development projects at the highest level gives business executives a much better ability to plan budgets, revenues, profits, and resources, and, therefore, a better vision for driving the business successfully.
Take a good look at your product development challenges right now. If your teams suffer from run-away investigations, over-design, or overly limited design and development schedules, consider the concepts and recommendations above. By understanding the decisions that are necessary, what knowledge is needed for those decisions, and what it takes to get that knowledge, we can construct better development plans, make better products, and be more predictable in our product development behavior. Give it a try.
Stay wise, friends.
