A couple of months ago one of the wheels on my push lawnmower fell off and I decided to buy a new mower. The old lawnmower had survived 10 years of inattention and I figured it was finally time to put it down. I drove to the local big-box hardware store and selected my new lawnmower.

 

I took it home, opened the box, threw away the owner’s manual (without even cracking the cover), put the mower together, added oil and gas, and fired it up. Then, I noticed something was wrong. There was no throttle on the new mower. My old mower had a throttle control. A turtle decal indicated slow speed and a rabbit decal indicated fast speed. There was no such thing on the new mower. It ran at one speed and one speed only.

 

At first, I felt a little cheated. I paid good money for a new mower and there was no throttle control. Then I thought about the usefulness of the throttle control. I could not recall a single time when I had ever adjusted it. The throttle control started in the “rabbit” position and stayed there for a decade. Never once had I thought to myself, ‘This patch of grass would be better cut at “turtle” speed.’

 

Perhaps someone at the lawnmower company figured out that a throttle control was functionality that no one needed or actually used. As I finished mowing my front yard and moved to the back, it occurred to me that the throttle control was like a lot of the software I’ve developed (at someone’s request) over the years.

 

According to the Standish Group’s CHAOS report 45% of the software features in a system are never used and another 19% are rarely used. If that is true, about 64% of the code we write is like the throttle on my old lawn mower. Someone said it was needed but almost no one subsequently used it. I then thought about how this 64% of little-used code cascades through our processes.

 

How much of our testing and quality assurance efforts are spent on features and functionality that will rarely get used? Same with application interface, integration, support and upgrade activities.

 

Now I was getting depressed. This never and rarely used functionality was hurting me in several ways. What functionality were we not developing, testing, integrating, etc. so that we could work on features and functions that no one would use? Finally, what could I do about it?

 

By the time I had finished my mowing, I decided to do a test. As part of our project design, we would ask a set of questions to sort through the features and functions we really needed. My draft set of questions included:

• Who is going to use this feature / function?
• What are they trying to accomplish with this feature / function?
• How often do they need to accomplish this task?
• If they don’t have this feature or function, how will they accomplish this task?

Done with my lawn, I decided to test these questions on a project we were just starting.  We were building a sales quote management system for one of our divisions.

 

For this test, we rigorously asked the above questions as we designed the quote system. By thinking about what features and functions we really needed rather than imagined we needed, we were able to reduce the time to develop the system by 50%. Even better, salesperson satisfaction and adoption was much higher than expected. Without all of the exception handling, the system was much easier and faster to use. The salesforce was happy to deal with the exceptions (since they are rare) outside of the system.

 

Based on this experiment, I have concluded that if we take the time to understand and then filter out the functions and features that are rarely, if ever, used everyone wins.

 

I’d be very interested in hearing from this you about your own experiences in scoping projects. Are there other questions we should add to our list? Please share your experiences.

Related Links
Ensure your teams are capturing all of the project requirements with the techniques in this requirements capture guideline. Then thin them out ruthlessly by comparing to the is/is-not worksheet the team has agreed on as part of project scope. Ann Drinkwater has valuable advice for keeping your requirements meetings on track.

Comments

Good story Niel. You are absolutely right – build only what is necessary and will be used.

I often see business groups thinking of every imaginable scenario and exception when looking to build a software system. Building a system to support this complexity is time consuming and expensive and often not necessary. Detailed exception planning and system design also requires stringent business rules be developed and implemented, which can be a challenge when going from a manual process (where rules aren’t as necessary) to a structured software solution.

Nice post. I often wonder how many more release dates we would hit if we separated the fluff from our projects... Anyway, another technique I've used is to lean on Pareto's Principle and ask the stakeholders to identify for me the 20 percent of the stories that 80 percent of the customers will use. Once I get the short list I ask if we can defer discussing the remaining stories in detail until the high impact 20% stories are complete.