7 questions to help you reduce project durations | Christian Hohmann

Christian Hohmann

“[…]Organizations dealing repeatedly with projects will soon develop templates of Work Breakdown Structures (WBS) holding the most current tasks and milestones. These canvasses speed up somewhat the project initiation and ensure some degree of standardization.

Over time though, the copy-pasting from one project to the next, the addition of “improvements” and requirements as well as countermeasures to problems kind of inflate the templates and the projects. This, in turn, extends the project’s duration as every additional task not only adds its allocated time to completion, but also the safety margin(s) the doer and/or project manager will add on top.[…]”

Sourced through Chris Hohmann

Michel Baudin‘s comments:

The project management literature astonishingly fails to provide guidance on the art of breaking a project down into tasks. The “Body of Knowledge” tells you what a Work Breakdown Structure (WBS) should look like but not how you actually break a project down into meaningful pieces, whether it is a dinner party, the construction of a bridge, or a moon shot. For a manager who has to make a plan, this makes templates irresistible: instead of thinking, you just fill in the blanks.

Chris’s questions are certainly relevant but I would like to go further and propose a few rules for generating a WBS.

Continue reading

Project Manager Versus Chief Engineer: What’s The Difference?

Question put to Michael Ballé in his Gemba Coach column:

Management wants us to start lean in product development, but refuses to consider the difference in roles between our current project manager and a chief engineer – how important is that?

Project Manager and Chief Engineer are job titles covering different roles in different organizations. Before commenting on whether management in the questioner’s company should switch titles, we should know how they select their project managers, how much authority the project managers have, and what they are accountable for. Some companies do an outstanding job of product development under project managers; others don’t.

Continue reading

About Teams and Projects

In The Wisdom of Teams, Jon R. Katzenbach and Douglas K. Smith explained that, for a working group to coalesce as a team, it needs a common goal, complementary skills, and mutual accountability among members. It sounds simple, but it is in fact a tall order, and there is no evidence that it is sufficient.  The authors don’t claim it is, but they found these characteristics among successful teams in sports and business, and found them lacking in unsuccessful ones.

What Makes a Great Team

Let us explore the meaning of these three characteristics in more detail:

1. A common goal. It can be organizing a successful conference, or JFK’s “before this decade is out, landing a man on the moon and returning him safely to the earth,” or building a motorcycle that wins a race. Whatever it is, the goal must be clearly stated in few words, with obvious success criteria, for team members to sign up.

Continue reading

Problem-solving: Dr. House versus the Shop Floor

Dr. House‘s fictional team of doctors may be the most famous problem-solving group on the planet. Week after week, they solve daunting medical mysteries under an abrasive, unfeeling leader, working in their differential diagnosis sessions with nothing more than a tiny white board to write lists of symptoms.

In real life, Steve Jobs, a man with character flaws on  a par with Dr. House, was able to lead teams in the development of products from the Apple II to the iPad. In light of this, you may wonder why, when faced with problems like an occasionally warped plastic part or wrong gasket, we need to have a team go through brainstorming sessions in which no idea is called stupid, draw fishbone diagrams and formally ask five times why the defect was produced and why it escaped.

House’s team, Apple engineers and Pixar animators are in professions they chose and for which a thick skin is required. They are the product of an education, training and experience in which abuse is used to filter the uncommitted. By contrast, assemblers and machinists are there not to realize childhood dreams but because these are the best jobs they could get. In addition, if they have even a few years of experience in a non-Lean plant, they have been trained to do as they are told. Outside of work, they can be artists,  do-it-yourselfers, or community leaders, but they have not been expected to use the corresponding skills at work.

Over the past decades, many manufacturers have realized that this is a mistake, and that there are emergency response situations that are resolved faster with the participation of the people who do the work than without it, and many small improvement opportunities that are never taken unless operators take them on. But welcoming and soliciting their help is not enough. Historically, the first attempt was the suggestion system, dating back to 1880. It is still in use at many companies, including Toyota, but, while it is part of continuous improvement, it is not an approach to problem-solving. Employees make suggestions about whatever they have ideas about; problem-solving, instead, requires a focus on a subject identified by management or by customers, and usually needs a team rather than an individual.

Kaoru Ishikawa’s concept of the Quality Circle in 1962 was a breakthrough, not only in organizing participants in small groups but also in teaching them the 7 tools of QC to solve quality problems, as well as brainstorming, PDCA, and presentation techniques. The key idea was that pulling a group of shop floor people together was not enough. Quality Circles still exist, primarily in Japan, but the ideas  of providing technical tools and a structure to organize small-group activities around projects have propagated many other areas. Setup time reduction projects for example, can be run effectively like Quality Circles but with the SMED methodology taught instead of QC tools. Conversely, if working on quality issues, a Kaizen Event team may use the same technical tools as Quality Circles, but is managed differently.

To an uninvolved engineer, a scientist or a medical doctor, “problem-solving” as practiced by shop floor teams may appear crude and simplistic. He or she may, for example, view a fishbone diagram as a poor excuse for a fault-tree because it makes no distinction between “OR,” “XOR” or “AND” combination of causes. In the fishbone diagram, these details are not omitted for lack of sophistication but instead by due consideration of the purpose. You can fill out a useful fishbone diagram in a brainstorming session with a problem-solving team, but you would get bogged down in details if you tried to generate a full-blown fault-tree. There are many simple techniques that could potentially be applied. The value of a problem-solving method is that, for a given range of problems, it has shown itself both sophisticated enough to work and simple enough to be applied by the teams at hand.

In this as in every other aspect of Lean, it makes a difference whether an approach is adopted for internal reasons or to comply with an external mandate. A customer that has developed a problem-solving methodology may require suppliers to adopt it when responding to quality problem reports. The suppliers then formally comply, but it may or may not be effective in their circumstances. For example, a car company that buys chips from a semiconductor manufacturing may mandate failure analysis on all defective chips, but this analysis will provide information on process conditions as they were six months before, when the chip was made. Since then, the process that caused the defect has gone through three engineering changes that make the results irrelevant. These results would have been relevant for mechanical parts with shorter processes and less frequent engineering changes, but the car company doesn’t differentiate between suppliers.

Did Citroen Use Too Many Phone Calls and Emails in Developing the C5?

Wiegand’s Watch is a monthly letter from Dr. Bodo Wiegand, who runs the Lean Management Institut, the German affiliate of the Lean Enterprise Institute. This month, he focuses on what he perceives to be a wasted use of email and cell phones in the development of the Citroen C5 car. Following is a translation of his letter, followed by my comments:

€ 16 million wasted in the development of the C5 car
Today I was at the airport and saw a billboard.
The development of the C5 at Citroen used 1,410,475 cell phone calls and 3,155,546 e-mails. This is madness. If  a phone conversation lasts an average of 2.5 minutes, it works out to 14 670 man-days or 73 man-years.
Assuming  writing a  technical e-mail on average takes four minutes and that it is read six-times, then these emails took up  65,741 man-days or 321 man-years. Assuming that 50% of these cell phone calls and 50% of e-mails were necessary but non value-added, this adds up to 40,000 man-days or 200 man-years, or € 16 million were needed to do the following:

  • Fix processes that are out of control.
  • Define nterfaces that were not specified.
  • Rethink procedures with qualitative gaps.
  • To answer questions.
  • To solve problems.

What a huge waste!
What a potential for improvement!
And Citroen boasts about it.

My first reaction is to wonder what is wrong with >1,000 people involved in a multi-year project like the development of a new car communicating extensively? It brings to mind Frederick Brooks’s famous audit of the Tower of Babel project in The Mythical Man-Month. The goal was clear and its lack of feasibility played no part in the failure. Human and material resources were plentiful in Mesopotamia, and were not a problem either. What caused the project to fail was that team members could not communicate. 

Product development generates many documents that need to be reviewed, discussed, annotated, updated, revised, and organized. These documents must also be available easily to all those with a need to know, and kept secret from all others. I don’t know on what basis Dr. Wiegand concludes that a large part of Citroen’s communications by phone and email were waste. For all I know, they may have been meaty technical exchanges that improved the design of the C5…

Of course, you don’t need electronic means of communication if everybody is in one big room, but that only works for teams that are small enough. You would need a convention hall for a team in the latter stages of car development, and some activities, like testing in a hot desert or snow, or ramping up production, take place at multiple locations. While always desirable, face-to-face communication is not feasible for everything at all times.

Just based on the statements from Citroen, if I would fault them for anything, it would be for relying on nothing more sophisticated than phones and emails, which is so 20th century.  There are now collaboration and on-line meeting tools that combine much richer exchanges with better data security and revision control. For example, engineers at different locations can view the same drawing on their screens, annotate it while discussing through an audio conference, and read each other’s body language through webcams.

Instead of having multiple copies of documents floating around in individual mailboxes, you can keep them in a library on a server to ensure that all participants in a discussion are looking at the same version, and to prevent these documents from leaking out.

You can also fault emails for lacking the kind of structure you find in A3 reports, which discipline authors in providing particular data items while helping readers find them. But again, more advanced communication tools can provide that structure through on-line forms .

For voice communication, there are also alternatives to cell phones. For people whose work causes them to move around within the range of WIFI network, for example, there are wearable devices that allow them to call each other by name and communicate by voice instantly, as if they were side by side.

So maybe the issue is not that Citroen C5 development used to many engineer-years communicating, but that, next time, they should use the state of the art to do it.

The Project Game

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:

  1. The first adviser claims that he can organize to produce an heir in four months.
  2. The second adviser quotes three to five years, taking into consideration the need to find an appropriate consort, follow the complex protocols of royal engagements and weddings, and let nature take its course.
  3. The third adviser quotes nine months.

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:

  • The soul of a new machine, This is Tracy Kidder’s account of the development of the MV-8000 computer at Data General in 1980. The technology is irrelevant today but the human dynamics have not changed. The now defunct Data General computer company  had been caught by surprise by DEC’s introduction of the VAX in 1978 and needed a response. The book has all the elements of a thriller: an inept corporate bureaucracy squandering millions on a luxurious research facility for no return, while a small band of rebels in the cellar of an old building succeeds against the odds in developing the product that gave the company a new lease on life.
  • Car, by Mary Walton, Like, “The soul of a new machine,” this is a product development case study – if the 1996 Taurus at Ford – by a journalist who was invited to follow it from start to finish. The most interesting aspect of this case is that, while the development project was technically successful, the resulting product did not keep its promises in the market.
  • Fred Moody’s I sing the body electronic is similar to the other books, but about software product development at Microsoft in the 1990s.
  • Stephen Ambrose’s Nothing Like It in the World takes you into 19th century project management on the transcontinental railroad.
  • A Man, a Plan, a Canal – Panama, a DVD narrated by David McCullough about the mother of all civil engineering projects. Note that the title is a palindrome.

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.

From scancards to “personal kanbans” and Ybry charts

Professionals know that their productivity drops when they take on too many concurrent projects. An engineer whose attention is split across 15 projects doesn’t contribute effectively to any. But it happens because supervisors keep piling on assignments without regard to this phenomenon. Over the years, cures have been proposed under different names, all aiming to cap work in process.

About 1982, a colleague showed me the system he used to manage what he was working on. It was called the Scancard System, and it used the hardware  in Figure 1. The cards were square, with 3 1/4-in sides and borders of different colors. They came with letter-size card pocket plastic boards that you could insert into 3-ring binders, keep on your desk or pin to a wall.

Figure 1. The Scancard System

He used it with one column for his backlog of things to do, one column for work in process, and one column for completed items. It was a paper-based system but, at the time, so was almost everything we did. It gave you visibility, it capped the number of items you were working on at one time, and moving cards from one column to the next was an effective metaphor for the flow of your work. The ads showed smartly dressed managers using their scancard systems in meetings. I went for it and used it for years, until I had a project with a company that used another system and switched to fit in.

Fast forward to 2011. Scancard Systems is out of business, and I hear of a system called “Personal Kanban,” that is focused on providing visibility and limiting work in process, using a white board and Post-Its as in Figure 2:

Figure 2. “Personal Kanban”

I put quotes around the name because I find it to be little more than a feat of vocabulary engineering, leveraging the buzz around a feature of Toyota’s production control system to repackage ideas that have little to do with it, are very simple and have been around for a long time. A software developer visiting a factory may see a similarity with Toyota’s Kanbans, but it escapes me.

Of course, if, as in Figure 2,  it is on a white board, you can’t carry it with you to a meeting or share it in your network. The Personal Kanban website advertizes an iPhone app called iKan, that I can’t find on Apple’s App Store. On the other hand, Leankit Kanban offers a web-based application with an iPhone version that looks very much like a team to-do list management system. It looks most useful if your work can be perceived as a collection of independent activities, which happens if each Post-It is for a whole project or for a prospect in a sales cycle. But it would not fit if each Post-It were for a task within a project, with precedence constraints or iterations between tasks.

Another limitation of such a status board is that is only shows current status, as compared, for example, with the Ybry chart of Figure 3, which shows the complete history of each project by using a line for each project rather than a card. Like the status board, it assumes that all project go through the same sequence of phases.

Figure 3. Ybry chart for projects going through the same sequence of phases

Ybry charts were invented by Charles Ybry in 1846 for railroad scheduling, and are still used for that purpose. See Edward Tufte’s Envisioning Information, pp. 107-110. The work-combination charts used in Lean operator job design are a variation on this method, as explained in Working with Machines, pp. 133-154.