Priorities

Apropos of nothing, here’s every RFP document issued for the ICM project in BC (and there were 10 different RPF/ITQ/RFI/NOI postings over the years) rendered as a word cloud. Notice the prominence of “child” and “family”. When you get down to brass tacks, enterprise IT doesn’t much care about what you do, but it very intensely cares about how you do it.

Once in a Lifetime: IT in Question Period

Today in question period, the opposition NDP in British Columbia devoted five of their six questions to information technology issues! It’s pretty rare that the snooze-fest that is IT rises to the level of political notice, so I don’t expect a repeat display again in my lifetime.

Some of the questions:

A. Dix: My question is to the Minister of Citizens’ Services. An independent report on integrated case management across ministry computer systems, meant to improve services to vulnerable British Columbians, states that the system may never be fixed. A system that cost over $200 million may have to be thrown out because of mismanagement. The report says that in the bidding phases for this technology, the ministries in question were in chaos, going through so-called transformation with a revolving door of ministers. The children’s representative has said: “This report speaks to incompetent stewardship.” With such damning comments, and a lack of faith that the system can be fixed, can the minister explain what went wrong and when the government will take responsibility for this mess?

R. Austin: It’s not just in the child welfare system that this mismanagement has occurred but also in education. We know that this government spent almost $100 million on their electronic data system. What we don’t know is how much was also spent by school boards on training, implementation and licensing costs. Communities and taxpayers should not have to pay the costs of Liberal mismanagement on these colossal computer projects. Can the Minister of Education tell this House how much in total was spent by districts and the government on this failed computer program?

The systems in question, ICM and BCeSIS, cost the government respectively about $200M and $100M. That is, far beyond the outer edge of where we can intellectually grasp the amount of money involved, or where the effort goes.

Here’s one way of understanding what a $200M project budget means, look at what the budget means in terms of people.

Assume a $200K fully loaded staff cost (salary, overhead, benefits, everything). That’s a big number, but let’s assume experienced professionals being paid commensurately. That means $200M equates to 1000 person-years of effort. Or, over a 5-year project span, a 200 person staff. What could you deliver, in 5 years, with 200 highly trained professionals?

Here’s another way of looking at what $200M spent on IT means. Over the four year period from 2003 to 2007, Facebook grew from Mark Zuckerberg’s dorm project to a company with 50 million active users. In that time, during which Facebook had no revenue, investors put just under $40M into the company. So it cost $40M to build the 2007-era Facebook.

So, $200M to build a failed case management system that (poorly) serves a working population of a few thousand civil servants, against $40M to build an intricate social network that serves a population of 50 million.

There’s no way to get around it: enterprise IT is hopelessly broken, and much of the money we spend on systems development is wasted. We need a new way of doing business.

Modular Systems Development

Turns out not only am I not insane, I’m not on the bleeding edge or even remotely innovative!

When I say that enterprise IT projects should be broken into small parts, done by independent small teams, and manage risk by managing size, I’m actually parroting the United States Office of Management and Budget, the boringest, stodgiest organization on the planet!

Modular system development mitigates risk, says Daniel Werfel, federal controller for the OMB.

Under modular development, discrete project deliverables get pushed out more often, meaning that reviews and evaluations happen sooner, allowing for the possibility for quick corrective actions that can mitigate financial exposure.

And…

Projects of a more traditional variety–in which about 80 percent of the budget goes to customizing a commercial solution–cannot quickly adapt to changing laws or technology and often have costs rise by hundreds of millions of dollars.

Check out this awesome graphic from the guidance document:

Read the full guidance document if you dare: they didn’t get to be the boringest, stodgiest organization on the planet by bringing their “B” game.

COTS uber alles?

I continue to follow the ongoing $180M-and-counting IT debacle of “integrated case management” in British Columbia with interest, perhaps because it’s a local catastrophe and not some far-flung disaster.

The latest tidbit is an independent consultant’s review of ICM from the perspective of the Ministry of Children and Families (MCF). I hadn’t previously appreciated the extent to which the hydra-headed nature of ICM as a project of both MCF and the Ministry of Social Development (MSD) was contributing to disfunction.

In politic terms, the consultants point out that MCF was the weaker partner in the partnership, and therefore got steamrolled during the design phase. MSD had a stronger team, was better prepared, and got what they wanted. MCF was the red-headed step-child.

Another issue the consultants noted was the way the “COTS” requirement and “no customization” made a bad situation worse. No matter what the clients wanted, there was a arbitrary external rule always in play:

The ICM solution [should] not be based on a customized system, but as much as possible rely on an “out of the box” product (with necessary configuration to meet the respective needs of MCFD and MSD).

If you knew the magic incantations, you could sometimes get an exemption, but the MCF team didn’t know how to play the game:

It became clear in our interview process that while the project principles did support exceptions to the “no customization”’ rule where there was a solid business rationale, current MCFD leadership did not recognize they could make this appeal, and so remained fully constrained by the design and implementation of a single instance untailored to MCFD needs.

And so the final product rolled out was a design disaster for child protection:

The decision to implement a single instance of the Siebel product required that all users (regardless of ministry or program) share a common set of forms and data attributes, even though they touch on completely different topics and clients, and speak very different practice “languages”. This has also led to many forms being developed with redundant fields and or labels that are meaningless to the majority of users.

In fact, the “phase 2” rollout was such a disaster that the whole COTS “no customization” rule seems be to up for review! Tucked into the consultant report is this little gem of a status update:

The ICM/Deloitte Project Team has also been working on the design and development of an external service provider portal which will utilize a custom user interface (i.e. leveraging the information within Siebel but presented through a completely separate web application). While the service provider portal does not have any direct relationship to MCFD’s Child Protection Services, it does demonstrate that the project team can design and develop a solution that builds on the Siebel platform with a customized user interface and significantly improved usability. This approach will be of value as we consider the revised child protection solution and we see it as a very positive step.

Plan B is now officially under way! The generic Siebel interfaces are being ditched in favour of (gasp!) custom designed user interfaces fit to purpose. Will the Siebel interfaces all be eventually phased out? That’s my prediction.

The only question left is how long MSD and MFC will have to pay Siebel licensing for a system that has been delivered over-budget and with insufficient functionality largely to cater to the predictable limitations of the Siebel software and the “no customization” COTS philosophy. A long, long time, I fear.

Is building enterprise systems a capital expense?

First, terminology: operating versus capital expenses. Bah! Accounting! However, it’s important stuff. Wikipedia provides a good example of the difference:

For example, the purchase of a photocopier involves capital expenditures, and the annual paper, toner, power and maintenance costs represents operating expenses.

The key thing to remember is that a capital expense is supposed to convert cash into an asset.

Second, application: most enterprise information system builds these days are funded as capital expenses. Money is spent, and at the end of the day the organization places an entry on the balance sheet saying “System Z is worth X million dollars”.

Third, contention: this common IT accounting practice is bullshit.

The reason it is bullshit is that the asset has to be placed on the books with a value, some dollar figure that represents what it is worth. This isn’t just some made up number, it’s important. This number is a component of the total asset value of the organization, and if you are adding up the value of the organization, it will be added in along with the cash, the real estate, the fixtures, all the other things that we know do have value.

Does the enterprise information system have value? How much? Where does that number come from?

Is the information system value a re-sale value? No. Unlike the photocopier from the Wikipedia example, the enterprise information system has no value outside the organization that built it: it’s sui generis, custom-built for the purposes of one organization.

Is the information system value a replacement cost? No. Governments build things like bridges and highways that don’t necessarily have a re-sale value (who is going to buy them?) but still have a provable value in terms of their replacement cost. If it takes $100M to build a bridge, it’s a fair bet that it’ll take $100M to build a second one just like it. Is this true of enterprise information systems? If I build a billing system and it costs me $1M, will it cost you the same thing to build a second one? If you have access to my source code and specifications, you could probably build an even nicer one for 1/10 the cost or less, since you wouldn’t have to spend any time at all discovering the requirements or doing data cleansing. There’s no expense in materials and relatively little of the labor value ends up embodied in the final product–the system value is not the replacement cost.

Is the information system value durable? No. Long-lived public infrastructure may not be re-sellable, but it often has a useful life span reckoned in multiple decades. Given that, it’s fair to say that the cash involved in building it has not been spent, but has been converted into a fixed asset. Do enterprise information systems have that kind of durability? Do I even have to ask?

Does the information system value reflect a one-time acquisition cost? No. The $3B (gulp) Port Mann bridge newly opened on BC’s Lower Mainland will have an annual maintenance cost of perhaps $30M a year, %1 of the capital cost. The asset is built, and we get to keep using it almost for free (except for the tolls to cover the loan, ha ha!). Is this true of enterprise information systems? In my experience, information systems budget 10-20% of build cost for expected annual maintenance. So, it’s very different again.

Is there any case at all to be made that enterprise information systems can be treated as assets, and hence budgeted as capital expenses? Yes. But it requires that the asset value be assessed very conservatively (the whole build budget is not indicative of final value), and that the value depreciate very quickly (the system has a relatively short lifespan, years not decades).

But rapid asset depreciation is just as hard on a balance sheet as operating spending is! Build a $100M system and depreciate it at 10% a year, all you’ve done is concentrate $100M of IT spending into a very short period of time and spread out the depreciation over a decade.

So, skill testing question for all you IT practitioners out there. Who will get the better results:

  • the manager who spends $100M in one year on a system build and depreciates his asset over the ensuing decade? or,
  • the manager who spends $10M a year over a decade in incremental system enhancements and improvements?

Note that both approaches have exactly the same effect on the organizational cash flow. Take your time, don’t rush your answers.

Accounting for enterprise information systems as capital expenses is a mistake. It’s dubious from an accounting perspective, because the “asset” on the books isn’t re-sellable, doesn’t hold its value, and doesn’t cost nearly its book value to replace. And it’s dubious from a practical perspective because it forces system development and maintenance into an incredibly risky and inefficient spending pattern.

Don’t do it if you can help it.