Topic 3: How do you get a pricing project started?

Home / Insights / Pricing In-Depth / Topic 3


Navigating a Pricing Project

If you’ve done your homework and are confident you have a pricing opportunity, it’s time to start thinking about a project.  Depending on what you’re doing, the project could be extensive or it could be a quick hit.  We’ll cover scoping the project in the next articles, but first some things to avoid.  Pricing projects, like any enterprise project, are subject to similar pitfalls that can be avoided or mitigated to ensure a successful project.  In our experience, here are some of them:

  • No executive sponsorship. Pricing projects are resource intensive and touch a lot of parts in an organization.  Without executive sponsorship, these projects rarely have a chance.  Clear leadership helps align key resources that need to contribute on the project and ensures you have their attention.
  • Competing priorities. In one company, the leadership had made a decision to go with one software solution but the project team didn’t support the decision.  The project team worked with the product and halfheartedly attempted to get it working but ultimately opted to abandon the solution for their preference of a custom-built solution in contrast to the leadership’s direction.
  • Too many cooks in the kitchen. Without executive sponsorship and a clear direction, different factions in the organization align towards competing objectives.  Then, they’re compelled to ‘right the ship’ in accordance to their own objectives.
  • Underestimating the scope. In another case, the level of effort for a pricing project was way under estimated because the scope had not been defined.  The inexperienced leadership made knee jerk decisions on timelines in contrast to the advice of the more experienced team members.  Pricing projects need well defined requirements and typically require a lot of integration which takes time.
  • Data availability. Pricing projects require data.  Ultimately a pricing solution is a calculator – it brings data in, calculates and computes, then sends data downstream.  If you’re not prepared to get the data out of your systems, don’t start the pricing project.  As part of a readiness exercise, you might want to consider a master data management project or something similar to ensure data is available.
  • Limited business experience from implementers or no technical expertise in business owners. Someone on the team needs to bridge the gap between the business side and technical side.  These are two different languages and unless someone translates, you won’t end up with what you want.  There are often tradeoffs in implementations and if the technical folks don’t understand the business benefits or the business folks don’t understand the difficulty of implementing features then you can end up with an end result that misses the mark or cost overruns.
  • Ill-defined benefits. This is the big one.  When benefits are clearly defined, everything else follows.  Leaders support strong business benefits and competing priorities fade away.

These projects are typically transformational and affect a large part of your sales organization.  Because of that, they really need strategic sponsors at the executive level in a company.  They aren’t easy and the process changes that permeate after implementing these solutions are as complicated as the technical challenges.  Ignoring this reality just puts the project at risk.

All parties from the top down need to be in alignment.  If any link in the chain isn’t on board, it will again jeopardize the project.  This does not mean suppress critical thinking or challenges to the majority opinion, but there needs to be a set of strategic goals that everyone agrees with so everyone is marching in the same direction.  Here are some steps to take to mitigate the above risks prior to starting the project:

  • Clearly define the business benefits. This is one of most important things to do when starting a project.  The business benefits guide the project and ensure when you have disagreement you can balance the discussion against the benefits you are trying to deliver.  In addition, as the project progresses you should measure the business benefits achieved and evangelize the results with business owners and executives.  On the flip side, if it is not achieving the expected business benefits, realign towards them, revaluate, or cut your losses.
  • Align the business leadership. Once the business benefits are defined, it is easier to get an executive sponsor.  The executive sponsor should support the business case whole heartedly.  If the executive sponsor has a lukewarm feeling towards the business case, he or she is less likely to be the evangelist you will need with the other company leaders.
  • Always listen to the end users. Success lives and dies with the users.  If they don’t accept the solution or it is too difficult to use, they won’t adopt it.  In our projects we rapidly prototype and regularly demonstrate the results to the end users to solicit feedback.  You run the risk of getting additional scope, but this can be managed by putting it in the queue and aligning to the business priorities.

Keeping these risks and mitigation points in mind when embarking on a project is important.  In the next articles, we will walk through project planning and scoping.

Planning a Pricing Project

Structurally, pricing projects aren’t much different than most 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.

Pricing project structure

We find that taking bit sized chunks is best when deploying pricing projects.  As discussed previously, we have a program planning phase where we determine what functionality would go in each business release.  When we know what is in the first business release, we start the project.  We typically use the following framework for a business release:

  • Requirements and blueprinting. Good requirements are essential to the success of the project.  The first step is to comprehensively document the business user requests.  This is followed by detailed user workflows, high-level data flows, and user acceptance tests.  After this is documented, the technical architect and/or developers are consulted to get estimated timelines and balance technical feasibility against business goals.
  • Iterative config and development. Configuration and development are when the business features get codified.  With enterprise software applications there is typically configuration work that tweaks the application to enable the features the business owners would like to see.  There might be data modeling or price modeling that conforms to the needs of the input and output data.  In addition, development work might be needed to fully realize the business owners vision.  In either event, iterative discussions will take place between the architect and the technical implementation team.
  • Integration testing. After configurations or code is released, integration testing is done to finalize the data inputs and outputs and the interfaces that are used.  The bulk of the independent work is done in the previous step and then end to end testing is done here.  This could be flat files, real-time calls, or a bus.  The data could be coming from multiple sources and be sent to multiple destinations.  The complexity of this step could extend the timeline.
  • User acceptance testing. After the integration testing, user acceptance testing is done on the final functionality.  In the config and development step we typically show the business users what will be coming, so they have a preview, then in user acceptance testing they work through the defined test cases.
  • Deployment and post move to production support. The last step is to deploy the functionality to production.  The setup and installation is done prior to this step and here we would move data, code, and configuration to the production systems.

These steps are put into a more detailed plan with a business release taking a few months or longer.  A typical schedule for a pricing project might be as follows:

In conjunction with the plan we develop a resource plan with the mix of team members necessary to deploy the project.  In our projects we use consultants who are experts in the products we implement mixed with part time and full-time resources from the customer.  We typically see the following roles are needed in varying degrees.  On smaller projects, people can wear multiple hats to keep costs down, but larger projects typically require more dedicated roles:

Role Responsibilities
Project Manager Managing the project and playing an SA role, coordinating with AAP
Solution Architect Solution architect would define and oversee the overall requirements, network architecture, solution approach, and integration architecture
Senior Integration Developer Integration architect would define and develop the necessary integration functionality
Modelling Architect Manage, define, and document the pricing model
Test Manager Continuous testing and documentation would be performed throughout the project
Business Analyst Analyzing requirements, working with modeling architect and integration development to deploy the solution
Developer Additional development to support integration

In addition, the customer typically provides following roles:

Role Responsibilities
Project Manager Dedicated to the project
Subject Matter Expert Significant involvement during program planning, blue printing, and testing phases. Need coverage of all the pricing processes
Legacy Data Owners Need resources that understand the format and context of the data from the legacy systems that will drive the pricing process
Integration Need resources to provide sample feeds from legacy systems, participate in the design of interfaces, support integration testing, and operationalize the new feeds
IT Operations Participate in the design of the operational processes as the new systems come on line. Batch windows for feeds, SLA’s, backup / restore processes, initial loads, net change feeds, etc
Users Participate heavily in UAT and as needed during blueprint and config / test phase
Steering Committee Provide guidance during program planning and a monthly cadence to review progress and resolve management level issues

The plan is an union of required business functionality, success factors, resources, budget, and timelines.  Once this is done, it is time to start implementing.