Beyond Agile/Scrum: Less Software, Happy Clients

In the digital world, there is an epidemic of over-delivering software solutions – a recent IT department we visited typically green-lights 80 projects per year – and completes only 15.  

Why?  Because they are over-delivering their solutions – each one consuming more time and effort than necessary.

Case Study:

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 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).

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% of the issues could be resolved by the software.  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 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.”

In this content area, we cover:

  • Why software solutions are often over-delivered
  • The cost of over-delivery
  • Identifying the Outcomes to be Achieved of the software solution
  • Creating an effective problem statement with you and your client
  • Determine interrelationships between causes and root causes
  • Understanding process flow, backlogs and the three main decisions of Lean
  • Understanding value demand versus failure demand/preventable work, and quantifying cost of the latter
  • Understanding wide range of typically invisible causes of poor performance
  • Algorithmic vs Heuristic work – and how software can solve these problems.
  • How to create requirements that define what problems need to be solved by the Client versus which problems can be solved by through automation – to create a true lighter-weight, right-sized digital solution


  • One-hour talk
  • Group/team multi-day training workshops (1 day, 2 days or 3 days)
  • Consulting engagements to work side-by-side with you to improve your ability to deliver less, but more valuable, software to your clients.  Or, as a client of IT, to develop better, more focused requirements resulting in a product that takes a fraction of the time and effort to develop, while actually working once implemented