Please update your RSS or email subscription to this blog, as I have moved to ZDNet. I apologize for the hassle but please subscribe below:

Here is the new subscription address:

http://feeds.feedburner.com/zdnet/projectfailures

To see this posting, please go to our new blog address:

http://blogs.zdnet.com/projectfailures/

If you subscribe via RSS or through email, you MUST re-subscribe here:

http://feeds.feedburner.com/zdnet/projectfailures

To see this posting, please go to our new blog address:

http://blogs.zdnet.com/projectfailures/.

If you subscribe via RSS or through email, you MUST re-subscribe here:

http://feeds.feedburner.com/zdnet/projectfailures

The Project Failures blog has moved to: http://blogs.zdnet.com/projectfailures/.

If you subscribe via RSS or through email, you MUST re-subscribe here:

http://feeds.feedburner.com/zdnet/projectfailures

To see this post, click here to go to the new Project Failures site.

To see this post, please click here to go to the new Project Failures site.

To see this post, please click here to go to the new Project Failures site.

I’ve started creating posts at the new site; please go there to see the latest:

http://blogs.zdnet.com/projectfailures/

And subscribe here: 

http://feeds.feedburner.com/zdnet/projectfailures 

Effective immediately, I am moving this blog to ZDnet, at the following address:

http://blogs.zdnet.com/projectfailures/ 

If you subscribe via RSS, please update your subscription to the following:

http://feeds.feedburner.com/zdnet/projectfailures

Dan Farber, Editor-in-Chief of ZDNet, invited me to join their blogging community; given the bright folks over there, I thought it would be a lot of fun. There may be glitches during the transition, such as a few missing comments and some bad links on the old posts, but they’ll get worked out during the next few days.

Most importantly, everything about this blog will remain the same: content, posting frequency, subject matter, and so on.

Big4Guy describes costs when implementing SAP or Oracle. The cost elements he describes more or less hold true when implementing any enterprise software, not just big ERP systems. Here is his list of implementation cost components (which I have paraphrased):

1. License cost
2. Legacy data migration
   
3. User interface customizing
4. External consultants
5. Internal project team labor
6. Training

Big4Guy also correctly remarks that implementation costs are heavily driven by complexity and project scope. A larger, more complex system will be more expensive to deploy than a smaller, more constrained project.

For example, if software will be deployed inside a single department, the implementation costs will likely be lower than software deployed across an entire company. Although this is obvious, many project failures could be avoided if stakeholders were not so oblivious to that which should be obvious.

This is off-topic, but too bizarre to avoid mention. From Paul Kedrosky:

Being profitable too soon gives investors, rightly or wrongly, an idea of what the margins are on the business, as opposed to what they could be in some perfect world. As a result, it takes a mighty force for them to not start wading in with discounted present value worksheets, and the like, thus hammering your valuation and generally making funding much more complicated (and equity consuming) than if you were wildly unprofitable.

Yash Pandhi, VP of Consulting for CollabraLink Technologies, writes about project failure on the CIO magazine website:

From my consulting industry’s selfish perspective, I’d love to tell you that big, complex enterprise-wide [software] implementations offer the greatest chance for success. I can’t. An overly ambitious project scope or implementation schedule is the most frequent problem I see in stalled projects. Certainly, some of that excess resulted from senior managers aggressively responding to competitive pressures. Others, I came to learn, grew in size to justify IT expenditure.

Too many consulting companies love huge projects where they can suck every possible dollar out of the customer’s wallet. How refreshing to see a consultant describe the truth: smaller, controlled projects are generally more successful than huge megaliths, which are almost certainly doomed to fail.

For many years, SAP was a poster child for the “not invented here” syndrome. Sure, the company has always been developer-focused, but arrogance in any form is unpleasant. Recently, I’ve heard stories about a new openness at SAP, so I read this post from fellow Enterprise Irregular, Thomas Otter, with real interest:

SAP’s collaboration with Adobe is a great proof point for how things have changed here over the last decade or so. 10 years ago if we had seen the need for a better forms handling tool we would have taken a bunch of physics graduates and a dark room, and two years later they would have emerged blinking into the daylight with a new tool.  Instead, we’ve realised that Adobe know really stuff about forms and building lightweight applications, so it makes a whole lot more sense to work with them, rather than reinvent stuff ourselves.

Thomas works for SAP, but he’s a straight shooter and critical of the company when they deserve it. Therefore, these comments are a serious indicator of positive new attitudes at SAP.

The UK National Health Service is cancelling an IT-related contract due to problems with the vendor. From an article on silicon.com:

The move was taken when it became clear that Atos Healthcare - part of IT services company Atos Origin - was not in a position to provide the services to the timescale agreed in the contract, the Department of Health said.

———————————

Atos Healthcare said in a statement: “The Department of Health yesterday advised Atos Healthcare that it did not intend to proceed with its centrally procured Diagnostic Services contracts for the North West and South West regions. We are in the process of engaging in discussions with the Department of Health to agree the final termination details of the contract.”

The NHS has an absolutely terrible record of IT-related project failures. How did they select a vendor that is incapable of completing the work? One can only guess.

According to the Hawk Eye, Iowa has the distinction of joining Nevada and Wisconsin on our list of recent state government project failures. In this case, A.T. Kearney was hired for $3.4 million and saved the state $2.9 million. From the article:

“When [the project] started, the payment to A.T. Kearney was about 35 percent of projected savings, but it ended up being about 120 percent of savings,” [state auditor David] Vaudt said.

Obviously, the outcome was affected by something expected after the project started. The state says it’s a multi-year contract, and hopes the loss can be made up in the future.

Will this contract pay off for Iowa in the end? Here’s my opinion:

[via fellow Enterprise Irregular Jason Busch] 

CIO magazine presents warning signs for identifying troubled projects:

1. Project team lacks substantial buy-in and interest in the project’s success
   
2. Poor communication between stakeholders and project team members
3. Few interim deliverables, so tangible progress is not demonstrated
   
4. Bad news isn’t allowed to be shared, meaning denial is pervasive
   
5. Project team works lots of overtime, suggesting the schedule is slipping
   
6. Project resources are frequently diverted to other activities
7. Interim milestones are often missed
   
8. Reducing project scope is viewed as an acceptable means to meet budget and schedule requirements

If your project exhibits these traits, you’re a candidate for membership in this exclusive club.

IT-director.com has an editorial stating 90% of SOA projects are failing in a significant manner:

The problem is that for every successful SOA implementation, there seems to be ten that are providing few of the desired benefits. Many of these failures are down to poor understanding of the underlying principles of SOA…

The point is pretty clear, so I won’t say more. Unfortunately, much of the editorial is written in technobabble gibberish, so I can’t recommend that you read it.