ERP Benefits Still Falling Short?

Computerworld reported a couple of weeks ago on a recent study of the business benefits of ERP conducted by Panorama Consulting Group. Their findings were less than encouraging:

More than half of companies that implement ERP systems end up getting no more than 30% of the business benefits they expected…  Of the 1,600 organizations surveyed, 72% said they were "fairly satisfied" with their ERP package. But this can be misleading, according to the study: "Some executives are just happy to complete projects… and give little thought to whether or not the company is better off with the new software or whether or not they’re getting as much out of the system as possible." More than half (51.4%) of ERP projects went over budget, the survey found, and about 35% of the respondents said their projects took longer than expected.

Depending on whether you believe research from sources like Standish, these figures may simply be representative of broader issues with the success rate of software projects—small consolation, given the central role ERP plays in running today’s businesses.

What to do about it?  The article summarizes the report’s recommendation’s:

ERP customers can avoid surprises by taking the time to pin down a project’s real costs, which go far beyond software licenses. Three quarters of a project’s budget typically goes toward implementation, hardware upgrades, customization and other needs, according to Panorama. Customers should also "identify pockets of resistance within the company and determine the organizational change management needed to make the project successful," Panorama suggested. Altimeter Group analyst Ray Wang agreed. "People do not invest enough in change management," he said. The length of ERP projects can exacerbate dissatisfaction, he added, noting that users’ requirements might change a great deal between the time the vendor is selected and the time the system is deployed.

It’s interesting the degree to which change management continues to be identified as a major point of failure in ERP implementations. Not that I’m suggesting that change management is easy to pull off, mind you—far from it.  But the problem identified here doesn’t seem to be properly funded change management failing in the attempt. Change management has been widely and publicly discussed as a—perhaps even the—critical success factor for ERP success for at least a decade now, since the media coverage of several troubled projects in the late 90s. If there remains widespread underinvestment in it, there must surely be systematic reasons for that—reasons built into the standard ways companies select and design ERP projects. Several likely factors come to mind, but I haven’t seen a widespread, detailed study of why underinvestment continues over time. That’s some research I’d like to see.  If anyone knows of some, please let me know in the comments, I’d love to check it out.

As for the factors I think are at work, I’ll address that in a future post (or posts).

Advertisement

Ed Yourdon on Death March Software Projects

If you missed Michael Krigsman’s post about it a few weeks back, you might want to check out the Ed Yourdon’s presentation on “death march” software projects (which I’ve embedded below).  Those of you who have been on a death march will feel right at home as he describes them, and you may find the advice he offers very useful the next time you find yourself stuck in one.  The presentation is full of though-provoking tidbits… I think my favorite part is the section on system dynamics modeling (slides 89-96).  It outlines why project team dynamics are so complex and so easily underestimated.  Slide 72, “Worst Practices” is also worth a look, especially if you are involved in project leadership, whether as a manager or sponsor.  From that page comes: “Don’t expect to recover from a schedule slip of more than 10% without acknowledging a disproportionately greater reduction in software functionality to be delivered."  I wince to think how often that principle is ignored.

Rome Death March Nov2009

View more documents from yourdon.

ComputerWorld: How to Make Your ERP Roll-out Succeed

If you have been around ERP implementations for a while, you can be forgiven a sense of deja vu as you read this ComputerWeekly article, which says that training and change management “can be the difference between success and failure.”  Poor change management has been recognized as a leading element in project failure for at least a decade now, ever since the high-profile teething pains experienced by SAP and other vendors in the 1990s.  Many articles were written about the challenges faced by Hershey, Whirlpool, and other companies that struggled with their new systems because of primarily organizational challenges, and both ERP vendors and their implementation partners responded by improving their ability to prepare people for the changes a new system introduces. 

The real news then, isn’t that good change management is a critical part of making your multi-million dollar ERP investment.  It’s that ten years later, it remains such an impediment to ERP success:

Microsoft Project 2010 at First Glance

Microsoft’s Office 2010 Engineering blog ran a nice overview of Project 2010 back in October, a quick read that highlights some of the new features in the upcoming release.  Now that the public beta has been available for a few weeks, I’ve finally had a chance to see what they’re talking about—and I must say I’m impressed.  Changes to Project have been positively glacial in many ways, especially compared to the pace of change in the Office suite.  Project for Windows debuted in 1990, for example, yet it wasn’t until sixteen years later that users gained the ability to Undo more than a single action arrived. 

It is immediately apparent when you open Project 2010 that this time is different: there’s a lot here that’s new.  Consider, for example, some of the changes you see as soon as you fire the program up and load a plan:

How Long to Develop An Hour of Training?

Estimation is one of the more challenging aspects of project management, and is central to project success.  Formally or informally, most project work is tracked and evaluated against the expectations set up front for cost and time required.  Inaccurate estimates can have serious consequences for an organization, the project team—and the project manager.

The typical PM learns two things about estimation early in his or her career:

1. It’s a bad idea to offer estimates before you have enough information to properly scope the project, because once people hear numbers coming out of your mouth, they will remember them forever.
2. People will insist you do it anyway.

Good practice says that estimates, especially early ones, should be given as a range, with the width of the range set by the uncertainty of the estimate.  Even then, you still need a starting point.  Enter the rule of thumb.  For those times when you need a ballpark figure to gauge the size of a training project, many managers and organizations have history doing similar work they can draw upon to get started. 

But what if you are just getting started as a training manager, or have never developed a particular type of training before?  What if you want to gauge your personal experience against industry norms?  Back in 2003, Karl Kapp conducted a survey of learning professionals, and wrote an article that compiled estimates for developing of an hour of training using various techniques.  Kapp and Robyn Defelice have recently updated the original article with findings from a new survey.  The initial response pool isn’t huge (47 participants), so the results should probably be used cautiously, but it’s some of the best public data I’ve seen, and the new article covers a broader range of development approaches.  The authors note that estimate duration for several training types of development have increased since the 2003 survey, and suggests that issues with scope and change management—in both the project management and organizational sense—may be responsible. 

It’s also worth noting that the authors are continuing to collect estimates, so if you’d like to contribute to the study, follow the link to the article above and scroll down, or visit the survey directly here.

Should You Hire Technologists for Their Industry Knowledge?

Pat Ferdinandi questions the current trend.

A Cynical Start for a Cynical Series

Barry Otterholt at the PM Hut blog has started a series of posts he calls A Cynical Perspective on Project Management with the tongue-in-cheek “Project Management 101.”  He explains, “Most of us need to learn by our own mistakes, rather than heed the wisdom of others. Here then is the prescription for learning, so you can make the mistakes faster and get to the wisdom sooner.”  It’s pretty entertaining, I just hope there aren’t budding project managers out there who read it and miss that it’s humor.  I’m looking forward to see what else he has planned for the series.

Get the Failure Over With

Why wait for your project to actually fail when you can imagine it did up-front?  Simon Moore at Strategic Project Portfolio Management writes about the use of a “premortem” as a risk management tool.  The supporting research found their use can increase the ability to correctly identify reasons for future outcomes by 30%:

…[P]ost-mortems are, by definition, only successful correcting mistakes after they happen. …Experience may be the best teacher, but that can also prove expensive. Pre-mortems offer a different solution, correcting problems in advance, and eliminating the risk in the first place.

A pre-mortem involves getting project stakeholders and participants into a room before a project starts, making the rather bleak assumption that the project was not successful and then determining the cause. By assuming that the project has already failed, it makes it much easier for everyone in the room to be creative in pointing to potential problems and shortcomings.

I think it’s fascinating that a simple and completely notional change in mental perspective can have such a profound impact on the effectiveness of surfacing risks early.  Moore links to this Harvard Business Review article in which Gary Klein introduced the term “premortem”; it goes into more detail on the research behind the idea.

New Features for MS Project

Microsoft is hard at work on Project 2007, due to roll out later this year alongside the next version of MS Office. Here are two features that ought to be popular with anyone who’s spent any time at all working with Project:

"Multiple Levels of Undo: There was a post from Dieter’s Project blog about this feature. As he explained, it was an incredibly hard to implement feature but amazingly rewarding to see customers reaction! Project “12” will support multiple level of undo but we have gone beyond that and also support custom batching of VB code. What that means is that you can wrap any VB code with new functions that will become an undoable action. This is great if you have custom Add Ins or have extended applications running with Project.

"Task Drivers: Many of our customers had some problems finding out what happened to the schedule, so Project “12” has this new feature called Task Drives. A common question you may have when looking at your project schedule would be “why has a task moved to a certain date?” Now, you are able to select that task and see what is driving that task to be at the state it’s currently in."

Sounds like initial user response has been positive, to say the least:

I thought that this was a funny story about the Project Conference.

During Tuesday’s keynote by our GM, Mike showed off multi-level undo in Project. Our VP was sitting in the audience and heard the person next to him gasp and say "Oh My God …" The audience burst into applause after seeing Mike undo a bunch of actions.

I admit I never asked myself why this hadn’t been implemented yet; I was simply content to be annoyed it hadn’t been.. Apparently it was quite a technical challenge to make happen.

Estimating Realistic Project Deadlines

Open Loops:

Over at Thinking Faster, Jeffrey Phillips shared an article from The Economist about projects taking longer than expected and going overbudget as a result. Jeffrey states that this is a result of "Sunny Side" thinking. In other words, planning as if everything goes according to plan with no obstacles or setbacks.

Ah, if I had a dollar for every time…

The post continues to describe a formula for calculating project duration based on a formula that factors optimistic, pessimistic, and most likely durations for each task. It’s a good formula, and a good idea to use it, but here’s the thing: this is not a new development. What is described is PERT analysis, a technique developed by the US Navy nearly 50 years ago for the Polaris ballistic missile project. The problem isn’t having a methodology for accurate estimates. The problems are spreading the word and summoning the will and discipline to use techniques like this in the face of pressures to estimate quickly and communicate happy news and predict early dates.