March 3, 2007

Last weekend I had a conversation with an uncle who recently retired from his accounting job at a large university. His family was financially secure, the children were grown (with his first grandchild on the way), and he was healthy after going through a medical scare years ago. It was time to call it quits, start to restore the antique motorcycle his wife had given him for Father’s Day last year, and get ready to bounce his new granddaughter on his lap.

But before it was official, his employer asked him to reconsider, for one more project: deployment of an enterprise (ERP) application across all the colleges of the university. “There was no way I was ever going to stick around for that,” he told me.

Most of us don’t have the luxury of tipping the hat and bidding adieu like my Uncle Larry did in the face of a life-changing project presented by the boss. And life-changing it will be for a lot of people. What started out as a US $100-million project has ballooned to $250 million. As a friend once said to me, “Now we’re talking about a SERIOUSLY BIG man-sized pile of money!”

It’s no wonder that my fellow Cutter colleague Steve Andriole said that not one of the CIOs and CTOs that he had spoken to in the last few months would install their enterprise applications again if they had a chance to do it over. In his recent Cutter Trends Advisor entitled, “Sourcing Today and Tomorrow” (15 February 2007), he said it took many of them years to get the software to work, with some costing hundreds of millions of dollars. A few had even been fired when they exceeded their budgets and schedules. Do you really wonder why some folks head for the hills when the boss says the words, “Oracle,” or “SAP” implementation?

I don’t think it has to be that way. One of my clients — a large financial services company — has a solid benchmarking initiative in place that shows how nearly 100 of its projects has performed in terms of cost, schedule, and quality across small to very large IT projects. Among the projects was a group comprised of package implementations, all plotted against industry trend lines. We color coded those projects on the graphs using a legend convention showing them as blue squares, with the rest of the projects plotted as green circles, to distinguish the ERP batch from the overall sample.

The good news: In almost all dimensions, the ERP projects behaved like the other “traditional” projects! The bad news: some had overruns and slippages just like the rest, and the piles of money for some of the overruns were pretty big. But not all behaved that way. Some were quite successful, showed high levels of productivity, and were right on target for the scope, meeting their deadlines, and finishing within budget.

What does that tell us? That ERP projects can either succeed or fail just like any large-scale IT project, and in my view, it is within our ability to influence their outcome. Enterprise application projects are not going to go away anytime soon in my view. Andriole thinks that CIOs will stop doing them, rent versus buy-and-install (going the ASP 2.0 route), and shift to software as a service (SaaS), but I think that will take a long time. Meanwhile, big organizations — multibillion-dollar corporations — still need to run their businesses. Their legacy systems will either take ongoing care and feeding, or CIOs will make the shift to companies like Oracle or SAP to keep the ship moving. Like it or not, companies will have to get better at managing this kind of work.

So here’s some more good news: I believe that it’s possible to better understand, manage, and predict how these projects behave, and not suffer from year+ delays, cost overruns, and poor reliability. Having worked with dozens of clients doing package implementation and deployment projects, including the major enterprise application vendors, here’s what we know about these kinds of projects:

■ Productivity on ERP projects is very similar to traditional IT (development) projects. Their schedules, effort/cost profiles, and defects position similarly against other software project trends.
■ Three distinct classes of complexity seem to drive their behavior: upgrades (lowest complexity), standard implementations (medium complexity), and global deployments (highest complexity).
■ It’s possible to “size” this work by estimating and counting elements like business processes (number of major/detailed processes) and the custom artifacts to implement them (i.e., reports/tables, interfaces, conversions, enhancements, and forms).
■ The effort proportions for things like the “business blueprint” phase relative to the “realization and preparation” phase are highly similar to the proportions seen for the “requirements/design” and “construction/test” phase on traditional software projects.

So here’s the tricky part: traditional projects have long suffered from cost overruns, schedule slippages, and cuts in scope, so tell me again why it’s good news that ERP projects behave similarly?

It means that companies that have improved their ability to measure and estimate their projects can apply the same skills to better forecasting enterprise projects. It also means that if you collect some historical data on non-enterprise projects, there stands a good chance that you can le