Costly Mistakes You'll Value: Part Three

Bringing it all together

In Part One of this blog post, we explored scenarios meant to challenge our perceptions of what is and is not "expensive." When looking at the cost alone, it's easy to point to the "thing" that costs the most money as expensive. When we bring in value considerations, we find the most "costly" thing isn't necessarily the most "expensive" thing as the value or return on investment matters. We also recognized that this isn't exactly groundbreaking insight.

In Part Two of this series, I delved into integrating value and technology lessons into practical advice for technology leaders based on my takeaways from How Big Things Get Done by Bent Flyvbjerg and Dan Gardner. By examining the meticulous planning that contributed to the successful completion of the Guggenheim Museum Bilbao, I emphasized the importance of understanding the full scope of a project before starting execution. I advocated for viewing technology initiatives as products rather than projects, necessitating ongoing development and management to adapt to changing needs, which balances thorough planning with the flexibility afforded by Agile methodologies. Finally, I tied the post back to Part One by demonstrating how this approach drives informed, value-driven decisions rather than just cost-based ones.

So where do we go from here? We've reoriented our minds from cost to value, and discussed the importance of investing the time to understand a project's (or product's) needs before starting it to drive successful execution. Another key factor How Big Things Get Done emphasized was the "what." What materials, architecture, and engineering know-how were applied to a project that led to successful outcomes. As a technologist, I would be remiss not to tie that same wisdom to technology selections and portfolio management. And somewhere along the way I might hint at another article brewing in my mind.

Been there done that

Flyvbjerg and Gardner realized in their vast project research that those projects using tried-and-true materials and technologies excelled at delivering projects on-time and on-budget. The book referenced New York City's The Empire State Building as an example. Arguably the most famous building in New York City, it was built in 1 year and 45 days[1]. Flyvbjerg and Gardner dug into what made this possible in an era where mechanization and automation isn't what it is today. They found that the designers chose known materials and engineering, which meant they were building with known-knowns from day one. Then they went on to master the art of building a floor - repeating the process over and over - 102 times. Flyvbjerg and Gardner also integrated the "known-known" concept with the successfully executed Bilbao Guggenheim museum, which used all manner of unknowns in materials and design. The difference? They experimented and tested - starting at a small scale and intentionally expanding the scale once the unknown became known.

These same principles (using known or experimenting to make the unknown known) is equally critical in the realm of technology projects. Here, the temptation to innovate is ever present with the rapid pace of change often leading teams to veer into uncharted territories, risking project timelines and budgets. In technology, just as in construction, the foundation of a project should be built on well-understood, proven technologies and architectures that ensure stability, reliability, and deliverability. This approach not only mitigates risks but also enhances the scalability and maintainability of the technology solutions delivered. But where's the fun in that?

However, innovation is also a key driver of technological advancement and cannot be entirely sidelined. The challenge, then, is to find the right balance—integrating cutting-edge technologies in smaller, controlled portions of the project, where they can be tested and validated. This strategy allows for the exploration of new tech while relying on established methods and architectures for the core functionalities of the project (or product). By treating technology adoption as a portfolio of knowns and unknowns, organizations can effectively manage risks while fostering innovation. This dual focus ensures that each project advances the technological frontier responsibly through careful vetting and experimentation, and securing the project's success and sustainability. May you build something with tech that mirrors the beauty and innovation of the Bilbao Guggenheim Museum.

Rethinking value

When integrating emerging technologies into projects, be wary of the Tech Sirens calling you toward the rocky shoals. You must realize the value promised by realizing a successful project. Therefore, for the most crucial parts of your technology stack, it's wise to rely on tried and true technologies and architectures. These are the elements that ensure your project's backbone is strong and capable of supporting the functionalities expected of it.

Equally, stealing an adage from the business world, if you aren't growing, you're dying. Investments in emerging and innovative tech is a must. This also brings you much needed value when done right. However, remember the Sydney Opera House (see Part Two).

In cases where emerging technologies align with the project's value proposition, consider their integration carefully to manage cost, risk, and value effectively. Start with incorporating new technologies in non-critical, peripheral features where they can be tested and iterated upon without jeopardizing the entire project. This approach aligns with the principles of modular design, eloquently described by my colleague Sean Beard as "loose coupling, tight cohesion." This method ensures that new technologies are sufficiently isolated, allowing for easy adjustments or removal if they underperform, minimizing potential negative impacts. As mastery over these new technologies grows, their integration into more significant parts of the project can be expanded, cautiously increasing their scope (perhaps in future projects). This gradual, measured approach not only safeguards the project but also paves the way for more confident and extensive use of innovative technologies in the future. To quote my Amazon Web Services (AWS) friends, "there's no compression algorithm for experience." It takes time and deliberate practice.

Portfolio management

So what is the right balance at the project level? The program level? The portfolio level? Let's think back to Part One. How do you ensure that your project's or product's "customers" are thinking "this is valuable" vs. "this is expensive?" By providing them what they expected and needed within the timeline and budget promised.

So, consider your timeline for providing value for the project's investment. How soon must you deliver? More specifically, how soon must you deliver those parts where expensive becomes valuable? Where can you carve off space for experimentation?

Begin by designing an innovation initiative composed of scope, schedule, and budget (Project management triangle for the win). Where you have space to prove out innovative design and building techniques (see the Bilbao Guggenheim Museum, but with technology). In short: design the innovation maturation path. Pick a use case, design for modularity, and build it. Develop your metrics (quantitative AND qualitative - what does success look like?). Remember: not everything measuring value does so with numbers. Plan your route to quickest failure (see Google's X Moonshot Factory), document the outcomes, share the knowledge, and begin integrating into the project or product based on your investment and risk thresholds.

Now repeat and expand. Assess these same options across your collection of projects and products. Seek opportunities to share the risk and investment cost by exploring innovative technology and approaches that benefit many. Aim small. Miss small. Share. Integrate outcomes. Repeat.

Of course it's not that simple, but the key takeaway is that innovation investment decisions should be weighed at the project level, program level, and portfolio level. That risk multiplies if not managed collectively. The value created also multiplies because you're making deliberate decisions, minimizing blast radius, sharing the knowledge, increasing the experience, and enabling future integration with innovating tech at the portfolio level. Take that "expensive."

If you think hard enough about this approach, you might start to ask: why must I "transform" if I'm continually iterating and integrating new technologies into my projects, programs, and portfolio?" I'll save my thoughts on that question for another article (hint, hint).

Conclusion

It's all so simple, right? Putting naiveté aside, ...

Converting expensive to value takes work. You have to continuously resist the temptation to jump on the latest tech bandwagon for fear of being perceived as "legacy" or "outdated" while selectively choosing where to move unknown tech to tried-and-true. You have to invest the time to understand your projects and products. You have to make the core of those items based on tried and true. You have to deliberately select the innovation, experiment, learn (e.g., skillset building), and scale over time. This is a muscle, and it must be worked over and over. May your technology gym efforts become the source for future How Big Things Get Done success stories.

I welcome your thoughts on this, so please share comments or reach out to discuss more. I wish you success in converting "expensive" to "valuable."

I do not participate in Amazon's affiliate program and receive no proceeds from linking to the "How Big Things Get Done" book.

[1] “About the Empire State Building.” About The Most Famous Building in New York | Empire State Building, www.esbnyc.com/about. Accessed 29 Oct. 2024.