Structurally, a pricing project isn’t much different than many enterprise software projects. Planning is the key to success. The first step is to work with the client team to develop an implementation strategy that works for all parties. The plan would have a firm scope for the first phase and potential scope for subsequent phases. This allows you to be agile as new information and situations come to light.
An implementation strategy will help guide the project and should address the following:
Document the expected drivers of benefit and the changes that enable and sustain those benefits
Define the business functions each application will cover during each phase
Define the data flows and integration methods between the applications for each phase
Assess the risks and plan mitigations to keep the project on track
In addition, implementation success factors should be discussed. Some of the factors that might be included are:
Involve key business users throughout the project. Users aid in defining requirements, setting scope, reviewing prototypes, performing acceptance testing, training other team members.
Keep implementation phases small. Phases should focus on a “minimally viable product” approach to manage risk and maximize the opportunity to learn and adjust as you go.
Maintain a consistent team from start to finish. This allows you to maintain institutional knowledge, minimize handoffs, more effectively support live issues and modify earlier work when needed.
Next, what are the pricing pain points you are trying to fix? When we identify the pain points, we will also estimate the financial benefit or productivity gain expected from addressing the issue. If you went through the process of identifying your pricing errors and analyzed the causes, you will have a good idea of what your pain points are. Here are some typical pricing pain points that we have seen in implementations:
Prices aren’t making it to stores quickly and reliably
Customers are demanding instant access to their loyalty points and stored coupons
Network connections are unreliable to the stores and often go down
There are potential price conflicts or margin leaks between price changes, promotions, markdowns, and coupons
Prices are managed in complex spreadsheets and there is an associated risk of making pricing errors often with the processes
The need to keep prices and promotions across channels aligned
These are some example of pain points that might exist in an organization. As mentioned, this list can be distilled from the analysis exercise of determining where your pricing errors are coming from. The list might also contain tangential pain points that aren’t directly causing pricing errors, but do cause frustration with the team that manages prices.
Rather than a big bang approach we subscribe to many different business releases that focus on key functionality. But where do you start? For our projects, we initially use a broad brush to identify how complex the different features are and balance that against the pain points. A business release would have well defined benefits that are attributed to specific feature requests. There are typically many different business areas you could start with for example a specific set of features, brand, geography, set of stores, or channel. We typically look at the following criteria in deciding where to start:
Start with a quick win. Often one of the best places to start is something that would address one or more key pain points and keep the timeline short. If you sized the complexity of the features and cataloged the pain points, you should be able to gauge what would be a quick win.
Understand the quality of the current data sources. Poor data quality is an issue with most projects and can bog down any timeline. A quick assessment of where and how to get the data, what kind of holes exist, and what kind of transformation should feed into your assessment of complexity.
Supportive business group. Another factor is what business groups are supportive of change and have the bandwidth to help drive the early implementations. If key personnel aren’t available such as business owners, users, or IT staff then your timeline could be in jeopardy.
Participation. Determine what level of participation the business can provide during the project.
Competing projects. Determine if there are other active projects that would impact the same resources or systems.
Other priorities. Are there any business priorities that would need to take into account? In retail, we often deal with back to school or black Friday and have to plan around those events to ensure we aren’t impacting those critical times.
All of these factors should be taken into consideration when determining where to start. Once you nail down the initial business release, you can plan it in detail to determine the expected timeline and cost. At the same time, you should identify the future business releases you expect to follow. You don’t have to plan the future releases in depth but should have a rough idea of complexity and cost which will drive your overall resource allocation and budget.
Structurally, a pricing project isn’t much different than many enterprise software projects. Planning is the key to success. The first step is to work with the client team to develop an implementation strategy that works for all parties. The plan would have a firm scope for the first phase and potential scope for subsequent phases. This allows you to be agile as new information and situations come to light.
An implementation strategy will help guide the project and should address the following:
In addition, implementation success factors should be discussed. Some of the factors that might be included are:
Next, what are the pricing pain points you are trying to fix? When we identify the pain points, we will also estimate the financial benefit or productivity gain expected from addressing the issue. If you went through the process of identifying your pricing errors and analyzed the causes, you will have a good idea of what your pain points are. Here are some typical pricing pain points that we have seen in implementations:
These are some example of pain points that might exist in an organization. As mentioned, this list can be distilled from the analysis exercise of determining where your pricing errors are coming from. The list might also contain tangential pain points that aren’t directly causing pricing errors, but do cause frustration with the team that manages prices.
Rather than a big bang approach we subscribe to many different business releases that focus on key functionality. But where do you start? For our projects, we initially use a broad brush to identify how complex the different features are and balance that against the pain points. A business release would have well defined benefits that are attributed to specific feature requests. There are typically many different business areas you could start with for example a specific set of features, brand, geography, set of stores, or channel. We typically look at the following criteria in deciding where to start:
All of these factors should be taken into consideration when determining where to start. Once you nail down the initial business release, you can plan it in detail to determine the expected timeline and cost. At the same time, you should identify the future business releases you expect to follow. You don’t have to plan the future releases in depth but should have a rough idea of complexity and cost which will drive your overall resource allocation and budget.