Pitfalls and complications of implementing a demand planning transformation

Implementing a demand planning transformation is rife with pitfalls. Any organization engaging in a transformation needs to carefully plan and execute to reap the benefits of its efforts.

Is your organization ready for change and fully committed to it?

Successful transformations require a sustained commitment not only from leadership but from everyone. There’ll be setbacks. Make sure everyone is aligned with your project’s “north star” to make it successful.

It’s here that one of the first hurdles comes up. Most implementation projects are delayed by issues and circumstances, and it’s not uncommon to see the go-live date pushed out. At times like these, your focus must remain on the transformation’s benefits and advantages. These temporary setbacks should be taken as learning experiences. Each can help you improve the process along the way.

And yet, demand planning transformation journeys have many pitfalls. Some are related to data quality, while others are about how requirements are developed and managed throughout the implementation.

Let’s review some of these pitfalls and look at workable options for avoiding them.

• A lack of quality data during various stages of the project. This pitfall manifests itself in various ways:
  • A complete lack of data during the initial stages of the implementation
  • Lack of full-scope data during the latter stages of the implementation
• The consistency and quality of the data after the project go-live
• Not having an adequate time window to review functionality based on actual data
• The discovery of new requirements in the late stages of the project
• An absence of sound project management throughout the journey

1. Data quality is one of the biggest pitfalls a transformation journey faces

The correct data is essential. We’ve seen organizations commit to data elements that aren’t always available, and then the implementation gets delayed due to the unavailability of the data. Therefore, it’s ideal that your implementation team first decide on an MVP (minimum viable product) and the data needed to deliver it. The MVP should be based not only on desired functionality but also on the reliable availability of relevant data.

The lack of full-scope data during the next phases of the implementation also creates issues. Without full-scope data, the project team can’t quantify how robust the solution is and its ability to handle the requisite data volume. Even when full-scope data is available, something can go wrong, and time is required to correct the issue and get back on schedule. Your project team should create an action item to check the entire data flow and functionality with the complete set of data within the SIT (Systems Integration Testing) phase. Without this, the SIT shouldn’t be approved.

Another pitfall of the implementation is the quality of the data sent from the legacy system to the planning system after the new system has gone live. A lack of consistent and quality data quickly erodes user community trust in the new system. The project team’s hard work can be in vain if the data quality isn’t up to the task and doesn’t support planning or decision making. Your team should incorporate go/no-go decision gates throughout the journey’s various phases to evaluate the data’s consistency and quality. The transformation program should go live only after verifying the quality of the data received.

2. User story development goes awry when using mocked-up data

Once the MVP is completed, the project team should create epics and user stories to deliver the MVP. Our observations usually show that user story development happens using mocked-up data. The project team should try to get sample data and mock-up data as close to reality as possible. You often see that functionality looks great when using mocked-up/sample data. When the actual data is received, the same functionality underwhelms, and new requirements arise. One solution to avoid this particular pitfall is for your team to complete an overview of functionality when a larger data set is available. The project manager should define a time window to deal with the new requirements that may come when using real data.

3. New “discoveries” can set projects back if not managed properly

Another pitfall is the “discovery” of new requirements and functionality during the later stages of implementations, in particular during User Acceptance Testing (UAT) and the user training phase. Again, you can avoid this (if not eliminate it) by conducting rigorous sprint and SIT reviews.

The focus of the UAT should be to see how the requirements, as defined via the epics and the user stories, were developed and find related issues. Almost invariably, there’ll be new requirements identified. Here, best practice is to categorize them into “must have,” “should have,” and finally, “nice to have” for go-live.

A detailed discussion should take place, and the user community should convince your project team why going live without certain functionalities wouldn’t be possible. Only the “must have” and low-hanging/high-impact functionalities should be developed and delivered before UAT closure or for the pilot phase. Future releases should be updated to include “new requirements” and should be time-boxed for development.

4. Sound project management can be woefully absent

Every journey counts on sound project management principles. Consider the three sides of the triangle — cost, quality and time — when making project decisions. Many transformations fail due to the simple lack of sound project management. Don’t let yours be one of them.

— By Sheetal Pusalkar