|
|||||||||
|
Train Wreck Management by Mary Poppendieck On October 5, 1841, two Western Railroad passenger trains collided somewhere between Worchester, Massachusetts and Albany, New York, killing a conductor and a passenger and injuring seventeen passengers. That disaster marked the beginning of a new management era."[1] These words open Peter Scholtes classic book on leadership. He goes on to explain how the term "management" was unknown in the days of cottage industries. As business grew and became geographically dispersed in the 1800s, a way to run these businesses had to be found. But there were no models outside the church and the military, so investigators into the train-wreck disaster looked to the Prussian army for a model. And there they found the classic organization chartthe one we know so well today. Scholtes calls it the "train-wreck" chart. It was revolutionary at the time. The purpose of what became today's organization chart was clear: the assignment of responsibility would enable "prompt detection of derelictions of duty...and point out the delinquent." Scholtes says: "A fundamental premise of the 'train-wreck' approach to management is that the primary cause of problems is 'dereliction of duty'. The purpose of the organizational chart is to sufficiently specify those duties so that management can quickly assign blame, should another accident occur."[1] Blame Note the thinking here: problems are caused by people who don't do their job well, so finding someone to blame is the first step to correcting problems. Scholtes notes: "The era of management that began in the mid-1800s can be characterized as "management by results"....Since managers could no longer do the work themselves or direct others in the doing of the work, managers exercised their authority by holding people accountable for results....In the 1950s, management by results reached its epitome in MBO (Management By Objectives) and performance appraisal, the Harvardization of train-wreck management."[1] He goes on to say that at the time, this theory of management was the best available, and it succeeded in creating order out of chaos. "People like Whistler, McCallum, Frederick Taylor, or Henry Ford in the United States or Darby, the Stephensons, or Brunel in England were pioneers....[T]hey did their best and, by and large, what they did was very good." "Meanwhile, in Japan..." is the title of the next section of Scholtes' book. He chronicles how a better approach to management emerged in Japan in the 1950s, assisted by W. Edwards Deming. Deming taught that most of the problems we encounter (perhaps 90 percent) are the result of multiple influences; they generally cannot be attributed to a single cause. Assigning blame for a problem to the last person involved is worse than counterproductive, it will probably make the bad situation worse. Exhorting people to "be careful," "try harder," and "work smarter" is not useful if individuals have little effect on results. Rewarding or punishing people for outcomes that are not under their control can only result in discouragementor in gaming the system. Instead, chronic problems must be fixed by finding their underlying causes and addressing these effectively. As Deming points out, this usually involves changing the systemthe way things are done. And according to Deming, it is management's job to change the system. Process or People? Agile software development places a strong emphasis on putting change into the hands of front-line people on self-directed teamsisn't this contrary to Deming's philosophy? Writing in 1995, Scholtes lists what he calls "fads" for addressing systemic problems: "empower people, put them into self-directed teams, motivate them, offer incentives, reengineer and reinvent them." And then he says: "All of the empowered, motivated, teamed-up, self-directed, incentivized, accountable, reengineered, and reinvented people you can muster cannot compensate for a dysfunctional system....A well-run organization with well-functioning systems allows people from top to bottom do work of which they can be proud."[1] So where does this leave us? Which is more importantprocess or people? It helps if we trade in the overloaded word "process" and use "system." In the article "Managing a Living System, not a Ledger,"[2] H. Thomas Johnson says "Managers at Toyota believe that improving the system is the surest way to improve long-term financial results." He points out that Toyota takes lots and lots of measurements, but they do not use these as performance measurements. Johnson writes: "Toyota makes virtually no use of management accounting targets (or 'levers') to control or motivate operations....Toyota focuses its operations on continuous system improvement through endless rapid problem solving. And they emphasize genchi genbutsu, or 'going to the place,' to see where a problem occurs, firsthand. They don't rely on second-hand reports or tables and charts of data to achieve a true understanding of root cause. Instead they go to the place (gemba) where you can watch, observe, and 'ask why five times.' This attitude shows a deep appreciation that results (and problems) ultimately emanate from, and are explained by, complex processes and concrete relationships, not by abstract, quantitative relationships that describe results in simple, linear, additive terms." Winding up the article, Johnson says: "Financial quantities cannot reveal if a system is improving or not....No company that talks about improving performance can know what it is doing if its primary window on results is financial information and not system principles....Companies that intend to perform like Toyota should recognize that...they will never get there by trying to motivate and direct 'lean' initiatives with 'lean accounting' and management accounting 'levers of control.'" Taiichi Ohno on Standard Work Let's go back to the source of the Toyota Production System, Taiichi Ohno, and see what he had to say about processhow it is established and how it is changed.[3]
Process AND People Ohno believed that the primary job of team leaders (first line supervisors) is the constant improvement of the way work gets done. Work standards should be written and posted, but this had better not take very long because the standards should change all the timeat least once a month. Standards are not about how work should be done, but how work is being done. You don't want the standard to be too perfect, because that leaves no incentive for workers to improve their standards. If workers are annoyed by a standard, they are expected to change it. They do not drop a suggestion in a suggestion box, they do kaizen. That is, workersled by their team leaderdo many rapid experiments, find a better way, agree on the improvement, quickly document the new way, and use it. When a standard is improved, the decision for the change must be made by the people doing the work, so they won't feel it is being forced upon them. People like to use effective processes, and they also like to have control over their own environment. The Toyota Production System provides for both. Ohno made it clear that people must be at the center of improving their own processes. Process improvement may be done only "at the gemba" and it is up to the workers to decide whether or not a proposed improvement should be implemented. Workers are expected to keep changing the way they do their job; in fact, it is bad leadership to have a process so perfect that workers have little incentive to improve it! Assessment and Certification Scholtes takes process improvement assessment programs such as International Organization for Standardization (ISO) 9000 to task because even though they seem good on the surface, they have some problems:[1]
Conclusion When Deming said "change the system," he was talking about changing the complex, interrelated processes used to get work done. Deming believed that changing the system is management's primary job, and in order to do this, managers need competency in four areas:
When all of these areas are balanced and working together, great things can happen. Mary Poppendieck and Poppendieck.LLC are dedicated to bringing lean thinking to software development. This article was previously published on the Poppendieck.LLC Web page. [1] Peter R. Scholtes, The
Leader's Handbook (Columbus, Ohio: McGraw-Hill, 1998). |
|||||||||
|
|||||||||