Dec 4 2011
Via Scoop.it – lean manufacturing
Another take on the issues raised in Waiting for each other. Bringing waiting taxis to waiting customers in batches seems like another bad idea.
Via runningahospital.blogspot.com
Dec 1 2011
The developments of the Airbus A380 and the Boeing 787 were both more than two years late. You might think that these two master aircraft builders would know better. Such performance, however, is not the exception. Generally, from kitchen remodeling to the development of a product or a production line, projects tend to be behind schedule, over budget, or both.
That it is technically possible to do better even with a large-scale project involving new technology is illustrated by the Apollo program: it reached the goal set by JFK 5 months ahead of the deadline at a cost of $24B, accurately estimated in 1961. Even NASA, however, did not repeat its Apollo performance with the Space Shuttle. 100 years before, another major project, the transcontinental railroad, was also completed in record time at a cost that was consistent with original estimates.
It is therefore legitimate to ask why we are not able to do better, given the tools we now have. The key is that project and program management are treated like technical fields when they should be viewed as games, meaning that outcomes are the consequences of decisions made by several independent agents. In project management as described in the PMBOK, you break a project down into smaller tasks, to which you assign durations, resources and constraints of timing or precedence. Then you run calculations that produce Gantt charts, load profiles for resources, the critical path, etc. The most commonly used tool is the Critical Path Method (CPM), as implemented in packages like Microsoft Project. Then there is Eli Goldratt’s Critical Chain Project Management, focused on resources, and the Design Structure Matrix (DSM) to manage task iterations.
These are logically consistent models, and good fodder for presentations, but cast aside in daily project management in favor of the primitive action-item lists. The most obvious problem with the use of the tools is that durations for elementary tasks are not known, and that I have never seen an organization make a serious effort at collecting this data. A project task is not like an assembly operation that you can time with a stopwatch or record on video. And project work is never completely repetitive: if you keep repeating the same action, it may be called production or transaction processing, but not project work. Since you have never done this project task before, you cannot tell exactly how long it will take, but you can get lower bounds based on its content — for example if it involves driving 60 miles or waiting for paint to dry — and you could estimate it based on similarities and differences with tasks you have done before, if you had kept track of them. Engineering work is organized by project, and the time of engineers is tracked through time sheets, but these sheets are filled out after the fact by the engineers themselves for accounting, and are not accurate.
There are ways to estimate task times better, but that is not the main concern of project managers. Instead, their thinking is centered on sentences that begin with “Nothing else matters if…” Initially, a manager commissioned to lead a project has to come up with a plan that needs to be approved and nothing else matters. The purpose of the plan is therefore not estimation but persuasion. How this is to be accomplished cannot be stated in a generic way, because it obviously depends on who is to persuaded. What is a constant is that the project manager is selling, and will do whatever it takes to close the deal.
Imagine a king who is single and wants an heir. He solicits three members of his council to manage the project and gets the following responses:
Assuming the king operates like most corporations, whom will he appoint? The first adviser’s proposal is physically impossible, no matter what resources are put to the task. The second adviser strikes the king as too cautious. The third adviser gets the job, because he is proposing an aggressive schedule that is not impossible. The adviser knows the deadline won’t be met, but he can deal with that later. The king knows it too, but is betting that the adviser will redouble his efforts to atone for his failure to deliver on time. Four years and eleven months later, a prince is born.
In this kind of situation, the task durations used in project planning are the shortest that don’t violate the laws of physics. The project managers make the sale on that basis, miss the deadlines, and work desperately hard to finish. As a result of surviving in this game, they are promoted and continue the same practices with the next generation.
The game does not have to be played this way, but the initiative must come from the top. Soichiro Honda set a different tone early in the development of his company, by engaging it in motorcycle racing. When participating in a race, nothing else matters if the vehicle, pilot, pit crew and supplies are not in place and ready at the start of the race. Such hard deadlines are also found in organizing concerts, preparing museum exhibitions, or launching a space probe to fly by multiple planets. They focus project teams on realism in task assessment and creativity in dealing with the unexpected. Besides the publicity, Soichiro Honda’s purpose was to infuse all the company’s projects with the “racing spirit.”
There are, of course, many other useful perspectives on project management, and I find that the most interesting to read are case studies. Following are some of my favorites:
Tom DeMarco’s The Deadline is not a case study but a novel about project management. It is about software development but is entertaining and enlightening even for readers in other fields. DeMarco is a deep and original thinker, but with the wit of a Tom Wolfe.
Dec 1 2011
Via Scoop.it – lean manufacturing
RUSSIA: Alstom Transport is to provide Russian Railways specialists with training in the implementation of lean manufacturing technology under a memorandum of co-operation which was signed during the Second Railway Congress in Moscow on November 19.
Via www.railwaygazette.com
Dec 1 2011
Steven Spear’s The Essence of Just-in-Time:Imbedding diagnostic tests in work-systems to achieve operational excellence is a working paper from Harvard Business School in 2002 focused on the interaction between JIT and problem-solving. It is an important topic, only briefly alluded to in Lean Logistics and covered in more detail in When to Use Statistics, One-Piece Flow, or Mistake-Proofing to Improve Quality, but there are many other improvement opportunities besides product quality, and shining a light on their relationship with JIT is useful.
Spear’s paper is worth reading because he did his homework: it is based on research that involved immersion in a Toyota supplier support team, visits to seven Toyota plants and 12 suppliers in Japan and the US, and working as an assembler in a non-Toyota plant for comparison. I recommend in particular sections 4 to 7. Section 4 is a case study of mattress manufacturing at Aisin Seiki, from which the following sections draw general conclusions.
You have to look past the other sections, which mainly reflect Spear’s membership in the academia tribe. His research is described as an “ethnographic study,” which conjures up the image of an American or European spending 15 years among the Guaranis of Paraguay recording what they are willing to share of their language and culture. That this vocabulary should be used in a study of Lean reflects how alien the world of manufacturing is to academia.
As an academic, Spear is obligated to reference other academics, but not non-members of the tribe, no matter how major their contributions. For example, the only Japanese author in the bibliography is Takahiro Fujimoto, from the University of Tokyo, but neither Taiichi Ohno nor Shigeo Shingo appear. Section 3, on Methods, opens with “Many scholars argue…” With all due respect, the arguments of scholars don’t amount to a hill of beans in Manufacturing, because, unlike Computer Science or Biology, it is not a field to which they have contributed much. From Taylor and Gastev to Ohno and Shingo, the key innovators in Manufacturing have almost all been self-taught, Lillian Gilbreth being the exception with a PhD. Why was Spear’s research not done in an Industrial Engineering department, where its content would normally place it? As I found in my own ethnographic studies of academia, the need for grants pushes researchers in other directions, like genetic algorithms.
Dec 5 2011
Total: All Encompassing or Involving Everybody?
“Total” is used in the names of improvement programs like Total Quality Control (TQC), Total Productive Maintenance (TPM), Total Quality Management (TQM), or Total Flow Management (TFM), but the meaning is different on both sides of the Pacific. In the US, a Total program addresses all the issues related to its object; in Japan, it involves everybody.
When Armand V. Feigenbaum coined the term Total Quality Control in 1951, he meant that Quality Control should start with product development and end with customer support. When Kaoru Ishikawa took the concept to Japan, the acronym TQC was retained, but “Total” translated as “Zensha teki” (全社的), meaning “Company-Wide,” implying the involvement of every department in the organization. A more precise translation “Zenyin sanka” (全員参加) was later introduced, which means “with participation by every employee” and shifts the emphasis even further. Back in the US, the notion of involving everybody arrived in the 1980s when TQC morphed into TQM, but elsewhere, as in Euclides Coimbra’s TFM, it means encompassing an entire supply chain.
Programs that “involve everybody” are programs that every employee is the company must participate in. They are not volunteers but draftees. Understandably, such programs are difficult to implement, and often result in individuals just going through motions to humor their bosses and wait out the program. When joining a company, employees accept rules pertaining to working hours, compensation, expense reports, and interpersonal relations, but these general rules at the corporate level do not specify, for example, which tools are to be used in each job. Individuals don’t necessarily get to choose, particularly in production, but the standards they follow are set at a lower level than top management.
Starting a program that is “Total” in the Japanese sense means extending the reach of corporate mandates. It is easier to do in organizations to which employees have a career commitment than where employees are recruited for specific skills that they have acquired and can re-market elsewhere. Be it easy or hard, you have to consider whether it is wise. A company-wide program is a centralization effort and reduces the autonomy of lower-level business units. As most companies are trying to go in the opposite direction, you really don’t want to start such a program unless (1) its benefits are obvious, and (2) there is no other way.
A TQM program may mandate that the Plan-Do-Check-Adjust (PDCA) process be used when implementing any change throughout the company. Since everybody must participate, the PhD-level scientists at R&D will be required to undergo PDCA training and to formally use it to organize all their activities. As a group, they will be offended and some may quit. Elsewhere in the company, project leaders will dutifully reports their action items as being in a state of P, D, C or A. The organization can claim to be on board with the program but truly is not.
5S, on the other hand, is a program that can only be successful if everybody participates. The benefits of 5S are not easy to quantify, but everybody likes the outcome: given the choice of working on a shop floor with or without 5S in place, few would choose without. The problem is that even fewer show any enthusiasm for doing the work necessary to achieve and sustain this outcome, and this resistance can only be overcome if everybody from top management on down gets physically involved. When touring Japanese plants, you so often see the plant manager pick up a stray scrap of paper off the floor and put it in a dustbin that you feel the incident has been staged, but the message is clear: everyone should behave as if the tidiness of the whole plant depends on the individual behavior of each.
A more modern and successful program involving all employees is Hoshin Planning, a strategy deployment approach that is well described in Pascal Dennis’s Getting the Right Things Done. It results in employees having small, actionable sets of strategic directions, determined with their input and consistent across levels. It is much more sophisticated than the target numbers game that management-by-objectives has degenerated into in many companies, and the vertical and horizontal interactivity of the process makes it impossible for any segment of the organization to opt-out.
A company-wide program is implemented top-down, starting with top management and cascading to the shop floor, with appropriate training at each level. It is different from Robert Schaffer’s Breakthrough Strategy, which starts with a pilot projects effecting a deep transformation of a small segment of the organization, whose success makes it go viral. By providing rapid improvements and building the skills base, the breakthrough strategy bootstraps the Lean transformation of a plant but can take it only so far. Once the leaders of local projects start wondering what their successes add up to and where they are leading, they are ready to pull together and take on the challenge of involving all employees in the parts of Lean for which it is necessary. It is top management’s role to sense when an organization is ready for this transition.
Share this:
Like this:
By Michel Baudin • Management 0 • Tags: 5S, Continuous improvement, Hoshin, Kaizen, Lean, Quality, TQM