Want to Write a Great RFP? — Don’t Forget About Data!

Want to Write a Great RFP? — Don’t Forget About Data!

Reading time: 4 mins

Request for Proposals I review a lot of Request for Proposals for system implementations – some well-written, some not. But one of the things I see lacking in most RFP’s is sufficient attention paid to the topic of data.

When data is under-addressed in the RFP, in the subsequent negotiations and/or the project itself — bad things can happen. Even if you are planning a brand new installation without any data to migrate, there still should be a well-articulated strategy for data. Likely, the primary reason you are implementing the software is so that you can get data into and out of that system reliably. Think of software as the plumbing in your house and your data as the water that will flow through that plumbing system. Unless you want to risk the success of the project, you need to make sure you plan in advance for the planning, coordination, and monitoring of those water pressure tests by including the following details in a well-crafted Data Readiness section of your RFP:

  • Data Profiling – If you don’t know the type, variety and quantity of the data you, then you cannot plan well for its handling.  Data profiling is the process of analyzing the available data from systems and reporting on the attributes (fields) characteristics, pattern of values, etc. to produce meaningful statistics useful in planning the project. Data profiling is typically performed by the data transformation team and will be used as input to data requirements gathering and mapping docs.
  • Data Cleansing is typically the responsibility of the business, however, if you know you have some particularly messy data, you might want to make the System Integrator (SI) an “Accountable” resource on the RFP RACI chart for this activity. There will be some discussion during negotiation, but out of that discourse should come an agreement by the vendor to provide some support (and tools) to help you with your data cleansing chores.
  • E-T-L Roles:
    •  Extract – designate who will be responsible for extracting the data from the source systems. Many times this is done by the business systems team, however, to get the best outcome for your data migration, it is best practice to have an experienced Data Migration team extract from your data sources at the direction of the legacy business team.
    • Transformation – you definitely want either your System Integrator or, better yet, an experienced data migration team to determine and perform the data transformation (or conversion) of the records. The major reason to use a separate data team is Segregation of Duties. When one team (such as the system integrator) controls both the data transformation and the system configuration there is a temptation to downplay issues with the intention (or hope) of fixing them later. Data gets loaded, but no second party has good visibility into the actual processes used. Regardless of who performs it, the transformation methods to be used should be documented in the Data Approach document and the details of each object and each field should be specified in the Data Mapping documents. In some cases, the legacy system team can do the transformation for some objects, but this is only advisable if this is a highly technical team.
    • Load – Often times this is the responsibility of the system integration team who is configuring the new target system.
    • Mock Loads & Data Validation – make sure to spell out the number of times your team will attempt to load the data. Stating this in an RFP will lay the foundation for the expectation for high data quality. The number of mocks (2-4+) can vary based on the size of the project and the number of test cycles planned. Be sure to include the language to state that Data Validation will be performed by the business, but must be accommodated in the project schedule.
    • Data Readiness Metrics – the compilation and publication of these metrics for the project team should be the responsibility of one person associated with the data loads. Data Validation metrics should be included in those metrics.

Making your Data Readiness Strategy a well-constructed pillar of the project from the very beginning in the RFP will help you build that comfort you need for when you turn on that system at Go Live!          

To learn more about how to plan an effective Data Readiness Strategy that you can build into your RFP or project, attend my session at the Managing Your SAP Projects 2017, Avoiding data danger: How to mitigate data risk during your next project.

Daryl CrockettDaryl Crockett, ValidDatum
CEO of ValidDatum, a women-owned small business focused on helping commercial and government clients with data-centric project management and services. A recognized leader in data validation, and data migration, integration and governance, Daryl has a background as a highly innovative international consultant & C-level executive with a wide variety of industry and implementation experience including oil & gas, life sciences, software, government, media, financial services, and manufacturing. Certified ISO 8000 Master Data Quality Manager (ISO 8000 MDQM), ISO 22745 Master Data Validation Committee Chair (2015), ECCMA Board of Directors, Member IAIDQ.org, Lean Six Sigma (Purdue), Member US Women’s Chamber of Commerce (Washington, DC), SBA Certified EDWOSB, WBE (WBENC) Woman Business Enterprise certified, WBE (MA), DBE (MA). Daryl is also co-inventor of AMIGO™ Software , a patent-pending implementation & information governance software, designed specifically for highly regulated industries.


More Resources

See All Related Content