Costly mistakes you'll value: Part Two

Here is the Part One version of this article.

Picking up where we left off

Ever get busy and months go by? Happened to me. Here's Part Two just a wee bit later!

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. So, where do we go from here?

I recently read "How Big Things Get Done" by Bent Flyvbjerg and Dan Gardner, a book focused on exploring why large projects tend to fail while also exploring the characteristics of those big projects that defied the odds and got it right. Where "right" is defined by a project completed within the estimated timeline and budget while delivering at least the value intended. What is truly fascinating about this book is the database built by the authors that originated from collected metadata covering 16,000+ projects - it's the largest project database in the world.

Moving Forward: Interweaving Value, Technology, and Projects

In Part Two of this blog, I want to explore the intersection of Value and Technology with the lessons I learned from "How Big Things Get Done" to offer a series of perspectives that should inform technology leaders in how they design and initiate technology projects. Buckle up as I'm going to challenge multiple approaches and weave in a few perspectives on how we might reframe some of the problems we often encounter in the information technology world.

Framing the Problem

A business stakeholder comes to you, an IT Leader, and states: "I need a dashboard that shows me how the systems in our facilities are performing, and I need it to tell me when something has gone wrong." As a technologist and data lover, these words are music to my ears. It's easy to begin thinking about a data warehouse (or lake) where we can collect data and build modern analytics dashboards with widgets and graphs galore. Sign here - let's get going. Did I trigger another one of those "what's the catch moments?"

In the early 1990s, the Basque government approached the Solomon R. Guggenheim Foundation proposing to fund the construction of a Guggenheim museum in Bilbao's then decrepit, yet once flourishing, port area [1]. They ultimately selected architect Frank Gehry, who visited Bilbao and met with the group spearheading the project. Rather than take the request at face value, he spent time understanding the museum's intended purpose and vision asking numerous questions and challenging the committee's thinking along the way.

Museums offer the opportunity to interact with items containing historical, scientific, artistic, and/or cultural value. We could leave our understanding here, or we go further to understand that the Bilbao museum project was meant to revitalize an economically depressed area and this museum could be so much more than a house for relics. Its very design alone could revitalize a declining area. Mr. Gehry took a moment to understand the true need and ultimately designed a museum that incorporated the environment, the lighting, and the flow of a people creating a now world famous structure that serves a purpose far greater than a container for precious artifacts.

Mr. Gehry spent the time to understand the problem and reframed the ask. Similarly, our business stakeholder would likely benefit from a solution and approach that could do far more than provide diagnostic and descriptive analytics in a dashboard. Reframed, the true value is moving the solution toward one that could identify when facility issues might occur allowing proactive remediation vs. reactive disaster recovery.

Value Principle #1: Budget for the time and resources necessary to truly understand the problem or opportunity space at hand. Chances are, you only think you know what problem you're trying to solve or opportunity you're trying to capture.

Planning

I love the world at the intersection of Operational Technology (OT) and Information Technology (IT). The marriage between hardware and software is a beautiful one. However, hardware is a bit like construction - there is a strict(er) tangible outcome as change is often expensive and timely.

Software, on the other hand, enjoys characteristics that afford development methodologies like Agile to exist. In short, Agile allows teams to work in small, iterative chunks where each iterative chunk must produce working software components. However, business and customer needs can allow the team to change direction based on evolving needs and priorities - much like a flock of birds changing direction. This "agility" is designed to prevent building something that simply fails to meet user's needs. Idiom 1: "building the plane while we're flying it."

On the other side of the coin is the Waterfall approach, one that on the face of it might lend itself to an approach Flyvbjerg and Gardner would celebrate. The Software Development Lifecycle or SDLC prescribes a very structured process where requirements and planning happen before a single line of code is written (slight hyperbole applied for effect). The assumption is that the requirements and design are understood well enough to go forth and build.

One of my key takeaways from "How Big Things Get Done" was the emphasis on planning and its impact on successful projects. The authors went to great lengths to share the anecdotal aspects of Frank Gehry's efforts to realize the Guggenheim Bilbao museum. From simple sketches to physical models to a software package that allowed for the entire design and construction manifest creation. Before a single construction activity began, the entire approach to building the museum was planned. The result - an on-time and under budget project.

My Waterfall fans will feel validated and celebrated with this outcome. The Agile software development community might suggest this detailed approach to planning would be a poor(er) use of money as the expectation is needs and wants will change throughout the life of the project and software development affords us the ability to change more easily than modifying the architecture and engineering of a building. So, we should allow for this change and minimize the upfront planning investment. If we go back to Part One we might be tempted to call this type of planning "expensive."

More often than not my clients will embrace one approach or the other. Waterfall or Agile. Both have merit, but Idiom 2 provides us the way forward: don't put all of your eggs in one basket.

Software development is a special kind of animal. Well built software affords changes in ways that changing the architecture and structure of a building do not. Equally, knowing where you're going will minimize cost, time delays, and risking an unusable outcome because nothing was ever finished due to constantly shifting priorities. So what eggs are we putting in what basket?

The answer lies in Product Management. First, this requires shifting your mentality from a project to a product. Rarely in my world is something built that is meant to have an end. Software is built and then must be maintained and often improved after users use it and their needs change over time (admittedly software is retired, but usually long after original expectations). Second, product management is a separate group within the delivery landscape. Users inform the Product team what is needed. The Product team synthesizes and prioritizes these needs ultimately setting the north star. The Development team then fuels their Agile processes with direction set by the Product team. There are books written on this, so I'll skip going deeper here.

"How Big Things Get Done" challenged my thinking as the type of planning celebrated in the book would be difficult in the software world. Similarly, no planning has equally poor outcomes.

Value Principle #2: See your technology projects as technology products. Invest in a product team that creates the third leg in your stool (users, developers and testers [the full gambit here], product owners). This essential team is an investment, but provides value through balancing the absolute planning that drives rigid outcomes with the agility that lets you more easily meet customers' shifting needs and priorities without the risk of never getting anything fully done.

Recap: Laying the Groundwork for a Grand Finale (Part 3)

So far, we've challenged the word "expensive" as a single-dimensional concept that fails to incorporate value concepts. We parlayed our value concept and lessons from "How Big Things Get Done" into a business case for investing in truly understanding the problem before diving in with technology solutions (build me a descriptive analytics dashboard showing real-time problems vs. build me an analytics platform that can help me predict those problems). Finally, we've explored the value of managing the polarity between planning everything up front and going full-tilt agile where constant change precludes (hyperbolically) anything getting done through incorporating Product Management into the technology build process.

In Part Three, we will shift our focus forward to managing a technology portfolio (not of projects but of technology selection), understanding how we manage value through recognizing work complexity, and bringing all these concepts together into a set of recommendations to guide you in managing a technology program.

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

Bibliography

[1] “Guggenheim Museum Bilbao.” Wikipedia, Wikimedia Foundation, 5 Mar. 2024, en.wikipedia.org/wiki/Guggenheim_Museum_Bilbao.