• Services
  • Blog
  • Contact

Make New Programs Succeed​.

Delivering Fast: How Some of the Greatest Feats Were Built In Just Days

3/26/2023

0 Comments

 
Picture
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:
  • The Empire State Building construction was started and finished in 410 days. 
  • The Eiffel Tower was built in 793 days . 
  • The Pentagon, the world's largest office building, was designed in 3 days and built 491 days later.
  • The Alaska Highway was built in 234 days (1,700 miles of military roadway total, connecting eastern British Columbia with Fairbanks, Alaska)
  • The first Boeing 747 was completed in 930 days.
  • Disneyland. Walt Disney's conception of "The Happiest Place on Earth" was brought to life in 366 days.
  • JavaScript language. Brendan Eich implemented the first prototype for JavaScript in 10 days. It shipped in beta in September of that year. 
  • Git was developed and self-hosting by Linus Torvalds within 4 days later, and launched 17 days after.
  • The iPod shipped 290 days after Steve Jobs greenlit the project. 
  • Amazon Prime was implemented in six weeks.
  • The New York Subway's first 28 stations opened and started within 4.7 years.
  • P-80 Shooting Star, the first jet fighter used by the USAF, was delivered in 143 days. 
  • COVID-19 vaccines ... well, you get the idea! 

​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:
  • The Alaska Highway, when first delivered, was nowhere near what we would consider a highway by modern standards. It was at best a gravel path that only military vehicles could use. Full construction would take several more years. But the MVP served its initial military purpose.
  • Disneyland's day 1 launch was a well-documented disaster. They ran out of food within a few hours, had no water fountains on a scorching hot day, and the rides were breaking down constantly. But the sheer amount of consumer demand it generated allowed it to establish itself and work out the many kinks over time. 
  • The first Boeing 747, when delivered, was really just a prototype, as was the P-80.

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.

    Categories

    All
    Artificial Intelligence
    Business Development
    Customer Intelligence
    Data Privacy
    Data Protection
    Demand Generation
    Growth Hacking
    Industry Analysis
    Leadership
    Market Opportunities
    Product Management
    Product Market Fit
    Program Delivery
    Project Management
    SaaS
    Strategy

Proudly powered by Weebly
  • Services
  • Blog
  • Contact