A couple of years ago, my former manager David Denton forwarded me a recorded presentation by Mary Poppendieck, a leading Agile software development expert and co-author of the popular book “Leading Lean Software Development: Results Are not the Point.”

Watching the video on the InfoQ website is a bit kludgey and Mary has lots of wonderful details that are worth hearing. So, with Mary’s permission, I’ve had the video transcribed and included her slides in context. I hope that this will make this very useful knowledge easier to find and learn from. Mary, thanks again.

I’ve eschewed block-quote formatting as it made this transcript a little harder to read. I’ve also edited slightly for readability. Otherwise, everything beyond this point is Mary’s work.

Today, I’m going to talk about the Tyranny of the Plan and I wanted to start with the question of, where do plans come from? [Slide with a computer clip art image.] That’s where they come from. All the time that I see plans they somehow they’re generated on some computer or other and actually if you think back or read back in your history, there weren’t that many detailed plans before there were computers to put them together. If you take a look at MRP plans, I was in manufacturing plants in the 1980s and I was the IT manager and the thing I managed was an MRP system, it’s for your requirements planning system. It looked sort of like this…

Well, not quite the graphics there, but anyway all kinds of details about how each workstation would be scheduled and exactly what each workstation in the plant would do every single day.

The problem with that is that it didn’t work. The thing you did then, there was a body of knowledge by the way that you could get certified in. it was called APICS, American Production and Inventory Control Society and I got certified—fellow level—passed every test at the highest level and I learned every single way there was to forecast you can imagine and how to put together all of these MRP systems. One of the things I learned was about a nervous MRP. The nervous MRP means that if ever you don’t do something exactly the way that the plan says that you’re supposed to, things start going haywire really fast and very soon everything is wrong—doesn’t match the plan anymore—and so you have to re-plan.

Now, a nervous MRP means that when you re-plan, everything starts zero-based. They start re-planning from where everything is and if you take a look at it the next morning you come in and say “oh, this is totally different than what we were doing yesterday.” Things have to be shuffled around. Everything has to change and it doesn’t work. You can’t re-plan everyday because it just jumps all over the place. You can’t re-plan every week. Re-planning actually just sort of makes everything go strange. It doesn’t take reality into account.

So the MRP plan never worked and we always heard this: “if only you would try harder to do exactly what the plan says, then the MRP system will work.” Have you ever heard that before? Okay. Well, that’s what we were told. But then there was this thing. This is a Kanban card and this is how the Kanban system worked and when we heard they were doing this kind of stuff at Toyota we thought they were nuts. They were doing things exactly. How could it possibly work? But we tried it in our plan and we found that it worked very well. Before we went to using a pull system with Kanban, we were able to pack out, out of the end of our plant something like 60 to 62% against plan every single week. Not very good, right?

It was really the best that anybody could do with that kind of a plan. One weekend after several months of preparing, we cut over to a pull system—or a Kanban system—and the next week guess how much we packed out against plan? 95%… and it went up after that. So one of the interesting things is it didn’t work. It couldn’t do what it said you were supposed to do, but a pull system, a Kanban system where you have cards here, they go work here, they caused production to get made, it worked at that point and it works reliably in manufacturing when you figure out how to make it work right. Much more reliable than that.

And then there’s project plans.

So you’ve all seen that, right and how well does that work? It gets about as nervous as an MRP plan whenever you don’t do exactly what the plan says. Now this is just the one project, but what if you have a plan for 15 projects and you’re going to swap teams in the middle? How well does that work? It’s just about as nervous as any other detailed planning of stuff that has variation in it. So what has turned out to be better—and what this conference is all about—is something a little bit more like this [pointing to slides] where you have a workflow that goes through here and you have stages of the workflow and you have limits. It doesn’t have to look like this. This is basically a Kanban board to pull your software through the system while limiting work in process at the same time.

Then there’s another kind of plan—construction plans—which again are computerized. That’s where they come from and how well do they work? About as well as all those other computerized plans. The minute it rains or somebody doesn’t show up or something takes a little bit of extra time or something like that, it falls apart. There’s an organization called the Lean Construction Institute that’s got a huge amount of work done in this area and they’ve devised something called the Last Planner System which is a weekly planning mechanism whereby you look at what’s supposed to more or less happen based on the plan and what actually happened and you commit to the next week of work and in that way you actually get huge amounts more done than if you try to follow a plan like this.

So back when computers started generating all of this detail was when we started getting nightmares over how are we supposed to follow it. I don’t know that this kind of detailed planning for any area where it’s been tried where there’s any kind of variation has ever had a track record of working. But you also have to think about this: people have been building buildings for a long time. Now we haven’t actually been trying to do manufacturing with a MRP system until computers came around and we didn’t actually try to do project planning in detail until computers came around, but they’ve been building buildings for a century or more: great, big massive skyscraper buildings.

So you’ve got to ask yourself, what did they do before computers? Maybe there’s something that we could learn from that. So I was in Denmark a couple, three years ago and I ran into somebody that was in the construction industry. He was associated with the Lean Construction Institute and he said “there is something that’s very strange that I have to investigate. Did you know that they built the Empire State building in eight months?” I said “no, you’re kidding.” He says “I have to figure out how that happened.” Okay, so that was long before there were computers. How could they have done that? Well, it turns out —there’s the Empire State building—it wasn’t exactly eight months.

They started in September, 1929. They signed a contract September 21st and started demolition on September 22nd. So this is 85 stories—and plus a bunch up there—and on September 22nd they got started. What happened the next month? Big crack, sort of like we’ve been through one of those recently. So one month later the stock market crashed and virtually all of the other buildings that were planned and on the drawing board were cancelled in New York City at the time, but this one got built. On January 22nd in 1930, the site had been cleared. It had quite a few 20-story buildings on it. It was two square blocks and they started excavation on March 17th. This is the St. Patrick’s Day and it’s not an accident that they started the fill construction on March 17th.

On November 13th it looked like this. So this, from March 17th till November 13th, that’s the eight months that he was talking about. Now, it didn’t’ have the top on. So this stuff up it looks right up to there in eight months they put it up, the stone, all of the exterior. How amazing. Then on May 1st 1931, the next May, it opened. There was a reason why it had to be on May 1st, because in New York City at the time the leases for all buildings started on the first of May every year. So when they signed the contract on September 21st, the agreement was that it would open May 1st, 18 months later.

It had to in order to be able to take advantage of the leases. So that was the rule. So it was basically exactly on time and in fact it was 18% under budget. Now you could maybe say it was under budget because of the depression or something like that, but actually it was under budget because it was on time when it comes right down to it because the amount of money you can spend even in building a building has huge amounts to do with how much time you have people on site. The materials are pretty much going to cost the same amount of money.

So, interesting thing is that in New York City at the time this was normal. Remember, no computers. Really nothing even like a computer and they were able to build this building here which is the Chrysler building in 18th months. It was completed one year before the Empire State building. It is 66 stories tall. It was built in 18 months and it was competing with this building which is 40 Wall Street and this building is also 66 stories tall and that was built in one year, not 18 months. From of time that they started demolition until the time of occupancy: one year. The reason why this one was built was to compete with this one to be the tallest building in the world and in fact so they put this fancy stuff up on the top. The reason why that’s up there was to win the race and when Walter Chrysler saw that this building was putting all that stuff up he went to his architect and he said “Think of something! You’ve got to be taller than them.”

So you see this here thing? Okay, so that’s what he thought of. That was this extra peak and they actually built it inside the building so that nobody could tell that they were doing it and then they jacked it up. After the newspapers gave these guys credit for being taller than that one, then one day—one noon—they started, jacked it up and then they bolted it in place and they didn’t tell anybody and it took two weeks for people to notice that this building had suddenly got bigger than that one. Well, anyway the real reason why they’re there is because they knew how to build buildings fast back then in the 1929–1930 timeframe. It was routine. It was commonly done. The deal was that you started in the fall, in the spring, you built the outside and got done by fall and the bad weather came. You spent the winter finishing up the interior and on May 1st it was open. That’s how the tall skyscrapers in New York were built. Routinely.

So, how did they do it? They didn’t have a plan, which laid out the detailed task that everybody was supposed to do. Instead they focused on the workflow instead. So I want to show you a quote schedule for the Empire State building.

This is the steel schedule. So note: it’s 85 stories so there’s two, four, six up to 85, right. Here is the month January, February, March, April through till September. This line going this high diagonal, that is when the first overall plan for the steel was completed. First the design of the steel was completed on those days. You can see that this is when they sent the order to the steel mill. Actually they had two steel mills. They had steel mill A, steel mill B, steel mill A/B. See that? Every so often—every few stories—they’d switch to a different supplier so that they never would get behind.

This is a third one. This is when the detailed design of each level of steel was done. This is overall design. This is detail because it’s load-bearing. It’s different for every floor. Actually two floors at a time because the columns are two stories tall. So this is when they did the detailed design, and this is when the delivery happened, and this is when the construction occured. So this is delivery on site and within a week it’s up in the air. It’s there. So that’s how they did the flow. Now if you look at this, this is a workflow. Design, order, detailed design, delivery, and construction. That every one of them goes through the same workflow and they just do it as an offset. The entire building was built this way.

They said, we thought of it as a band marching through the building and out the top. It doesn’t matter if it was steel or whatever, they had four pacemakers.

First of all you saw the plan for the structural steel construction and it was completed on September 22nd which was 12 days early. Then the second pacemaker was the concrete floor construction and it was completed on October 22nd, six days early. You can imagine the same type of a schedule for that and the exterior mill and trim, the middle is where the windows and the joining stand doors in between them go up in columns and then the trim and then the limestone which is in separate column. The interesting thing is that—for example—this was completed quite a bit earlier than the other because every one of these workflows was separate from the other workflows.

So it was designed for example so that windows could be put up without any exterior scaffolding and without the floor needing to be in place. Each workflow was completely independent of the other so there would be no cascading delays. So if you get stuck on the concrete floors it doesn’t matter. You can still put the windows and the stone up and get the store floors in. The only thing that really had to be done first was the steel, of course. This has to be 1930 and by looking at the height you could almost put a date on it because the thing went up just over the summer time from nothing to the top by the end of the summer.

So those were the four pacemakers and that’s what they did. They had independent workflows, which were separately scheduled and everyone was scheduled to be paced at a cadence and go up.

So what have we learned? See this thing? Kill the computer. So that’s the first thing we need to learn. We have to stop using our pet things called computers to figure out the details of every task that’s going to be done and lay it out on a schedule and then figure out how to make that schedule happen. That doesn’t work.

Let’s take a look at what made this thing successful. How could they possibly do it in that amount of time? First of all they had a team of architect, owner, and builder. So on September 21st when they signed the contract, all three were involved and by the way there was no design at that point in time on September 21st when they signed the contract. They figured out the design later. They had building permits for 85 stories. So they know it would be 85 stories and that they fudged some numbers to pretend that that would be the most economical height, but everybody knew they really just wanted to be the tallest building in the world and when they signed the contract it was a fixed price contract for the builders who were actually responsible for most of the cost.

So by working together as a team, these folks—in October, November, December timeframe—came up with a design and they came up with a design by talking to all of the experts that they needed to talk with in detail and figure out how the important things had to happen. So for example they knew for sure that they needed to design the elevator shaft first because they were going to determine everything else. They had to design criteria from the floor to the top without changing elevators. That was one of their design criteria. So they went to the Otis elevator and they said “what have we got to do to meet our design criteria?” They started out with figuring out how the elevators were going to be laid out.

They didn’t have design loopbacks because they had extremely experienced builders. The builders knew what they were doing. They had been building skyscrapers for between 30 and 40 years and they understood what they had to pay attention to and what was possible and what had to be designed in what order to eliminate the loopback. Now, all the computers in the world: they’re not going to substitute for deep experience. I propose that if they didn’t know what they were doing there’s no way: they would not have had the chance to hit that kind of number.

Another thing that they did was: they thought about the constraint. The builders understood very well that the key constraint was not stone, steel or anything like that, not labor but getting that much junk onto two small square blocks in the middle of a very big busy city in that amount of time.

When you think about all the stone and all the pipes and all the wires and the windows and the steel, all of that had to be delivered within a very short window of time. They knew that if they figured out how the stuff was going to move, they were going to be able to get the rest done. If they could get the right stuff in the right spot at the right time at the right floor every single day for a year, the building would happen. That was basically all they did, all that they scheduled, and all that they focused on.

They had 500 trucks a day arriving during the workday, during the daylight hours. They didn’t have floodlights, so lights for working at night or anything like that. 500 trucks a day. I’ve heard K-Mart brag that they can manage 500 trucks a day, but this is like one truck a minute and they were doing this in 1930. Pretty amazing.

They decoupled the different workflows. So they did not have cascading delays. They dealt with each workflow separately. But not only that, but they designed the building to decouple the workflow. The building was designed to be put up fast. You go back and think about software architecture or system architecture, one of the things that we don’t pay that much attention to—when we should—is how to create an architecture which decouples the workflow so that things can be done independently of each other and not have cascading delays.

They also did things like—as I showed you—they had alternate mills doing the different stories. So about every 10 or 15 floors there was a different mill delivery. So if one of them got a little bit behind they had some cushion to catch up and they had an alternate supply. They had a case for dealing with dependencies. Rather than creating dependencies, they broke dependencies. They got rid of as many dependencies as they could. The other thing they had was what I would call cash-flow thinking and I think cash-flow thinking is a fundamental concept in all lean thinking. You think from the time I invest in something until the time I get my value back how short a period of time can that be. This is exactly the opposite of balance sheet thinking, the thing that killed too many car companies I think.

Cash flow thinking. They said guess what, every single day is costing us $10,000, which is $120,000 a day today. So every day that we can save, we can save $10,000 (or equivalent of $120,000). So it pays to invest money to save time. So they invested money, for example the railroad track that went on all of the floors to move materials around. They invested money in having bigger electrical boxes that for all the switches and all of the plugs so that they could take a conduit and run it straight in between rather than having to bend it into the smaller box.

So now 85 years later they still have the big electrical boxes, but guess what:  they got the building up faster because of it. Here I think is the critical thing. The schedule was not laid out based on the details of the building design. They didn’t design the building and then create the schedule. They created the schedule and then created the design to fit in the schedule. The building was designed based on the constraints of the situation.

Here were the constraints that they had at September 21st when they signed the contract:

  • They had two acres of land in the middle of New York City
  • They had zoning ordinances
  • They had $35 million of capital
  • They had the laws of physics, which they couldn’t violate
  • There was May 1st 1931 and that was it and the building was designed to meet the constraints.

So if you go to I don’t know, what we would call PMI School in the US. It’s probably called something else here. You learn that you start by figuring out what you’re going to do then you break it down into pieces and that’s called work breakdown and then you sum up the total of that and bingo, there’s your schedule. That’s not the way to schedule. The way to schedule is to start with the constraints and create a structure that can fit in the constraints. That’s one of the most important ways to get rid of the tyranny of the plan.

So what else have we learned? We’ve learned to design the system to meet the constraints. Do not design the constraints from the design. Make sense? It’s really a radical idea, but why not? Because you know what, those constraints are real. Time constraints, budget constraints, all sorts of things are real. They’re not going to go away. Why do we decide then based on the design, which is completely arbitrary? Why not start with the real constraints and design to meet them? So if we have a round pole, we do not want to build a square pit. We start understanding the pole is round and then we create a round hole to put it in.

Secondly, decouple workflow and in system development this generally means have a low dependency or architecture. But that’s the only thing it means. It means think hard about how not to have dependencies in your schedule. Again, if you go back to good old PMI school, you learn how to create PERT charts. What do PERT charts do? They figure out all of the dependencies in the system and figure out what you’ve got to do first, second, and third in order to handle all of the dependencies. What if we would spend spending all of that time figuring out the dependencies in the system—and how to organize them on a schedule—and instead figure out dependencies and figure out how to break them?

So breaking dependencies from an architectural point of view and from a scheduling point of view makes a lot more sense than figuring out how to schedule them because a schedule will not necessarily be true. Lastly, we’ve learned that it’s easier to control workflows and to get more predictability out of workflows than out of schedule. So I would like to make the point that schedules and workflows are different things. They’re kinda orthogonal to each other.

A workflow is something that moves steadily and constantly through the system. It can have some milestones and start and stop dates, which would be the schedule. But a workflow is a constant reliable flow of work through the system. The most important thing to do in any kind of planning is to establish a reliable workflow. When you have a reliable workflow you have a lot more control over the system than you could have with any kind of schedule at all. So if you really want control and predictability, then go for establishing a reliable workflow rather than establishing a schedule which needs to be followed… especially a schedule at the detailed level.

So that’s kind of what we might have learned from the Empire State Building.

So let me ask this question, why do we schedule things? One the reasons why we schedule is to control the future, to make things happen at a certain point in time. But the problem is we know that detailed schedules are deterministic, we’ve rolled them up from a work breakdown structure and they don’t allow for variation. Remember my plant and they would say “if only you would try harder to do exactly what the schedule says.” Well, you know what? Machines break down or if you’re in construction, weather happens. Problems exist. When you try to lay out a detailed schedule using any standard scheduling system, you’ve created a deterministic schedule that has no way to deal with variation unless you add slack. Slack is an interesting thing but maybe you don’t want it.

One of the interesting things about flow systems is that they don’t need slack. They filled it in whenever they need it. They don’t have to have it planned in from the beginning. So if you have what I’m going to call normal variation or what is technically called common cause variation, then you have a problem because you have a deterministic schedule sitting on a lot of detail with variation. It’s also well known by any good black belt or anybody else who’s studied variation that attempting to remove common cause variation from a system causes it to oscillate, just like that. That’s like one of those laws of physics that you don’t get to violate. If you try you get the oscillation.

So if we have a detailed plan, and we have common cause variation, and we try to get rid of it: this is what we get. So managing the level of workflow is a lot easier than following a deterministic schedule because we’re not going to drive this kind of oscillation into a workflow. When you take a workflow and make it steady, you’re not trying to take a deterministic plan and constantly match it.

The second reason why we schedule is to predict when things are going to happen. It would be nice to know. It’s kind of important sometimes. Then again we know that when you base schedules on experience, remember those builders, they’d been there, they’d done a lot of skyscrapers already, then they’re reliable.

But if you build up schedules based on wishful thinking, guess what? They’re not going to be reliable. They’re just going to be a high hope. Well, good luck. Especially if you sum up schedules from a work breakdown—which are already guesses and hypotheses—then what you’ve got is a hypothesis about how the future might unfold. It’s not a bad hypothesis. One thing you know however is that it’s probably not the way the future is going to unfold. So when reality doesn’t match to schedule, what do you do? Because it won’t. Because there’s variations, normal variations. Guess what? If the reality does not match the schedule, then the conclusion should be the schedule was wrong. Instead of somebody didn’t figure out how to follow the plans and try hard enough.

So when we have this thing called variance from plan against which basically most project managers happen to be measured from their basic performance, right? Okay, how are we doing with earned value and that sort of thing. Basic project management measurement is variance from plan. So say you vary from plan. What happens? Oh, you’ve got a performance failure, right? Maybe. There is another way to look at performance from schedule. Perhaps it’s not the person who’s trying to manage the schedules fault. Perhaps it’s the schedule’s fault instead. In fact, if the schedule is a hypothesis rolled up from a lot of detail, it’s the schedule’s fault, not the person’s fault and what we really should do is view it as a learning opportunity.

Guess what? We’ve learned something about our capability to schedule and we have to rethink how we’re going to schedule because this particular one wasn’t correct. We came up with a wrong hypothesis. What is it about our scheduling approach that gives us wrong hypotheses?

So you have to look at failure not as a way to beat somebody up, but as a learning opportunity instead. One of the interesting things or one of the interesting quotes today I’ve heard from Deming, which I really like is this one: He says “don’t set targets” and by this I mean performance targets. Don’t set targets because if you have a stable system—a stable workflow—then there’s no use to specify a goal. You’ll get whatever the system will deliver, whatever it’s capable of, what its capability is.

A goal beyond the capability of the system won’t be reached. So why bother setting up performance targets? Now, if you don’t have a stable system, if it’s varying all over the map, then again no sense in setting a point because there’s no way to know what the system is capable of producing. If you have a schedule—which is just basically a guess—what good is it? Measuring variance against that plan doesn’t make a whole lot of sense. Instead you need to learn how to learn. Now, here’s a basic fact of life that one of the things that I’ve been observing in the book by Steven Spear and I’ve been observing it also: any complex system—and the further on we go down the path of technology, the more complex systems get—they will always eventually fail because they’re just pretty messy.

We know this from software. We know this from any complex system. Tom was in the hospital a few weeks ago and I saw a complex system with a few holes in it too. Any complex system is going to eventually fail. The real question is, “when it fails, what do you do with that failure?” A failure should demonstrate to you that you do not understand how the system works. You don’t understand how the schedule works or how things interact. Well, of course not. It’s too complex. Therefore failure is the system talking to you. It’s trying to tell you something that you don’t know. If you take failure as an opportunity to learn more and improve the system, then you will be able to harness that complex system gradually and more completely over time.

But if you take failure—for example to meet a plan as something where the person who was supposed to do it has failed—then you’re not going to get any better at managing that complex system. Fundamentally complex systems when they talk to you by not having things just exactly right need to be paid attention to. Even little tiny defects—the kind of things that are inconsequential—if you pay attention to those or learn from those and create a reliable workflow, then you will have a system in which you have more and more capability to be confident of. You have more and more capability to make predictions from.

So one of the things that I’m going to talk about now is two things, scheduling and workflow because as I said they’re different. You still need to know when things are going to be done. The general concept that I have of scheduling is what I would call pull scheduling, not push. Not take a whole bunch of detail and shove it out onto the organization and say “here, do this,” but pull.

So pulling for example in a software product this happens to be that you decide at the beginning because you have enough knowledge and experience to make this kind of decision—because you’ve been down this path before—that this project is going to take say 15 months to deliver.

And so the first thing you do in the first two months is: you make sure you really understand what the customer’s problem is and their intention. You really understand what your overall technical approach is going to be. Then you review that after a couple of months and you make sure that everybody is talking the same way and that you know those things. You know what, if you don’t figure this out—if you don’t pass this test—then you stop and fix it and you don’t go on with the rest of the schedule.

But once you get to this point where you have a good technical approach and you have a good understanding of the customer, then you should actually be able to execute the rest of the schedule on time. But that doesn’t mean we know exactly what we’re going to deliver and marketing can start writing up their brochure. That means that we decide here at two months that three months from now we’re going to have finished the proof of concept and at that point we’re going to decide what goes in the alpha release.

Now it’s three months later and we look at the proof of concept and decide on alpha release features. Three months after that the alpha release is ready and we decide: “what are we going to put into the beta release?” Then three months later we’ve been watching the alpha release, the beta release is ready, what we decided we could put into it three months before and so we decide now—finally—a baseline of what we guarantee will be in the first release. Not everything, but the baseline. Up until this point guess what? Marketing doesn’t get to go out and tell everybody what we’re going to have. We haven’t decided until here [13 months] what’s going to actually be in the product.

We’re going to solve that problem. We’re going to take that technical approach, but now we know in detail the baseline. We have a beta release and after two months on the beta release we start saying “okay, now let’s finalize and add a few details of what is actually going to be in that final release.” We decide that and then release it two months later.

So that’s a concept of pull scheduling. Every single quarter—two or three months—is a basic milestone. You decide upon the work for the next three months based on what happens at that synchronization meeting. It can be a couple day meeting or everyone get together and say here’s what’s happening over the next three months.

So you’re pulling from a three-month away deadline the work that happens in that three-month window. You based your estimates on experience and data, not wishful thinking. You time-box; you don’t scope-box. So you don’t ask “how long is this going to take?” You ask: “what can we do by this date?” That’s how you time box. You don’t ask “how much is it going to take to make the scope,” it’s “what scope can we finish in the next three months?” Then you use these integrating events to create both cadence and a pull for the next three months.

So that’s scheduling. The other thing you need in order to make this all work is what I’m going to call reliable workflow. Reliable workflow—especially if you’re handing off stuff from one organization to another—you need to figure out how to create reliable workflows. [Referring to the slides] This is more from Steven Spear’s “Chasing the Rabbit.” So if this is your process, what you do—no matter if it’s a team process or individuals—there’s still going to be some handoffs. As this work goes through here you get some input and you have some outputs. You need to constantly learn when things go wrong. Remember: when your system fails you, the important thing to do is to listen to that failure and learn from it.

So if you get inputs that aren’t exactly right, you need to let your suppliers know that they need to give you something that’s more correct. How do you need your inputs to look? They should be asking you for your feedback. If your customers get stuff that they don’t really want, that isn’t working for them, that has even small defects, problems in it: they should give you feedback and you should ask for it. So this is a reliable workflow. A reliable workflow has output here where you get your final output—that is wonderful stuff for your customers—but it also has all these intermediate steps to get there.

So it has a pathway. How does stuff move? If you think back to the steel schedule for the Empire State Building, there was overall design, order to manufacturing, detailed design, delivery on site and put-up. So they have a sequence of activities with a clear workflow and connection. So your handovers from one spot to the next, for example from the design group to the mill or somebody like that and what you need to do at each handover is make sure that it’s done correctly. You have feedback. If things are not happening correctly at that hand over you fix it. Then you have to have some understanding about what constitutes good development, good programming, good TDD, good continuous integration, those sorts of things and clear standards for that. Then you constantly improve that. The last thing for improvement is: never add value to defective input. Figure out what caused the defect and fix it. Verify that your output meets the needs of your customers. When a problem is exposed, forget workarounds. Don’t ignore the noise and relegate it to the background. Find and fix the root cause of it.

So let’s go back to my first question. “Where do plans come from?” I want to talk about another thing that happened. This was just as computers were beginning to dawn. This is one of the most successful weapons projects. You might not be interested in weapons projects, but this one is kind of interesting. This was the Polaris submarine project. It was started in 1956 to 1959.

A program that was supposed to take about nine years actually took about three. It was constantly and continually rapidly improved upon for the next eight years. So they took the design 12 years, but they did it in small stages. and this was the beginning of PERT charts. I kid you not. This is where they were invented. They were invented by William Raborn and he had a reason for that. This was a long term program and it was going to take a lot of money from Congress and Raborn knew that Congress was: they got elected every two years and with all this change. So he invented this interesting story. He says “I have this wonderful management method. It’s called PERT charts and it’s going to keep us basically on schedule for the whole thing” and in this case by the way money didn’t matter. Schedule was the only thing that mattered.

“It’s going to keep us on schedule” and he used this as sort of a façade to keep congress funding the thing because he had this fantastic fail- proof management system. It didn’t depend on people anymore. It depended upon his wonderful management system. Now, basically it was designed to track an extremely aggressive schedule. It didn’t take any into account costs. But it really and truly was a façade. If you read this book—which summarized from a lot of detailed interviews exactly what happened—he said that it was not really used by the project in the early years. They didn’t use this PERT chart. They just did it in order to keep Congress happy.

The requirements and scope were changing all the time anyway so the charts never meant anything. It was a nervous thing. The technical officers in the program bypassed it. They figured it was unreliable. The contractors thought it was worthless, but it was there and it kept the funding coming. Now unfortunately, this thing was sold by Raborn so well that it became the basis of all kinds of future projects. In fact, UK was one of the first countries to adopt it for their projects because they wanted a mechanism to make projects work. It really in the end came back to bite the original people who designed it because they were forced to start using it eventually.

So if you think about this, suppose he says that it didn’t actually make the success at all. It really made it appear to be the method of success, but then it became the thing that we had to live with. So if that wasn’t what made the Polaris program successful, what was?

What do we really need to do in order to have successful projects? One of the things was: they had a technical director. His name was Levering Smith, who had a fierce understanding of what he wanted to do. He had complete control over the requirements. Now if you want to be successful that’s what you want to do. You want to have control over the requirements. He got to change them if he didn’t think he could meet them. So basically he designed the requirements to meet the schedule rather than designing the schedule to meet the requirements.

He made or directed all key decisions. His personal signature was on all the key interface engineering drawings for the first eight years. He focused everything on deploying: getting the submarines in the water as fast as possible. He managed to do something in three years that was considered to be a nine-year project. He did three stages, simple stage, more complicated stage and the final stage. Three timeboxes; incremental delivery. What a good idea.

His primary goal was an operational system—just to learn from—as early as possible and so when he got the job he said let’s see, we’re building a submarine right now, right? Yes. Okay, how much room do we think we need for these missiles? I think it was – what was it Tom? 17 feet? 17 meters? 40 feet. So he said let’s just take that submarine, stretch it out 40 feet, build it and we’ll figure out what to put in. very much like the Empire State building. They started going before they had a design.

He also had what I want to call is a decentralized competitive organization. This is interesting and important. First of all, all technical people had control over their own decisions. He didn’t make any attempt to tell technical people what to do. What he did have was for every major subsystem at least three contractors working on it. They had to have 10 massive inventions in new technology in order to make this work. So what he did was, for every major subsystem he had three different contractors working on it. Sound expensive?

Okay, but guess what, it’s the way to make sure that you get something that works on time. So there were three different contractors and the best one won with every subsystem. That was the way that the technical people in every single contracting organization got to do whatever they wanted. They got to do whatever they thought was correct and then the best decision against the two other competitors or three other competitors was the one that was chosen.

Sometimes we call this approach set-based design. It’s an interesting name for having a lot of options explored in detail in a technical manner before you happen to make the decision. It sounds expensive, but actually it’s one of the best ways to keep an aggressive schedule that we know.

Emphasis on reliability. There was an amazing emphasis on passing all the tests, which were the first things that were designed where we heard this before. One of the things you always hear about in any kind of lean software development is massive emphasis on reliability. If there was one thing that Levering Smith was criticized for is that he focused too much on testing and reliability. Good criticism.

Lastly, everybody was completely engaged in the system. They were saving the world for one thing. There was also a great interaction between the contractors and the technical people (stuff that in the US would be illegal today by the way because you couldn’t go to dinner with a contractor and not have some sort of collusion be accused of). But they did and all this kind of interaction of everybody and talking was encouraged and rewarded.

So those are the kinds of things that make schedules work, not PERT charts or detail schedules that you have to follow on every task. It’s reliable workflow and this kind of stuff. So with that, look at that [Q&A slide]. There’s 10 more minutes left for questions and I think Allan is going to come up and answer some questions.

Question-and-Answer Session

Moderator:         So actually I’d like to invite the audience to ask questions. Think about something. Yes.

Speaker:             Were there any project managers for the Empire State?

Moderator:         Were there any project managers for the Empire State building?

Mary:                  For the Empire State building the builder, that’s what they did. They managed the workflow. They as I said had a fixed price contract and they knew that the only way they could make the cost, they had cost and date. Where you saw the constraints was to create the workflow and that’s what they concentrated on. For example if a truck pulled up, the minute the truck came near the building somebody from this, there would be a – there was a trailer where all of the building people lived. They would run up to the truck and they would have a manifest of what he had and they would hand him a detailed schedule of exactly where do you go with it and where do you lay it down.

No truck waited for any information or in line about where they should go or what they should do. So the people in the builder’s office spent all of their time making sure that the people and the materials were always where they were supposed to be. The workers had foremen who hired them every morning, got them to the right spot and when you had the material and the workers at the right spot, it got put in. So that’s what they did. They made sure that all of the material and all of the workers knew exactly where to be when.

Speaker:             Actually (inaudible) when they show that when the (inaudible) went up and all the other things went up had determined the answer. He was like here’s a continuous flow diagram.

Mary:                  Oh yes. It’s exactly a continuous flow diagram. That’s what they did before computers. They managed the workflow.

Speaker:             So (inaudible) … taller building

Moderator:         Question, are the tallest buildings the (inaudible) 0:49:55.

Speaker:             No, they were a lot more taller than the (inaudible) 0:49:56, many of them. Probably all the biggest. So what of the Empire State?

Mary:                  None has gone up anywhere near the pace. Basically as far as I know, nothing, no tall building has come close to matching the pace of the Empire State building. Oh and by the way, one of the reasons for that is because the depression followed by a war created a 20-year window in which people forgot how to do it.

Speaker:             You mentioned slack briefly and slack is common in Scrum teams. They’re building slack in, in order to sort of manage that variation on expected thing. Do you think there is there anything else that you would say about slack in…?

Mary:                  Nobody needs slack when you have a plan.

Speaker:              Is it really that simple? When closest…

Mary:                  Think about it. Pull systems, with a pull system there is always something to pull from the top of the queue. So when you run out of work you pull the next thing and do it. So in a pull system people always have something to do. You don’t even worry about slack. Pull systems manages it’s own slack automatically. So if you have to build in slack that means you have a plan.

Speaker:             So you said you used the analogy of buildings and you said as part of your presentation that it’s really important that the people working on the project had deep experience. Outside of buildings—in the present day—many projects are doing things for which people don’t have that good experience. By definition they are innovations. So you’re dealing with a great deal more uncertainty in the initial estimation and if you were funding a project—a business board would normally be required to do—they need to have a sense of the scale of what it is that they’re attempting to achieve for the sake of it. So that seems to me to be a much harder thing to do therefore than just building another building because although the shape may be different the…

Mary:                  So let me – when we did product development at 3M, we were always doing innovations because the basic theory was that if you had no innovation or invention in the product, no patent then you basically had no protection for your prices. So I worked for years on projects, which were constant innovations. Interestingly enough they didn’t actually have a predetermined schedule. So I want to show you something here. Let’ see if I can do it on this slide because that would be the easiest for me. There’s two ways to think about funding.

One is here is a project and here is the beginning of a project and you get a lump of money and then you go on till the end of the project and maybe when it’s done you get some more for maintenance or something like that. And so if you get all the money in the beginning committed, then the people who commit the money want to know when it’s going to be done and what they’re going to get for their money. But in a good product development environment and the way that we always did product development at 3M, we had incremental funding. So there was concept funding, feasibility funding, a little bit more funding here, a little bit more funding here. At every stage here we reported what was going to happen. We also reported when the next stage was going to come.

So. we didn’t have this whole massive frontend schedule. So I think the evil is this term “project” because “project” tends to mean frontend funded and frontend funding is big-batch funding. Big-batch funding creates big-batch thinking on the part of the funders and on the part of the people executing. So what you’re trying to do is have incremental funding in the same way that you have other incremental stuff. With incremental funding, then you don’t necessarily need to have the seasoned experience. But if you’re going to do this stuff here, big incremental funding, big incremental stuff, then you better know what you’re doing in the beginning. Otherwise you need to adopt a much more evolutionary approach.

Speaker:             Actually I wasn’t (inaudible). You mentioned when you were at 3M you switched over to a local system. I’m wondering, was it something that not just you, but the other people involved where it’s kind of aligned to? They got everybody to figure if this was going to work or is it just doing what you were doing didn’t work then…

Mary:                           Oh, it was the second.

Speaker:             It really was the second?

Mary:                  Yeah. It was like we were about to die because all of a sudden – we were making videotape and our Japanese competitor started selling their videotape for less than we could make ours for. So we had as an operating committee in the plant, we had two choices: We could close down the plant or we could figure out something new and innovative. Not knowing any better and every single book written telling us what to do told us that we were doing everything right.

So we decided to figure out what the heck was going on in Japan and we got this green book called the Toyota Production System written by Taiichi Ohno. Terrible book, badly translated, all industrial engineering stuff. But we studied it and we read it and we said “well, can’t think of anything better. Let’s give this a try.” So we created it and there were consultants out there or anything like that. We had to figure out how to do it ourselves. We did it through the line managements of the organization by creating a simulation at the operating committee level and then we sort of passed that down through the shift supervisors and said here, “this is the general idea, figure out how to make it work in your area.”

So we spent some months doing that and then we tried it. It was just amazing how successful it was. But it was not just because it was a pull system. It’s because it was a pull system designed by the people doing the work. They figured it out. They figured out how to solve the problems. It wasn’t problem free, but everybody that was working on it had helped to design it and they could figure out how to fix it. On an ongoing basis they were able to constantly improve it.

Speaker:             (Inaudible) learning about (inaudible) back then?

Mary:                           That’s what we were hoping for.

Speaker:             (Inaudible)

Mary:                  No. The theory said we should get that kind of part out and in fact we promised our VP like a two week window and we said what if you could get anything that you wanted two weeks after the order came to the plant and he said “ah, wow.” So my pal, the materials control manager Gary said “okay, so guess what, we can’t have you calling the plant with those emergency stuff anymore because everything we know about how this works says that will break the system.”

So no more emergencies. No expediting. No red flags. Everything has to go through even, steady flow. That we understood. He said to the vice president, “if we can deliver everything you want in two weeks, will you stop calling the plant.” The vice president said “sure, no problem.” Of course we started delivering in two weeks and he was totally amazed because we have this 95% certainty and we knew the theory of what was causing it and we could see the practical-ness of what was causing it.

So like three, four months later the VP got used to it and he would – he called Gary up one time and he said, “could I have this one in one week” and Gary said, “Remember what you promised. You will mess up our system if you introduce this expedite. You have to keep the flow even. You have to focus on the even flow. Having something come in there and change the way the system works does nothing but create turbulence and mess up the flow.”

Speaker:             (Inaudible) you’ve got on (inaudible) there is a branch of software engineering (inaudible) and most of the (inaudible) California. That is how they did (inaudible) work.

Mary:                           Exactly.

Speaker:             Now, it also looks like to me the whole (inaudible) can talk about the lead or (inaudible) the software (inaudible) Now most of these software companies (inaudible) we might as well a dance like more successful this whole forum than many (inaudible). So I was wondering…

Mary:                  I doubt they figured that.

Speaker:             Okay. So that was my first question.

Mary:                           Yes.

Speaker;             Then we go to the (inaudible) practices you see in the product development (inaudible) and software industry which you have the corporate and IT how each team should be looking to follow the plan.

Mary:                  Yes. There’s one thing that’s missing that you see in every entrepreneurial company starting up and it’s called “that entrepreneur,” the guy with the big idea that understands the technology and understands the customers. What we don’t have in corporate IT is any concept that even comes close to a product manager or anything like that that you find in every product company. Somebody that has a vision of what the customers really want and what the technology is capable of and can make those tradeoffs. Instead, too much of the IT people are order takers. Go to the business and do whatever they say. That’s not the concept. The concept is to understand well enough what’s needed out there to make aggressive tradeoffs so that you can figure out how to design to fit the constraints. That means there’s got to be somebody there that can make those choices and say “no, we don’t need that. That can be later.” Typically IT departments lack that, but companies that are trying to start new products have only so much money. They’re much more capable of making those tradeoff decisions and you need somebody that’s in a position to make the “yes, we’ve got to have this, no we can do without that,” decisions and they’re tough decisions. There is typically is no role in IT departments to make those tradeoffs.

Moderator:         Okay, this will be the last question.

Speaker:             Just coming back on that, this guy Eric Ries, he said, what he said is that with a visionary leader we can have these mini divisions. He would argue that actually you want to invest in testing those assumptions as soon as possible through experimentation.

Mary:                  Well, even if you have a visionary leader you had better have a way to test your assumptions in the marketplace. The only place where I disagree with Eric—and I agree with him on almost everything—but he does say every so often that you start with a known market and then you have to figure out how to make it work. I’d like to go one step further and say no, “you really don’t necessarily even have to take the market as known.” You should start with somebody that has a vision of what the market might look like. But you shouldn’t even take that as fixed. You should be able to test all of the assumptions about what you’re doing and what’s important against the market.

I love the way that he does that. He references a book called the Four Steps to Epiphany (or is it five?). Four Steps to Epiphany, which is really a good book that tells how to understand the customers. Don’t just go out there. It’s aimed at marketing and in that book he says marketing takes the product for granted. So I would like to see tighter ties where marketing feeds back into the product design also, not just into the customers. Other than that, I couldn’t agree more aggressively or wholeheartedly with Eric Ries.

Moderator:         Okay. Well, thank you very much.

Photo from Didier Beck