Down the drain

Hallelujah and amen.

Anything with "project" in the title also ensures failure. Just as in "project management." Please. It's management. Unless the project "managers" have a good process to back them up and buy-in from all managers, they might as well just beat their heads against the wall.

Good news -Most CIOs I know are extremely wary of launching mega-projects. They learned from their late 90s, early 2000s ERP, ebiz,Y2K experiences.

Bad news - Most vendors I know, though, still want to shoot elephants as I wrote here

http://dealarchitect.typepad.com/deal_architect/2005/10/any_budget_so_l.html

$125 million ? That's nothing.
The Irish government wasted 150 million euro ($190 million dollars) on a payroll system before eventually conceding defeat.

This is an argument for SOA.

Large or small, IT projects have a habit of becoming rapidly unhinged if they are not focused on addressing the

realities of the business environment that they will operate in and support. We’ve seen a number of silver bullet

technologies come and go over the last few decades (databases, expert systems, client-server, BPM, and now SOA) which have

demonstrated time and again that technology driven approaches rarely deliver on their initial promise. The lesson

would seem to be that simple adoption of a new technology will not deliver the grand application that (we think) the

technology might enable.

Successful projects place the business centre stage, with technology in the background playing a supporting

role. As Nick and ordaj point out, successful projects address specific business needs, have buy-in from all

stakeholders, and are integrated into business environment in which they will operate. Technology is then pulled into

the project as appropriate to solve specific problems.

Some emerging technologies (primarily SOA) show more promise, as they are part of an emerging trend to take

a business-focused view of IT. However, we must remember that

href="http://www.oasis-open.org/apps/group_public/download.php/15071/A%20methodology%20for%20Service%20Ar

chitectures%201%202%204%20-%20OASIS%20Contribution.pdf">the magic is in how the technology is

applied, and not in the technology itself

.

of course the biggest mega projects in the indurty right now are those at Oracle with Fusion, SAP with its SOA and customer migration, Microsoft as it tries to integrate Great Plains, Navision and other acquisitions...chances of success?

Project size is relative. A small organization can get crushed by the weight of a fairly simple accounting solution project. I receive distress calls weekly from clients who have wasted a lot of cash trying to get a new system live, to no avail. But until they fail, large or small, no one wants to listen to person who says something reasonable like 'let's knock this out in pieces and prove the system one foot at a time." No, the heroic always want to push the entire boulder up the hill at once.

The Lloyds case is 'special.' It's an institution steeped in 300+ years of history where automating even the most (apparently) simple things is incredibly difficult. It also has a special form of accounting that makes solving Rubik's Cube look like a walk in the park.

The point is made very well in the DT article:
"The problem was underwriters and brokers just didn't seem to care about getting involved and making the market more technology based. People in the market felt they hadn't been consulted properly and as a result, the Kinnect solution simply did not get any market momentum."

In other words - no buy in.

Nick's talking rubbish in places. I just don't see the connection with his thesis and the DT report.

Many of the projects I've seen fail are as a result of poor project management. Who talks about that? It's not always the case the software was particularly poor or 'not fit for purpose.'

In recent years, software has improved immeasurably - the days when Oracle warehouse numbers failed to balance when represented in the GL are gone. (Or at least I've not heard that one recently.) Sure, vendors make mistakes - it's the nature of software that it's imperfect. But there's a difference between imperfection and crap.

The minute companies try replicating existing broken or less than efficient processes they build in failure.

Where vendors and SIs do have a responsibility is in over promising. They get away with it because they have knowledge the customer doesn't and which the customer has no way of testing. Simple solution - don't pay for what you don't get. Look at what happened with i2?

To Tom's point, I'm assuming he's talking about relatively small companies. Very often, what I see is a failure to understand the significant operational change that new software brings combined with inadequate training and communication.

As to Sam's point. How is this a case for SOA when there was nothing there before?

There's no magic wand in all of this but a more careful analysis is needed if companies are to learn the lessons of others. Anyone want to put their hand up and say: "Hey I screwed up?" didn't think so.

Perhaps you would like to comment on your colleague Nicholas Timmins' write up of the NHS IT megalith, er, project. (FT 16/01/2006). He sounds very optimistic about it. :)

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

URL:
Remember me? YesNo

Comments:

Rough Type is:

Written and published by
Nicholas Carr

Designed by

JavaScript must be enabled to display this email address.

What?