35 W Bridge Overview No one starts a software or engineering project with the intention of failing. In software, failures often happen in silence, which is the sound you hear when everyone abandons the new application to return to the tried and true, or to try something else they hope will get their work done more easily. When engineering failures happen, people notice. Planes crash. Rockets explode. Bridges collapse. Airlines, chemical plants, utilities, and pipelines suffer accidents and outages. What leaders do when these failures occur tell you a lot about what they value, and about the priorities they set for their organizations. The Keystone Pipeline debate is a contemporary example that pits the demands of the public for accident-free energy against the hard challenges of moving volatile forms of crude oil.
In connection with a conference I’ll be facilitating for a client next week, I’ve developed a case study on how the Minnesota Department of Transportation (MNDOT) reacted to demands for new quality and safety standards following the Twin Cities I-35W Bridge collapse of 2007. We’re using the case to stimulate discussion with a software implementation team on how MNDOT and its contractors created an innovative bid process, design rules, and project management approaches to address these heightened standards, and to meet a radical rebuilding schedule. By giving the rules an upgrade, MNDOT’s new bridge was finished three months ahead of the ambitious schedule, and won over 20 awards for innovation. The story of how they accomplished this feat may be useful to other organizations who desire better design capabilities that will promote speed, innovation, and reassurance to their stakeholders.
Interested in learning more? Check out the attached PDF article on the rebuilding of the bridge.