by Steve Hamilton, Agile Client Service Director
The construction of the Empire State Building vs. a routine system upgrade. Can your project plan hit the broad side of a barn?
On a tour of the Empire State Building, I was struck by the project plan for its construction. My family made fun of me as I focused on a Gantt chart instead of looking at the hundreds of interesting construction photos and articles posted around the gallery.
I am used to massive project plans with hundreds or even thousands of rows filled with complicated dependency diagrams, resource utilization, percent complete, etc. So, I was surprised to have discovered this plan had none of that.
Yet somehow, they were able to build the largest building in the world—and do so on time and on budget.
To get a sense of the sheer scale, let’s compare the Empire State Building’s (ESB) construction with recent software project I was involved with: a routine system upgrade.
-
- Budget: The Empire State Building’s budget in 2018 dollars was approximately $675 million. The system upgrade? Roughly $10 million.
- Peoplepower: 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 about 20% under budget. The system upgrade has been delayed by six months (a 25% increase in the 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 (I) representing tens of thousands of lines (II).
|
|
|
To summarize, 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 is aware of every important project detail in order to map out the dependencies, understand whether the project is on schedule, and within their budget.
Sadly, these plans often contain a high level of precision with very little accuracy. In effect, we are trying to hit the proverbial “broadside of the barn,” yet we end up putting a very small hole in the wrong barn. Instead of realizing that we missed the mark 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 The 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 comparable project.)
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 (“the real place”), 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 an Agile Transformation Consultant specializing in Product Management in the Agile Practice at Plaster Group. He specializes in lean and agile methodologies and is passionate about aligning business and technology groups to deliver the “right” thing, at the “right” time, and in the “right” way.
Follow Steve on Twitter: @stevenhamilton.
