When IT is employed as the last thing to do in any transformation, all the code written is used, it always results in beneficial impacts on customers, service agents’ effectiveness and, therefore, operational cost, and the investment in IT is marginal compared to the norm, thousands rather than many millions. The shift from first to last is, of itself, a transformational challenge for business analysis and the IT industry.
First let’s acknowledge an unspoken truth: 90% of large-scale IT-led transformation programmes fail. 30% completely, 60% in part, creating escalating costs. If you’ve read Part 2 of this series you’ll understand why one of the reasons for failure is management’s mind-set; they articulate problems and specify solutions that amount to doing the wrong thing righter. Business analysis that starts from a conventional command-and-control view of the problem and solution is doomed. For example, if the brief for the analyst is to get all call-centre employees working at the level of the best, any analysis would be futile as the major causes of variation in agent performance are all in the system – and that’s the responsibility of management. A second major cause is the project-management mind-set and bureaucracy that encompasses large-scale projects; another is the assumption that IT will drive the change: “IT first”.
It is the Business analyst’s job to analyse. Knowing how to show that it’s the system that is the issue is the starting-place – as I argued in Part 2 (“get knowledge”) – it is to disregard any a priori views of the problem. So let’s return to the case of housing repairs as an illustration of what that looks like and why we need to leave IT until last.
These days few repairs organisations operate without IT systems and those systems teach us a lot about how managers think about controlling the work. Managers want the IT system to make it possible to take bookings, set target dates, schedule repairs, allocate work to tradespeople – usually via a personal digital assistant (PDA) – monitor their activity and close jobs. They often want IT to provide scripts with easy-to-follow menus. And they want reports showing the jobs arrived at within target times, jobs with arrivals beyond target times, jobs completed according to standard times and those taking longer, all of which can be expressed in terms of RAG status. Managers believe all this will maximize the productivity of repair personnel, give visibility of achievement of targets, and control work activity. This is how they think about the control of the work. The IT systems they buy to automate these controls cost a quarter million or more to buy and tens of thousands a year to keep; but they are part of the problem.
Analysis of systems like this follows the steps to “get knowledge” outlined in Part 2. It typically reveals that few jobs are completed on first visit, end-to-end times for customers are dire, the focus on activity and targets are a primary cause of dysfunction, the level of failure demand is robbing the system of capacity, the measures-in-use blind leaders to these important truths and the scope for designing a system that gives customers what they want, when they want, it is eye-wateringly attractive. A system designed on the basis of the customers’ purpose. Designing such a system will eradicate not only failure demand but also the wasteful consumption of resources created by the conventional command-and-control design. The economic advantage of being able to give customers what they want, when they want it is now transparent.
Knowledge of demand is key – the big lever. Despite management’s doubts, demand is always shown to be largely predictable. That, with knowledge of actual time taken to complete work, enables resource scheduling to match demand. Now you’re in a position to offer service on the day and at the time the customer wants. You’re also able to resource materials only at the rate you consume them, materials costs fall while the capability to have the right resource in the right place increases.
The IT required to do all of the foregoing is built as the improved design is developed with desk-top tools, quickly and simply: time-series data, expressed in capability charts, to provide knowledge of the predictability of demand; same for data on the actual time taken to make all types of repair. These then become the building blocks for understanding the relationship between demand and capacity and, from there, creating a reliable scheduling system. You need IT to keep a record of what the repair was (which can only be done accurately on completion) and feed data to finance systems. Data on demand and consumption of materials is used to reduce the time between purchase and use (cutting costs) – as well as ensuring materials are available as required – ensuring first-time resolution. Finally you need IT to provide managers with complete real-time visibility of all work, providing jobs to repair personnel one at a time.
Step one is get knowledge, step two: redesign for effectiveness then, lastly, step three, pull in IT. It is to start from a base of knowing what IT can do to support a more effective design, the costs of development drop to tens of thousands and everything developed gets used – an amazing feat in IT development. And the benefits delivered by the IT system are significant: Real-time visibility of the work, accurate information about demand and activity times, costs and materials employed. Materials are purchased on the principle of time rather than unit cost, as the time between purchase and use is the means to reduce inventory (buying on unit cost is shown to increase inventory, and thus cost).
In the UK many repairs organisations have followed the steps above and deliver repairs when customers want them at as much as 50% lower operating cost; they have dumped their conventional IT system that cost a lot to buy and keep, and have built their own for tens of thousands. Which takes us back to where I started: The only thing missing from Agile is knowledge; it should be the analyst’s touchstone.
Author: John Seddon, Author of Beyond Command and Control & Professor at Buckingham University
John Seddon is a management thinker and commentator, and currently a visiting professor at Buckingham University Business School. His latest book Beyond Command and Control is a detailed account of how leaders of service organisations have changed the way they think about the design and management of their organisations and achieved profound results.