Book Excerpt: Why New Systems Fail

This excerpt is from Phil Simon’s recently released book, “Why New Systems Fail.” It focuses on mid-implementation mechanisms that organizations can utilize to address an IT project gone awry.

The perfect is the enemy of the good.

-Voltaire

CHAPTER 18: MID-IMPLEMENTATION CORRECTIVE MECHANISMS

Introduction

As a general rule, implementations do not just spontaneously combust. Failures tend to stem from the aggregation of many issues. While some issues may have been known since the early stages of the project (e.g., the sales cycle or System Design), implementation teams discover the majority of problems during the middle of the implementation, typically during some form of testing. This chapter focuses on the different mechanisms available to the organization that has reached the point of no return-i.e., pulling the plug on the project is not a viable option. Specific measures include:

Adding Resources
Replacing Individual Consultants
Replacing the Project Manager
“Losing” the PM Altogether
Changing Consultancies
Mid-Implementation Audit
Moving Non-Critical Items to Phase II

Adding Resources

Many PMs and implementation teams do not anticipate the time and resources required during testing. Faced with delays from previous phases of the project, their stopgap solution is to throw more people into the fray. For example, a company has tasked its HR, payroll, and finance managers with data validation. However, those three people are not terribly skilled in tools such as Microsoft Excel or Access

To remedy the situation, the organization involves IT more than originally planned. IT must create an automated tool that performs the validation electronically. On the less-technical end, employees not critical to the project might be asked to spot check some transactions from the new system and see if they match the equivalent transactions from the legacy system.

Note that the simpler the task required the quicker end-users can perform them. It does not take a rocket scientist to look at two paper or electronic paychecks or purchase orders and note any differences. Very little formal training should be required for tasks as simple as these. If shown how to do something or given a formal script, the end-user should be good to go. However, for more involved tasks, it is unrealistic to show previously uninvolved and inexperienced end-users how to perform them and expect quick turnarounds. In these cases, the adding of resources may actually be a net negative.

Let’s consider the example of Atlanta Medical. Henry is the payroll manager on an implementation that is in the middle of testing. In trying to make up time, he involves Aaron, the payroll clerk who had previously been peripheral to the implementation. Aaron attended training six months ago but really has not touched the system since then. It may take so much time for Henry to show Aaron how to process payroll that the time spent explaining the tasks to him actually exceeds the time that it would take for Henry to simply do it himself. Even assuming that Aaron is a quick study, he no doubt will have questions about what to do if and when issues arise, thus taking Henry away from his original task.

Adding more resources can have mixed results. If the right people are involved at the right time to perform tasks within their abilities, then the benefits will outweigh the costs. The bottom line is that adding more people will not always fix an issue and make up for lost time. There is no guarantee that these steps will put a project back on course. What’s more, an experienced PM should know this. When unsure about whether this tactic will work, the PM should ask his or her seasoned consultants about the expected outcomes before committing resources.

Replacing Individual Consultants

From the client’s perspective, there are several reasons that any individual consultant might need to be replaced. The first and most important is an inability of that consultant to contribute at a level mandated by the client. As discussed in Chapter 8, the type of consultancy selected often drives the type of consultants placed on the project. The larger firm might send in a team of consultants, some of whom are more junior than the lead consultant. To be sure, not all consultants possess the same background, skills, and expertise in any system or with the individual applications within that system.

Client senior management typically removes a consultant from a project for two major reasons:

The consultant lacks the ability to contribute at the required level
The consultant has a personality conflict with other team members

This has happened to almost every seasoned consultant, including yours truly. Sometimes clients and consultants just get off on the wrong foot. For example, more technical consultants might come off as abrupt with “warm and fuzzy” end-users, causing conflict.

Clients certainly have the right to remove a problematic consultant at any point during the project, as they are the ones paying the bills. However, the effectiveness of this strategy cannot be guaranteed for a number of reasons. The following general rules apply for replacing external consultants.

First, timing matters. Organizations in the latter stages of an implementation will have greater difficulty in finding a suitable replacement. What’s more, organizations close to system activation should almost never replace a consultant-absent some sort of gross misconduct. It is very difficult for an organization to expect a consultancy to quickly locate and deploy a suitable consultant who can hit the ground running at this critical stage.

Second, trying to address personality conflicts among existing team members is typically more effective than bringing in a new consultant. In other words, as the project progresses, the institutional, system, and business process knowledge of an external consultant may become irreplaceable. Also, it is important to understand the source of the conflict. Is the client upset that a delivered feature in the software being implemented does not work as advertised or as it does in the legacy system? If this is the case, then the consultant is simply the bearer of bad news. Supplanting that consultant will not resolve the underlying problem. A new consultant may provide the answer using different words or in a different voice but the overall message to the client is the same: The software does not work as the client wants it to work without some type of customization.

Third, the greater the depth and breadth of that consultant’s skills, the less willing the client should be to replace that consultant. Replacing the seasoned consultant who diplomatically challenges poor client decisions with a more malleable but less knowledgeable, less skilled consultant may appease a client in the short-term. In the long-term, however, that switch will probably lead to setup, testing, or validation issues. Perhaps the original consultant knew the ultimate outcome of poor setup or processing decisions and was simply trying to avoid them, not merely being difficult.

If a consultant comes across as abrasive from day one, then the best course of action for both the consultancy and the client is to attempt to address the issue immediately. Sometimes it’s simply best to cut the cord right from the start. If a personality conflict exacerbates over time, then the resolution is much less clear. Client perceptions matter and no one should have to tolerate demeaning comments or actions from a consultant on site at $200 per hour. However, client end-users should tolerate an expert consultant who means well and simply wants the project to be successful, even if he or she is a little quirky. (Trust me, working on projects like these tends to make people a little eccentric.) After all, that consultant brings a great deal to the table and will not be around forever.