How Do You Know When Software Is 'Good Enough'?

Ann All

When I wrote about the idea of "good enough" technology earlier this month, it was in the context of buying enterprise software and hardware. The idea is to buy technology that might lack some features, but contains the ones that are really important to your company, thus saving money by not buying bells and whistles you don't need.


Of course, there's a possible snag in this process. It should be fairly easy to throw out technologies in the "not even close" and "wildly unnecessary" categories. But how do you differentiate between "good enough" and "close, but no cigar?"


Recognizing "good enough" is even more of a challenge if your company is developing software, either for its own use or for a customer-facing application. Writes Chuck Musciano on The Effective CIO blog:

In a world of dwindling development resources, knowing when to stop is crucial to providing maximum service for the minimum investment. The moment a developer begins working on the eighty-first percentile of a project, they have gone too far. They need to be pulled off and turned loose on the first percent of the next project.

And going beyond "good enough" tends to take IT projects off the rails, as business professors Chris Sauer, Andrew Gemino and Blaize Homer Reich (and many other researchers) have found. As part of a 2007 study on project failure, they wrote:

Ambitious-sized projects, moving targets and managerial turnover present challenges for IT projects that stretch even experienced project managers and result in greater variances. Effective oversight of projects can help project managers respond to these challenges.

Yet few projects feature the kind of definition that makes it easy to see when "good enough" has been reached, notes Musciano. Even with such definitions, "user-induced scope creep" tends to extend projects beyond this point. (Moving targets, anyone?)


He suggests bringing in what he calls a "sudden interrupter," which he defines as "someone who comes to the process late, has not been a part of the incremental walk, and can easily see that things are off track." What does a sudden interrupter do? He writes::

They provide a bit of cognitive dissonance that allows the team to reset, regroup, and reassess what they are doing. Even if the group decides that they do want to continue their discussion, the pause allows them to confirm that they are on the right track.

That sudden interrupter should probably be a business owner who hasn't been a regular part of the project team, based upon a short list of project-management best practices I pulled from Baseline. Companies should regularly assess projects to ensure they still satisfy business needs and are running smoothly. As part of these assessments, a business owner should substantiate the value, suggested Mike Sisco, an IT consultant interviewed by Baseline. Without such substantiation, a project should be scratched.

Add Comment      Leave a comment on this blog post
Nov 2, 2009 12:30 PM Raj Menon Raj Menon  says:

Interesting post. The idea of having a "Sudden Interrupter" to introduce a continuous third perspective, leans a lot like leaning towards an agile project management framework. You are correct that it would be best to have the Business owner be the SI, as in case of a SCRUM team involving the Product Owner to shed light on project health, unassumingly.

Once again, a good and thought provoking post. I am glad to see Chuck's writing being referenced. He is one who I follow ardently on twitter @EffectiveCIO.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.