The Fallacy of Requirements
Have you ever tried to write the perfect CRM requirements specification? I’ve been on a mission to write a complete, accurate, unambiguous requirements specification. A perfect specification is succinct enough for a sponsor to approve, but yet detailed enough for a team to build. I’ve never succeeded.
Why do we write requirements specifications for our CRM software projects? Why do they fail to convey our requirements?
Created using Project Cartoon.
Your CRM requirements specification is probably wrong. It’s probably inaccurate. Probably too short for half your audience and too long for the other half. Is there is a better way?
This article will highlight the fallacy of requirements.
My findings ideas aren’t all new or limited to CRM projects. Poor requirements specifications plague most CRM projects. Bad requirements can derail Microsoft Dynamics CRM, Salesforce.com, Oracle CRM or any other CRM implementation.
My experience lies in adapting agile practices to CRM projects and that’s what I wanted to share with you.
Why do we write requirements specifications?
You could just hire a CRM consultant, describe what you want, and sit beside them while they develop the software until it’s perfect. You might end up with exactly what you want without ever writing down your requirements. This is a feasible option if you own the company and don’t have a boss or shareholders to answer to. But it’s not usually the best use of your time.
We write down our requirements so that we can convey what we want to other people. We write specifications for internal stakeholders. We need to persuade them our CRM investment is justified with a business case supported by high-level requirements.
We also write specifications for an internal or external CRM project team. They need detailed requirements to provide us with an estimate of the project’s effort and cost. Then they use the requirements specification to design and configure the CRM software for us.
The person responsible for eliciting your requirements is your CRM business analyst. It’s the business analyst’s job to describe your requirements. Short enough to be understood and approved. Detailed enough to be implemented.
On my mission to write the perfect CRM requirements specification I have tried lots of ideas in my early career as a CRM business analyst. I studied for a Diploma in Business Analysis from the British Computer Society. I read lots of really good books on requirements engineering. I used formal software engineering methods such as the Unified Modeling Language (UML) and Rational Unified Process (RUP). But I may as well have written the requirements in a foreign language.
Fallibility of the written word
As a CRM business analyst, I’ve written requirements using use cases. I have organised lists of functional requirements and non-functional requirement statements with MoSCoW prioritisation. I’ve compiled data dictionaries and business rule catalogues.
But using words to describe requirements is hard. Even Shakespeare would have struggled to command the words to faithfully, accurately and completely describe users’ CRM requirements. It’s easy to turn misinterpretations into mistakes even when the requirements are carefully spelt out.
Is there a Google Translator for requirements, please?
Imagine that most CRM requests for proposals (RFPs) are a genuine attempt by a client to find the best CRM solution. Imagine they are not rigged. Publishing a good requirements specification will result in a range of potentially suitable proposals. The better the requirements, the better the proposed solution will fit. Providing ambiguous and incomplete requirements will return vague or inaccurate proposals. A bad requirements specification might even cause some suitable providers to qualify out.
I have seen thousands of examples of badly written requirements. I can recognise them because I’ve written lots of bad requirements myself.
Let’s have a look at just a few of the problems with trying to specify requirements in writing.
Understand the requirements
“Req. B-1: The supplier must demonstrate an understanding of, and ability to deliver on, the requirements and objectives in the development and implementation of a Claims Management System.”
So there is a requirement to understand the requirements? This RFP had a small catalogue of vague requirements like this one. It didn’t state any project objectives. Somehow the respondents would magically understand what’s needed. Importantly, they had to be able to provide a fixed-price binding proposal.
“The IMS will have the ability to monitor social media, including Twitter, Facebook, etc.“
Any time you read the phrase etc. or such as it means the requirement is incomplete. Is there a requirement to integrate with LinkedIn or WeChat? There could be. Who knows what’s hidden inside the et cetera at the end of a list.
Capability or feature?
“Ability to create customisable dashboards containing reports for management to review without any coding knowledge. Includes the ability to customise parameters and information display (such as dates and chart type).”
Anytime I read a requirement where the CRM system must have the ability to it’s usually a requirement for a capability and not an estimatable, testable, usable feature.
All the leading CRM platforms have configurable dashboards. Will those dashboards meet your managers’ requirements? Who knows. You haven’t specified what questions your managers need to answer when they open a dashboard.
Business processes and workflows
“CRM system must have a standardised sales process for prospect/lead/opportunity – sales funnel.”
Unfortunately, there is no universal definition for the terms like process, workflow, trigger, automation, or action. Take extra care when using these words in your CRM requirements specification.
Definitions for these terms differ between software vendors. Definitions also differ between proposal writers even when they are proposing the same CRM software. Specify your definitions carefully. Ask providers to clarify theirs.
“Ability to alert individuals and groups when: a ticket has been raised for that group; a ticket has been raised for a particular product type; a ticket has been categorised as a complaint; when a ticket has been closed.”
Here’s an example of a very common requirement for alerts and notifications. Alerts and notifications interrupt my work like a child tugging on my arm. Consider very carefully the situations when a user might appreciate being interrupted. I’ve never met a CRM user who wanted to receive more pop-ups or system-generated email messages.
Images lack context
Napoleon once said, “a good sketch is better than a long speech”. Or, or we say in software, a picture is worth 1024 words. In my CRM projects, I have tried: use case diagrams, business process models, state transition diagrams, context diagrams, system interaction diagrams, data flow diagrams, data models, lo-fidelity wireframes and high-fidelity prototype screenshots.
But it’s hard when someone tells you what they need and you have to draw a picture to represent those needs. Even when it’s a critical situation and you need to get it right.
Imagine sitting down with a police photo-fit sketch artist to try to create a likeness of a criminal you witness commit a crime. You’re a highly motivated stakeholder if that crime was committed against you, and the police sketch artist is a highly-trained creative professional with years of experience working with victims of crime in stressful situations.
Unfortunately, even the results of police photo-fit sketches are not always accurate.
Pictures can only convey a snapshot of what’s required and can’t convey the context of why. Even when you know exactly what you want and you start off with a picture of it modelling your requirements in a picture is hard. The end result is often nothing like you had imagined.
Let’s try modelling our business processes
There are some types of graphical models that are designed to be unambiguous, testable and even machine readable. For example, an executable business process model using BPMN 2.0 can be validated and executed by compliant business process management software.
There are three levels of BPMN process models: descriptive, analytical and executable.
Descriptive BPMN process models are useful for conveying and agreeing on high-level business processes with stakeholders. However, descriptive models are usually insufficiently detailed for implementation in a CRM platform.
Analytical BPMN process models contain a more appropriate level of detail for the CRM implementation team. But they require too much explanation to be easily understood and approved by the stakeholders.
The most detailed BPMN process model is the executable BPMN process model. A valid executable model is unambiguous, testable and machine readable. Here’s an example of an executable BPMN process model for a hiring process.
Credit: Max Tay, BPMN Professional.
It’s unlikely we’re able to create these very specific models without specialised BPMN training and skills. Usually, the only person on the CRM team who completely understands the model is the BPMN process analyst who produced it. That doesn’t help much with communication.
Business process models have their place in our CRM requirements specifications. But we’re often caught between needing high and medium levels of detail. In BPMN terms, we’re caught between descriptive and analytical level process models.
Riva role activity diagram, an alternative business process modelling notation
In 2005, I discovered Martyn Ould’s book Business Process Management – A Rigorous Approach . The book describes Ould’s Riva business process modelling architecture and role activity diagram modelling notation.
I loved the intellectual completeness of Ould’s notation. So much that I hired him for a one-on-one coaching session. We met in a hotel meeting room in Swindon before I embarked on a business process modelling project at Rackspace’s San Antonio headquarters.
There’s a serious shortcoming with Riva despite its intellectual rigour. Have a look at this role activity diagram and see if you can spot it.
Unless you’ve read Martyn’s book it’s really hard to follow what on earth is going on. I laugh when I look back at it — I had to buy a dozen copies of Martyn’s book for the Rackspace team just so we could understand each others’ models.
Even if you don’t use complicated notations like BPMN or Riva, you could just create a simple workflow diagram using the simple shapes in Visio. Tragically, many of the workflow diagrams found in CRM requirements specifications don’t make sense, even if they appear simple. I’m sure we’ve all seen activity rectangles with one line entering and three lines exiting or decision diamonds with no labels. Not very helpful.
So how do we convey requirements?
If the written word is insufficient and pictorial models are fallible, what is the best way to convey requirements between stakeholders?
Stories. Stories have existed long before written history. From cave painting to novels to movies, stories have always fascinated us. Story-telling methods and media have changed, but the desire to tell and hear stories remains undiminished.
About ten years ago, I read about Kent Beck’s user stories in Mike Cohn’s User Stories Applied. Finally: progress! When we use user stories we admit that they are just placeholders for the undocumented requirements. But they can become a hot mess of unspoken, undocumented fragments of possible requirements.
But user stories can become a hot mess of unspoken, undocumented fragments of possible requirements. New user story practices have emerged that have improved their usefulness over the last ten years. Jeff Paton’s story mapping technique brings a shared understanding of the big picture and prioritised releases so that user stories avoid the hot mess syndrome.
I’ll be writing more about the user story practices I have used successfully in my CRM projects in upcoming articles. Meantime, I’d love to hear about any other requirements analysis or management practices that you have used successfully on your CRM projects in the comments below.