Planning and Control of Application Software Package Implementation Projects

This article originally ran in the Business Software Review.

Updated version Copyright? 2003 Systems Management Resources, Inc.

Introduction

Application software packages are more functionally rich and more reliable than ever before. Today, every application area from banking to manufacturing has multiple package options for each of its major business functions. Many vendors, responding to customer pressures, now have internal quality assurance programs and active product support organizations. Why then do the missed schedules, cost over-runs, irate users and lawsuits continue to plague those of us who are buying and installing them?

There are two basic reasons for these continuing problems. First, we are attempting to automate increasingly complex and unique business functions with ?packages? and often seriously underestimating our real resource commitments. Second, we are attempting to manage these projects with inappropriate methods. Somehow along the way, the ?rules of the game? changed, and the tools and methods that served us so well for in-house development no longer seem to work. We acquire and install package after package and come to accept as normal the serious problems that recur with each new attempt. Vendors become defensive as those of us who have been burned before approach them in a cynical and often unreasonable manner.

It doesn?t have to be that way. Those companies that recognize the fundamental differences of software package projects and tailor their project management techniques to exploit those differences have the best chance of obtaining benefits that software packages promise. Vendors who accept their role as responsible advisors to their clients and who back their commitments in a tangible way prosper because of their improved reputations. Everybody wins.

In this article, I will look at the ?environmental differences? that all application software package projects share and relate them to the planning and control process. I will briefly discuss some major aspects of plan development and project control. Some specific suggestions on things to do to ensure a viable software project in this unique environment will be offered. A major aspect in the development of a ?fault tolerant? plan is the integration of your users and the software vendor into the project. Consequently, some emphasis will be placed on the integration issue.

So What?s Different?

The environmental difference that creates the most problems is the revolutionary (rather than evolutionary) nature of these projects in you company. For new systems developed ?in-house,? there is often an historical basis. The information technology staff that designed and built the system are very familiar with its technical aspects. They are quite capable of maintaining and enhancing the new system. In most cases, the new ?in-house? system is so long in coming that there is time to bolster weaknesses in the staff or technical environment before the system enters final testing. On the user side, participation in the design of the new system often creates the feeling of ownership that is so important to the success of the project. Training on the new system can occur gradually as the system is developed. How very different is a typical software package project!

Often the technical staff is presented a ?sack of software? and some installation guides, with the promise of technical education?later. The source code (when available) is written to different standards. The users are presented with 100 pounds of system documentation and asked to identify any required changes within a very short time frame, in addition to supporting their normal duties. In reality, when the base system is installed, both the user and technical staff need a quantum jump to the learning curve, just to be minimally effective on the new system.

There are also some problems with system expectations in this environment. We all want fast and easy solutions; it?s just human nature. Software vendors encourage us to believe their products provide them. Even the term software package leads us to believe that, if we select one from shelf A and one from shelf B, all our information needs will be met. As a result, the technical staff becomes unusually unforgiving of technical flaws in the product and the user can?t accept the fact that he needs to test the system thoroughly. Unchecked, this situation is damaging to both the vendor and the customer.

At the risk of pointing out the obvious, the presence of the vendor in the project is another significant difference. There are far-reaching implications of a vendor presence in the project plan. At the core of the problem is the presence of a participant, on the critical path of the plan, who is capable of unilateral actions that may help or hinder your objectives.

Many of us have wished for binding contract with our user or information technology departments when trying to stabilize in-house projects. It is only when we deal with a vendor that we usually get this wish granted. The legal aspects of software and services acquisition have been extensively studied and refined in the last five years. While there is a place for legal complexity, the plain truth is that most companies expend five times as much effort on the legal nuances as they do in creating a document that provides for a performance-based business relationship with a vendor. We strain at details and leave in place enormous ambiguities on deliverables. The ambiguities present in most contracts are the source of over 80 percent of the misunderstandings that so often occur between vendor and buyer.

The last major area of difference is the presence of a body of other users of the same base system. This factor provides both major problems and major opportunities in the implementation and maintenance of the system acquired. While customers do compete in many ways for a vendor?s support services, the potential exists for creative co-operative actions between using companies. While some vendors exhibit concerns over such ?collusive? activities, these arrangements are usually to the vendors? benefit, often enabling them to improve their products.

Critical Factors

The first rule hasn?t changed ? it?s ?keep your eye on the target.? In the case of application software package projects, there are actually six ?targets? or, stated differently, there are six factors that will make or break the project, shown below.

Figure 1: Critical Factors For Implementation Planning

It is very desirable for the upper management of both the user and IT departments to have a good understanding of these factors and how they will be accounted for in the acquisition and implementation process. This enables the department to approach the vendor and the user with the understanding of both the required tasks and their interrelationships. In software package implementation projects, the manager with the most effective management system will quickly dominate the project. All too often, this manager is the vendor ? possibly to the detriment of the project.

The first three factors ? requirements identification, business basis and mutual system understanding ? all deal with clarity. In finding the software package best suited to your needs, it is very important to have a good understanding of the relative importance of automated support to the key business functions performed. Many companies do this by contacting the vendors first (?Let?s see what?s out there?) and users second (?Let?s tell them what?s out there?). Reverse this order and you accomplish two things. First, you begin helping the users to climb their steep learning curves. Second, you better position yourself to recognize the important features as vendors begin to sell their wares.

Clarity of understanding the basic functions to be supported in the package and of support levels from the vendor guards against massive cost overruns and litigation. By frequent use of the question ?Just what do you mean, Mr. Vendor, when you say you support ?..?? you can remove the ambiguity from which so many attorneys build a practice. Consider any significant performance representation that is not incorporated into contracts to be wishful thinking as far as project planning is concerned. There are many techniques for incorporating system features and expected levels of vendor support into written agreements without provoking ?vendor paranoia.? Your approach to this needs to be beneficial to the vendor, as well. Communication and cooperation are key to this process.

Fault tolerant planning is required to compensate for your lack of direct control over the base software system and the vendor. It also addresses the ?elevated expectation? environmental issue discussed earlier. The most serious planning error we see is over-optimism in creating project schedules, based on vendor marketing representations. Many purchasers want the ?quick fix? and leap into believe that abbreviated training, enhancement and testing periods are achievable. Reality dawns late in the project and schedules are ?revised.? The use of outside consultants who have knowledge of the true time to expect deliveries and queries to other companies who are farther along in their projects can make your estimates more meaningful. In development of the new implementation plan, provide for occasional ?system update? releases from the vendor and the disruption that this will entail. It is not unusual for the installation and verification of these releases to take from one to four months ? a significant project factor. Lastly, avoid tight scheduling around delivery dates from the vendor. This will provide flexibility that both you and the vendor will use as the project proceeds.

User integration and staff development tasks and techniques address the learning curve and elevated expectation environmental factors discussed earlier. The two main benefits to be derived from addressing these issues are user acceptance of the system and the ability of the IT staff to be self-sufficient in the day-to-day support of the system.

The Prototype Project

Consulting companies are very fond of the terms ?methodology? and ?phased approach.? In many cases, a consulting customer should substitute ?cookbook? and ?excess effort? when confronted with the terms. However, as a framework for customization, a generic plan coupled with a basic understanding of the true project parameters is useful. Coupled with a good project planning and control system, this generic project can be expanded and customized to become the basic management tool of the project. For the most part, the seven phases are easy to understand. As points of definition, however, the ?search? phase begins when vendors are initially contacted. The ?acquisition? phase begins when the primary vendor is selected and contract negotiations begin. The ?installation? phase ends when the basic unmodified software package has passed acceptance testing. Most of the customization and training tasks occur during the ?implementation? phase. ?Maintenance? begins when the system acceptance test for the customized system is satisfactorily completed and the remaining enhancement projects are under 80 hours each. Extra effort that may be required due to subsequent vendor release remains a maintenance function.

Within this framework, your project managers can formulate and execute the required tasks. To illustrate how the critical project factors are addressed within the project environment, let?s look at how the user and vendor are ?managed? during a typical project.

A Necessary Element

Addressing a professional society, I recently made the statement that ?if the problem addressed by the new system is not pressing enough to justify the use of significant user personnel on a long-term basis, the project should be cancelled.? In answering several questions that the statement generated, I realized that simple concepts are often the most difficult to digest.

In fact, early staffing of a user ?task force? to support the project is critical to its success. During the needs assessment phase, key user personnel need to assist systems analysts in identifying the business functions to the supported. They should be very active during the search phase in evaluating systems options. During acquisition, the user is invaluable in ?discovery? of true system capabilities. Since product education, user support and extra cost enhancements are often bargaining chips in negotiations which vendors, the user should be actively involved to ensure that the concessions being sought are the most beneficial ones to the company.

Upon delivery of the base system, early product education of the user task force, combined with a structured hands-on investigation of the system, positions the user to be very effective in detail definition of custom modifications. This early ability to ?touch and feel? the system is one of the major advantages of acquiring a software package.

At this point in the project, look for a critical sign of success: user identification with the project and system. This is necessary because the largest user resource demands are about to begin, and the beginning of the implementation phase is not the time to have contention on the merits of doing the project.

Most software package implementation projects place a larger strain on user resources than upon the information technology staff. The IT staff has 80 to 90 percent of the system code and 100 percent of the architecture available from the start (another package benefit). The user, however, should test the customized package as if it were a new in-house system. Training of user personnel is just as difficult with package as with in-house systems. The user staff on the project peaks during the implementation phase. During the system acceptance testing, the education quality, programming skill, vendor support and the management control systems are stressed. You should have a clear measure of the benefits you have gained by this time if you have used outside consultants to assist in the project.

During the maintenance phase, a subset of the user task force should be kept available to re-test subsequent vendor releases and to verify system performance. It?s to the benefit of the project if continuity of personnel is achieved.

Big Expense, Big Payback

The software vendor can be ether an impediment or substantial asset during this project. Under the buyer?s management control, integrated into the project on a cost-effective basis, the vendor is a valuable resource.

The vendor is one source of valuable information on the systems capabilities and estimated project cost during the search phase and acquisition phase. He can assist in a variety of ways from sending marketing literature to full-scale requirements studies. Unfortunately, this information has a strong marketing bias and therefore needs verification and other more independent sources.

During the installation and implementation phases, the vendor?s in-depth knowledge of the system is best used to increase the productivity of your own staff through education and critical technical assistance. A great deal of care is necessary in this area to ensure that each vendor service acquired at least triples in payback the cost of those services.

In the event that serious project difficulties develop, a good vendor can supply additional resources to assist in recovering the project. However, the object of an integrated management approach to the project is to avoid this requirement.

The availability of product support agreements from vendors, in theory, can significantly reduce your maintenance phase expenses. In practice, this is the service most often abused by vendors. Key to the effective use of product support is the clarity of the performance commitments obtained from the vendor during contract negotiations. The implementation of management controls to structure the request to the vendor and measure the responses is the best approach to ensure a payback on product support expenses.

Overall, a commitment-oriented, performance-based business relationship (as opposed to an adversarial or ?buddy-buddy? one) is the key to effective integration of vendor services.

The Intelligent Customer

Purchased application software and vendor services are often the most effective cost- and time-saving tool available to a company with a pressing information need. Implementation projects based on these packages represent a far more complex project management and control environment than in-house development. By recognizing the special hazards and unique opportunities these packages and services afford a buyer, and by managing the projects accordingly, you can realize the benefits so often promised by these large application software packages.

Ed Praytor is president of Systems Management Resources, an Atlanta, Georgia firm that, since 1985, has specialized in software package and computer services acquisition and implementation projects. Prior to his association with SMR, he spent 10 years in key management, marketing and implementation consulting positions with major application software vendors and facilities managers. As a technology arbitrator for the American Arbitration Association since 1991, he adjudicates disputes that often arise from not following the principles in this article.