 The Empire State Building was built in just 410 days. Disneyland was brought to life in 366 days. The Javascript language was prototyped in 10 days, and launched 4 months later. How were these and other major feats accomplished so quickly? And what lessons do they hold for managers looking to deliver fast today? Patrick Collison of Stripe fame maintains a list of achievements, known all over the world, that were delivered very fast. For example:
Collison compiled this list to inspire teams that fast delivery is possible, and to contrast with civil projects today that are delayed due to bureaucracy. But I'm interested in what the common patterns are that allowed these projects to move so quickly in the first place. What was their secret? And what can leaders take away if they want to go fast themselves? DESIGN IN ADVANCE The Empire State Building, the Eiffel Tower, Disneyland, the iPod, the P-80 Shooting Star, and many other projects listed had very well documented detailed designs prior to starting build. Disneyland, for example, Walt Disney had been designing for years prior to getting started, as well as choosing where to develop and getting the permits, clearing as much out of the way upfront as possible before actually pulling the trigger on build. The designer of the P-80, Kelly Johnston, began working on it years prior as an internal development project when jet engines were first coming on the scene and he saw where the future was heading. He already had most of the design work already done, that’s why it only took 143 days to tweak it for the engines and systems to be used. Arguably even Javascript and Git benefited from a design upfront. A single person, Brenden Eich, first implemented the Javascript prototype in 10 days which the delivery team was then tasked with replicating for production. Linus Torvalds, the creator of Linux, had a very detailed idea for Git thanks to intimate knowledge of the code. In today's world of agile, teams get started on build with just a napkin sketch and figure out the rest along the way. There are good reasons for this too, but note that virtually all the projects on Collison's list had a strong vision for the project and many had an upfront detailed design. EXECUTIVE WITH DECISION-MAKING POWER IS STRONGLY INVOLVED Every one of the projects on the list had an owner or a senior executive fully dedicated to the project, involved and sometimes even micromanaging the details of the project. In today's terms, this is the Single-Threaded Owner role. Think of Steve Jobs or Walt Disney who were very closely involved in all aspects of design and delivery of their flagship products. This is in stark contrast with many projects that companies take on, who assign a team and a PM or director to oversee the work, but that PM and director are multi-tasking on other projects, and neither has much real authority compared to the senior leadership who are working on other things. HEALTHY BUDGET AND TOP TALENT It should perhaps be obvious that none of these projects were operating on a shoestring budget, allowing the projects to hire top talent as well as more than enough total people to carry out the work. The Empire State Building, for example, was able to hire the best craftsman from around the city. With the Depression looming, these craftsmen were looking for work, and the owners who had done well in the stock market were able to pay them double the going rate. The first iteration of the New York Subway employed 7,700 workers. The Pentagon construction was over $500M in today's dollars. In software there is merit in having lean teams, but there's no denying that when you add up design, development, security and operating costs of a large program - these are not shoestring budgets. PRE-FABRICATED MATERIALS The secret of the Eiffel Tower's quick assembly was the complete prefabrication of the 12,000 parts of the tower in Eiffel's workshops in Levallois-Perret, which had already begun during the construction of the foundations. There, all parts were calculated, drawn, cut, drilled, pre-assembled with rivets, then sent to the site and sent back to the workshop if they were defective. The Empire State Building was constructed using prefabricated materials, which were staged nearby for fast access and could be quickly assembled on site. The fabricated metal framing of the building didn’t require finishing on half the sides. Special window designs allowed for rapid installation. Even the COVID19 vaccines were not developed from scratch, but based on pre-existing mRNA research! In the software world, this is akin to using established 3rd party components, or even simply configuring a fit-for-purpose COTS product. WORK LIKE CRAZY? Almost every story on the list feature workers working 24/7. For example, workers who laid down the Alaska highway lived in tents by the highway for the 234 day duration. Each night they picked up and moved their tents to where they would need to continue construction the following morning. The Amazon team who created Prime pretty much lived at their desks for 6 weeks. Voluntary paid overtime can make a software project move faster, but this only works in very short timeframe (think: a 2-day crunch before a major deadline). Otherwise, study after study has shown that extra hours quickly become counterproductive, burning out staff and driving them away, as well as eroding product quality. Thank goodness it's not the early 1900s anymore. Some projects on the list employed more ingenuity than just brute force labor, such as rotating shifts around a 24-hour cycle. SELECTING THE RIGHT DELIVERY PROCESS FOR THE TASK AT HAND As Morgan Brown documents, the construction of the Empire State Building was done using a "fast-track" method, which meant that work on different parts of the building was occurring simultaneously, rather than waiting for one part to be completed before starting on another. Key to construction was the use of an assembly line process that employed up to 3,400 men per day who worked around the clock in three shifts to complete the building as quickly as possible. The contractors also had ‘just-in-time’ delivery down to a science. They had delivery times from the steel mills running so efficiently, that steel beams arriving on site were still warm to the touch. Delivery schedules were dialed into rigid 15 minute windows. Today in software, teams follow processes such as Scrum or Kanban. While these are industry standards, a lot of teams go through the motions by rote. But, as I document in 12 Surprising Facts About Scrum, Scrum doesn't want you to apply any process dogmatically. You should not be asking "What did I do yesterday? What will I do today? What is blocking me?" as a ritual in the standup, you should tailor the standup agenda to the specific needs of the project. You should not write user stories in the format "As a [person], I want [X] so that I can [Y]", you should write stories that best suit the unique needs of your project. Scrum wants self-organized teams to tailor their own processes to best suit the project, just as the workers of the Empire State Building tailored unique processes for their needs. MVP DELIVERY Many of these projects did not deliver the final product as we know it today, but rather an MVP that worked for 1 specific use case:
This parallels today's IT projects, where teams that want to deliver fast focus on delivering an MVP. The problem is that MVPs are often just prototypes that don't really have a strategy behind them. The team needs a very precise idea of who the MVP is targeted to, what is the "killer use case" the MVP delivers, and what are the minimum constraints that must be satisfied for it to be viable. LITTLE RED TAPE Collison makes the point on his page that many of these projects were able to deliver quickly because they were not mired in bureaucracy. I'm all for getting rid of red tape to empower teams to get work done efficiently. This is part of what a single-threaded owner must do, and whoever the project sponsor is. If on the other hand, Collison is trying to make the point - as some in Silicon Valley do - that the world needs less regulation and we'd be better off delivering projects as we did in the early 1900s, I'm not convinced. We're lucky to have the workers' rights and safety measures that we do today, and around the world we need a lot more of this, not less. The point is to deliver fast - using all of the documented lessons we've derived from high profile successes and failures in different industries - while increasing respect for people and safety along the way.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |