Retail System Implementations
Ask the Experts
Retail System Implementations
Ask the Experts
In this edition of Parker Avery’s “Ask the Experts” series, we focus on retail system implementations. Implementation projects come in all different sizes and flavors, and they bring the possibility of greatly enhancing capabilities in a specific functional area or across an entire company. Implementation projects also bring a number of challenges. Backed by decades of implementation experience, Parker Avery experts Dave Birdsall, John Lawing, and Rob Oglesby provide their perspectives on the nuances and challenges associated with implementation projects.
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 from business and 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 a firm believer in a 1-1-1 ratio 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 a buffer to account for these types of misses.
Everyone thinks they can get the design done quickly because the customer wants best practices.
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 system implementation. There are many factors that can make integration extremely difficult to design. Typically, clients concentrate most of their time on the actual user-viewable functionality in an application. While that focus is expected, a lot of times clients 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 altogether. 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 toward the new application. When a client properly prepares its users, there is much less anxiety because they 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. Also, process validation checks after go-live are 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 straightforward, there are always non-system, business process-related activities that are just as critical to be included in the learning documentation.
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. In addition to business users, companies need to 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 upcoming changes but also act as a funnel of communication between upper management and the affected users. With the full support of management and the visibility of 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 sponsorship, communication, as well as learning and development. 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.
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.
Occasionally implementation projects experience delays—particularly 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: A major contributor to implementation delays is 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 significant 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.
When a client properly prepares its users, there is much less anxiety because they already know what they are getting into.
There are typically a number of third-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 third 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 a clear division of project team roles and responsibilities. Additionally, iron out what methodology will be used and what the deliverable templates actually contain. Anyone that has worked on a system 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 software development life cycle (SDLC), you see more variations. Review the templates—and real examples—upfront so everyone knows what the expectations are. All of these points tie to having a strong PMO structure in place.
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 leader 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.
If you could name a single success factor for a system implementation, what would it be and why?
Dave: Active sponsors who support the project management office (PMO). 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: Present and engaged business resources. Strong and knowledgeable resources can make huge impacts on an implementation, but if they 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 the 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.
Contributors
The Parker Avery Group is a leading retail and consumer goods consulting firm that transforms organizations and optimizes operational execution through development of competitive strategies, business process design, deep analytics expertise, change management leadership, and implementation of solutions that enable key capabilities.
