Canadian Government Executive - Volume 25 - Issue 02

Figure 1 TRANSFORMATION April/May 2019 // Canadian Government Executive / 35 How did they overcome that challenge? As it turns out, many software solutions are bloated, providing far more function- ality than required. Why? Because the organization goes shopping for “features” – instead of first deeply understanding its “must-solve, cannot fail” business prob- lems. 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 clients and IT professionals, the follow- ing were the top reasons for this “feature creep”: • Rare opportunity: Often system replace- ments or major refreshes only happen once per generation (or less), so there is a motivation to demand all possible fea- tures “just in case,” because we may not get another opportunity in the foresee- able future. • Poor understanding: clients do not un- derstand 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 chal- lenges. 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, tak- ing effort and time to re-update them, and as time passes more staff depart the proj- ect, and the more total effort and time re- quired to implement the project. The greater the requirements, the great- er the resources required to implement the solution (often around 30 per cent of total cost) and the more resources and at- tention required to maintain the solution (often around 50 per cent of total cost). These resources are effectively stolen from 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, implement- ing them, teaching them and maintaining them? Especially while our IT depart- ments are at the same time facing huge backlogs of unaddressed needs? To struggling leaders and teams, it is al- most irresistible to try to pack in as much functionality as they can. When we asked 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.