Evaluating large IT project proposals

Evaluating large IT project proposals

Summary: There are (at least) nine common, technology free, indicators of a project that represents a systems disaster in the making - here's the list, and the rationale.

SHARE:

Brief: 7

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

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.

Topics: IBM, Enterprise Software, Linux, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

11 comments
Log in or register to join the discussion
  • Excellent catalog of failures

    But if we assume that any large IT Project Proposal is going to be a failure, why not
    just reject it without evaluation?

    What does a proposal for a successful project look like?
    Erik Engbrecht
    • That's much harder to do...

      In part, I think, because so few succeed fully.

      I do have some comments about this in an earlier section: remember the stuff about who pitches the proposal?

      In general, however, I think that the best strategy is to weed out the probable failures, than look carefully at the remainder in terms of whatever criteria make sense for them. I agree that this is a bit of a cop out, but don't know how to construct a set of rules which, if met, mark a probable success.
      murph_z
      • If you can accurately identify failues...

        Then you can identify successes because they are not failures.

        Who's your audience again? Is it the board and executive management, or is it the poor guy pitching projects to them?
        Erik Engbrecht
        • Answers

          Projects meeting one of these conditions almost always fail - but at least some projects which don't meet these conditions also fail.

          The audience for Brief is the senior decision maker.
          murph_z
  • RE: Evaluating large IT project proposals

    Paul, I wonder if there are any clues to failure in project
    timelines and deliverables? I would think that not
    planning to deliver actual technology early on in the
    timeline would be a red flag for directors. I know it is for
    me. John in Denver.
    john.orr@...
    • Agreed

      notice, however, that a project which delivers early and often ( ;) ) is a really a stream of related small projects - i.e. the duration rule applies: the shorter the project duration, the more likely it is to succeed.
      murph_z
  • You left out of the Munich summary...

    ... the fact that the government employee who represented the project publicly acknowledged that some/many of the employees would continue with Microsoft Office for the foreseeable future. And he left out that the rest of the employees wondered why they were too unimportant to be heard about their own preferences, no doubt.

    There has to be a reason to make a change. And when it's not an obvious upgrade, as with installing a lster version of Office, there has to be a reason besides money and an assurance that nothing is being lost. Changes from WordPerfect to Office would probably provide a model. Including Microsoft's providing of means to make Word more like WordPerfect during the transition. (WordPerfect help continues.)


    Murph wrote well about the hopes of reassuring employees:

    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.

    [End of quote.]

    But he didn't explain clearly the reason such elaborate efforts were necessary. Perhaps because he would have had to accept a Microsoft product as both the expected standard and as the beneficiary of a somewhat emotional connection.
    Anton Philidor
    • Sure I did, Anton

      Look at why I said the sale happened .. that, by itself explains why those promises were thought necessary.
      murph_z
      • Ulterior motives

        The issue is the reason those leading the Munich Windows-to-Linux project promised employees that disruption and loss of functionality from replacing Microsoft would be minimized, and kept their word.

        You assserted that conditions of the sale of the idea made such promises necessary. The conditions of the sale were (quoting the Comment):

        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.

        [End quote.]

        Yes, the decision was political, in that it had nothing to do with software, hardware or price. And yes, IBM thought at the time to gain some profitable business selling German and other European cities on open source, as Harold Hill sold the need for a band and uniforms and instruments in Music Man. And yes, IBM withdrew even before the rubes knew they'd been hornswoggled, because the marks wanted what they were paying for, and weren't willing to pay excessively. That led IBM to a restructuring of its European operations.
        (IBM was proof against affection for open source or those to whom the company had sold a bill of goods. Harold Hill was affected by the feelings of a librarian. IBM would have dismissed him.)

        But the reason for Munich's decision was, I think, less about showing disapproval for President Bush's policies than finding a way to reduce sales for money by a successful foreign company. There was a chance to advocate a local product as a replacement, as you observed, and to escape caputalism.

        As Mr. Flude indicated, the wayward effort had begun before Iraq was invaded.


        Then, whatever the political cause, employees knew that the decision was made without regard to them and without regard to the effect on their work. These emplyees decided not to accept what was happening to them. Which they must have seen as a negative, or why demand that their losses be limited.

        Surprisingly, their efforts succeeded in gaining promises that were kept. This can't be related to the political reasons for the action; employees have had to endure changing to Linux in a vanishingly few other places without successful protest. And the changes in those other places were obviously as unrelated to software, hardware, and cost as was Munich's.

        The means used in Munich was probably an employees' association. But for this discussion, the important fact is that the employees did care enough to make an effort intensive enough to be successful.

        Whatever their feelings about President Bush and/or capitalism, they had a simple devotion to Windows and Office that can only be described as admirable, even heroic. Let's not diminish their feelings by ignoring them.
        Anton Philidor
        • No

          1) the employees were not consulted. The no change promises were (as is usual) all about making the sale.

          2) yes the sales pitch was entirely levered on anti-American feeling, using President Bush as the anti-christ to move the faithful toward good pan european solutions (that just happened to have a German incarnation too).

          3) the failure didn't come about because of user resistance - in came from doing the wrong thing, in the wrong way, at the wrong time, and for the wrong reasons.
          murph_z
  • Now its 2013 and the project was a success

    5 years later - this project was taken to completion and not a failure. They have successfully removed the majority of the vendor lock-ins and maintained their freedom and lower cost to taxpayers.
    Austin_Nader