Arghhhh . . . When Doing Nothing Works Better Than Doing Something

It’s beneficial to determine the vital steps and questions behind a successful project so you can repeat them in the future. If a project doesn’t end as planned, it’s also important to figure out what was missed so you don’t have to re-learn a mistake. I've been doing a post mortem for a recent project and finding two frustrating lessons.

Both tie to an unexpected twist near the project’s end. The non-technical team (that would include me) was surprised by an unanticipated outcome that fell short of expectations. Our technically-oriented teammates, closely involved in the project’s design, were also surprised – surprised that we hadn’t clearly seen the (obvious to them, unexpected to us) detail in all the drawings and plans we'd reviewed for weeks.

So what happened?

In retrospect, the critical detail was in the drawings, but it was lost in a misperception of foreground & background. We (the non-techs) were looking at familiar & prominent images in the drawings, so the unfamiliar (and less prominent) detail moved deep into the background of our visual perception.

To compound matters, the non-techs drove a significant design change before the project’s start. Its ripple effects magnified the detail we’d missed once the project neared completion. Because we couldn’t perceive the detail, we didn’t realize our decision didn’t make sense. And since the techs couldn’t perceive that we weren’t visualizing the decision’s implications, they weren’t prompted to say it didn’t make sense.

The first lesson then is that there probably wasn’t any clear way to avoid the disconnect. Since neither group could perceive the potential problem, neither was able to ask a clarifying question or make a mid-course correction. I don’t think I’ve run into a situation quite like this previously. I’ll be more sensitive to this possibility in the future when working with a very proficient technical group, although I'll still be without a great question that could confirm everyone’s perceptions.

The second lesson? Much of my consternation about the project’s outcome took place just before its completion. While that’s usually a good time to view a project and correct last minute issues, it clearly wasn’t in this case. When everything was done fifteen hours later, the previous day’s glaring problem was barely noticeable within the finished project. The final steps re-oriented my foreground / background perception, allowing the problematic detail to fade into the background once more.

Short story, here are the lessons learned:

1. Sometimes there’s no way to perceive a potential problem to head it off, and
2. Sometimes reviewing a project before it’s completed creates more problems than it fixes.

While these certainly seem like valuable lessons, I HATE them both. So if you can figure out better lessons than these, ones that actually involve fixing something rather than simply waiting around to see what happens, let me know. I’d appreciate it!