The Chief Information Officer hoisted a thick binder up to eye level and let it free-fall onto the desk with a thud and a cloud of dust. He predicted, “By the time I retire in 10 years, this software won’t be implemented, and if it is, it probably won’t work.”

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 Ministry – 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.

Some reports suggest that close to 20 per cent of features are rarely used, and more than 40 per cent 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 unaddressed needs?

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 resolve these issues.
  • 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, taking effort and time to re-update them, and as time passes more staff depart the project, and the more 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 per cent of total cost) and the more resources and attention required to maintain the solution (often around 50 per cent of total cost).  These resources are effectively stolen from other important projects, preventing IT from delivering value to other parts of the Ministry’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 (see image).

Once the CIO’s cross-functional team identified this short-list of challenges and assessed whether currently-available technology could solve them, they realized that expecting digital solutions to solve all of their problems was a pipe-dream. Only about 20 per cent of the issues could be resolved by the software (at least until AI becomes a fully-accessible, broadly-implemented reality). By the way, the team estimated that each business case going through their system experienced at least 7.5 weeks of preventable effort – multiplied by an annual volume of 300+ business cases. Not solving these issues carries a serious price tag indeed.

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 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 takes two years to implement. This is more like four days of a business analyst and a coder to improve your existing system.”

To learn more about this and related topics in this field, go here or check out Lean Government Summit 2019, which will be held on October 1-2, 2019 in Ottawa. This summit brings together global public servants and thought leaders to share breakthroughs in the delivery of products and services through improved processes, innovation and energized people.