Originally Published MX November/December 2002
BUSINESS PLANNING & TECHNOLOGY DEVELOPMENT
Predictably Fast!With four key changes in belief and behavior, company leaders can increase speed and improve project predictability.
Lisa Scheinkopf
When it comes to developing and marketing a new product, every company aspires to faster and more-predictable project completion. In an industry such as medical technology that is heavily regulated, deeply dependent on people with specific skill sets, and intimately linked to the accelerating rate of technological change, achieving greater speed and predictability in this area can seem like the impossible dream.
Bringing new products to market faster has obvious competitive advantages. First-mover benefits are likely to be enormous, of course: the difference between being the first one to market and the second often amounts to tens of millions of dollars in revenue in the weeks and months following product launch. Just as the payoff for being fast and first is typically huge, the effective penalty for lagging and arriving late is likewise staggering.
A development project can take years. Nevertheless, delays of weeks, or even days, may have devastating consequences. At worst, a wrong guess about how long one particular stage of the process will take could mean finishing second in a winner-takes-all competition. At best, that day when the company stops spending money on developing the product and starts making money from selling it is postponed.
Taking longer than planned to complete any phase of a long development project is always costly. And a delay in one company project commonly slows down others as a by-product. So, becoming able to more accurately forecast how long a certain project will take has clear bottom-line benefits.
Many in the medtech industry have essentially written off the possibility that predictability in project management can be improved. There are just too many unknowns, they say—too much risk to be managed. But despite the regulatory environment, technological change, and heavy skill dependence, medical technology companies can speed up product development and reliably forecast how long development projects will actually take. Most companies, in fact, can achieve significant improvement in this area without necessarily increasing capital expenditures or human resources.
Four fundamental shifts in management beliefs and behavior can make a profitable difference.
Busyness Does Not Equal Throughput
Research reveals that most proj-ects of all kinds take longer than planned. The intuitive belief is that the way to speed things up is to keep everybody working full bore. Sweat dripping from brows and universal 80-hour weeks show that the company is doing all it can to bring the project in on time. So goes the reasoning. Yet most executives could attest that having staff work longer and harder does not produce the desired result.
Staying on track does not depend on keeping all corporate resources—people or equipment—busy all the time. It's much more important to know which resource area is putting a cap on the volume of work that can get through the system.
Every system has, by its nature, some working asset that is its most constrained resource, commonly known as a bottleneck. In systems in which capacity is pretty evenly balanced, the bottleneck jumps from area to area unpredictably. One day it might be the information technology department that is holding up the works, and the next week product testing, or a clinical study. Not knowing where the jam-up is going to occur from one day to the next is obviously an undesirable situation.
In other systems, the bottleneck is always in the same place, perhaps a department that is chronically understaffed even during stages of the project cycle when its burden of work naturally increases. With medtech companies, this area of constraint is likely to involve a particular skill set.
The software design engineers may be the holdup. When projects fall behind schedule, it seems to be because these particular employees are stacked up with work and can't adhere to the project schedule. Clearly, keeping the hardware designers busy or adding some overtime in regulatory affairs will have no effect on accelerating the project in this situation.
But both the speed of the project and the predictability of its conclusion can be enhanced by focusing improvement efforts on the bottleneck. Sometimes the best solution is simply to hire more of this most valuable skill and let something else become the constraint. If getting the product to market faster than the competition depends heavily on that skill set, and if getting there sooner will result in millions of dollars in sales, then it hardly makes sense to try to save the cost of a couple of salaries.
However, hiring more of a particular type of skilled worker is often not an option: there simply aren't enough such specialists in the job market. Nor does the fact that the constrained resources—those software design engineers in the example—are working at full capacity necessarily mean that project managers are using them wisely and well. Managers would be smart to make sure that what these rare and valuable employees are doing is necessary; to relieve them of any tasks that could be done by others; and to see that their assignments are delivered in excellent shape, with all expectations, specifications, and limitations made crystal clear from the outset.
Often, when work is handed from one project resource to the next, so are quality problems, which creates yet another staff-related constraint. A piece of information may be missing, or the work done may contain errors that need to be dealt with before the project can move forward.
And if the bottleneck occurs with a particular group of highly skilled employees, managers would be wise to make sure they're not working 80-hour weeks. Allowing working conditions that lead to ulcers or nervous breakdowns is not an effective way to manage a project constraint. Nor should valuable performers ever be so overloaded and underappreciated that they take their talents to a competitor.
A bad situation is never a simple matter of blaming that software design department where everything gets stacked up and makes the project late. Rather, it's always a matter of looking at the whole project, making sure everyone understands where the constraint is, and getting the other resource areas to contribute toward moving more work through the bottleneck area more efficiently. This doesn't mean keeping everybody busy, but it often means making everyone accountable for the overall results rather than only their own personal bailiwicks, and aligning the reward system accordingly.
Extra Capacity Is Not Wasted Capacity
The common wisdom is that extra system capacity is wasteful and bad, and should therefore be eliminated. In truth, not having some extra capacity available is a sure way to miss project deadlines and due dates. This is easy to understand at the individual level.
Let's say it typically takes someone 45 minutes to drive to the airport, and that the drive typically uses two gallons of gas. If the person has to catch a flight for an important meeting, chances are that he or she has more than two gallons of gas in the tank and leaves home much earlier than 45 minutes before the plane is scheduled to depart. A detour, highway construction, an accident, weather conditions, or any number of other things could add minutes and additional fuel requirements to the drive. Having plenty of gas and allowing extra time to get to the airport will accommodate most unforeseen problems and delays.
Too often, business executives assume that product development projects aren't going to encounter highway accidents and icy pavements. Capacity gets pared to the bone and projects fall further and further behind. With no cushioning, the system can't accommodate even minor mishaps—a couple of people out for a week with the flu—let alone major problems.
Prudent executives will regard a certain amount of extra capacity as protective capacity, not excess capacity. Protective capacity enables an organization to cope with the inevitable mistakes, miscalculations, and unexpected problems that crop up in any human endeavor.
In planning a development project, it's important to build a safety margin into its anticipated duration to account for inherent variability in rates of progress among tasks. A best-case scenario, in which every task takes exactly as long as projected, should never be assumed.
Most companies determine likely project duration by adding up time estimates for distinct tasks, a practice that leads people responsible for each task to be extremely liberal in es-timating the time requirement, and then to perform their work so as to fill the time frames established by those inflated estimates (as Parkinson said they would). A better approach is to build time buffers into the project (see sidebar). These are visible and strategically located blocks of time that serve as time banks.
The cushioning built into cautious task-time estimates is invisible and almost always gets used up. If the schedule says some work is to be completed by Friday, there is usually no incentive to finish it on Wednesday. The time just disappears. Visible buffers, on the other hand, get consumed only when the project experiences real variability—say, a test gone awry, a late shipment from a supplier, or storm damage that closes the facility. A big advantage of pulling the safety margin out of the task-time estimates is that whenever a task is completed ahead of schedule, the time gained can be used to move the project toward completion faster.
A plan is nothing more than a plan. Making the transition from liberal task-time estimates to buffered project schedules requires changing what is tracked and emphasized while the project is being implemented. For instance, instead of focusing on milestones and task due dates, managers must shift attention to how buffer depletion could risk on-time completion of the project. And instead of trying to keep everyone busy, company leaders might better celebrate occasions when people have worked so effectively that they have depleted their queues.
"Multitasking" Only Sounds Efficient
The popular view is that multitasking is a desirable behavior, that working on a lot of things at once is a good way to keep everything moving along. In fact, multitasking is one of the best ways to lengthen cycle time.
It's better to instill in busy employees the "get it, work it, and move it" attitude and practice. That means concentrating on one task until it is finished or until there is nothing further the individual can do with it.
In medtech firms, the results of switching to the "get it, work it, and move it" mode can be dramatic. One company improved the performance of its analytical chemistry lab by as-signing one task at a time to each of its chemists and assigning those tasks only when they were ready, that is, when all necessary paperwork and materials were available. The company also reduced work in process—so-called "inventory"—by making sure that no chemist was ever in-volved with more than two tasks at a time.
Finally, the company instituted a policy of not interrupting chemists already working on tasks in order to start them on new tasks when project priorities changed. Instead, the next chemist available for new work would take the highest-priority task awaiting attention. It took the company one week to implement these new work procedures, and output doubled almost immediately. Not incidentally, both chemists and supervisors reported that both the quality of work done and the working environment improved as a result of the changes.
Shifting attention among several different tasks undertaken at once inevitably means wasting time. It's almost always possible to speed up work flow by 10–30% just by getting employees to stop multitasking. The plain truth is that people cannot do more than one thing at a time. Multitasking is really nothing but switching back and forth between several tasks.
Projects Are Joint Efforts, Not Competitions
Another intuitively true assumption is that any improvement anywhere in the organization improves its overall health and fitness. Various departments and divisions of the enterprise set their own performance goals and focus on meeting them, tacitly equating local excellence with the good of the whole. Many improvement methodologies rest on this underlying belief.
Unfortunately, it's not true. Local improvements may have no effect on the bottom line or the end result. They can even have a negative effect. A better farm can't be achieved simply by optimizing the silos.
Organizations are living systems; their parts and subsystems are interdependent. It's not always obvious how a change in one part of the system will affect other parts, or whether it will help or hurt the big picture. To get sustainable improvement, including the ability to complete projects on time consistently, requires being able to see the entire system and then deciding how the success of that system—not its individual components—is to be measured.
Almost always this means adjusting rewards and incentives. The kind of change needed to effect significant improvement in system performance inevitably shifts the balance of power. It turns certain groups of employees into heroes and makes other departments look like villains or super-numeraries. Obviously, people will resist or try to subvert change that hurts them in the ego or in the pocketbook.
To be able to predict accurately how long it will take for, say, a medical imaging device to be ready for market introduction, not to mention attain market acceptance, depends on organizing a development project so that design, engineering, sales, management, manufacturing, finance, and other departments all act for the good of the whole and are rewarded for doing so. Yes, it's a very different mindset from the ones that commonly pit marketing people against the manufacturing team or that glorify one group of employees at the expense of another.
Conclusion
Medtech executives who want to speed up product development and make project completion dates more predictable may need to change their understanding of what makes work flow efficiently, in accordance with the counterintuitive principles just outlined. It's not about keeping everyone busy all the time. It's not about eliminating every bit of perceived waste in the system. It's not about expecting employees to juggle several ongoing tasks every day. And it's not about encouraging local improvements in the process chain.
No. The way to optimize project speed and predictability is to align management belief and behavior with departmental practices and purpose in a common effort to discover and eliminate project constraints. A light focused on where the bottlenecks are can illuminate paths down which opportunities lie.
Lisa Scheinkopf heads the life sciences division of Chesapeake Consulting Inc. (Severna Park, MD).
Copyright ©2002 MX
