I find that most upstream project errors occur due to simple misunderstandings. Although I always try to ask all the relevant questions early on, there are almost always gaps in what I’m really trying to learn, and sometimes there are subtleties in terminology that mean very different things when being translated from business requirements into technical specifications.

Last week, we had a project extended slightly to support an additional locale. The engineer responsible for the project gave me two options: one simple (but inelegant) and the other sophisticated (but time consuming). I asked the client if they had a preference between the two, but rather than explaining how this impacted the business aspects, I pretty much laid it out as “hack vs elegant”. The client opted for the more elegant approach, which we began.

I took a walk to ship something from the UPS store. On my way back to the office, a car pulled up next to me and a woman asked “How can I get out of Redmond?”

Being the helpful citizen, I replied, “Pick a road and don’t make any turns.”

She smiled—patiently—and asked me how to get to SR-520, the nearest highway. After all, this was the question she really wanted answered. She was two blocks away, so I obliged and gave her the info she really wanted. I’m pretty sure that worked out fine.

Anyway, I rushed back to the office and called the client again. This time, rather than asking the “hack vs elegant” solution, I explained how the decision we were making now would impact the way we would extend the project in the future, and asked the client where they saw the project evolving to. As it turned out, the client had upcoming features I hadn’t accounted for, and the “hack” approach was actually the more elegant option because of the feature requests we would receive once we finished off the current round.

The moral is simple: ask the question you really want answered. It makes life a lot easier down the road.

5/1/2007 10:02:13 PM (Pacific Standard Time, UTC-08:00)      Comments [0]