I’ve researched and consulted on megaprojects for more than 30 years, and I’ve found that two factors play a critical role in determining whether an organization will meet with success or failure: replicable modularity in design and speed in iteration. If a project can be delivered fast and in a modular manner, enabling experimentation and learning along the way, it is likely to succeed. If it is undertaken on a massive scale with one-off, highly integrated components, it is likely to be troubled or fail.
Unfortunately, in conventional business and government megaprojects—such as hydroelectric dams, chemical-processing plants, aircraft, or big-bang enterprise-resource-planning systems—the norm is still to build something monolithic and customized. Such projects must be 100% complete before they can deliver benefits: Even when it’s 95% complete, a nuclear reactor is of no use. Components are typically bespoke, with a high degree of specificity rather than modularity, which limits opportunities for learning and increases the costs of both integration and rework when problems arise. New technologies and customized designs are common, which further hinders speed and modular scale-up. What’s more, the size of megaprojects is typically specified many years before operations are slated to begin. That spells disaster.
… To entrepreneurs in the tech industry, much of this will sound familiar and logical. But large corporations and governments have yet to internalize these lessons for big-ticket projects. To be sure, many megaprojects—such as bridges or power plants—are unlikely to ever be completely modular, but there is still plenty of scope for choosing technologies that enable rapid scaling and introducing modularity by applying tried-and-true technologies in innovative ways.
That was from the excellent Bent Flyvbjerg writing at HBR, Make Megaprojects more Modular. Read the whole thing, interesting throughout. He provides a few examples of how big projects were successfully modularized, like Tesla’s gigafactory, Madrid’s metro, wind farms, and Planet Labs satellites. Take these to the bank whenever someone says that modular development is fine for small IT projects but not for big projects.
Flyvbjerg also provides an example of how not to do big projects, like Japan’s Monju fast-breeder reactor:
At Monju, everything was done just once, with extreme complexity. That created a phenomenon that operations experts call negative learning, a dynamic in which learning slows rather than accelerates progress. The more the Monju team learned, the more obstacles and additional necessary work it identified.
Leave a Reply