Take Smaller Bites
31 May 2012Yesterday, contra to the usual course of events, a question about IT was raised in BC Legislature, regarding the Integrated Case Management (ICM) system:
C. Trevena: The government has been phasing in a $182 million integrated case management system in the Ministries of Social Development and Children and Families. It’s supposed to improve services, but feedback from social workers using it shows the opposite. Social workers are talking about some very serious concerns. They say it’s cumbersome and can result in dangerous mistakes being made. In the Ministry of Children and Families they can’t get the information they need about children at risk quickly, and that often results in a crisis. What is the Minister of Children and Family Development doing to make sure this computer system is not going to hamper the work of child protection officers?
To which the Minister responded:
Hon. M. McNeil: The integrated case management system that is in its phase 2 has, as with every new technology, some challenges when it first begins. But I have to tell you that this integrated case management system for our ministry alone is replacing 64 individual technologies. I think what it’s going to be able to do is to allow our social workers and our front-line workers, once they get fully trained and fully up to speed on the actual system, to be able to communicate with each other so that communication between the various entities will ensure that children and youth in this province are well served.
And I have to admit, the first thing I do with this kind of thing is think “$180M is a lot of money, a lot, I wonder what that buys?”. And the answer is, over a 10 year life-span, using a $150,000 fully loaded FTE cost, $180M is equivalent to 120 staff. That’s how much incremental extra efficiency the new system has to provide over the status quo. Were the old systems wasting the full-time efforts of 120 people?
But that kind of analysis is reductive. Systems get old, they need to be replaced, and integration has benefits in terms of new capabilities that can be offered that the old processes could not provide. So, was there a way to make things better, but maybe without spending $180M on a huge waterfall project?
I mused about ICM for a while. $1M isn’t actually a lot of money. You can get a team of perhaps 5 senior contractors for that kind of money. And once you commit to converting 64 systems simultaneously into an integrated system, it seems no wonder that the budget blows up. On the other hand, these large waterfall projects have a tendency to fail, precisely because they do try to solve so many problems over such a wide scope in one go.
I think the “answer”, if you can call it that, is to commit to incrementalism in all things. IT folks desperately want to re-write. We desperately want to fix everything at once. But that’s not the only way to get new and better systems.
What if the ICM project had, instead of deciding to integrate all 64 systems at once, instead decided to integrate just two of the largest systems? They would have created a problem with far less scope and risk, and with a far lower budget. The trouble with a team of 200 (or 100, or 50) is that, thanks to the miracle of Brooks’ Law, large teams waste an awful amount of time in coordination costs. Meetings, emails, status updates, reporting. All the effluvia of project management.
Unfortunately, there’s a bureaucratic problem with approaching ICM by integrating just a few systems and then incrementally adding new systems over time. Doing so would mean the project could no longer be funded as a one-time capital expense. It would have to be funded as an ongoing operating cost. And capital costs are treated very differently from operating costs. When the media reports that “government is running a deficit”, they are reporting on the operating deficit. So there is a lot more political sensitivity (at the moment) around operating expenditures than there is around capital expenditures.
The end result? The provincial accounting system is forcing IT into a waterfall methodology, as if building information systems is the same as building bridges.
I don’t think that’s the right way to treat IT systems. They aren’t bridges. Unlike bridges, it’s possible to completely re-write and re-build a running IT system 100% (or 200% or 300%) while keeping it in operation. For example, Facebook has been incrementally re-architected and re-built several times since it started, expanding a million fold over the period, and hasn’t had to be shut down for upgrade once. The same is true of Google, Amazon, and eBay.
Continuous change and incremental upgrade on running systems should be considered a best practice! Why? Because they force IT teams to break projects into discrete testable chunks, instead of attempting grand moon-shot re-writes-from-scratch.
Committing to continuous change in systems, instead of a build/maintain/retire cycle, would have all sorts of positive effects. The systems would have dedicated development staff who understand the whole thing soup to nuts. New features wouldn’t require outside contractors who themselves need to spend time learning the system (imperfectly) before they can start. User interface and ergonomics could be continuously measured and improved over time, like Facebook and Google do, instead of guessed at in waterfall design documents ahead of time.
Getting there from here will be hard, because the capital funding model is going to continue to push projects into the classic waterfall failure mode: over-promise on scope and features; under-budget to get past Treasury Board; hire expensive international system integrators because only they can show the past experience with $100M project scopes.
But if we know why it’s broken, maybe we can fix it!