When “Good Enough” isn’t Good Enough

So what is this picture? The unhelpful answer is that it is a photo of a sign with a burlap sack on it. I’d like to say that my community thought it would be a cute Halloween decoration, but I cannot. The truth: it is great example of the “good enough” anti-pattern.

Pulling the curtain back a bit further, I can tell you that there are legions of these in my neighborhood. Many months ago, road construction required some long term rerouting of local traffic flow, so a large number of detour signs were installed. Still months ago, the construction completed and the signs were no longer needed. The correct solution was to remove the signs; the “good enough” solution was to cover them with burlap sacks. It was, no doubt, quicker and cheaper: it solved the immediate problem.

As architects we frequently face “good enough” solutions employed to solve an immediate problem. Just as frequently, once the “pain” of the immediate problem has been relieved (or even reduced), the interest in implementing the correct solution fades. We have some strategies for avoiding these situations:

1. Strive for strategic solutions that meet tight budgets and timelines. Higher costs and longer timelines sometimes correlate with better solutions, but not always. Determining if a strategic solution can be implemented for the same (or close) impact requires that the project employ math to compare the cost and timelines, not emotion. The gut reaction of almost every project manager will be to assume the strategic solution will cost more and take longer. We have all been a part of “good enough” solutions that – not surprisingly – took much longer than expected to implement.
2. Probe the reality of the deadline. Frequently a “good enough” solution will be implemented to meet a deadline that is not as immutable as it seems; a deadline which shifts multiple times through assorted scope modifications. This can result in a spaghetti mess of a solution after spending more time and money than would have been spent doing it right from the start.
3. Help the decision makers understand the facts. Nothing is free. A solution cheaper than the strategic solution is cheaper for a reason. The project will carry more delivery risk, the solution will skip functional and non-functional requirements, or the enterprise will be less prepared for future technology needs. A business can always choose to make choices like this, but they need to be conscious choices.

None of this is to imply that there are not situations where a “good enough” solution is, well, good enough! The analysis associated in 1-3 above will identify those scenarios.

It is also critical that these non-strategic design choices be documented. We will also share some additional strategies for documenting and managing these non-strategic design decisions in a future article.

With regard to the burlap solution, I will keep you posted and share the outcome when one of the sacks blows off and unleashes a phantom detour…

Comments