Knowing When To Stop October 30, 2009
Posted by Chuck Musciano in Leadership.Tags: Leadership, Management Skills, Project Management, Software, Teams, Users
trackback
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]
The Effective CIO 
I remember a Microsoft developer saying that a trait he looks for in programmer is the ability to manage the balance between doing things right, and doing them right now. In most cases perfection is indeed the enemy of good enough.
Though we don’t have anyone with the “sudden interrupter” title, we often use a member of the exec team championing a project for this role. They understand the project but don’t regularly get involved in the details. As a result, they are often able to come to meetings when things are off track reset the focus. Sometimes its a simple concession on features and other times it’s bringing up work arounds to some issue those emersed in the project came to believe was a must.
Slightly off topic, but I’m curious to see how you feel this doesn’t apply to testing. In my experience, the same issues exist there. In any system of even mild complexity, the test landscape is too vast to cover all possibilities. In this case you’re mitigating risk (of going live with something with a serious flaw) versus never going live at all (due to too much time spent testing).
I also think that the executive sponsor is a good sudden interrupter. They have a high-level grasp of what they are trying to accomplish, they are often astounded at the detail that results from that vision, and they have the clout to eliminate features quickly.
As to testing, come back on Monday…
A Trusted Technology Partner and Strategy Consultant makes for a very good “Sudden Interrupter”. They are totally unbiased and do not have to keep score or worry about emotions of the players involved. I know of a few good ones..
Good Post Chuck. Very similar to the concept outlined in the Innovators Dilemma where lower quality steel production from Nucor ended up taking over the industry of what “had to be produced”. I like the idea of the executive sponsor coming back and reviewing where things are. One challenge I see, however, is that sometimes the vision of the executive sponsor is not being met because they did not realize how much detail was required to achieve their vision. They need to be astute enough to understand that when it is good enough versus what they greatly desired in the first place. If they can, great. If not, they will drive the project deeper into the last 20% than the developers. Thoughts?
[…] Knowing When To Stop by Chuck Musciano on The Effective CIO […]
Perfection depends on perception too …
One way I sell the “good enough” to my management is by INSISTING that the core solution be built and tested first. This way we can launch any time … as the deadline nears & if there are roadblocks to completion, we launch with the basic service and no one complains.
Warsha.Bhatia@gmail.com