About Bridges, Software, and Failures by Juan Hidalgo

3 Min Read

A long time ago, I was discussing with an old friend/colleague about how to document and manage the experience that we got in a previous Project for the European Commission. The main reason for the discussion was to avoid falling into the same mistakes again. My friend recommended to me a “must-read”, a paper from a well know VP of Research in Google, Alfred Spector.

Bridge illustration by Ryan ConnollyIllustration by Ryan Connolly

Alfred Spector, was co-author in 1986 of a scientific work, where he compared bridge construction with software development. Alfred Spector, for those who do not know him, was Director of the ITC (Information Technology Center) at Carnegie Mellon (off the record, the University of my dreams), VP at IBM, VP of Research at Google, and from 2015 is CTO at Two Sigma.

Alfred Spector determined that when a bridge collapses, or has technical problems, it is immediately investigated, being perfectly documented the causes that have originated that situation. That information, and the result of the reflection on what could have been done better, offer us a series of decisions or actions to prevent similar situations in future bridges.

This report, as part of the Requirement Analysis, is the first document to be consulted when the design of a new bridge begins to be discussed.

Unfortunately, mostly times we are not doing this one in UX projects. This is mainly due to a lack of procedures or methods to investigate failures, which it is translated into a problem of coordination of actions.

The lack of error analysis processes, generates that these errors can happen again and again, and they have a negative and proportional impact on future projects

The NO investigation and adequate reflection leads to a complicated sequence of actions (timeline):

  • Making decisions becomes difficult
  • The same mistakes are made again and again
  • New errors appear, leading to inadequate decisions
  • The economic cost comes out of the forecast
  • Delivery dates are not met
  • And the characteristics delivered do not match to the expected ones
  • Cancellation of the Project

It is true that UX Projects have many differences in its approaches to the bridge construction, but what Alfred Spector tries to make us see, is how the investigation of past failures, must articulate the decisions of future Experiences.

My friend told me that he was using the conclusion of that paper, as a very important part of the RA. Describing and highlighting, what worked and what did not work in the previous project. Summarizing the approach:

Sooner, rather than later — learn, recognize, and document the mistakes of the last project, they will be the first requirements for your next successful project.

Final suggestion

From the exploration and investigation of our failures, a valuable knowledge is generated that will bring us wisdom as the basis of our future successes. The rest is pure and ephemeral arrogance, based on “false positives” of expertise.

References

[Project Smart.co.uk] The Standish Group Report: CHAOS

[IAG Consulting] Business Analysis Benchmark 2009 Report