My phone rings. It’s a call from a person I have never met. It’s a C-suite exec telling me his project team has major problems with their data. Judging from the sound of desperation in his voice, his reputation probably depends on the quick resolution of those problems. Many carefully-built careers have been scuttled by data disasters which often come as a surprise to the project team and their leadership. But decades of fielding frantic phone calls and subsequent project rescue experience has allowed me to compile this list of warning signs that your project might be destined to be doomed by data:

1. Your System Integrator says, “Data is a business problem.” It is common for the System Integrators to marginalize their responsibility for the data. And we all understand that the data is owned by the business. But without the cooperation and helpfulness of the System Integrator, your data will have a very rough journey, and this friction could slow down or even derail your entire project. After all, the only reason you are implementing your software is so that you can get data out of the new system. Therefore, it essential that the focus on the data should be paramount within the project. Data should not treated like a lowly stowaway to be unloaded roughly at the very end of the trip. Data is everyone’s problem.
   
2. You have planned only one test data load before Go Live. Data is fluid. It is the lifeblood of your business. It can also be messy, inconsistent and deceptively complex. It takes multiple load cycles and testing with that data to ensure your data can be loaded correctly, and that the data is behaving as expected in the new system and in all reports, interfaces and downstream systems. If you have poorly timed or insufficient “Mock Loads” in your project plan, you’re headed for a rocky landing.
   
3. You don’t share Data Readiness Metrics and data related issues as part of your regular status meetings. This is sailing blind without navigational aids. Even small issues not reported and addressed early can lead to major course corrections later. The best practice: Have a knowledgeable Data Lead involved from the start of the project to manage and reports on data related activities.
   
4. People are creating “fake” data for use in a formal testing cycle. Using pretend data to test system functionality is like announcing you are ready to sail around the world because you read a book on sailing. Your real data has variability and challenges you cannot even imagine at this point. The collection, filtration, cleansing, transformation and the actual loading of that data will be revealing, likely uncovering a host of issues -- some of which may lead to software configuration or design changes. System design changes in one area can impact other functionality within that system and potentially  downstream systems. Bottom line - the earlier you find these data challenges, the more time you have within your project schedule to adjust for them.
   
5. You don’t have a written Data Validation Strategy. Data Validation is a process for determining that your data is complete and correct – as determined by the Business. It is a distinct set of planned, auditable activities that should start before functional testing (Iteration Test Cycles and User Acceptance Testing) and should also be performed again prior to Go Live. There is nothing worse than sequestering your entire business team for days of testing – then to watch everyone sitting idly because the someone realized the data is not right and the planned test scripts cannot be performed. A well-constructed formal Data Validation Plan is the “secret sauce” that engages the business in a methodical way to spot those unexpected data issues so the project team can take the appropriate action before it’s too late.
   

 
I wish you and your project team a safe journey. But be on the lookout for these warning signs, and if you see any, make course corrections quickly.

Let’s face it. The primary reason for the software you’re implementing is so that you can get data into and out of the system reliably. Think of your software as the plumbing in your house and your data as the water that will flow through that plumbing system. Despite the obvious risks of plumbing a whole enterprise and then testing with fake or insufficient data, I am continually amazed at how little effort most companies expend on managing the Data Readiness and Data Validation aspects of their project. The consequences of that lack of preparation can be disastrous!

Data is fluid. Since many implementations (such as for a new ERP system) take place over an extended period of time while the business is in full operation, it is not unusual for the data to change significantly over the life of the project. Customers, Vendors, Employees and Materials are being created and updated. Customer Pricing is changing and Territories are re-aligned. Therefore, you must plan for sufficient and proper “Mock” Data Conversion Load Cycles to ensure you have handled and validated the latest data available and have addressed all possible variations. Too often, the project team plans only one or two partial data conversions mocks, but this approach is NOT a promising plan for a dry basement after Go Live!

Data is easily contaminated. Without the proper management of activities such as Data Governance, Data Profiling, Data Cleansing, Data Conversion and Data Validation, even small amounts of rotten data present in the legacy system can create a mucky mess in your brand new system. Careful attention must be paid to planning, communication, execution and monitoring of these data related activities to adequately de-risk your ERP Implementation.

You-know-what flows downstream. Small data problems at the beginning can become really big problems as the data moves through your systems, being processed and combined with other data. For example, a missing Sales Territory on a handful of migrated high volume customer records may mean that your combined Sales by Territory reports may be inaccurate. Make sure you plan sufficient time to thoroughly and formally test ALL of your downstream applications, databases, analytics and reporting with migrated real data from your ERP Test instance before you go live, leaving enough time in the project schedule to do upstream corrections and re-testing for any defects found.
​
To boil it down -- Following this advice will make your Data Readiness Strategy a well-constructed pillar of the project from the very start and will help build business confidence in their data. You will be better prepared to turn on that data faucet at Go Live!