Navigating Software Projects across the Bermuda Triangle — Lessons from How Big Things Get Done

Imagine this: You’re deep into a massive project, your original timelines are a distant memory, your budget got bloated but still managed to vanish into thin air and the promised benefits seem like a mirage. Sounds uncomfortably familiar? If you’ve ever worked on large ambitious endeavors, there are excellent chances that you have swam trying to keep your project afloat in the Bermuda triangle of time overruns, cost blow-ups and benefits falling short. Organizations invest a lot in ‘program management’ wizardry to keep their initiatives in control but keep getting frustrated.

Bent Flyvbjerg is someone who has tracked and helped manage mega-projects more than most of us. As a researcher, he has compiled a huge database of big projects in various industries with details on the planned vs actual timelines, costs and benefits. As a practitioner, he has worked with companies and governments to get projects back on track. His book “How Big Things Get Done” has the lessons learned both from the data and the practice. My key takeaway from Flyvbjerg’s book is a paradigm shift in project management philosophy. He emphasizes that, while substantial efforts are typically invested during project execution to regain control, it is often too late at that stage. The crux of successful project management lies predominantly in the planning phase, but not just any planning but ‘active planning’ that goes beyond traditional project proposals and budget spreadsheets.

While the book primarily discusses infrastructure-related projects, its insights hold valuable lessons for those involved in crafting technology solutions and overseeing digital transformations. We’ll explore the universal principles provided in the book and examine how to adapt and implement them within the context of software development and product management. In the end, we will also discuss some tough problems that need other approaches to manage.

Learnings

1. Be clear on the “why”

Projects aren’t goals in themselves. Projects are the means by which goals are achieved. While this should be straightforward, it is surprisingly challenging in practice. An easy test to validate this: Try asking different folks working on any project on what the end objective is and see how different their answers are. Establishing a clear and specific goal is the first step in any big organizational endeavor. A good goal would be one that is problem focused and not solution specific. A good goal would allow sufficient exploration of the solution space before deciding on what should get built.

From the perspective of building software, this translates to being very clear about the business goals, customer & user goals and problems, and the targeted change in each of these as a result of the project being proposed. Being explicit about these aspects aligns stakeholders before and during project execution, making it easier to prioritize tasks and reject competing new work. Amazon’s PR-FAQ based working backwards approach is an example of how this “why”-driven approach can be translated to the real-world.

Another practical way to check if the “why” has actually been thought through or has only been paid lip service is to check the PRD for a planned feature. Often, you might find a small section on the current state with some metrics defined but left blank and uncalculated, followed by a description of the proposed solution without any analysis of the various options considered. These are clear signs of starting to build something without understanding the problem in depth yet.

2. Plan actively

Instead of thinking of plans being the typical gantt charts and resourcing spreadsheets, Flyvbjerg wants us to reimagine the planning process to essentially cover all aspects of a project that come before the expensive parts. In the book, Flyvbjerg details Pixar’s movie development process to illustrate this. The most expensive part of Pixar movies is the high-definition frame-by-frame rendition of the animations, using stars for the final voices and the professional music score. But the key risks in animated movies are related to the story and the script. By iterating multiple times (8–10 times if needed!) through each prior step of the process — from story outline to script to detailed storyboards and non-professional voice-overs using only a few folks and expert feedback, they are able to shelve ideas or rework them before spending the big money.

Applying this approach to software development, the “plan” should include the following.

• Recognizing that the most expensive phase is when engineers start building things. The solution exploration, design, analysis and solution validation phases are cheaper. Building a “maximum virtual product” (a different type of MVP, so to say) should be a key goal of the planning phase.
• Leveraging the knowledge of the team to poke holes into the solution and surface risks upfront (more on this in #5). Identify which ones are important to be addressed and build the mitigation into the program plan.
• Removing any illusions on engineering feasibility by identifying the riskiest parts of the solution and validating those upfront through tech proof-of-concepts.
• Knowing if the solution is viable. Estimation of the marginal cost of the solution being built (both the initial cost and potential lower costs with optimizations in the future) and the potential to increase prices or decrease any other operating costs should be part of the plan.

3. Identify your project’s lego blocks

A very insightful chart in the book shows the deviation in planned vs realized timelines and cost by sectors. The highest escalations occurred in the infra construction for conducting Olympic games, building nuclear power plants and building IT systems. The lowest escalations (where there were even examples of projects getting completed within budget and before timeline) were wind power projects and solar farm installations. The worst offending project categories are characterized by monolithic architecture and by their one-time nature making it difficult to convert learning that arises during execution into improvements in subsequent phases. Conversely, less risky projects, such as wind and solar initiatives, emphasize modularity, with factory-based manufacturing of core components and simple on-site assembly. For example, in solar projects, the assembly process involves arranging identical solar cells into panels, stitching panels together to create arrays, and assembling arrays into solar farms of varying sizes, simplifying the overall execution.

From a software organization’s perspective, it might not be immediately obvious what the legos can be. Software is distinguished from physical infrastructure through its zero marginal cost distribution. So pretty much each new software development project should involve creating something new. But legos can be seen in surprising ways.

• Platformize reusable components: Larger companies with multiple products can benefit from creating reusable components, such as user authentication services, payment systems, or discount engines that can be used across various products.
• Dedicate some bandwidth to building tools that free up the core teams to focus on what matters. For example, these can be self-serve tools for marketing teams to manage content on the website, building test automation to make development cycles shorter and implementing monitoring & analytical tools.

4. Keep the execution window short

Given enough time, everything that can go wrong with a project will go wrong. Organization’s strategic priorities can change, people quit, competitors do something disruptive that need to be responded to, … The “fat-tail risk” encompassing what all can go wrong will be very long. A key way to mitigate this is to keep the actual window of project execution as short as possible. Software, fortunately, is malleable and upgradable, making this achievable.

• Control scope and be “agile”. Divide the execution process into smaller, manageable phases, with releasable software at the end of each phase. While choosing to build a Minimum Viable Product (MVPs) may not always be suitable, especially for consumer-facing applications that aim to deliver a rich user experience from the start, it’s essential to break down development into smaller phases. These interim software versions should, at the very least, be usable by internal test users or beta customers.
• Have dedicated teams available during execution. For the engineers working on a specific feature or sub-module, it should ideally be the only thing they are responsible for during a sprint cycle. This reduces distractions and keeps the teams more accountable.
• Preemptively address dependencies — Identify and resolve dependencies before the execution phase begins. These dependencies can be external, involving vendors and partners, or internal, such as collaboration with other engineering teams, infrastructure teams, finance, or legal departments.

5. Create an empowered and “experienced” team.

Very rarely does a project fail due to a problem that was not anticipated by someone in the team. Creating an environment where everyone feels free to ask questions and challenge the prevailing wisdom can go a long way in surfacing risks. Enabling mechanisms for doing this like Pre-mortems can be a structured approach to create such comfort zones while also being outcome-oriented.

Teams that manage to stay together across multiple releases create their own rituals to solve problems. This is a way in which the “experience” becomes relevant and becomes a lego block in itself.

Tough Problems

While the above guidelines can really help in taking control of big initiatives, there are certain aspects of building things where this might not help much. It is useful to be aware of these to apply the guidelines in the right context and not get blindsided.

1. Strategic misrepresentation during planning:

This is the intentional understatement of estimates or inflation of potential benefits to get a project approved or an initiative started. It can happen due to a few reasons.

• Politics: Starting projects involves assigning resources to teams and individuals. Having resources is a source and sign of power. Wherever there is power, there is politics. In typical organizational settings, stopping things that are in progress is an order of magnitude more difficult than starting new things. Ambitious folks understand this and try to get things started by securing necessary approvals through lowballing estimates if that helps.
• Culture: Plans are created not with the intent to actually deliver but to get the blessings of the powerful person who needs to sign it off. “This aggression is what the leadership will like” then becomes the easier and practical route for managers to take rather than bringing up the unknowns & risks and having a tougher conversation on why something will take more time.
• Competition: This is more common when involving vendors for integrating their solutions. There will almost always be multiple vendors that will bid and timelines and pricing will be key aspects in the evaluation. This can result in problems that vendors know will surface during the project to hide behind in T&Cs and Assumptions.

The fundamental aspects that enable strategic misrepresentation are the lack of sufficient scrutiny of plans to identify the flaws and the difficulties in ascribing accountability for delays and failures that are detected later on during execution.

2. Building truly new things:

The principles and guidelines discussed here will be of limited help in building truly new things — like self-driving cars or the metaverse. Developing groundbreaking technologies and creating entirely new markets often necessitates a more significant focus on research and development (R&D) and experimentation. These endeavors require a “plan-to-build” approach rather than a “plan-to-implement” perspective. However, even in moonshot initiatives, a significant portion of the project often involves solving more practical and grounded challenges.

3. Strategy and ongoing planning:

Most of the lessons here are applicable for projects and initiatives that are well defined and boxed around by scope or time. From a software perspective, the learnings will be directly applicable for one-time projects and development of specific features, but less suited to guide ongoing work such as managing product roadmaps. Product roadmaps typically involve iterative cycles of feedback and continual improvements, pursuing diverse goals at different stages in a product’s lifecycle.