Knowing When To Stop October 30, 2009Posted by Chuck Musciano in Leadership.
Tags: Leadership, Management Skills, Project Management, Software, Teams, Users
A recent issue of Wired had a great article on the concept of good enough: when products meet enough needs that consumers are happy. The author gave several examples of good enough: MP3s instead of CDs, Flip cameras instead of high-end video cameras, and even Predator drones instead of manned fighter jets. In each case, the product is woefully short of perfection, but is still so useful that the perfect alternative is being sidelined in the market space. (As an aside, you may not need to read the entire Wired article; for many of you, my summary will be good enough).
The idea of good enough is certainly not new, and is simply the latest incarnation of the 80/20 rule. Unfortunately, I think many of us who understand the 80/20 rule are still struggling to implement it in practice. It turns out it is really hard to know when to stop.
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. This is true for everyone in the development stream: the business analysts, the designers, the infrastructure people, everyone. At some point, they are spending too much time on a project, expending effort that will not result in proportionally additional value. They need to let go and move on.
[Note that this is not true for testers. There is no 80/20 rule for testers. They need to test 100% of the 80% that has been built. More on this in another post.]
The problem is that no one knows when they have reached the eighty percent point. Very few projects have a bounded definition that makes it easy to see when enough is enough. Even when you do have such a bounded definition, user-induced scope creep can easily push that definition further and further out, dragging the eighty-percent point along with it.
It is often the case that a team will unknowingly extend the scope of a project as they work through the details of the spec. Seemingly appropriate questions lead people down paths that occupy way too much of their time. Everyone in the room knows how they got there, and why they are discussing some arcane feature, but no one was able to throw the flag and stop the process along the way. It all seems to make sense at the time.
That’s when you need a “sudden interrupter:” 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. 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.
I doubt that many people carry the title of Sudden Interrupter, but I’m beginning to think we need a few of them wandering about. Gentle challenges during any decision-making process are generally helpful, whether you are designing software or refining a budget. If nothing else, having to explain “why” to an outside observer is a constructive, cathartic exercise. So, go help someone. Interrupt them!
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio124″ only_single=false]