ERP Implementations: Resolving Obstacles through Thoughtful Leadership

Leaders carefully choose their involvement.
When the work is done, their team will say
"We did it ourselves!"¹
—Lao Tzu, Tao Te Ching, chapter 17

It's a known fact: ERP (enterprise resource planning) implementations are very difficult, but they can be highly beneficial. When the business case development is complete, the contracts are awarded, and the fundamentals of project management are in place, the leadership team needs to prepare the project team for the rigors ahead. Resources need to be allocated and monitored. Communication and collaboration are likely to become strained. Engagement will ensure that the planning is effective, the changes are managed, and the work is interconnected. Introducing a new product requires a balance between continuing with existing operational norms and adopting new best practices. Being sure that everyone in the institution is ready and aware of the project requires effective change management and training strategy. Invariably, problems arise and require mitigating actions.

With numerous technical obstacles and sometimes intractable personnel challenges to be overcome, success is best measured a year or two after go-live. The most promising aspect about an implementation is that it fundamentally re-creates how an organization conducts its business. Ongoing excavations of old processes often reveal long-accepted deficiencies. The potential to fix these gaps is tantalizing, but this opportunity gradually collides with a practical realization that not all problems can be solved as new ones emerge. Guiding an organization through this process while managing the impact of change requires thoughtful leadership that effectively resolves obstacles.

Preparation

Planning work that is performed before the start of the project will pay dividends in the future.

• Leadership Responsibilities. A successful project requires a strong leadership team to drive change and ensure adoption. Identifying the appropriate individuals for leadership roles, establishing a leadership hierarchy, and outlining a shared vision, goals, and governance process are key. The particulars of governance and leadership roles are too extensive to list here and are context-specific to the size of the organization and the project. But in general terms, the following roles and responsibilities should be specified:
  • Executive sponsor: arbiter of functional team performance and business goals
  • Program lead: vendor management, conduit to board; lead executive steering committee
  • Project manager: overall project scope, deliverables, and tasks; lead steering committee
  • Functional leads: oversight and coordination of functional objectives; lead functional teams
  • Workstream leads: front-line teams, objective focused, and issue escalation; lead area teams
• Backfill. The project will be highly demanding of key people who need to focus on the project and who will not be able to attend to regular business operations. Teams with sufficient redundancy may not need backfill, but areas with key person dependencies will benefit from backfill. It is ideal to onboard backfill positions three months before the start of the project to provide time for knowledge transfer with key individuals. Similarly, plans should be made to end backfill contracts three months after project completion in order to provide help during post-live stabilization. Also, hiring full-time regular positions and offering a retention bonus can help retain backfill before the contract ends. A backfill strategy helps ensure a high level of resiliency and adaptability: at its best, backfill can operate as a strategic reserve.
• Time. As the project progresses, it will demand a greater amount of time from an increasing number of staff. Several key staff may reach a saturation point before project demands are met. The mitigation of time contention includes the delegation of work or the addition of resources. Note that the addition of resources is easier and more effective the earlier it is done in the project: an individual who has already become overwhelmed will struggle to find time for knowledge transfer with additional help. A good barometer to note is that the final three months of the project—when major issues are resolved and the sprint to go-live occurs—are the most demanding and intense. Thus, if consistent issues of time contention are identified early, mitigation is likely necessary.
• Vendor Management. An implementation effort has five components that may be provided by vendors: (1) implementation; (2) training; (3) change management; (4) staff augmentation; and (5) post-live support. Important areas to monitor closely include consultant availability, performance, and communication. Vendors operate differently based on their role: staff augmentation vendors tend not to have a strong connection to their consultants, whereas the currency of implementation vendors is long-term relationship-building. Naturally, having multiple vendors on a project creates challenges. Perhaps the most difficult of these is the "seagull effect": a consultant who offers input that isn't helpfully connected to an established context and who then leaves for the next task with no ownership of what just occurred. Mitigating for this is time-consuming and requires strong partnerships with vendors.

Communication and Collaboration

An ERP transition is the largest project many staff will experience: the level of complexity and coordination required over a long period of time is unique. Further, working across functional areas in such an interdependent way is uncommon. Several experiences can help set expectations for team members.

• Information Gap. Gaps can occur between someone who knows something important and someone who needs to know but doesn't. This can happen when multiple discussions are occurring concurrently and key people have to triage their attendance. Another form of gap occurs when a problem is identified, discussed, and resolved before some stakeholders even knew that the problem existed, let alone that action was taken to resolve it. Some gaps can occur in ways that are unavoidable, but other instances may reflect a breakdown in communication. For example, if a team member and a consultant do extensive work that runs counter to a key decision, the impact of such a divergence may not be recognized until it is too late. These gaps can be managed with strong delegation processes and a regular communication cadence for teams.
• Problem Solving. As a consequence of the information gap challenge, in a fast-moving and complex project with many participants, it isn't immediately obvious when something bad happens (e.g., a mistake or omission). Time is required to untangle and identify particular problems, during which period more damage may occur. Since remediation plans sometimes require patience to see results, a problem may have persisted for several weeks before being effectively resolved. Rapid identification and escalation of problems is therefore necessary for efficient problem solving.
• Changes. Requesting a change has a direct correlation to budget and timeline. Changes are a necessary and normal part of any project, but they need to be organized and controlled. Thus, gating questions can establish helpful guardrails: is this a feature request, a reversal of a past decision, or a fix of something that doesn't work as intended? There may be different perspectives on what needs to be fixed. When functionality technically works, but not in the desired way, is a change necessary or is it better to accept the shortfall to save time? Even though establishing a clear and rigorous process to funnel changes requires time and attention, this is an essential communication and collaboration tool.
• Planning. At any given stage of the project, planning for the next stage is necessary. This is another important source of time contention when team members (naturally) want to prioritize working on current tasks and communicating and delay planning for later. Planning is most effective when the organization that is implementing the ERP system drives the effort, as opposed to relying on a consulting partner. Depending on the speed of decision making in the organization, effective planning might need to begin a month or two before the start of the next project phase. As former US President and Army General Dwight D. Eisenhower explained: "Plans are useless, but planning is indispensable." While planning cannot anticipate all the work ahead, it is necessary throughout an implementation, from kicking off the project to planning for post-live support and governance.
• Time Distortion. Large implementation processes often feature significant information flows to mitigate the challenges described above. While increasing communication flows is an obvious and "easy" solution, doing so results in more meetings (to say nothing of the effectiveness of meetings), which reduces time for technical work and puts pressure on oversubscribed staff. In this environment of frequent communication, there is an ancillary effect of distorting time: a decision made yesterday "feels like" a week ago because team members are cognizant of the volume of activity that transpires in a single day. Recognizing this can help prepare team members for stressful events when someone may feel that an information gap of a day or two, for example, is tantamount to no communication at all!

Design

Implementing a new ERP system requires building it to meet organizational requirements. Sometimes organizations implement a new ERP system precisely because they are not operating efficiently and see the system as a vehicle for establishing new best practices. In this situation, can an implementation vendor provide "best practice" advice? Maybe not. For one thing, consultants are ideally situated to discuss what is possible rather than what is "best." Further, a healthy consultant service model is to acquiesce to customers' requests and find ways to make them work. Finally, while consultants may have experience building a variety of ways to get a solution in place, there are a multitude of best practices. And in any event, consultants don't stay long enough to see how a solution ultimately works for the organization. These qualifications notwithstanding, it is possible for a consultant to fully dive into organizational business processes, identify the needs of all relevant stakeholders across campus, and then give guidance on best practice design. But this approach requires an extensive discovery phase before project kickoff and entails additional expense. Otherwise, the more common and effective route to obtain a best practice solution is through experienced functional leaders.

A similar question to adopting best practices is, how do you know if the design is what it should be? A standard project methodology doesn't provide design validation, and vendors who have a delivery-assurance process can belie the importance of project governance to incrementally drive this review with respect to the project goals. The best general approach is to ensure that a diverse and authoritative group performs the work and that stakeholders are consulted regularly. This sounds obvious, but it comes at a heavy price: it requires a high level of staff commitment and availability. For example, the recruiting function of an ERP system should ideally have three distinct groups designing how recruiting occurs for the three categories of employees in higher education: faculty, staff and student workers. Failure to be sufficiently inclusive and authoritative during a design process will lead to post-live shortfalls that can negatively impact the organization in a variety of ways. Two additional questions relate to nuances when addressing the quality of design work: Are staff considering the whole picture with a mind to variances, as opposed to focusing on exceptions as guardrails for a thought process? Is the implementation partner explaining all the possibilities of how the software can work, or is there a tendency to "lift and shift" by making the new system operate in a way similar to the old system?

Training and Change Management

The quintessential question in training functional users is, when should training occur? What comes first: doing the job, or being trained to do the job? Experiences vary, but the following five tenets should be considered:

1. Training must occur before consultants are gone so that functional users can operate the software.
2. Training is a prerequisite for the transfer of knowledge from consultants to functional users.
3. Functional users will become busier as the project progresses.
4. Training availability constraints from vendor and staff schedules can create time variances.
5. Training that is done too soon before hands- on work will likely be forgotten.

In sum, there isn't an easy answer to the question, but a reasonable approach is to implement a steady training regime that neither occurs all at once nor waits until the end. While this is difficult to accomplish, it is possible with good planning and resource allocation. In a similar vein, training the campus community needs to occur before go-live. This is an important source of community feedback that will provide insights into adjustments needed before go-live.

Higher education organizations often have varying degrees of decentralized environments, all of which present a natural parry to a centralized system change like an ERP implementation. Change management is an organized approach to implementing training and communication to prepare the campus community for system adoption. The highest-level governance team (e.g., the executive steering committee) should have close oversight into these activities. This work is directed toward various constituencies including the board, executive team, mid-level managers, project participants, and members of the campus community. Successful change management requires several predicates:

• The team needs to understand the prospective work of the project.
• The team needs to be aware of the capabilities and limitations of the new system.
• The project needs to be running well.
• Technical and business decisions need to be carefully and properly tracked, communicated, and escalated.

Finally, when change management is outsourced to consultants, a few points of caution should be kept in mind. First, change management consultants are more likely to perform work that doesn't have clear outcomes. Second, the scope of work can sprawl without tight controls and oversight. Third, externally driven change-management activities often become a point of resource and time contention for the project team.

Testing

Testing during implementation is an iterative process of checking work done to date and making changes that align to expectations. Testing is the penultimate quality-control exercise that requires a thorough understanding of business process in a myriad of permutations. This means that broad participation is essential, but adding individuals who haven't already been involved in design or configuration work can be problematic. Doing so slows the testing process and runs the risk of critiques about design decisions that may be counterproductive at a late stage. If crucial stakeholders cannot be included from the project start, an effective approach in project planning is to add considerable time after user testing to account for revisiting anticipated design changes. Short of either approach (early inclusion or additional time and budget), broad participation in testing can only help the team develop awareness of issues to anticipate after go-live and thus influence training around go-live. In cases where testing is limited to a small group of individuals without expansive knowledge of how users perform work in the system, the post-live system is highly likely to suffer operational obstacles that will have adverse business impact.

In the event that an internal team lacks the necessary resources or knowledge, consultants might be suggested to help drive the testing process. The essence of testing is a quality-control exercise, however, and thus must be driven by the institution, for a variety of reasons. First, only the institution can validate whether or not the work hitherto performed is appropriate for the organization. Second, testing is a validation of the design and configuration work performed by the consultant teams. Third, testing is the first opportunity for transference of ownership and knowledge to functional areas. For example, any dispute about improper consultant work is best identified during testing. Disputes after testing have amorphous attribution: did anyone identify the issue as something to test? Was the issue simply missed during testing, or was it something missed in design? An organization that successfully plans for the testing process and has functional areas that assume full ownership over the process can ensure a high level of confidence in the quality of the product delivered.

Problems

Projects invariably have issues. While it is important for leaders to stabilize problems, doing so requires a balancing act of responding expeditiously but not overcorrecting. Bill Gates once noted: "Bad news travels fast in a successful organization." This is good to keep in mind, but consider also that inaction is sometimes wise: delaying problem dissemination might be the way to go when the criticality of the issue takes time to understand. For example, let's say in the morning a major crisis arises about problem x requiring a redesign, but by the afternoon a simple workaround is found! Disseminating an incomplete picture may have caused unnecessary disruption. Further, rumors can form when issues are communicated too quickly without a comprehensive follow-up about the solution, a situation that can then snowball into a perception of frequent problems. Thus, steady leadership is required to manage expectations and communication around problems.

It is helpful to consider context for some of the major types of problems that can occur on a project. The most serious problem, short of cancellation, is a delay coupled with cost overruns. Cost overruns can occur without a delay (e.g., increasing resources needed to ensure the timeline is met), but as a general rule, delay requires cost increases.

• Delay: If a delay is necessary, how long does the delay need to be? Consider that the sprint to go-live is typically a multi-month process. As a result, a minor delay may be a three-month extension: a few weeks to fix the issues identified, before going through a go-live process. Further, consider that payroll implementations are easier to reconcile on a quarterly basis for year-to-date tax accounting reasons; thus, delay increments tend to be thought of in terms of three-, six-, nine-, or twelve-month options. It is helpful to build a budget contingency that is structured in terms of delay: for example, a contingency that models six months of additional consultant spend and concomitant backfill costs.
• Consultants: Complaints about consultant performance may occur. Over time, a documented pattern of issues can make a strong case. Changing consultants is hard, but retaining a failing consultant is harder. Thus, issues may reach the point where there is a need to reclaim dollars or even change vendors. Such challenges require a balance between judicious calculation and decisive decision making. Alternatively, issues with consultants may ultimately point back to internal deficiencies. On other occasions, a complete reversal can occur: inaction on a request to remove a consultant may lead to a consultant who becomes an indispensable team member for the project. In all cases, a deliberative approach and strong partnership are necessary.
• Disorder: While harmony and equilibrium are hallmarks of success, disorder occurs in the absence of good systems (e.g., project management, governance, and leadership). Red flags include general confusion, lack of communication, unclear delegation, unfulfilled core project tasks, poor coordination between teams, and insufficient accountability mechanisms. Stressful and difficult work can cause people to fall into counterproductive habits and to make poor decisions in the absence of good systems. Imagine, for example, a functional lead who will not follow any planning process for the configuration or testing phases of a project. Establishing a robust leadership team with strong governance, in tandem with the consultant team, can avoid these issues.
• Drama: High drama tends to occur over relatively small issues, whereas icebergs are more muted (and hidden) affairs. While problematic behavior comes in many forms, two of the most interesting roles that can adversely affect a project include (1) managers who impact their team members through reassignment, reducing time on the project, stopping work on the project, or giving contradictory orders to project decisions; and (2) someone who has key knowledge or extensive historical knowledge and who is negative about the project and keen to identify problems and deficiencies but disclaims ownership in resolving the issues identified.
• Perceptions: A funny saying about projects is that sometimes you need to get all the liars in the same room. This can happen because the issues are complex and nuanced: someone may correctly state that x is fixed but someone else needs to fix y, whereas another person states that y is fixed but x is not. This is contradictory, of course, but perhaps only because the larger picture is missed. Perhaps x and y are fixed in ways that work internally but that don't work in concert. Alternatively, maybe z is set up in such a way that any fixes to x or y will not be sufficient. Bringing people together to troubleshoot issues is time-consuming but highly effective.
• Attrition: This problem deserves distinct mention because of how difficult it is to manage. Attrition permeates teams in ways that are both immediately obvious and not fully revealed for months. Small things are missed, things that no one notices for a week or two, and when an issue is eventually noticed by someone, the full impact may not be appreciated. Three to four weeks may pass before the project team collectively realizes that the small item missed has grown into a major obstacle. Attrition has several distinct, pernicious effects:
  • Absence: Prolonged absence means that critical work and communication are not done. This ultimately may mean that key functionality or data may be incorrect at go-live.
  • Coordination: Work between teams suffers when a team member is absent. This has a variety of effects, among them that tasks become out of sync.
  • Continuity: A break in knowledge and context about previous work and decisions often results in a loss of momentum that leads to a reduction in both the quality and the timeliness of decisions made.
  • Change: New people tend to want to change what was done before they arrived. This can create additional tumult and can threaten both budget and time constraints.
  • Relationships: Every team has a cadence. Having to reestablish trust and rebuild a team during complicated work reduces morale and efficiency.

In the realm of risk management, risks can be put into the categories of accept, mitigate, transfer, or avoid. Needless to say, attrition is best avoided, particularly among leadership positions. Retention bonuses can be an effective way to avoid attrition in key positions. If attrition does occur, the best mitigation solution is through realigning internal resources and reconstituting existing backfill. A less-desirable solution is outsourcing via vendors who at best can provide the benefit of additional hands but who will not be able to mitigate the other effects of attrition.

Success

One of the most important components for success in an ERP implementation is the leadership team. The upheaval is significant, and the ultimate realization of gains requires a steady course at least twelve to eighteen months after a go-live. During the project, leadership is necessary to flexibly manage resources and resolve issues as they occur. This management can range from adding resources to changing role assignments to settling conflicts. It is the role of the leadership team to develop a common understanding of the shared challenges, offset by the new opportunities, in order to set appropriate expectations and help the institution endure the impact of change.

An interesting paradox is that whereas ERP transitions are sometimes implemented as a way to fix organizational deficiencies, these same deficiencies can prevent an ERP project from being successful. A successful ERP implementation provides structure, collaboration, effective communication, clear direction, and accountability. Yet deficiencies can come roaring back when the structure provided by a project is removed.

The pathway to lasting success is a governance process that continues past the go-live. A flexible leadership approach can maintain the positive momentum of an ERP implementation across cross-functional teams, leading toward a collaborative operational model.

Note

1. Author's translation. ↩

---

Brian Basgen is Associate Vice President for IT at Emerson College.