Beware of the Simple Things: 3 Flags to Look Out for in Domains
Your new client already has a requirements document, and has been doing work in the domain for 10 years. They use simple concepts: reports, studies, projects, updates, project IDs, owners. They ‘just’ want to transfer their Access data into a relational database, and share information with their clients via a web application. We’ve done that before; why should it be complicated? We spotted [what should have been] early warning signs on a recent project:
Our client used simple words to mean complex things.
They used the same word to mean different things.
They used different words to mean the same thing.
Shortly after we finished discovery work, we found ourselves arguing with each other about what the word ‘study’ (and project, results, owner, area and facility; even the concept of identification) meant to the client. During the discovery, the client apologized for using jargon. What jargon? We thought the word ‘project’ is perfectly clear. It turned out that the client has silos, and the people in each of the silos have different workflows, legal obligations, and time scales. Organically, each silo began using the same words for different concepts, and different words for the same concept. The client also has some diplomatic issues; not nailing down specific words for specific concepts was a way to keep the peace via ambiguity. And one can scrape along that way in a set of loosely linked Access databases, since it’s not going to enforce validations on data entry.
Access suited many businesses well in the recent past, not just our one client. Storing data locally and informally creates flourishing fiefdoms, lubricates the wheels of business communication, and allows those who like manipulating data to create worlds in which to thrive and adapt. Moving to the web, and to larger aggregations of data, crushes idiosyncrasy. Bad data can’t be tolerated even for diplomacy’s sake. Outliers must be brought into line or removed. Stakeholders who liked the way business was being done are not going to be easily enticed to change to suit someone else’s need for a clean dataset.
Well, as Jeff says, our clients wouldn’t be our clients if we couldn’t help them in some way, and sometimes the best way we can help is to point out their business’s inconsistencies, and help them see the trade-offs more clearly. For our part, when we leave a discovery session unable to agree among ourselves about what the client meant by a particular term, it should be a warning that we are in diplomacy, not development, and we should account for diplomatic risk in the cost.
