Surviving A Major System Implementation Project, With Your Sanity and Your Team Intact, Part 1 of Series

Series Description

Most organizations go through a major system implementation of some magnitude on a recurring basis. Those implementations can be fraught with peril.  Surprisingly, implementations rarely seem to improve with experience.  There are several reasons for this which relate to the quality of planning, execution and post implementation learning.

This series of articles will share best practices for all steps in the systems implementation process. These practices are sources from numerous implementations at several organizations and many colleagues and educators.  These practices can be the difference between success, failure or that in-between place where many implementation projects end up, (also referred to as Phase ‘X’). Following these practices can help you, as a project leader, to survive and thrive while maintaining your team and your wits.

As with most projects, systems implementations tend to have several well defined phases. The first is early planning, which covers the period from inception through initial authorization of the project. Then will delve into the selection process followed by the implementation planning, execution and go live.  The last section will focus on post-implementation assessments, future phases and how to integrate continual improvement into the culture of your organization.

Points to Consider on a Major System Implementation

Few projects have a greater impact on the operations of an organization than major systems implementations.  These projects can have wide scopes that will change interaction between staff, clients and vendors.  They can affect every employee and can be one of the largest expenditures that the organization undertakes. A major project is one requiring more than six months to complete, that impacts two or more significant business processes or requires a large cross-functional team to complete.

Before embarking on a major system project, leadership must recognize and prepare for the challenges associated with the project. Senior leaders must ensure that the project does not conflict with any other known major initiatives, such as merger or acquisition activities, significant staff change, office relocations or major customer related operations projects.  Nothing can derail a systems project faster than a competing initiative, especially one that is considered “customer-facing.”

Early Planning (9-18 months before expected project kick-off, longer if operational cycle requires)

In the early planning phase of the project, the goal is determining generally the size, scope, timing, impact and rough budget.  The end of this phase is a request for authorization to proceed with the project presented either to senior leadership or the Board. At this point, there should be a clear need for the project, such as near-term obsolescence of existing systems, growth-driven strain on existing system capacity or the strategic expectations of a need for upgraded capabilities. Identify Initial ownership, decision-making processes and support teams.

Initial Requirements

Defining the requirements for the new system at a very high level will help to determine what general options are possible.  It is best to identify all the broad needs and then determine priorities to refine the scope.  This will not be the final assessment, but it is a good place to start.  This step should include discussions with cross functional leaders, customers and vendors to identify any concerns that could be addressed in the project.  In addition, the organization’s strategic plan should be consulted, to ensure alignment of the needs with the expected requirements.  For example, the project need may be for a system that can process 25% more invoices, but the strategic plan could be projecting expansion that will drive a 125% increase in invoices.

While needs are being gathered, it is important to also be thinking about the value of the project. Eventually, in the approval process it will be necessary to define the return to the organization on the investment in the project.  So, during this phase, start collecting data on costs of the current platform. How much maintenance does the current system require? What capacity can it produce? How often does it require updates or upgrades and how disruptive are these?  What is the user experience? How long does it take to process transactions?

Resistance

In the planning phase, it is also helpful to consider the likelihood of resistance to the project.  Since the project will have sweeping changes to the organization, now is a good time to determine the likely reaction. Will this project be one in a long line of systems projects that only serve to complicate and frustrate employees?  Is there pent up demand for change that will add in employee engagement with the project?  Knowing if there will be significant resistance is an important step for planning the project properly.

Costs

With a general understanding of the requirements and value, start exploring the costs of potential solutions.  Now is not the time to investigate too deeply. Plenty of cost information is available on the major systems providers.  Typically, they align to the size or complexity of the organization.  Do your homework on systems costs and likely implementation-related expenses to get a general rough order of magnitude.  You don’t want to go to your Board without some general idea of cost, since the range is very wide. You also do not want to dig too deep at this point or you risk building a solution around a product and that can be a recipe for disaster.

Interim Steps

After the primary requirements have been defined and prioritized, you can make an assessment to determine if there are interim steps required.  If the gap between the current system and the future system is too great, it may be necessary to fill in a few of the gaps with an interim project.  This can occur when processes are manual/paper-driven and the project goal is automated and integrated.  The learning process to move from manual to electronic to automate to integrated may simply be too much for one project.  While planning for the major project continues, an interim project may be initiated to improve a specific process. This will help to avoid delays on the major project.

Impact Assessment

As discussed previously, you need to de-conflict the project from other major ongoing or planned projects. Beyond that, you must determine if the internal resources are available to staff the project.  Can the current staff make the time to support the implementation?  If not, you will need additional staff or consulting costs.  Also, are there project management skills available in the staff or are the IT resources available experienced in the types of systems that will be considered? Any skill or educational gaps need to be considered so that training costs can be factored into the budget.  If your current system is home-grown, or is a simple “out of the box” product, it is unlikely that your IT staff will have the capacity to manage a more complex system.

Communications

Another step is to determine the communications process for the project.  Communication plans vary with the size and distribution of the organization. If your organization is geographically dispersed, then you need to consider different engagement and training tools.  The goal is to identify any additional communication costs to add to the project budget and plan.

Informational Board Presentation

So, by the end of the early planning phase, you have a clear set of requirements with prioritization and a general idea of cost magnitude. You have identified interim stage requirements, collected information on value drivers, capabilities of staff and resources required to fill gaps.  That is a good set of information to present to your Board for initial authorization to proceed to procurement.

Every Board is different. However,  I strongly suggest that you complete an informational presentation to the Board prior to procurement phase. That phase is very time intensive and engages vendors to produce work, as well.   Before starting procurement, you need to know that the Board is comfortable with the project’s size, scope and potential cost.

The initial Board presentation should establish the need for the project, the general parameters, resource requirements and timeframe for completion.  This is your Board’s opportunity to ensure that the project aligns with the organization’s strategy and does not conflict with any major initiatives.  The Board’s oversight role is to understand the need for the project and to gain comfort with management’s plan for procuring and implementing the system.

An informational presentation to the Board includes the following;

• A summary of the project
• A clear, concise definition of the problem and the expected value
• The scope boundaries for the project
• Significant projects or initiatives that the project might impact
• Ownership of the project, decision-making processes
• The procurement process, including cross-functional user representation
• A discussion on the expectations of how the project will integrate/interact with the current IT infrastructure
• Resource requirements, including; rough order of magnitude of costs, labor required, any external support
• Value drivers, including; future headcount impacts, customer service impacts, velocity of cash flow and process or other resource efficiencies
• Initial expected success factors, such as, decreasing billing errors or cycle time or complying with an upcoming regulatory requirement
• Communications plan, including; next stage timing, staff communications and any interim steps to be taken before the project is brought to the Board for formal approval.

Going through an Informational Board presentation is a good way to avoid rework later. It limits the risk that the Board will not agree with the scope, timing or resources required for the project.  In addition, there may be the need for a capital fund raising campaign to support the project.  As best practice, pre-work with the Board is always helpful.  If management is pondering a major systems project, it should be discussed early on. That way the Board is not surprised when the Informational Presentation occurs.  The CEO and Board Chair should work together to determine how to engage the full Board.

Wrap Up and What’s Next

In this article, we reviewed the early preparation and pre-work necessary to initiate a major systems project. With steps listed in the article, you should have a clear understanding of the size and scope of your project. You should also have leadership and Board buy-in for the project. This will be critical for obtaining final approval for the project expenditures later.

In the next article of the series, we will explore the Procurement Process. The article will share best practices for running an effective and efficient procurement process. I cannot stress how important good procurement practices are to the successful execution of a systems implementation project. Anything missed or overlooked during procurement will cause chaos, confusion and costs later.

Make learning a shared experience. Share your thoughts on this topic in the comments section.  Thanks! –mike