His team and their clients worked for years to compile a 500-page binder of requirements for the new system to automate the backbone process of his organization – a case management system to shepherd business cases through a complex review and approval process.

A few months later, in the same office, he congratulated his team for reducing the 500 pages of requirements to just 111 pages. Six months after that, he, his team, and their clients celebrated the successful implementation of the slimmer, better, software package, years ahead of schedule and under-budget.

How did they overcome that challenge?

As it turns out, many software solutions are bloated, providing far more functionality than required. Why?  Because the organization goes shopping for “features” - instead of first deeply understanding its “must-solve, cannot fail” business problems. As a result, they never define which business problems the software can solve – and, just as importantly, what business problems the software cannot solve.  In other words, they do not identify which problems the CIO should solve, and which problems the COO should solve.  So, the CIO ends up (unfairly and unreasonably) on the hook for both. 

The 2014 Chaos Report by the Standish Group suggests that close to 20% of features are rarely used, and more than 40% of features are never used.

If we rarely or never use these features, then why do we bother defining them, building them, testing them, implementing them, teaching them and maintaining them?  Especially while our IT departments are, at the same time, facing huge backlogs of work?

To struggling leaders and teams, it is almost irresistible to try to pack in as much functionality as they can. When we asked clients and IT professionals, the following were the top reasons for this “feature creep”:

• Rare opportunity: often system replacements or major refreshes only happen once per generation (or less), so there is a motivation to demand all possible features “just in case”, because we may not get another opportunity in the foreseeable future;
• Poor understanding:  clients do not understand the causes of the major issues in their business, so they ask for as much functionality as they can in the hope that one of those many features will magically resolve these issues; and
• Disconnect:  Developers and approvers of requirements are distant from the day-to-day business and are afraid of turning down functionality, given their limited knowledge of the business challenges.

This “feature creep” has huge costs:

• Try to follow this chain of events:  the more features, the bigger the project, the greater the cost and risk, the higher the level of governance required to approve it, the more effort invested in defining the project, the longer it takes to go through the definition and approval process, the more stale the requirements become, which take effort and time to re-update, and, as time passes, more staff depart the project, increasing even more the total effort and time required to implement the project.  
• The greater the requirements, the greater the resources required to implement the solution (often around 30% of total cost), and the more resources and attention required to maintain the solution (often around 50% of total cost) – these resources are effectively stolen from other important projects, preventing IT from delivering value to other parts of the organization’s business and mandate.

Many organizations do not have a good handle on their key problems or their causes before they define their requirements.  And this is as much a core business issue, as it is a CIO issue.

What Challenges can Software Solve?

Highly transactional business processes (mass-processing, or mass-customization) are defined by decision trees and business rules that can be coded into software to provide a high degree of automation.  Processing mass transactions such as tax returns, pension benefits, and so on are often great candidates for serious automation.  

However, deep-thinking work (such as building or reviewing business cases, policies, strategies, correspondence, etc.) are much less able to benefit from digital solutions.  In the deep-thinking business case review and approval process that the CIO at the top of this article was attempting to automate, after a deeper review of the process by staff using Lean, they identified nine “must-solve, cannot-fail” challenges (Figure 1.0).

And as helpful as Agile/Scrum is to deliver twice the software in half the time, without first understanding deeply the business problems and their causes, this worthy discipline is often limited to “building the wrong thing faster, with less effort”.

Every hour you spend better understanding the process you are attempting to digitize could save you ten or more hours of effort later, while also freeing up IT and core business staff to deliver more value in your part of the business and elsewhere.

If you are a CIO, this approach can help you satisfy more clients and get rid of your own backlog. If you are a client of IT, understanding better your own business issues and their causes can get you your desired system more quickly, with greater likelihood that it will actually work once delivered.  As another CIO said when looking at the list of his client’s root causes: “This is no longer a $ 300,000 project that has to go through our approval process and take two years to implement. This is more like four days of a Business Analyst and a coder to improve your existing system.”