Project Management

Why do package implementation projects take so long?

Your third-party IT solution took much longer to implement than you thought it would. Tom Mochal explains why this catches so many CIOs by surprise—and why it shouldn't.


When a company needs an IT solution to solve a business problem, it has three main ways to fulfill the need:
  1. Reuse a similar solution that may already exist at the company.
  2. Develop a solution from scratch.
  3. Purchase a package from a third-party vendor that satisfies most or all of the business requirements.

While more companies are choosing to purchase package solutions to meet their business needs, there is a tendency among some CIOs to think that implementing a package should be relatively easy. After all, the application has already been built and presumably has been implemented in other companies.

These same executives, however, would be amazed to see the cost of implementing packages. Sure, they understand the license cost associated with purchasing the package—but they don’t always understand why the internal implementation costs are so high.

It’s true that packaged solutions can almost always be implemented faster and cheaper than developing the solution from scratch. But the total time and cost required for a package implementation project may still be substantial. Here’s a closer look at why.

What is required?
Consider the main phases in an application development project. Typically these include:
  • Planning
  • Analysis
  • Design
  • Construction
  • Testing
  • Implementation (followed by long-term support)

Purchasing a package means much less design and construction work since the package has already been designed and built before it goes onto the market. And since you don’t need to test basic functionality from scratch, testing time is also much shorter.

In general, design, construction, and testing are where the cost and cycle-time savings come when you implement a package. But what work still needs to be done in a package implementation project?

First of all, you still need to do the planning and analysis. This allows you to document your business requirements so you can evaluate the packages to see which comes closest to satisfying your needs.

You may also require some customization, although in general, the less the core package gets changed, the easier it will be to implement and maintain. Any changes to the base package need to be supported separately by the vendor or your staff. Modifying a third-party package may be essential, but the more changes made, the harder it will be to implement and support the package. Packages that require substantial modification may not be good for your business needs.

You should also remember that since packages are built to support as many business models as possible, you may need to configure the software and select the appropriate options required to meet your specific business needs.

In addition, you still need to test the package with your company’s data to ensure that everything behaves as you expect. This includes internal IT testing by the developers, as well as rigorous user acceptance testing. Obviously, you never want to implement a package without validating for yourselves that it works as intended.

What’s left?
New packages or upgrades require user training. You’ll also need to deploy and implement the package into your production environment.

Many packages require that business processes be changed, so business users will have to be involved in managing and facilitating organizational change. Lastly, you’ll need a period of post-implementation support to ensure that the application is working successfully.

All of this work takes time and effort. The larger and more sophisticated the package, the longer and more costly a package implementation project will be.

Time and money
In 1996, a major company I worked for decided to implement an integrated SAP solution. You might think that this could be done almost painlessly. After all, SAP already has over 25,000 software installations worldwide. Think again.

The planning process was very lengthy, the software complex, and the analysis required to map it against the company’s business processes was extensive.

Also required were cultural changes in the way people did their jobs, which is tough to prepare for and implement. The project is expected to be finished by 2005 and will likely take hundreds of millions of dollars for implementation.

There are many company benefits to having an integrated, packaged IT solution. And while low cost and quick implementation time may not be among them, it’s still cheaper and faster than building everything from scratch.
Are these guidelines similar to the ones you have in your organization? Do you agree or disagree? Start a discussion below.

Editor's Picks