Requirements Gathering: I Assumed You Knew

Julia Donaldson & Data Management?

My 2-year-old daughter has a new favourite bed time book: Monkey Puzzle by Julia Donaldson and illustrated by Axel Scheffler. For those that don’t know the story, it follows a young Monkey that can’t find its’ Mum and is helped out by a Butterfly.

The young Monkey proceeds to describe its’ Mum to the Butterfly who takes it to the animal it thinks is its’ Mum based on the young Monkeys’ description. The Butterfly makes a number of errors based on the description: an elephant because she is big, a snake as it has a long tail, a parrot as she lives high in the trees and so on.

Project Scoping: Cover the basics

Reading this story for the umpteenth time, I had an epiphany moment, firstly in how this book relates to the Data Management industry and secondly, and probably with a much greater affect upon the success of a development project, how this book relates to the key stage of requirements gathering.

The epiphany was during a key point in the story, where after several failed attempts to find the Monkeys’ Mum, the young Monkey asked why the Butterfly kept on taking him to the wrong animal as none of the animals looked like him. The Butterfly said was surprised by this fact and asked the young Monkey why they didn’t say that from the start, receiving the reply…

“I assumed you knew.”

Don’t Assume Like Monkey

Many providers (and sometimes clients), particularly in the Database Marketing and Customer Data Platform arena are all too often the Monkey. The requirements gathering stage is such a key part of the project if not the most important stage. All too often both this and the testing phase are often rushed through or cut short, leaving one side or other to make assumptions.

If this is the case the project is doomed to fail, as those assumptions or lack of detail will be developed into the final product (SCV, Customer Data Platform or Data Migration), leading to an unhappy end user and a lot of wasted time and money.

Involve all stakeholders

Another common error is that the person or department providing the requirements on behalf of the client are not the ultimate end user. Again, this can result in assumptions on how the final product will be used that vary greatly from the real-world use case.

The best way to avoid this error is to ensure that everyone who will be using the finished Customer Data Platform has input into the requirements stage. Bear in mind that not every requirement has to be met in the first phase. Many of our successful Data Management projects are phased with additional functionality gradually built up.

Communication is key

If you opt for a phased approach for your Database Developments, make sure that all key stakeholders (including your supplier) are aware. Doing so not only keeps end users aware of the arrival of the functionality they need, but can help your supplier build the SCV or Customer Data Platform optimally for your needs.

Accurate requirements gathering can be the base of the test criteria throughout the project to make sure that it is both on track and fit for purpose. Whether the aim of the project is to build a Single Customer View, Customer Data Platform, Data Warehouse or “simply” migrate data between systems, avoiding assumptions will lead to a more successful project in the short-term as well as the long-term.

For more tips on how to run your Data projects, view our complete guide to to building a state of the art marketing database.