% fortune -ae paul murphy

From chapter 2 "Evaluating IT Proposals

Brief: 7

This is the seventh excerpt from the first book in the Defen series: The Board Member's IT Brief.

Large IT Project Proposals

Large projects tend to be classified as strategic and presented to boards for approvals in part because many are strategic and in part because the risks undertaken in these tend to be large enough that senior management wants a board blessing before proceeding.

A proposal to change from SAP to Oracle would, for example, be obviously strategic for a major railway - and so would a bank IT proposal to expand into the internet payments market.

Such projects seems to come in a nearly infinite variety, but all of them live or die by their management plans. Develop a sensible plan, execute correctly, and the project may have a chance.

So how hard is to develop one of these? Here's an excerpt from a spam email:

An effective Management Plan can be written by an experienced Proposal Manager with little or no expertise in the subject matter of the RFP. Writing one from scratch however, is costly, time consuming, and tedious. The Proposal Architect, our new proposal writing product, provides model text for the different sections that comprise a management plan. Using model text and, if you have it, information from previously written proposals, can save thousands of proposal writing dollars and make a proposal more compelling and responsive to the RFP requirements.

Don't kid yourself, that's how a lot these things get put together.

If you're a lawyer or CPA you're probably familiar with billings pressure. IT consulting isn't any different: same business structure, same pressures, same methods, just a different market.

Here's an except from a September 5, 2005 Computerworld article by Marc L. Songini:

SEPTEMBER 05, 2005 (COMPUTERWORLD) - After spending $39 million on an ERP system that failed to meet management's goals for the project, King County in Washington would like to have another crack at succeeding. Officials blamed a lack of management oversight for the failure of the ERP system, which included PeopleSoft human resources software and SAP AG's R/3 financial application. That implementation was frozen in 2000, three years after it started. The ABT team, made up of in-house staff and independent consultants working under County Executive Ron Sims, needs $2.4 million in funding for preplanning work, including a business design and cost analysis. That outlay requires a vote from the county council. An independent consultant hired by the county, Dye Management Group Inc., estimates that the cost of implementing ABT will run about $47.5 million. That figure will be re-examined next year.

Here's a project "mile stones" summary provided by talkback contributor Richard Flude in response to zdnet's mid 2005 coverage of new delays in a major Microsoft to Linux conversion then going on at the City of Munich in Bavaria:

4.11.2001: examination of MS alternatives
17.04.2002: request for preliminary analysis
28.05.2003: detailed plan for Linux migration with SuSe and IBM
16.06.2004: project preparation (call for first tenders)
21.04.2005: internal kick-off meeting for LiMux migration

The project involves the migration of 14,000 desktops and 16,000 users to Linux and other open source software. A transition to the Firefox browser was the first step. They had hoped to start the migration to OpenOffice in 2005, but that has slipped to 2006.

The pilot of the LiMux client environment is expected in 1st Qtr 2006.

Where did all of these people go so far wrong?

There are (at least) nine common, technology free, indicators of a project that represents a systems disaster in the making:

1. Someone, usually systems management, picked the "platform" [meaning: hardware, operating system, and data management system] to correspond with what they have or want, rather than what the application needs.

2. The implementation plan is sold to users on the basis of the belief that the new product will allow old ways to continue essentially unchanged.

3. Consultants are given control --particularly consultants from large firms that bill on a per diem basis and depend on the continued goodwill of systems management and the various vendors involved, but not your board or user management, for further business.

4. Extensive customization, particularly of PC clients and/or application interfaces, is required.

5. The people in charge have selected technology they're not familiar with but have assigned people they are comfortable with, and whose experience doesn't apply to the technology either, to making it work.

6. The application addresses a production, sales, transportation, or customer issue but IT management reports through Finance.

7. There is active and continuing middle management lobbying for more process control.

8. No budget allocation is made for training senior management personnel to understand and use the information or process improvements expected.

9. The storage and use of the data coming from the system is treated as a separate project from the main implementation effort.

In general, an IT project with any two or more of these indicator conditions is going to fail in both its implementation and its benefit realization efforts regardless of its purpose, leadership, or the specific technology choices made.

In one way or another the two projects cited above each demonstrated at least five of these pre-conditions for failure -and therefore never had the remotest chance of coming in on time, on budget, or anywhere within shouting distance of meeting user expectations.

In their first, 1997, go round King County adopted a best of breed strategy - committing itself to custom interfaces between components taken from SAP's ERP suite and one developed by Peoplesoft. In doing that they gave their lower level managers and the consultants a blank check to slow the implementation while giving up the two primary benefits obtainable from an ERP system: a unified database and global process optimization.

One of the important messages here is that the big financial hit produced by decisions like King county's isn't captured by the $39 million dollar number in the news report - those millions only covered the hardware, software, consulting, and related costs sunk into this effort. The big dollar cost isn't publicly available: it's the cost of not having a functioning ERP for the period from the initial go-live date in 1999 to what ever the actual go-live date turns out to be - probably at least into 2009.

The folks in Munich had even worse problems. As put together in the first place the deal resulted from an IBM sales initiative to use European anti-Americanism as crystallized by opposition to President Bush's position on Iraq, as a lever to push Microsoft products out of European cities in favor of its own Linux services - a political sale, in other words, that had nothing to do with Linux or the customer's technical needs.

In Germany, IBM's chosen Linux partner was SuSe Linux Ag. The product, then SuSe 7.0, was rock solid - but the company was not and IBM was eventually forced to choose between buying it and closing its cities initiative in the German speaking countries - but then found it couldn't buy the company because of a legal issue in the United States. (SCO, holder of AT&T's Unix contract rights, alleges that IBM allowed protected code to escape into Linux and used SuSe as one of two primary vectors for doing it).

As a result IBM assumed some SuSe debts, invested $50 million plus a promise of future business in Novell, and gambled on recouping momentum through a sale of Linux desktops to Diamler-Chrysler.

Novell, in a legally unrelated move, then bought SuSe - turning it into an American company for purposes of the intended Linux sale to Detroit but leaving IBM with a massive PR problem in Germany - a problem that helped Diamler's Detroit employees scuttle the deal.

Munich later selected Debian Linux as SuSe's replacement, but by then the political drive to succeed with an anti-Bush strategy had been supplanted by a different drive: one not to fail too publicly. In late 2006 the consultants were largely responsible for operations, the pitch to users continued to be that the change would change nothing, work on both the interfaces and the custom client continued to get further and further behind, and continued "customizations" on both the Linux kernel and the openoffice applications was creating an enormous future support headache for the client. By late 2007 the project was dead - abandoned in all but name.

The lesson from all of this is simple: if the project plan before you exhibits any two of the indicators listed earlier - vote No, because this project will fail. There are always exceptions, but in general it really is that simple.

Some notes:

1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.