Our Thinking

Managing Package Implementation Projects

Posted by Aurore Stacker on Jun 18, 2012 12:54:14 PM

As more packages become available on the market, many organizations are opting for this approach rather than developing their own application, especially if they are not viewing the solution as a market-differentiator. Unfortunately, many organizations are struggling in their attempts to successfully implement off-the-shelf applications.

The key to a successful package implementation is recognizing the differences from a custom development project and managing the project accordingly as these differences engender a unique set of challenges and organizational implications.

Two primary differences of package implementations are: 1) the presence/role of the vendor and 2) the need for immediate familiarity with the application.

Dependence upon a Third Party Vendor

The package vendor plays a key role in a package implementation project and is in a position to assist in your success or to contribute to your demise. Your team is dependent on the vendor for a myriad of tasks such as providing:

  • The application
  • Initial training on the application
  • Data models
  • Conversion specs/scripts, etc.

If the vendor is unable to meet your timelines for their activities, how can you possibly meet your overall timelines?

The best way to manage this wildcard is with a well-crafted contract that details what the vendor is to provide and when it is to be provided. Tying vendor payments to deliverable deliveries will also help as cash flow can be a compelling argument.

Vendors typically bring an implementation methodology to the table, however, you need to recognize that their focus may be narrow and oftentimes limited to just installing the package. When this is the case, you need to supplement the implementation approach with the other activities typical of a project. Consider the need for:

  • Gap analysis and resolution
  • Determination of workflows
  • Development of interfaces
  • Data migration and conversion
  • Hardware and end-user devices
  • Organizational change management and end-user training

All of these need to be woven into a cohesive schedule with the vendor’s activities.

Even with a detailed contract, you will need to add vendor management to your ongoing activities. Be prepared for surprises such as vendor product releases that might impact your project timelines as well as sudden demands on your vendor representatives from other, perhaps “more important,” clients.

The Need for Immediate Familiarity with the Application

The second primary difference – the need for immediate familiarity with the application – can be a challenging one. As with most projects, you will want to be firing on all cylinders as soon as you start. In other words, you will want all components of the project to be up and running concurrently as soon as possible.

None of your teams, however, can proceed until they have a reasonable understanding of the application. This is why early training for the project team is a must! Everyone will need a basic understanding of the application and each team will also require specific knowledge. For example, if custom reports are to be produced, the reports team will require an understanding of the data model. The interface team will require an understanding of the interface messaging protocol available within the application. The configuration team will require an understanding of how the configuration tools work and the implications of the various configuration settings. Be sure this training is scheduled right away and include as many business resources from the project as you can.

In custom development, the application design evolves and there is time to proceed with the other components alongside with its development. Not so in package implementation. Because the package is in essence “ready,” everyone wants it implemented right away! This is oftentimes compounded by the vendor literature and sales pitches that make package implementations sound easy and fast. Managing these client expectations can be a challenge.

The “suddenness” of a package also tends to be a challenge for business users on the project. Contrary to custom development where they have input into how the system looks and operates from initiation through to implementation, they are faced with making business decisions well in advance of being comfortable with the application. This can result in all kinds of behaviours stemming from uncertainty and fear, such as wanting off the project, rejecting the application, feet-dragging and so on. Effective change management is critical and will likely start with the project team.

Common Mistakes

Two of the most commonly repeated mistakes in package implementation projects are:

  • Not paying attention to requirements
  • Not planning for adequate testing

The argument that we don’t need to understand requirements because we’re just going to put in the package will lead you down a path of misery. Avoid that walk at all cost. You must do the diligence of understanding the requirements so that gaps can be identified and solutions implemented to address the gaps. Otherwise your solution will be incomplete and your client unable to reap the intended benefits. This does not spell success.

Assuming that packages do not require testing because they are packages and, by definition have already been tested and implemented many times over, is a very risky proposition. Here are but a few reasons why you should plan to test your package solution:

  • The vendor may have recently made changes to the application and you are the first customer to have them applied.
  • Your organization’s configurations are likely unique and need to be tested.
  • Any and all custom development within the package or related to the package such as reports, interfaces, data conversions will need to be tested.
  • To ensure that the future state workflows will work with the package.
  • Perhaps you are the first installation!

In summary, package implementations share many of the same attributes as a custom development project and your best practices still apply. On the other hand, there are differences between the two that need to be understood and managed accordingly to ensure a successful implementation.

Topics: Leadership, Methodologies

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts