Implementation Preparation Best Practices

Article Summary: The preparation process – i.e., the “front-end” of a Best Practice enterprise software implementation project sets the basis for what follows. This article explains the common thread of ownership and effective leadership upon which a successful, low-risk implementation project is based. In a subsequent article, we will discuss the Best Practice way of organizing and preparing the implementation team, and then in a third article, the activities of the implementation team – conference room pilot, go-live preparations and support. Topics:

• Background and context factors
• Ownership – the overriding principle
• Leadership – key best practice
• Top management interface

Background and context factors Few business areas seem to be so risk-filled as implementation of new Enterprise software systems. Research has shown consistently that more than 70% of all ERP system implementation result in one form of short-fall or another, ranging from acceptable performance with no real measurable benefit but at a higher operating cost, down through several gradations of difficulty to outright failure. Collapse or bankruptcy does occasionally result, although rare.

A sane business leader reads these research findings and thinks “Yikes! Do we have to do this? There must be a way to reduce or eliminate this terrible risk, isn’t there?”

Fortunately, there most definitely is. Understanding and following proven Best Practices can and will lead to an almost zero-risk implementation project. These are NOT a mystery, although if one doesn’t know about them, they are. Absent proper preparation, implementations become the business equivalent of just jumping out of a perfectly good airplane and hoping that your parachute will open OK. “Banzai!” is not a Best Practice.

In this first of three articles, we discuss the Best Practice way to prepare for an implementation project. This involves understanding the common thread of ownership and leadership that runs through all facets of successful implementation projects.

Ownership – The Overriding Principle

At every level in a Best Practice implementation project there is the principle of ownership. The project that comprises the implementation is, itself a process – one that results in a slew of other processes. This means that the project manager, the team members, and adjunct participants such as those in functional work groups whose role is to interface with the implementation team – all of these individuals must feel the ownership of their tasks, that it is their job to see it through to successful completion, and to work as a team to bring this about.

The principle of ownership and its importance can hardly be overemphasized. Here is why:

• Risk mitigation - The team will not just “jump off the cliff” blindly. They’ll move when they are ready – because it is their project, their success.

• Details – ownership helps insure that participants are truly paying attention to relevant details – and ignoring irrelevant ones.

• Education and training – when non-owners attend classes, one is lucky if they a) show up, b) stay awake, c) retain much. In contrast, if it is my project, my success at stake, I will pay attention and make sure I retain everything I need.

• Preparation for Go-Live – a goal driven team that owns the outcome, the success, will not agree to a go-live until they know they are truly ready. At this point, the risk of failure or serious problems is virtually zero.

• Painless transition – if the team owns its success, and is prepared, the Go-Live is almost just another work day. There is little or no additional re-training of everyone, because they are prepared, looking forward to working with a new, better system and work flows.
  

Leadership – Key Best Practice

When a team of change agents, which is what an implementation team is, is organized, it is vital that, at the very start, that top management display real leadership – backing the team’s efforts, making sure everyone in the company understands their role, its importance, and that management is “in the boat” with the team – and will succeed or fail with the team. The oldest project joke is that the most important task at the start is to “figure out who to blame when it fails.” Unfortunately, this is what happens all too often. Make sure there isn’t even a suggestion that this could happen and your project will go well.

Experience – remember that most people on a project team have, at most, participated in one, perhaps two implementation projects in their career. This is OK, normal, but needs to be factored in. They are learning both how to do this one, and how to do them in an overall sense.

The Machiavelli principle – implementation projects “establish a new order” which has long been identified as carrying high risk to its leader – one where there are few friends, and many enemies. In many of the unfortunate situations the project management ends up consistently in a defensive posture, working in a conflicted state where each step forward exposes the manager to more criticism, opposition, and various fears.

Bearing this principle in mind, senior management can, in effect, “shield” the project manager by providing solid, consistent backing. This must go beyond just budget to clear, explicit leadership via words and deeds that clearly show support and an intention to share all risks associated with the changes being made.

If there is even a hint by top management that, in the event of a short-fall in the project that “heads will roll,” everyone will take cover, and the project will soon make no steps forward without solid CYA material in place, greatly hampering its effectiveness.

Top Management Interface

Every major project in a mid to large sized company needs a process to connect it with the CEO, ideally the Board of Directors, key investors, and C-level executives. There are several ways to accomplish this, such as:

• Executive Management Team (EMT) – in mid-sized or smaller companies, the project leader can just interface directly with the executive top management team. This provides an immediacy and a reality to the endeavor, as the EMT is fairly closely involved, and must understand and concur with all major issues, resolutions and decisions.

• Steering Committee – these can be very effective, or not, depending on how they are constituted, their charter, and how they are led and operated. We define a Steering Committee as an appointed group of senior level executives, either a mix of “C” level and below, or managers who are most affected by the project. Typically these are not the EMT, but are appointed by the EMT to function in their behalf. Hazards with Steering Committees:

• Disconnected from top management – since the project SHOULD be tightly tied to the company’s business strategy, having an additional reporting layer (read: “insulation layer”) allows the EMT the costly luxury of imagining that they don’t need to be concerned with it, never a good idea.

• Second-guessing / excessive approvals – a poorly led steering committee will require the project manager and his / her team to review each detail with the committee at its (monthly) meetings, until they fully understand it, then approve it. This severely hobbles forward progress, needless to say. It occurs when there is weak or no trust of the judgment of the project manager and the team. The trust issue should be addressed head-on, here as in all other circumstances where it occurs and changes made so trust can function – this is the only way true, effective delegation can occur.

• “No-shows” – key managers may miss meetings delaying key decisions, or producing “I’m not involved” attitudes in the missing manager’s mind. It can also foster an attitude of “abdication” instead of delegation.

• Single Senior Executive Responsibility – if the single executive is the CEO or President, this can work, unless his/her availability and access is very limited, typically the case. More likely, if the CEO says “I’ll manage this myself” it is a case of inability to delegate, which of course severely hampers the project. Alternatively, if another senior executive assumes this role, it CAN be very effective. While there are some great exceptions, generally this should not be the CFO, unless the person in this role is unusually operationally oriented. Otherwise it’s like having the CFO have reporting responsibility for all of IT. The financial function, in too many of these cases, ends up with everything it needs, while the operational functions wait, or worse, are starved of budget and leadership. When in doubt, remember the objective of the project – to improve (operational) performance of the business.

Summary of Factors – in the area of project leadership interfacing with the top management of the company, as we’ve seen, the mechanism or process used is not the major factor – it is how it is run or used that determines success. Some guidelines for a Best Practice executive interface:

• Keep the goal in mind – The goal here is a fast-moving, low-cost process that transitions the company from operating with its current systems and processes, to a new one. Everything that aids this process adds value to it, and activities and actions that do not subtract or are just waste – expensive waste. A Best Practice, of course, is to constantly strive to improve this, as with other processes by eliminating waste and improving quality.

• Summary level reporting only – one big time/cost waster is elaborate PowerPoint presentations and reports, which don’t add value. One of our favorite report Best Practices is that of a major global corporation. You are limited to one 11 x 17 piece of paper, both sides, but can do anything you want with it. This is the paper equivalent of the “stand-up” meeting – key issues only.

• Frequent is better – more frequent, short, informal, summary level meetings which focus on unresolved issues that need top management involvement, budget, time-line, schedule, or resource issues. This allows the project to move fast, change plans and directions quickly, without having get bogged down in the “why did the plan change?” kind of discussion, a waste of time.

• Confront CYA head-on – inherent in this kind of reporting structure and project is the desire to look good, look like you knew what was going on from the start, etc. The evidence that CYA forces are operating is when one sees an expansion of presentation materials, reports, minutes of meetings, emails and memos to “document” discussions and decisions, multi-media presentations, and other time-consuming items that do not move the project ahead. Once the project is done, none of this will matter and the extra baggage can, itself, cause the project to not meet its objectives.

In the next installment we will discuss how to form and prepare a successful implementation project team – how to select the team members, and the education and training component both for the team members, and others in the organization.

If you like this article and think it's helpful, please spread the word and digg it.
-