Easy as Implementing a Package

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 a going through a medical scare years ago. It was time to call it quits and 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 fact 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 $100 million dollar 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 article entitled, “Sourcing Today and Tomorrow,” he said it took many of them years to get the software to work, with some costing hundreds of millions of dollars (man-sized piles). A few had even gotten 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 showed how nearly 100 of their projects performed in terms of cost, schedule, and quality across small to very large IT projects. Among them 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, they 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 – multi-billion 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 “Business Blueprint” phase relative to the “Realization and Preparation” phase is 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 forecast enterprise projects. It also means that if you collect some historical data on non-enterprise projects, there stands a good chance that you can leverage these existing patterns to sanity check your deadlines, budgeted effort, and scope targets against this history. Even better, you can run one of the commercially available software project estimation models to more accurately forecast time, effort, and achievable scope on these deployments. That way, you can get realistic about what you can implement within a given deadline in the first place, and not have as high a risk at suffering from an embarrassing and potentially job-threatening overrun.

This is part one of a two-part article by Michael Mah. Part two will appear in the August Project Times

---

Michael Mah is a Senior Consultant with Cutter Consortium’s Business Technology Trends & Impacts, Measurement and Benchmarking, Agile Project Management, and Sourcing & Vendor Relationships Practices. He is owner/partner at QSM Associates Inc. Mr. Mah is a recognized expert on practical applications of software metrics, project estimation/control, and IT productivity benchmarking. Over the past 10 years, he has published numerous articles on these and other management topics. His recent work merges concepts in software measurement and benchmarking with negotiation and dispute resolution techniques for IT outsourcing and relationship management. Mr. Mah’s particular interest is in people dynamics, such as the complex interactions between people, groups, divisions, and partnered companies working on the technology revolution at “Internet speed.” He is also focused on the latest research and theory on negotiation, including the use of game theory, role playing, and training to increase corporate and personal effectiveness. Mr. Mah is a frequent speaker at major trade conferences, including the Cutter Consortium Summit series, Better Software Conference, the Software Engineering Process Group, Software Best Practices Conference, the Technology Partners International Outsourcing Conferences, the Sourcing Interests Group, and others. Mr. Mah has a degree in engineering from Tufts University. His training in dispute resolution, mediation, and participatory processes is from the Program on Negotiation at Harvard Law School and the Radcliffe Institute for Advanced Study. He can be reached at [email protected].