Why 45% of all software features in production are NEVER Used.

Most people when they look at this research see a problem in software development.  Based upon empirical data, that is usually not the case.

The Standish Group ranks the usage factor of features across the average enterprise software system. Their findings show that on average only 7 percent of an enterprise application features are "always" used, 13 percent of the features are "often" used, and 16 percent are used "occasionally." That leaves 64 percent of the features in an average enterprise application as either "rarely" or "never" used.

In the end, the Standish research is NOT a good indicator of poor software development performance. However, the data IS an indicator of systemic failure of planning and measurement processes.

Let’s say you have a $500,000 to build a software product.  After much effort to identify funding sources and justify future benefits (revenue growth or cost savings), you decide to try to maximize the return on the budget by going through a traditional buying process.

So you have your team of 3 people spend the next two months building out a long list of requirements including functionality, integration, scalability, security and requirements for the vendors.  The goal is to be able to communicate enough for an apples to apples comparison so the only difference is price.  This 25K internal cost (to do this by the team) is justified by the creation of an RFP.  This RFP will be sent out to whoever the organization has worked with in the past and several others.

To make sure the vendors have enough time, a 3 week timeframe is laid out including questions due week one, a vendor Q&A week two and responses due week 3.  Some vendors did not ask any questions and others suggested different approaches than what was suggested in the RFP.  Each of these were eliminated since obviously they can’t follow instructions.

Of the four responses, two suggested an initial estimating or discovery phase before an exact quote could be given.  Since there was a cost to this, these responses were rated lower.  The remaining two responses each had fixed bid responses and required a meeting to confirm expectations and next steps.  The decision was to bring these two vendors back in and play them against each other to potentially lower their bid to $350,000.  Great!  $125,000 buffer or savings available.

After negotiation, contracts, legal and scheduling… a kickoff is scheduled.  In the kickoff, a project schedule is communicated with high level milestones every 3 months.  The contract is also created so the payments are tied to these milestones… $100,000 at kickoff, $100,000 at Milestone 1 100,000 at Milestone 2 and $50,000 at Project Completion 6 months out.

Prior to Milestone 1, a design session has occurred to make sure the look and feel is right.  Also, implementation and integration discussions have occurred and an application architecture has been approved.  Documentation has been presented and everything seems to be going well.  At Milestone 1 – the vendor presents a summary of the work performed in PowerPoint with architecture diagrams, screenshots of the application and feature summaries.  It looks good so far so the second invoice is approved.  $225,000 spent.

Whether the rest of the project goes perfectly or not, in this model… almost half of the budget has been spent.  To date, no functionality could be released to users to return value on the investment.  The risk that the remaining budget can deliver functionality of value is huge.  Whether the selected team or vendor is using agile software development, waterfall or no process, this is a failure by the organization stakeholders to create an effective decision making process flow.

The majority of projects at this point will go longer than expected, have quality problems and cost significantly more.  Also, the waste in negotiating scope, who said what, when and other pain may still not get anything of value to production.  This is why only 45% of software features in production today are never used (or deliver NO value).

Even if everything goes great and the budget spent is $350,000… $157,500 delivered features will never be used.  Also, since only 35% of all software development effort is actually coding, how much other time, costs and effort was included in delivering the nearly $160,000 of features never to be used.

There is a better way.   No, agile is not the silver bullet.  Here are some key concepts which will help:

1. Assume that at any point you do not know everything – this helps everyone in identifying what is known and understanding what is not. Trust those who know (mastery) to lead you no matter what their title may be or whether they work for your company.
2. Share with everyone involved what is known and what is not – both the business stakeholders and the organization responsible for delivering have to share the good, the bad, the ugly all along the way. Transparency sounds great, but it does involve some pain for everyone involved.
3. Break down work into the smallest possible bits to reduce risk for everyone – this often very hard to do since trust is required all around to make sure the bigger picture is understood. Vision is required.
4. Have people work as closely together as possible – the further people are apart, the more difficult communication and collaboration are to occur. Everyone has a story of a bunch of people working in a small conference room on something and amazing things happening.
5. Have a visible and agreed upon 'definition of done' - everyone involved (the team, vendors, stakeholders) should agree to a list of items defining reality to 'done'.  This makes the answer to the question... easy - yes or no.  Transparency follows.

At a minimum, please ask why a few times when a large project is pushed forward using a big process.  You might find that there are no good answers and you can help improve the value of features delivered for the investment.

 If you are interested in exploring this further, lets grab coffee.  :) david.rice@centare.com