Ask the Experts: Retail Package Selection

David: In agreement with Robert, the first minimized activity that comes to mind is the lack of creating a script for the vendor demonstrations. When I have attended customer-driven demos, their typical script is a high-level list of items they want to be demonstrated, which leaves a lot of room for a vendor. A software vendor will put on their best show and not demo anything that doesn’t work right.

Typically, when Parker Avery works with retailers on system selection projects, we create a very detailed script that includes everything that the client wants to see supported. The details of these scripts typically include actual client data to be used. This is based on our experiences in implementing the software, and we know what an ‘out-of-the-box‘ solution should typically support.

By creating a detailed script, you’ll see not only the good aspects of the vendor’s solution but you’ll also get a better understanding of what the software cannot do. This approach enables more accurate evaluations with less subjectivity. Another area that outside retail system selection experts bring is narrowing down the list of contenders before conducting demos. We have completed numerous software selection projects and have a good idea of which software might be a better fit than others based on understanding the customer requirements. This will shorten the selection process and get you to the answer sooner.

I have seen internal selections where the scoring or valuation hasn’t been weighted based on business importance, causing the decision to be made based on IT criteria or non-business-centric criteria. I have seen the focus be purely on costs without focusing on the actual return on investment (ROI) of the project. Sometimes the ROI is not fully vetted or considered either because IT is doing the evaluation with minimal partnership from the business or the business is “too busy” to participate and sees these tasks as belonging to IT.

David: Absolutely, the most critical is to have business representation. To expand on Robert’s points, too often IT leads the selection and chooses a solution they think the business needs. To get buy-in, the business must be involved in gathering the requirements, attending the demonstrations, and participating in the evaluation. However, IT representation is also needed to evaluate the architecture, integration, and future support capabilities. Regarding specific roles, it depends on the software. You need to have a cross-section of the doers (e.g., assistant buyer), the managers (buyer), and the leaders (director and higher). All three roles will look at the software from different points of view. They will serve as your subject matter experts (SMEs). The percentage of time will vary. During the requirements gathering, you’ll need to have a couple of resources (typically a business analyst and someone who represents the business) dedicated full-time to the selection. In addition to participating in the interview gathering, they can assist in identifying who should be interviewed and scheduling the interviews. Each SME would need an hour for the initial interview. During the vendor demonstrations, each demo will typically be at least one day and sometimes more. You’ll need the SMEs full-time during the demonstrations. Of course, as you go through evaluations, you’ll need the SMEs for additional follow-up meetings and/or demos. This time commitment depends on what follow-up items come out of the demos.

Critical roles for a system selection project include business area leads and SMEs as well as the IT application owner. The business area leads and IT application owner should be dedicated to the selection while the SMEs could be partially allocated to the project. It is also important to include a key advisor who has experience with package selection and the “stumbling blocks” or misunderstandings that occur in this type of project. A good example of this is verbiage, meaning: what the business calls one thing versus what the vendor calls it. In merchandising, item attributes are key fields used to assist in reporting and operational efficiency. However, the vendor may call ALL fields attributes; this discrepancy would cause a misalignment of key business requirements.

Everyone wants out-of-the-box if they don’t have to change their processes. That’s where companies get in trouble. They feel they have some unique process that must be kept that represents a key competitive differentiator. While in some cases this is true, it typically just represents something (a process, policy, etc.) the company has simply always done. However, there are times when you do come across a unique requirement that must be met. Most software packages today have the capabilities to add business rules or develop a bolt-on at certain points in a system. In these cases, if you can’t resolve it via outside system processes, you can add a small application. The key is to ensure the “enhancement” doesn’t take you off the vendor’s upgrade path. It is extremely rare to have a true OOTB implementation with no enhancements.

The key here is twofold – the business’ desire to change from custom-developed solutions to industry best practices. Retail organizational change expertise is mission-critical when moving from customized solutions to industry best practices. The leadership team must continually reiterate the vision/direction and highlight the benefits of moving to industry best practices. Role modeling this vision for the team assists in moving the bar toward this strategic direction.

David: The typical delay is the scheduling of the demonstrations and ensuring everyone is available. The first thing you need to do is check the company calendar to see what might be bad weeks to conduct the demos (peak vacation time, holidays, line close, PO issue dates, etc.). Once you find available weeks for demos, it is necessary to book rooms right away. Usually, large rooms are needed for the demos, and in our experience, these rooms can be hard to come by. The other delay is following the package selection, during contract negotiation. This process can typically span a month or more, depending on a company’s legal team’s availability.

I have seen several things that result in package selection delays: unrealistic timelines from the start, underestimating the time needed to capture requirements, underestimating the coordination efforts of scheduling and staging vendor demos and reference calls, and lastly, the business’ need to revisit specific key topics for clarification of functionality before final scoring can be completed.

David: As I said earlier, having the business users involved throughout the process. The users of the system need to be involved so they have buy-in. You don’t want them thinking, “IT selected this package and told us to use it.” You want the users of the system to have ownership throughout the process from identifying the requirements of what they want the system to do to ultimately selecting the right solution for their needs.

Business vision and focus understood all the way down to the lowest level employee, along with the willingness to work with an experienced external partner who has the ability to mitigate the pitfalls of the selection process.