How does your project plan compare?
The Empire State Building, project plans big and small, and hitting the proverbial barn
Steve Hamilton | March 11, 2015
I recently toured the Empire State Building and was struck by the project plan for its construction.
I’m used to massive project plans with hundreds or thousands of rows stuffed with complicated dependency diagrams, resource utilizations, percent complete, and the like. This plan had none of that.
Yet somehow they were able to build the largest building in the world—on time and on budget.
To get a sense for the sheer scale, let’s compare the Empire State Building’s construction with the kind of software project I typically work on: a routine system upgrade.
- Budget: The Empire State Building’s (ESB) budget in 2015 dollars was approximately $600 million. The system upgrade? Roughly $10 million.
- Manpower: ESB had a team of 3,400, or about 7,000,000 person hours. The system upgrade had about 200 people or 800,000 person hours.
- Length: ESB was completed in 410 days. The system upgrade is expected to last 730 days.
- Expectations: ESB was delivered on time and on budget. The system upgrade has been delayed by six months (a 25% increase in timeline so far), and the budget has already been increased—twice.
- Documentation: ESB had 47 rows on its project plan (66, if you count subtasks). The system upgrade has more than 40 project plans (!) representing tens of thousands of lines (!!).
So, with a budget only 1.7% as large and using only 6% of the resources, this routine system upgrade took nearly twice as long to complete, ran over time and over budget, and had a project plan that was approximately 1,500% larger.
What’s the difference?
Many software projects take a command and control approach. This necessitates massive project plans to ensure that the project manager knows every little project detail and can map the dependencies and know whether the project is on schedule and on budget.
Sadly, these plans often contain a high level of precision but very little accuracy. In effect, we are trying to hit the proverbial "broad side of the barn,” yet we end up putting a very small hole in the wrong barn. And instead of realizing that we missed entirely, we congratulate ourselves on our precision.
So, what do we do?
In many cases these highly-precise project plans are created out of fear and mistrust. It’s an attempt to control an uncertain future.
If we can't plan these details out and map our dependencies, how do we know our team will do the right thing? How can I know we will be done on time? How will I know how much it will cost?
There’s a better way. For starters:
- Accept that we can't predict the future with any level of precision and decentralize control and/or execution to allow for rapid response to unforeseen events. (See Predicting financial crisis.)
- Accept that project plans and artificial deadlines don’t motivate people or guarantee results. Hire skilled people that you trust. (More on this in Daniel Pink’s piece on motivation.)
- Let people do what you hired them for! This is known as servant leadership.
Maxims like these are great. They serve as a guide when making decisions as you can test yourself against them. However, critical questions still remain, such as: How much will my project cost? How long will it take, and how many people do I need? How will I know if I’m on track?
Never fear: All these questions have answers.
Drawing from lean and agile methodologies, we can use empirical (evidence based) data to formulate their answers. For example, to plan cost/timeline/staffing for the system upgrade, we start by identifying a comparable project. Do so by looking at your own organizational history, consulting the experts in your organization, or working with your vendor to understand similar implementations they’ve done.
Once you’ve found a comparable project, base your plan on the relative size of your proposed project. Is it half the size? Twice the size? This will give you a highly accurate (yet not precise) budget. (Note: If it isn’t half or double you might not have picked the right project as your measuring stick.)
Finally, how do you know if you’re on track? This one is easy, and it comes directly from the world of lean. Get out on the floor, and talk to your team. It’s known as Gemba, and it’s a highly effective way to not only find out whether you are on track but ensure that you stay on track by identifying and eliminating risks and problems early and often.
On a 200-person project it is reasonable to walk around and talk to people. Focus on providing visibility of the work. On the Empire State Building they had the benefit of a giant structure that everyone could see every day. In the software world we can use visual tools like Kanban boards and demonstrations of working software to effectively provide status without adding undue overhead.
Which brings us back to our barn. When trying to hit the broad side of a barn, you’re better off putting a large hole in the correct barn than a tiny hole in the wrong one.
Steve Hamilton is no longer with Slalom.