“Can’t you just build it?”

I came across a cringe-worthy headline this morning that described a design mistake in the 520 bridge plan that will end up costing between $100-$200 million dollars. I pretty much knew what the article was going to say before I read it:

State admits costly mistakes on 520 bridge


“The state chose to design the pontoons itself on a fast track (rather than delegate that responsibility to contractors) as a strategy to attract lower bids and to get the floating section built by 2014, a timeline set by former Gov. Chris Gregoire.

Initially the strategy seemed to work, as the winning bid to build 33 pontoons at Grays Harbor, for $367 million, was $180 million less than the state expected to pay otherwise. But now, taxpayers and toll payers will surrender much of those savings.”

Where have I heard this before? Oh right, almost every project.

For some reason, clients and project sponsors–internal or external–seem to think that one of the easiest places* to save money is skimping on good project planning steps. This always, always comes back to bite the participants in the ass. I hate to use cliches, but “penny wise and pound foolish” and “if you fail to plan you plan to fail” are actually applicable.

As a PM, I’ve put together project proposals that include planning phase(s) and oftentimes they’re met with the attitude that proper planning and requirement gathering is unnecessary overhead, a buffer to pad the schedule, and/or a cynical way to squeeze more money out of the client. While these fears aren’t 100% unfounded and should be mitigated, the fact that subverting a solid foundation from which to build is a terrible practice.

This is where phrases like, “where did this dependency come from?” or “we didn’t know we needed accessibility standards and testing,” or “what do you mean it won’t work on our existing hardware?” are born.

The DOT creating the 520 bridge design in-house is common, and one of the less egregious examples of cutting corners. They saw an opportunity to “save money” and decided not to entrust the design to experts, who would have, I’m sure they assumed, gouged them. This isn’t uncommon, nor is it the worst type of offense. I’ve literally heard the phrase, “can’t you just build it?” in response to project plans. One proposal was met with something along the lines of how rather than spending money to plan what the product was going to be, we could just use that money towards development. These are sentiments from actual adults, and the saddest part about it is that I’m not surprised by it anymore.

While I’m a huge proponent of agile methodologies, one of their drawbacks is that some organizations see it as carte blanche to skip planning. This isn’t actually agile, but agile’s evil twin named “undocumented waterfall.” A good agile program does not skip planning, it plans constantly in multiple phases–the largest of which is at the beginning. For a great example, I just read an awesome blog about UX effort in agile  which shows the application of non-development effort in an agile environment–you know, planning how things should work before they’re built. Weird, I know.

I’ll end with the fitting quote from Paula Hammond, Washington Transportation Secretary:

“Everybody wants you to take risks, until something goes wrong.”


– k

*The other places are Testing and Project Management costs.


One response to ““Can’t you just build it?””

  1. Ryan says :

    *Outgoing/Fired/Resigned/Gone Transportation Secretary Paula Hammond

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: