This week, we continue with our “Ask the Experts” series with a focus on retail system implementations.  Implementation projects come in all different sizes and flavors, but arguably they all also come with challenges, as well as the possibility of greatly enhancing a specific functional area or even an entire company.  Here, Parker Avery experts Dave Birdsall, John Lawing, and Rob Oglesby—backed by decades of implementation experience—provide their perspectives on the nuances and challenges associated with implementation projects.

Q1.  System implementation projects can range from small highly-focused systems involving only a handful of departments to geographically-dispersed, company-wide ERP solutions. When a company embarks on implementing a new system—regardless of the size—what activities have you seen that often don’t get the necessary attention from the client or consulting resources?

Dave: The number one issue I see time and time again is the lack of involvement in IT resources. During several of my projects over the recent years, the customer is not dedicating enough of their own resources when the implementation activities start. Too often they are letting the consultants run things, which works fine until they have to support the solution after the consultants leave. A second issue is the underestimation of design, development, and testing time. Everyone thinks they can get the design done quickly because the customer wants best practices. However, it never works that way. I’m firm believer in a 1-1-1 ration of design to development to testing. While that might seem heavy, development always takes longer, and clients never want to move their date, so testing gets shortened. This ratio will give you buffer to account for these types of misses.

John:  From the IT side of things, I would say integration design does not get the appropriate amount of attention when building project plans for a new implementation. There are many factors that can make integration extremely difficult to design. Typically, clients concentrate most of their time into the actual user viewable functionality in an application, which is expected, but a lot of times they assume that the integrations allowing the systems to communicate are going to be simply plug-and-play. From the business side of things, change management is often underestimated or overlooked all together. People get set in a pattern of what their job entails, but when new systems are introduced, their jobs will change. This change naturally brings anxiety, and without the appropriate preparation and guidance, it can snowball into negative feelings towards the new application. When a client properly prepares its users, there is much less anxiety because they already know what they are getting into and can digest the applicable job changes before they actually start performing the new process. 

Rob:  I think there are two critical activities that even though they might get the attention, the resource dedication isn’t always “complete.” One is change management—and especially driving it with executive sponsorship and creating the “burning platform” that prevents regression. Process validation checks after go-live are also a must—to make sure people are not reverting to old habits. The other is somewhat related to this and has to do with the way people are educated on the new process. It can’t simply be about “the system”—but how to actually use the system to accomplish an activity. While the mechanics may be straight forward, there are always non-system, process-related activities that are just as critical to be included in the learning documentation.

Q2.  In conjunction with activities, which project roles have you seen not properly allocated in a full-time capacity—i.e., had that role or roles been sufficiently staffed at the onset, the outcome would have been greater success/adoption of the new system?

Dave:   See my first point in the first question. Dedicate full-time IT business analysts from the beginning. An additional responsibility to not underestimate is the amount of time it takes to properly plan conversion and cutover activities. Both of these activities need to be considered during the design phase. You cannot over plan these activities.

John:  Change management roles are often overlooked, underestimated or filled by resources in an organization that don’t necessarily have the experience to produce and enact an effective change management plan. Effective change management resources are able to not only prepare users for the upcoming changes, but they also act as funnel of communication between upper management and the affected users. With the full support of management and the visibility to that support, users tend to be more motivated and understand that the change is going to happen, even if their day-to-day job is going to be impacted. When leadership is not fully behind the project, there is a higher degree of adoption failure because that feeling is echoed through their employees.

Rob:  I see two opportunities here. One goes back to the first question—OCM. You’ve got to have the resources in place to focus on the sponsorship, communication, and the learning and development—and they need to be involved early so they become fully indoctrinated in the intended change (allowing them to more effectively craft their deliverables). The second is the need for project managers that also truly understand the content of the work required to accomplish specific deliverables. Massive projects are not cookie cutter—one sub-project to the next requires very different approaches and as such, different deliverables and different estimating approaches. These projects are far more than software enhancements—and require project managers that truly understand what must be accomplished and how to accomplish it.

Q3.  Occasionally implementation projects experience delaysparticularly with larger-scale systems. From your experience, what are the major contributing factors to delayed timelines? Are there specific tactics that can help minimize or avoid such delays?

Dave:  Clients not willing to change their business processes to do what the solution will enable them to do. As I stated earlier, everyone wants “best practice” until it forces them to have a major change. Then, they ask for a modification or an enhancement—these add complexity and additional development and testing to get it “right.”  The other point is underestimating the design and development. As I said earlier, when those are underestimated, it either shortens testing or extends the timeline.

John:  The projects I have been involved with that experience delays are usually the result of poor planning and trying to follow unrealistic timelines from the very beginning. Once one activity or milestone falls behind, it is very hard to catch back up if there isn’t a reasonable timeline to follow with a little buffer already factored into it.

Rob: The biggest cause for delay is the inability to quickly make decisions with finality. Often this is due to the wrong people being in the room (not the decision makers themselves), but usually it is just an unwillingness to take the risk—especially if it means a BIG change. In order to avoid this, the project has to ensure that all necessary stakeholders are represented in each meeting/design session that is relevant to their part of the business (even if they aren’t the “primary” stakeholder, if they touch/influence the area, they need to be present, so they can be an active participant in the decision). Furthermore, if the people in the room aren’t the key people, they need to be empowered by the key person to make the decision firm—the best way to ensure this is to have those people in regular (weekly at least) contact with the leader of their area. This enables them to truly feel confident that their input is consistent with their leadership.

Q4.  There are typically a number of 3rd party consultants, vendors, system integrators, etc. involved in large implementations, and these partners can be critical components to the success of the project. However, these resources often are a blend of outside companies, bringing different approaches and deliverables for critical project elements like process and systems design. How have you seen companies get all of the disparate 3rd parties “rowing in the same direction” and aligned on methodology in the best interest of the client?

Dave:  Great question and, to be honest, it has been hit or miss. The times I have seen it work well is when there is clear division of roles and responsibilities. Additionally, iron out what methodology will be used and what the deliverable templates actually contain. Anyone that has worked an IT implementation has completed a business requirements document (BRD). However, every company has different flavors of what it contains and the level of detail. As you move through the SDLC (software development life cycle), you see more variations. Therefore, don’t just use a matrix of what documents will be delivered. Review the templates—and real examples—upfront so everyone knows what the expectations are.

John:  Communication and leadership are the key factors. Everyone needs to know what their responsibilities are and be held accountable for them. In order to do this, typically you need a lead who is strong in communication and who can see and adjust everyone’s tasks and responsibilities as the implementation progresses through its lifecycle. Without the oversight role, everyone is solely focused on their individual silo of responsibility, which can result in gaps in the overall implementation process.

Rob:  This is an interesting one. Without a doubt, the more cooks in the kitchen, the more difficult it is to land on the specific recipe for success. Especially since each party tends to come with a different set of objectives and deliverables. The path to success includes the following principles:

  • Each party has a core competency—let them do what they are good at and “stay in their lane”
  • Someone has to be the leader—and it needs to be the party that truly understands the business objectives of the project.
  • Agree to the overall deliverables up front:  what they are, what they look like and who will be responsible for them. Make sure there is no overlap or redundancy that can cause confusion.

Q5.  If you could name a single success factor for a system implementation, what would it be and why?

Dave:  Active sponsors who support the PMO (project management office). In other words, they listen to what they are told by experts (internal and external) and support the decisions. Additionally, they stick by the decisions and are not easily swayed into changing their minds.

John:  Resources being present and engaged. Strong and knowledgeable resources can make huge impacts on an implementation, but if resources are not fully committed and engaged in the project, then things will get overlooked, partially conceptualized, and drawn out—all resulting in delays to the project.

Rob:  Nailing the scope. And making the scope business process centric and NOT system centric. Too often, the project scope is based on “replacing a specific system”—versus completely reengineering a business process (or set of business processes). When scope is limited to just the system, decisions can be made that seriously impact the ability to fully implement new business processes to their full extent, and this negatively impacts the ROI that was projected from the initial justification for the project.

For more Parker Avery thought leadership and client case studies on systems implementations, please visit: www.parkeravery.com/insights.html.