eyetoit

Project Sponsorship Part I: Selecting a Sponsor

Nearly every technology project of any significance in an enterprise needs a project sponsor. It used to be that the duties of many project sponsors seemed to begin and end with securing financial resources for the project. Beyond that point, the role would often become a largely titular or ceremonial one, typically involving irregular attendance at meetings of the project steering committee that might meet infrequently, unless of course the project experienced some sort of crisis - occasionally leading to the steering committee meeting far too frequently for its own good, with plenty of opportunities for recriminations and "blamestorming" (i.e. a session in which everyone contributes to the finger-pointing).

This is an admittedly critical picture of the process, but I imagine many people in organizations are familiar, directly, indirectly or anecdotally with experiences not too dissimilar to the description. While I wouldn’t characterize it as the rule, neither was it the exception.

However, rather than simply dissect what has gone awry in such situations; I believe it would be more constructive to talk about the project sponsor role from start to finish. This should have relevance to a fairly broad audience, from project managers wanting to help their sponsors to CEOs who recognize that effective sponsorship by business executives and managers is a key ingredient to maximizing the return on technology projects.

Because this is a sizable topic, I will be breaking the discussion into a handful of segments. I’m going to start with some quick thoughts on sponsor selection. In future segments, I expect to cover the responsibilities of the sponsor, tips on fulfilling and evaluating the role of the sponsor, and what to do in cases of sponsor nonfeasance (or less-commonly malfeasance). Please feel free to email suggestions for particular areas of the topic you would like to see addressed.

Thinking about IT and the Board

The point of these writings, for the most part, is to offer some insight and observations that business managers, executives and directors of (primarily) non-technology companies to help better manage the role and function of IT within their organization. In October's Harvard Business Review, there is a quite good primer on board-level IT governance written by Richard Nolan and F. Warren McFarlan.

In "Information Technology and the Board of Directors" (p. 96 in print - subscribers can access here - non-subscribers can view an excerpt) Nolan and McFarlan lay out a succinct yet reasonably detailed framework for thinking about key issues of viewing IT as part of the corporate governance function, such as:

• What is the current role of the firm's IT operation - (Support, Factory, Turnaround or Strategic) -  I have always used somewhat different labels - Cost Leadership (Support), Operational Excellence (Factory) and Differentiation (Strategic). Also, I have always excluded "Turnaround" as a independent role because it should be getting turned around to something (i.e. one of the three other types) - but from a governance perspective, the key point is that board should expect to more thoroughly scrutinize relevant issues in a case of a turnaround.
• What sort of questions should the board ask for each type of IT operation?
• How often should they ask these questions?
• What is the role of a board IT expert? (see some of my comments in "IT Savvy Board Representation" from last year)
• How do you establish an IT governance committee on the board?

There are details within the article about which reasonable people can differ, but overall it is really quite a good piece and I would encourage any senior business manager or director to read it and discuss it with their other board members.

The Risk of Dark-side CIOs: Crooked Information Officers

The Twin Cities local business paper reported Monday that Buca restaurants announced that they are suing their former CFO (who had resigned) and CIO (who they actually fired after an internal investigation) for all manner of malfeasance including most egregiously, manual journal entries and related party transactions. From the Business Journal:

The complaint alleges that Gadel and Motschenbacher caused the company to enter into unfavorable transactions with companies in which they had undisclosed, material financial interests, causing the company to overpay for goods and services. Buca also accuses Gadel and Motschenbacher of soliciting and receiving undisclosed kickbacks from a vendor, and seeking and receiving improper reimbursement from the company for personal expenses, such as family vacations, that were presented as business expenses.

Why You Shouldn't Earmark Capital for IT

Bart Perkins of Leverage Partners has a short and sweet piece in ComputerWorld titled "A Separate IT Capital Pool Makes No Sense." While I have certainly argued in favor of valuing IT projects (and their too-common overruns) in the context of the impact they have on the business (cf "The $1.6 Billion Web Site"), Perkins does a good job of breaking out some clear reasons why firms should not provide an earmarked capital IT budget. Several of his reasons are the obvious ones, and most all cache out to the benefit of holding all capital spending to the same standard, but he also identifies out some organizational benefits that occur when IT investments must stand on their own merit.

Gartner on Why IT Offshore Deals Fail

Gartner released some research last week, summarized in this Computerworld article ("Gartner: Five reasons why offshore deals go bust"). I think they are charitable in a number of ways, but the five main reasons they identify are:

Unrealized cost savings. As they point out, while offshore salaries may be lower, the additional costs of management, travel and infrastructure can rapidly eat into those savings, and for shorter-term projects (they suggest those less than one year, for certain) these costs may actually exceed the labor savings. For a more elaborate discussion of this issue, see my comments in late '04 "Thinking About Offshoring As a Solution: What's The Unit of Measure?"

The Double-Edged Sword of Customer Data

Many companies see Customer Relationship Management (CRM) software as an incredible opportunity to enhance their share of wallet of their customers. For large-scale retailers like Wal-Mart, Target or Albertson's, the ability to maintain detailed transaction-level data, when coupled with advanced data mining and analytics tools promises the ability to offer customers the right promotions at the right time as well as better predicting what inventory to have available at which store. This Sunday's New York Times led the business section with just such a tale about Wal-Mart and their use of data mining tools to know that they should get beer and strawberry toaster pastries to stores in regions under threat from Hurricane Frances. (I'm not kidding about the Poptarts, they apparently are big sellers before a hurricane.) But there is a potential downside to having all that data as well.

Project Success Rates Drop in 2004 (And the hidden reasons why)

Frank Hayes wrote in ComputerWorld today about the preliminary results of the annual Standish Group study on IT project failure rates. They are actually up from last year. This year saw 28% of IT projects were entirely successful (delivered expected functionality within budget) and 18% were canceled before completion - complete failures. Last year's study had things at 34% - 18%. Apparently the numbers are not yet finished being tabulated and analyzed, but Hayes learned from Standish that there were a few things of note:

1) Projects are getting bigger again, and we know from experience that big projects are more likely to fail

2) Larger projects have meant a return to more traditional development schedules

3) Lack of user involvement has gone back into the #1 spot for project failure. (Last year's #1, lack of executive support is still running a tight second).

The obvious advice is to work to keep projects small. Hayes correctly identifies well-known reasons smaller projects are more likely to succeed: fewer people means less communication and management overhead; small projects can more easily be developed iteratively with a high degree of user involvement; finally, they avoid the corporate politics that can come to pass with large projects.

Should You Kill That Project?

If you sponsor enough IT projects, it is likely you will most likely be faced with the decision of whether or not to kill a project. The decision is almost invariably a difficult one, with a desire to see the solution achieved vying with a realistic assessment of the project actually achieving the desired outcome. Emotional factors such as corporate face-saving and an the irrational value typically assigned to sunk costs complicate the intellectually challenging task of accurately predicting the final cost and final success of the project. In this installment, I hope to provide sponsors with some thoughts about making that difficult decision as to whether or not a project should be terminated.

Also, be aware that all of these points will also have merit in keeping an eye on projects to see if they are on track or starting to tempt fate. Many projects that ultimately need to be killed either shouldn't have even started or could have been saved had people caught the warning signs earlier.

One of the first things to realize is that, unfortunately, IT project failures are not uncommon. If you are in a large organization, it is a virtual certainty that projects have failed, even if those projects were not killed outright, or labelled as failures, Many projects actually seem to take former Senator George Aitken's advice about Vietnam, namely to "declare victory and go home." The point is: do not make the mistake of thinking that the project failure is truly unique, do not let the fear of being "the only one" to have a failed project prevent making the right decision.

HP's CIO on the ERP Problem & the Art of Diplomacy

A few weeks back I wrote about an AMR Research note on the significant problem HP encountered with an ERP migration; the problems had a material impact on HP's financial results last quarter. This week, Computerworld has an interview with Giles Bouchard on what went wrong with the migration. It's a decent interview, and there are some things to which I would like to draw attention.

The first thing is that the ERP migration that caused the problem was the 35th such migration HP had performed as part of the broader project. The prior 34 obviously went well enough to not cause a major disruption to the business (however, we don't know exactly how smoothly, given that Bouchard also says they planned on three weeks of significant business disruption for this migration). Regardless, the key take-away is that, as they say, shit happens, and even with a proven methodology and approach, it is still critical to plan for contigencies.

One cynical observation I would make about the interview reminded me of a former client, a CIO at a global medtech company, who remarked to me (to paraphrase) "Some of these CIOs I read about must be masterful politicians. You read about projects that completely explode and there's no accountability anywhere in the IT organization." Bouchard certainly could be accused of this. Consider the following exchange:

Things to Think About With Integration Projects

Computerworld reported in July about a new industry group, the Integration Consortium, that aims to make systems integration projects less expensive and more successful for its members. It is a very ambitious aim, and some of their goals are of a "boil the ocean" magnitude. While we're waiting for the ocean to heat up, a better understanding of integration from a business standpoint should actually help improve an organization's integration project outcomes in the near term.

It is a good bet that systems integration, in one form or another, will continue to drive a good chunk of IT value in many enterprises. Integration is what allows more parts of the enterprise (and the extended enterprise of suppliers and customers) work together with less and less human intervention.

At the very basic end of integration is simply getting system A to send data to system B (e.g. sending filled orders to the AR system for invoicing). More advanced integration has systems A & B sending data back and forth (an inventory and order management system communicating, for example). Progressively more advanced integration projects tie together multiple disparate systems and may start to incorporate aspects of Business Process Management (BPM) such that workflows and business rules are applied to the data moving from system to system (for example, managing the return process from the customer service rep issuing an RMA to the warehouse receiving the return and all the way to accounting for credit).

According to the Computerworld piece, The Standish Group estimates 95% of all integration projects fail, that is, overrun their schedules or budgets and/or underdeliver on their goals. Now, this is one of those stats that begs a number of questions, however, even the base number indicates something is wrong with these projects. The Computerworld piece also says industry studies peg integraton costs at 35% of total IT project costs for the average company. No matter how you slice it, this is a big impact issue.

Since I think the Integration Consortium's dreams are a long way from being realized but recognize that integration should continue to be a business technology objective, here are some things the business should think about when it comes to integration in the enterprise: