The Fallacy of Requirements
Have you ever tried to write the perfect 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 Microsoft Dynamics 365 projects? Why do they fail to convey our requirements?
Your Dynamics 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 Dynamics 365 projects. Poor requirements specifications plague most CRM projects. Bad requirements can derail Microsoft Dynamics 365, Salesforce.com, Oracle CRM or any other CRM project.
My experience lies in adapting agile practices to Dynamics 365 projects and that's what I wanted to share with you.
Why do we write requirements specifications?
You could just hire a Dynamics 365 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 digital transformation investment is justified with a business case supported by high-level requirements.
We also write specifications for an internal or external 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 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 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 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
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.
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?
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
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 requirements specification.
Definitions for these terms differ between software vendors. Definitions also differ between proposal writers even when they are proposing the same software. Specify your definitions carefully. Ask providers to clarify theirs.
Here's an example of a very common requirement for alerts or 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 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 1,024 words. In my CRM projects, I've tried use case diagrams, business process models, state transition diagrams, context diagrams, system interaction diagrams, data flow diagrams, data models, low-fidelity wireframes and high-fidelity prototypes.
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.
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 Dynamics 365 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 Dynamics projects in the comments below.