Preston Smith Quick Tips
(In the last Quick Tip, we showed how to calculate the cost of delay — the profit lost from a one-week slippage in a product development project.)
Some managers do resist these calculations, saying that the market for their products is so uncertain that they cannot estimate what would happen to sales if product introduction slips. They are correct for a very few bleeding-edge products where the market is essentially unknown. These calculations also break down for government projects for which there is no profit motive. But for 90% of product development projects, such statements belie a lack of marketing homework.
Another group says that they could never get marketing and engineering to agree on the assumptions underlying such calculations. True enough. However, this problem is actually a blessing. Doing the calculations requires engineering and marketing to grapple with the market conditions driving urgency. Until these two groups reach a common understanding on the market drivers, engineering is unlikely to really believe in the urgency, and their behavior will reflect this ambivalence.
Yet a third group says that management would not believe or act on such numbers even if they had them. True again, and this is why we put great effort into education when we work with clients to implement a cost-of-delay system. We show the finance people why they need to keep these tools simple. We coach senior management in working with development teams so the teams can make better, faster project decisions — decisions that will not be overruled by management later. You can do the same; just don’t assume that this education will happen automatically.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Many managers in industry want to get their new products to market faster. Ironically, when we ask them just how rapid product development will improve their profitability, we tend to get a quite different answer from each manager. Consequently, you can imagine the confusion at the worker level when time to market is mentioned. Some developers actually believe that shorter development cycles means skipping steps of the process.
This confusion needn’t exist. You can easily calculate just how much one week of delay on a project will impact your bottom line. To get this cost of delay — or urgency factor — build a life-cycle profit-and-loss statement for the product, assuming that it is on time. A simple spreadsheet on one page of paper will do. Then build a variation of this spreadsheet reflecting lost sales if the project is delayed by a significant amount, say three months. Calculate the profit lost by delay, and divide by the number of weeks of delay used to give you the cost of delay, in profit lost per week.
In doing this calculation independently for each project, one discovery you will make is that all of your projects are not equally urgent. You are likely to see a variation in the urgency factor of ten-to-one or more among your active projects. Then you and your developers can achieve consensus on time to market, applying it selectively where it will really have an impact on your bottom line.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
In many ways, yes. Some techniques, for instance, cross-functional development teams and a product specification well-rooted in the needs of the customer, will improve Faster as well as Better and Cheaper. Improvements in all three areas are especially likely initially in an improvement program, because large opportunities remain.
At other times, we encounter more of a trade-off. For example, a co-located development team is generally powerful for Faster, but it will not necessarily improve Cheaper. A full QFD (quality function deployment) analysis will help Better but usually at the expense of Faster. Employing an integral product architecture usually aids Cheaper, but a modular architecture is normally Faster.
It is essential to recognize that product development, at its very root, involves making countless trade-offs. Each development project has unique demands for Faster, Better, Cheaper (F,B,C). That is, F,B,C are NOT EQUAL on a given project, and each project will have its own desired balance of F,B,C.
Couple this with the fact that your developers — in their daily work — must make trade-offs among F,B,C, often subconsciously. If there is no shared agreement on the F,B,C balance for the project at hand, each developer will make her/his own choice.
When this happens, members of your herd will each migrate in a different direction. Then you will need a round-up, and round-ups degrade Faster, Better, AND Cheaper.
Another point to keep in mind is that emphasizing Cheaper too strongly can starve the program of the very resources needed to make the transition to F,B,C. You will have to invest resources to get better.
For more on this topic, refer to the article, “Reaping Benefit from Speed to Market.”
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
They can, but few product developers use them in a way that yields any real speed advantage. Consider that an ordinary prototype might take a month (20 workdays) to make, and a rapid prototype takes a day. Assuming that this prototype is on your critical path, you save 19 days, which is 4% of a two-year project — not impressive!
However, developers who apply prototypes wisely often see timesavings of 50%. They do this by viewing each prototype as an opportunity to answer a question. They ask their question clearly, build a simple prototype to answer only this question, get their answer quickly, and move on to another round of prototypes to answer the next set of questions.
That is, they view product development as a series of questions to be resolved, and they use prototypes to resolve these questions early, quickly, and precisely. Compared to normal prototyping, they “front-load” their prototyping by building many more prototypes earlier and focusing each one on a specific question. (Traditional prototypes are too infrequent and appear too late to provide effective feedback.)
Surprisingly, those who front-load their prototyping usually pay less in total for their simple prototypes than those who build a few elaborate prototypes late in development for verification.
To learn more, read some of the prototyping publications on this website, or see Stefan Thomke’s new book on contemporary experimentation.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
This depends on what you mean by lean. Although lean manufacturing is a clear topic—essentially, the Toyota Production System–people have interpreted lean product development in many ways. Katherine Radeka and Tricia Sutton nicely lay out five quite different varieties of lean product development in “What is ‘lean’ about product development?” Published in Visions, June 2007 (Vol.31 Issue No.2) pg 11-15.
To too many people, lean means simply to “lean out” the process, that is, to cut the cost of development by accomplishing more with less. Consequently, I will use this interpretation, knowing that others may look at lean development differently.
If our objective is to reduce the cost of development, whether lean or flexible development will be cheaper depends completely on how much change you face in your project. If you don’t expect much change, lean development will be less costly because many of the flexibility techniques incur extra costs, for instance, adding interfaces that will contain change or exploring alternative designs to keep your options open.
On the other hand, if you expect lots of change, flexible development will be cheaper because change is generally costly due to the replanning, rework, and waste of changing course. Flexible development reduces the cost of change by making it easier to switch to an alternative solution, even relatively late in development.
This is why I emphasize using flexibility techniques only when and where you expect change. You should not use them on every project and not even on every part of a project—only in the areas of a project or product where you face considerable potential uncertainty or change. Then use lean techniques elsewhere.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Quick Tip
October 2007
Phased product development processes (including Stage-Gate®) are popular, and most companies today use them. They allow management considerable control over and insight into a project without a great investment of time on their part. Thus, phased development systems have great appeal.
Unfortunately, these systems have the undesired side effect of not being flexible to change during development. They encourage management and the development team to make many project decisions before their last responsible moments, thus imposing unnecessary constraints on change. They encourage planning a project in advance and following this plan, thus penalizing project leaders who vary from plan— the essence of flexibility.
It isn’t that flexible development is “good” and phased development is “bad,” nor is one approach always preferred. It all depends on how much change you face in a project— or better yet, in a certain part of a project. If change is unlikely, phased development is cheaper and easier to execute. However, if change is likely, phased development will probably be frustrating and more expensive because work will have to be redone and decisions undone.
Consequently, it is a matter of recognizing where change is likely to occur in a project and employing flexible approaches there and more traditional phased development elsewhere.
So why not avoid change altogether and proceed comfortably with easy-to-manage phased development? Unfortunately, change is linked inescapably to innovation. If you aren’t changing things during development in response to what you are learning, you aren’t innovating. And innovation is what CEOs claim they seek
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
In our increasingly internetted world, information propagates faster and markets shift more rapidly. Consequently, many of our clients continue to shorten their product development cycles.
But speed has its dark side. Most of us have seen a development project go awry because it was rushed and important activities were skipped. More deeply, we have heard since childhood that “haste makes waste” and that “quick” leads to “dirty.” No wonder that we are suspicious about accelerating product development.
Fortunately, there is a bright side to speed: done well, speed is complementary to quality. When we dig into a specific project to see where its cycle time went, we discover that it vanished while waiting for resources, decisions, and information. When this happens, both speed and quality suffer. More time was wasted when work had to be redone due to poor communication or weak plans — again, a quality problem too.
It is no accident that many athletic events are races against time. A runner is able to win only when everything is in perfect condition: the training, the field, the equipment, and the runner’s health and diet. Runners who skip a few training sessions or skimp on coaching don’t win races.
Product development is the same: winning speeds are possible only when all conditions are carefully set up for the highest quality performance.
In fact, even if you do not need speed in every development project, speed is perhaps your best comprehensive measure that everything influencing your development process is operating at its highest quality level.
To pursue this topic, see our paper, “Reaping Benefit From Speed to Market”
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
We are moving toward virtual product development teams, due to globalization, the fragmentation caused by corporate acquisitions, and greater reliance on supplier chains.
However, many managers cave in too easily to this “progress.” They fail to appreciate that dispersed teams — especially virtual ones — always lose some of the effectiveness that co-located ones enjoy. In their book, Virtual Teams, Lipnack and Stamps, who have been promoting virtual teams for twenty years, state, “On the whole, a virtual team must be smarter than a conventional collocated team — just to survive.” (page 189) Likewise, Duarte and Snyder’s Mastering Virtual Teams emphasizes, “The complexity of communicating over time, distance, and organizations causes unique problems that are not easy to solve.” (page 77)
Basically, a co-located team brings higher performance at a certain cost of implementation. When time to market is vital, the speed of a co-located team can easily outweigh its cost. If you cannot completely co-locate, then partial co-location can bring much of the benefit at a fraction of the cost. For example, both sets of authors quoted above advocate bringing the team together face-to-face at the beginning of the project to build trust, establish their working processes, and resolve the fuzzy definitional issues that occur at a project’s outset.
You can also analyze your teams’ communication patterns to see just which individuals would benefit most from co-location.
Duarte and Snyder’s book provides much guidance in choosing virtual technologies appropriate to the task at hand. This book also guides you in building and managing virtual teams.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Not too well, and this is one reason why we decided to publish our book, Proactive Risk Management.
Typically today, a company has a stages-and-gates development process, and the first stage requires that the team identify and document the project’s risks. Because this is a required deliverable, it happens, and the risks are discussed at the first project review.
However, this is as far as it goes, and the risks wait like a time bomb in the project file. The development process doesn’t call for analyzing the risks, prioritizing them, or taking action against them. All of the benefit of project risk management stems from these later steps, which seldom occur.
Worse, when the identified but unmanaged risks start happening later in the project, it is embarrassing to the team and management to see that they had identified this risk but then done nothing to prevent or prepare for it. It would have been better to not have even identified the risks initially than to set themselves up for this embarrassment.
So, don’t get caught in this middle ground. Either ignore project risk management altogether or complete the risk management process, even if only for a few of your largest risks.
Of course, our book or our project risk management services will help you put a beneficial project risk management process in place, but you can get started easily by reading some of our articles on the subject, such as, “A Portrait Of Risk” or “Dealing With Project Risks Successfully.”
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
December 2002 Quick Tip
E-mail is a primary means of communication these days. Product developers spend more time on e-mail than they do on the telephone. It can be a great way to communicate.
But it also sucks up vast amounts of time that could be put to direct use in developing products. Worse, it is often a source of miscommunication and project delay.
Fortunately, you can take many steps to improve e-mail’s communication power. Many of these suggestions involve establishing policies or protocols to which everyone in the organization agrees. Thus, to build buy-in, develop these with lots of participation and be sure to focus on a specific deficiency that you have observed. Consider these protocols:
- A standardized way of writing the subject line, for example, starting with the project number (if you are having trouble sorting incoming e-mails)
- Always replying within a certain period, such as 24 hours, even if you do not have the full answer yet (if you are wasting time waiting for replies)
- Putting all requests for action in the closing paragraph of the message (if you notice that many requested actions are overlooked)
- Consciously trimming or adding to a message (if messages often contain either too little or too much information to respond effectively)
Finally, always be sensitive to how a thread is moving toward resolution. If you notice a message returning a few times without closure, maybe it’s time to forget the computer and pick up the telephone. Often, basic differences in tacit assumptions can be settled in seconds this way.
For more on this, see our article on dispersed product development teams.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Our 20 October 2000 Quick Tip “How do I hear the voice of the customer as I develop a new product?” dealt with “hearing” the voice of the customer. Having “heard” this voice, the next question is how we can capture it in a way that continues to guide us as we develop our new product.
The conventional wisdom here is to use a technique called QFD (quality function deployment). However, our experience has been that QFD can easily consume inordinate amounts of time and resources.
Alan Cooper suggests an alternative: personas. A persona is a carefully crafted composite description of a certain class of a user. You may have several personas for your product, but each comes directly from your detailed customer research, and together, they encompass most of your anticipated user base.
To render a persona real, its description includes a photo of the individual and a description of his or her idiosyncrasies. For specific examples of personas, see our review of Cooper’s book.
Once you have captured your principal users in a persona, you simply design your product to satisfy this persona. If you have done a good job of building your personas, your product will satisfy the needs of your principal persona and not alienate any of your other personas.
Note that this is a far different approach than the more common one of designing a product to provide all of the features that competitors provide — which doesn’t assure that any users will be happy. Furthermore, copying competitive features is a prescription for being a follower!
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
How and when you make decisions is a critical skill in developing products flexibly. The basic rule is not to make a decision until you must – what we call the last responsible moment (LRM). When you make decisions before this, you close off options, thus reducing your flexibility.
There is much more to the LRM than I can cover in this short note, but it is important to understand that this is not procrastination. Instead, it is a matter of recognizing early that there is a decision to be made, noting when its LRM will occur, and starting to collect information to aid in making it better when its LRM arrives.
Another critical aspect of flexible decision making to appreciate is that many of the approaches we use to manage development projects force us into making decisions before their LRM, thus restricting our flexibility. Such systems include phased development systems (for example, Stage-Gate®); conventional project scheduling, budgeting, and planning; and upfront product requirements specification. Consequently, the ability to maintain flexibility requires us to revisit such systems and reconfigure them to defer the nonessential decisions. Approaches such as rolling wave planning and the use of product visions do exactly this.
Fortunately, this is a rich area, and there are many tools available to make decisions more flexibly. These include decision trees, real options thinking, consequence tables, framing decisions before making them, and internalizing the LRM.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Experimentation includes not only experiments but prototypes, simulations, analyses, and any other process that involves trying an idea out to learn more about it. It can be done in many media: plastics, metal, circuit boards, silicon chips, molecules, and software.
Experimentation is a powerful tool to gain flexibility because it improves your anticipation and foresight. You can explore an area of the design to learn more about it — how it behaves, where its limits are, what it cannot do, and what it costs. Then if change occurs in this area, you are prepared. You know what choices you can make, how they will perform, and what the side effects of them are.
Effective experimentation is not a random search, however. Each experiment should be carefully designed and based in a clear hypothesis. Without this discipline, the essential learning will not occur. Keep notes on the conditions of each experiment and the conclusions you can draw from it. Then plan the next round.
This may seem expensive, but computer technology has made many types of experimentation ten to one hundred times faster and cheaper than formerly, which opens vast new possibilities for trying things out in advance. Like other flexibility techniques, it is cheaper and more feasible if you can limit the areas of likely change in the design and then only use the tool there. That is, consider flexibility a selective tool rather than a universal one.
For more on this, see our list of references, especially Thomke’s book, Experimentation Matters.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Product architectures span a range from integral (visualize a bowl of noodles) to modular, where functions of the product remain physically distinct. Modular architectures are powerful tools for isolating change to certain parts of a design, so that if one part changes, the change doesn’t trigger massive redesign.
In fact, this is such a powerful tool that your biggest problem in applying it is likely to be competing ways of applying it. Modular architectures are also valuable for improving manufacturing or distribution (as opposed to design) flexibility, reusing designs, or improving testability or serviceability. So you will have to choose carefully among these business objectives. If you choose design flexibility as your objective, you will probably have to choose further which parts of the design are most likely to change and thus could benefit most from being modular.
It follows that product architecture is too important to business objectives to be left as solely a technical decision.
To use modularity as a flexibility tool, select the portions of the product where your information is the shakiest or the areas most likely to change. Then use architecture to build “fences” (interfaces) around these portions to isolate them. But don’t over-modularize, which can become expensive. Also, once you have established interfaces, you will need a way of policing them, since they tend to decay over time as designers make compromises.
For more on this, see our list of references. Another important book on product architecture is appearing this month, but I cannot comment on it because I haven’t seen it yet.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Set-based design is an integral part of Toyota’s industry-leading product development system. It has great power for enhancing your ability to make design changes later and less disruptively.
Set-based design is a process of exploring options, understanding trade-offs between design variables, and identifying and imposing existing constraints on the design. In other words, you are mapping out the design space without making any commitments as to where you will be in that design space. Thus, you are deferring commitments but building your ability to move very quickly to a commitment when you need to.
Contrast this with more normal point-based design. In this approach, you start with an assumed design, check its suitability, and move on to a better solution in an iterative fashion. Point-based design brings you to a solution faster, but it provides no information about designs close to your path of progress. If something changes, you have no information about alternatives in the design space and must start iterating all over again.
The set-based approach is not natural. The point-based approach is built into engineers’ bones. It is the basis of calculus, which is the starting place of an engineering career.
One concern about set-based design is its cost. We do not have any relative costs for the two approaches, but set-based seems to involve more work, especially if there are no changes. On the other hand, Toyota uses it regularly for relatively mature products (little change), and Toyota is the acknowledged leader in automotive design efficiency.
For more on this, see our list of references, especially the Sobek article.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
The last few Quick Tips have covered various technical means of increasing the ability of your product development to accommodate change, but the “Agile Manifesto” makes it clear that individuals and interactions — that is, teams — come before these more technical approaches. So what can you do to help your teams to respond to change faster?
One is to cultivate generalists who can switch roles quickly. There is a limit to how far you should go with this, but most organizations cultivate and reward specialists far too much at the expense of their generalists.
Another is to clarify — in advance — the areas of authority that the team has, so it has the power internally to make the most common kinds of changes, and it knows clearly when it must consult with management. I see a lot of wheel-spinning on such issues.
Co-location is an old topic and one that is increasingly difficult to accomplish in today’s global workplace, but there is no substitute for it when you need quick, accurate communication to change course quickly. Fortunately, there are several things you can do to gain much of the benefit of co-location even when most of your team is dispersed.
Finally, since communication is at the heart of flexible teams, make sure that your communication technologies are working for you. For instance, if email inhibits or slows communication, establish team concurrence on how you will use email to overcome your biggest problems with it, based on your team’s experience.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Customers are — or should be — the starting point for any new product. Unfortunately, customers change their minds or do not know what they want when you start designing. If you are really going to listen to customers, you must find ways to accommodate the changes that they will bring.
Some developers attempt to skirt this issue by freezing the product specifications before starting design, but a previous Quick Tip “How can we complete our design work if marketing keeps changing the requirements?” showed that this is neither feasible nor wise. If you freeze the specifications, you rule out any guidance customers can give you.
There are several things you can do to improve your flexibility and openness to what you can learn from customers:
- Use an incremental approach. Incorporate now only what you are certain customers want, deferring other items until you have better information.
- Work more from a big picture. Focus on a product vision, which is likely to remain stable, rather than the details that are likely to change.
- Create personas for classes of your customers.
- Find and involve lead users (see the Democratizing Innovation review) to provide leading indicators of change.
- Discover ways unique to your company to keep in touch with you customers.
- Last, make sure that your designers have a direct connection to some customers, rather than receiving unintentionally filtered information through marketing or sales.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Each year product developers often plan (or hope) to do a better job of developing new products in the next year. It is much like New Year’s resolutions, which we make on a personal level.
However, at about this time of the year — toward the end of January — these people realize that other priorities have overtaken their plans for making process improvements. Later, looking back at the end of the year, they see that they never got around to implementing their well-intentioned plans.
Since this is the perfect time of year to recognize this phenomenon and correct it, let’s consider two things you can do now to make headway on your plans to develop products faster, better, or cheaper.
First, recognize that process improvements are an investment in a more effective — thus more valuable — organization. “Investment” is the key word here. These improvements are not free; if they were free, you would already be incorporating them. Consequently, in order for them to happen, you will have to allocate specific time and money to them, just as you would for a corporate investment in additional office space or new computer system. For instance, your personal time to implement the change must be budgeted into the investment plan. If it isn’t, you will never be in position to “take” time from activities that generate revenue more directly.
Second, think small. Make your plans and investments in small but sure steps. Resolving to do too much is precisely where most New Year’s resolutions fail.
To learn more, see our PDBPR column New Year’s Resolution Check-up or our article Your Product Development Process Demands Ongoing Improvement.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
Product developers are often process mechanics, thinking that if product development isn’t working, a process change will fix it. The first lesson we have learned from agile software development – the first line of the Agile Manifesto – is that, for flexibility, processes and tools are far less important than people factors – by an order of magnitude. So don’t expect silver bullets from process.
That said, you can do plenty to make your development process more flexible. First, recognize that the process should be emergent – emerging from the needs of the project itself as it proceeds rather than being fixed initially.
One way to make the process emergent is to standardize it at low levels, that is, establish the basic building blocks but allow plenty of freedom in assembling them. Observe that this is how we build languages: a fixed set of letters or characters, a little freedom to change or invent at the word level (blog, for instance, is a new word), more flexibility at the sentence level, and great freedom at the paragraph and document levels. Also observe that most development processes, such as phased development, attempt to standardize at the top level (the phases). In general, process quality arises in lower levels and flexibility stems from higher levels, providing quality and flexibility simultaneously.
Another counterintuitive approach is to build processes up rather than trying to eliminate unneeded parts. Although it might seem easy to remove parts, these constitute a safety net, making both novice developers and management reluctant to remove items. It requires a highly experienced developer to scale back confidently.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
When you are working in an environment subject to change, traditional project management does not work very well. Extensive upfront planning is a waste of time when plans are likely to change frequently. Instead, use rolling wave planning, where you plan the next stage well, the following one moderately, and only sketch longer-range ones. The planning rolls forward a stage when you reach the next stage.
The same goes for other traditional project management approaches. Project completion can no longer be measured in terms of deliverables delivered when these are subject to change (measure value delivered to the customer instead). Corrective action no longer means changing project activities to conform to the plan when, in fact, the plan may be the culprit (due to change). You can no longer reward project managers for following the plan when it may no longer be the best way of reaching the goal.
But the biggest change of all is in project risk management. In a traditional project, risk management that is built into the project plan works well. However, in a fast-changing project, risk management isn’t just part of the plan — it is the plan. You build the whole process around mitigating risk. You reassess risks frequently, and risk determines what you do first. If change is rampant, you are likely to have unknown risks, so-called unk-unks. They require even more vigilant treatment, as shown in an excellent new book Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects.
How far you stray from traditional project management depends on how much change you are encountering. But remember, if you aren’t encountering change, you aren’t innovating!
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
