Nov 11 2011
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.
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:
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.
Dec 1 2011
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:
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.
By Michel Baudin • Management • 13 • Tags: Product development, Project management