[23] For Loryn, Another Way
To Look At the Problem
Loryn, you've inspired me to action, if only for a brief interval.
ANOTHER WAY TO LOOK AT THE PROBLEM
Multitasking is the visible piece of the problem for product development organizations and for IT organizations. This is the widespread behavior that causes a huge amount of damage and, ironically, is actually encouraged by managers. But there's another way to look at the problem.
Imagine that you run a product development organization with a payroll of, say, $50 million, and you have n people on your payroll (managers as well as developers). Are your shareholders getting the most out of that $50 million annual payroll? If your organization is like the vast majority of product development organizations, the answer is a resounding "no!" ...why? ...because much of your organization's capacity to complete projects, for which you are paying $50 million every year, is being misdirected to create pips, projects in progress, which ultimately are terminated, killed, thrown away. Here's what's really happening to your very expensive product development organization.
First, your marketing people are launching projects faster than your developers can complete them. This wouldn't be all that bad, were it not for the fact that once each project is launced you and your senior people expect the project to demonstrate progress. The only way that this can happen is for your resource managers to shift capacity from the existing (earlier) projects to the new project.
What happens to those existing projects? Well, they slow down, of course. They slow down further with each new project that is thrown into the mix. Unfortunately, you don't see this taking place. The process takes too long for anyone to notice it. And no one notices that the number of pips is growing without bound.
Eventually, of course, you are forced to notice the pitifully slow rate at which projects are completed. Eventually, you just can't ignore the pain. What do you then? You call in some big consulting firm, for very big bucks, and you follow their advice. You kill at least half of your active projects. So, half of your pips go poof.
One result of having half of your pips go poof is that the capacity released by each poof is refocused on the remaining projects, and those remaining projects speed up for awhile. Why do I say only for awhile? I say this, because you never change the conditions that create the steady build-up of pips. Those conditions continue to exist, and they continue to create the everbuilding pile of pips. They create a virtual mountain of new pips.
Stop! Think about what's happening. Your organization is experiencing a series of transients. These transients have a very long time constant, of approximately two to three years. The expensive consulting firm tells you to kill half your projects, and you do so. This is the beginning of the transient. But the expensive consulting firm never permanently changes how you manage your enterprise. So once the transient begins, the number of active projects begins to grow again, steadily, over a course of two or three years. After that time, you feel so much pain that you call another big, expensive consulting firm. And they again tell you to kill half your projects. And so it goes, year after year. You and your managers create a mountain of pips, and approximately half of them go poof every few years.
Now, think about all the capacity (read that as millions of payroll dollars) that goes into all the projects that you kill every few years. All that capacity is wasted, discarded, thrown away, never to be retrieved. Worse! All that capacity could be used to bring products to market at twice your current rate. That's the real damage, all the business that you might do but never actually do, because you continually spend a huge portion of your payroll on pips that go poof, instead of investing that payroll on generating faster throughput, more completed projects, more sales, and much more shareholder value.
How much is the damage? Experience (my experience and that of a number of my clients) shows that product development organizations (and IT organizations) worldwide could complete projects at twice their current rate, if such a huge portion of their development capacity weren't being diverted to generate a pile of pips that ultimately go poof. Imagine the loss. Fully half of their payroll is being wasted right now.
Imagine the value that could be realized! With their current payrolls, product development enterprises worldwide could bring products to market at twice their current rate. It's mind boggling. The development payroll stays fixed, yet twice as many products reach the market each and every year, forevermore. Twice as many buying opportunities are created for customers each and every year, forevermore. Twice as many actual purchases take place each and every year, forevermore. Twice as much revenue is generated each and every year, forevermore. And it's all done without any increase in headcount, at least in development.
What's the answer? The answer is to apply rigorously, to the people-systems of business, the concepts, the principles, and the methods of engineering.
