Skip to content

How My First Agile CRM Project Got Approved

30 August 2016

My first agile CRM experience started out as a traditional, sequential, waterfall project for Premier Medical Group that quickly went sideways, almost went backwards, but turned around to become a pivotal moment in my career.

In 2008 I was running Increase CRM, a cloud CRM service provider, and I got a call from Debbie Cragg, operations director at Premier Medical Group (PMG). Debbie was looking for a consultancy to configure and host a new CRM system to replace their legacy insurance workflow system.

PMG prepares medical reports for solicitors as part of accident-related medical claims funded by insurers and employers. Their goals were to speed up the process, make it as efficient as possible, and help the insurance companies standardise payouts to reduce insurance premiums. They had 300 agents based in Ludlow (over 3 hours drive from our office in west London) preparing nearly 200,000 reports each year.

The perfect requirements specification

Dan Barber and I spent several weeks driving up and down to Ludlow to meet users, model their business processes, capture their requirements and analyse their data needs. We held lots of workshops and pulled together the best possible requirements specification we could. Hundreds of pages in glorious technicolor. Sure Step’s inventors would have been proud, but maybe not surprised of what happened next.

PMG’s goals required a complex solution that managed patients’ medical assessments in relation to their insurance claims. The medical examinations had to be scheduled in clinics arranged by PMG in multiple temporary facilities across the country every day and the doctors had to be provided with all the patients’ files for the day of the clinic in a custom offline synchronizing application that couldn’t use the standard client application. CRM had to manage a long-running case and all the related business processes with interactions via telephone, email and postal mail.

After spending several days reading the specifications and collecting stakeholder feedback, Debbie didn’t think we had captured all of the requirements or their complexity. She was expecting a larger implementation estimate.

“Could you double your quote and add a contingency?” she asked. It’s not often a client asks me to double my estimate (it’s never happened before or since!). Then she added, “But I really don’t want to wait nine months before we receive any software for testing. Can you deliver working prototypes before that?”

Let’s go agile instead!

I can’t even remember where I’d first heard about agile frameworks. (Possibly at a BBQ at Dirk Elmendorff‘s house one Sunday in 2008?). After a weekend crash course reading blog articles and a couple of days making calls around the Microsoft partner network I got connected to Paul Fox and a team at CIBER UK who offered to partner with Increase CRM and help us deliver PMG’s complex CRM system using Scrum. I pitched the concept to Debbie and she was immediately on board. Now all we had to do was convince her board of directors.

Debbie and I confidently presented our new approach to PMG’s executive team. But I think it was Shay Ramalingam from Nomura (an investor in PMG) who asked me: “How will we know when you’re done? How will PMG know that the requirements have been satisfied if the requirements specification isn’t part of the contractual agreement?”

It was an insightful and fair question, which makes it a shame that I flubbed the answer.

Don’t use this line in a pitch to executives

“When you’ve run out of money”.

That was my off-the-cuff reply. I tried to back-peddle fast, “In an agile approach the client sets the priorities according to business value, so PMG will control the scope and costs and can choose to keep the development going as long as our team is delivering features with more value than we’re charging you to develop them”.

Thankfully, Shay and the other executives — Jason Powell, Harry Brunjes and Jeremy Ellison — were able to see past my slip-up and give the project a green light.

And that is how my first agile CRM project got approved.

Product Owners for CRM Projects

29 August 2016

The perfect product owner

The role of the product owner is to set the goals for the CRM system, each release and each sprint. The product owner also describes all the requirements and acceptance criteria. He or she must be available to participate in every sprint event and have a senior role in the organisation such that they command a level of authority so that they alone can make prioritisation decisions. They have a responsibility to accept requirements when they are done, identify bugs and new stories.

The perfect product owner is a former UN secretary general, cooks 30-minute brownies in 20 minutes, can decide what to eat before setting the menu, and is an expert cat herder.

The real product owner

The role of the product owner has varied across my agile projects. Some product owners have been former business analysts learning to work with user stories and a product backlog. Other product owners are senior department heads comfortable with sponsoring the project and providing their vision for the desired business outcomes.

What I’ve found is that the best product owners are:

  1. Outcome-oriented: able to clearly describe the desired business outcomes impacted by the CRM system, able to set sprint goals that inspire the CRM team
  2. Well-respected: able to make prioritisation decisions without deferring to someone else, and holds significant influence over the intended CRM users.
  3. Narrator: able to describe the business requirements and acceptance criteria in sufficient detail that the features can be developed, tested and accepted.
  4. Entrusted: has integrity and is trusted by other senior stakeholders to balance competing priorities.
  5. Readily-available: can attend all the sprint ceremonies, the daily standups, and is frequently available for questions regarding stories and features.

Can just one person be the product owner?

Admittedly that’s a tall set of requirements for a great product owner. And I’ve never worked with a single product owner who meets all those requirements.

I’ve found that there is often a CRM executive sponsor who fulfils the requirements of being outcome-oriented, well-respected and entrusted and a delegate product owner who fulfils the requirements of being a good narrator and readily-available.

This combination of CRM executive sponsor and CRM product owner has worked well in several of my projects:

  • Peter Cook for Keith Ison at Guy’s & St Thomas’ NHS Foundation Trust. We worked closely with Peter, a senior medical physics engineer, on a day-to-day basis and presented our progress to Keith at the end of each sprint.
  • Steve Pomush for Carrie Leonard and Bryan Smith at American Homes 4 Rent. Steve was the VP of IT with the tricky job of balancing competing priorities within a single backlog from a number of different departments who used a single CRM platform for different needs. Usually, he directed us to concentrate on Carrie’s asset management requirements for a sprint or two and then back to Bryan’s property management department.
  • Victor Lee for Beth Cozza at Advantage Sales & Marketing. Beth was the Director of Account Services and a great product owner with day-to-day support and specialist technical expertise from Victor, Director of IT.
  • Ben Roles for Debbie Cragg at Premier Medical Group. Debbie was the Operations Director and acted as a hands-on CRM executive sponsor while delegating day-to-day details to business analyst, Ben Roles.

The Scrum framework requires that the product owner is one person, not a committee. Having more than one product owner certainly can be harder to manage,but I’ve found it much more practical to have two people working together as product owner than relying on a product owner superhero that doesn’t exist.

Do product owners need to be CRM or agile experts?

I’ve never worked on a CRM project where the product owner was a CRM expert. I’ve performed a few turnaround projects where the client’s team already know CRM but they’re rarely CRM experts.

Similarly, I’ve never worked on a CRM project where the product owner had ever been a product owner before. Most are agile newbies and heard about Scrum for the first time through our pre-sales engagement.

I recommend providing the whole project team with a workshop to introduce them to Customer Agility so that they are aware of the Scrum principles and practices before the project starts. But there’s no need for your CRM product owner to become a Certified Scrum Product Owner unless they want to launch a career in software product management.

Are you the perfect CRM product owner, or have you worked with one? Would love to hear about your product owner experiences in the comments.

Lessons From My First Agile CRM Project

8 August 2016

My first agile CRM client was Premier Medical Group. Their board of directors, after a nerve-wracking board meeting, gave us the go ahead to get started in late 2008.

My first agile CRM project team

My CRM consulting company, Increase CRM, only had a handful of consultants. None of us had ever implemented CRM using Scrum so we partnered with another consulting firm, CIBER UK. Paul Fox, a project manager with CIBER, was an experienced Scrum Master and calmly lead our merry band forward into sprint 1:

  1. Debbie Cragg – PMG Operations Director and Product Owner
  2. Benjamin Roles – PMG Business Analyst
  3. Neil Benson – Increase CRM Solution Architect
  4. Dan Barber – Increase CRM Senior Consultant
  5. Wei Chieh Soon – Increase CRM Developer
  6. Paul Fox – CIBER Project Manager and Scrum Master
  7. Mark Tolley – CIBER Development Architect

It was a perfect sized team with a blend of skills and personalities that worked well together from day one.

Setting up the room

We set up a project space in a meeting room in CIBER’s offices on Portman Square in London. One of the team, probably Paul, had the genius idea of using a roll of dry-erase whiteboard film. The film sticks to the wall by electrostatic attraction turning it into an instant whiteboard. Now we could write and attach sticky notes all over the place without annoying the facilities manager. We had two rows of facing desks with enough room for everyone’s gear. And we made it a team rule that phones calls had to be taken outside.

Here are a couple of tips from that room:

  1. Get a dedicated room for your CRM project team.
  2. Cover the walls in whiteboards. Use dry-erase whiteboard film if you have to.
  3. Have one or two projectors or large screens that anyone can easily use to demonstrate a feature.
  4. For your first Customer Agility project, sticky-notes and flip-board charts work better than agile project management software.

Setting up the backlogs

I can’t recall whether Paul tracked our backlog in an agile project management system. (That’s definitely a temptation I  hit at the start of every project.) Instead, we used the requirements specification document that we had written previously to describe the biggest requirements and wrote those down on big sticky notes.

We agreed with Debbie which requirements to start work on first. Debbie set the business priorities based on value and the team set the development priorities based on technical dependencies. We chose the first big requirement and then deconstructed it into smaller pieces of work that we could deliver in the first sprint.

Paul coached us through the Scrum events and practices, but there wasn’t any formal Scrum training or instruction. We just set about estimating the size of the requirements to build our product backlog coached by Paul. We had a very rough release plan by guessing what our velocity might be. Then we figured out the tasks needed to deliver the first set of stories and estimated the hours involved, and that was our sprint backlog.

Just-in-time requirements analysis

Dan and I had already spent six weeks gathering user requirements, so we had a fair idea of some of the details behind each of the requirements. But the requirements specification was already a couple of months old by now and PMG’s business was evolving rapidly. So Ben was kept busy using his operational experience and connections with the stakeholders to confirm and reconfirm details as we needed them.

Sprint reviews with stakeholders

Every couple of weeks at the end of the sprint we’d grab our release burndown chart and present the latest set of completed features to PMG’s stakeholders either in either Hammersmith or Ludlow and get their feedback. The regular feedback from users and senior managers helped us tweak our future stories and deliver a great product.

Happy endings

As I rolled off the project in 2009 the team had built most of the core CRM features and started work on the custom offline client that synchronised data with CRM and SharePoint. After 18 months of development all the pieces were in place and the system was live. By mid-2010 Premier Medical Group was sold by Nomura to Capita Group who recognised PMG’s capacity to scale their medical-legal operations in-part based on the Dynamics CRM “fully integrated IT-led medical reporting platform” that I was proud to play a small role in delivering.

Customer Agility Primer

1 August 2016

Customer Agility is an agile framework for implementing CRM software. It combines the Scrum agile product development framework with additional agile best practices.

It’s designed for CRM customers and consultants that want an agile process, faster releases, improved collaboration, greater transparency, and reduced risk compared to a traditional, sequential CRM project.

This post is the first in a series aimed at CRM customers and consultants who want to learn how to use Scrum in a CRM project. In this article, we’ll learn the basics of the Customer Agility framework with an introduction to its pillars and principles, roles, events and practices.

Core pillars and principles

Customer Agility has three pillars: transparency, inspection and adaptation.

  1. Transparency. Our requirements, progress, and issues are all out in the open.
  2. Inspection. We frequently inspect what we’ve built and how we built it.
  3. Adaptation. We frequently adapt what we’re about to build and how we’ll build it.

Customer Agility also embraces the core principles of commitment, courage, focus, openness and respect.

  1. Commitment. The CRM team commits to achieving the customer’s goals.
  2. Courage. We have the courage to solve tough problems.
  3. Focus. We focus on the work of the CRM project.
  4. Openness. Our communication is open and honest.
  5. Respect. The team members respect one another’s professionalism and ability.

Embracing these values is more important than perfectly adopting any of the practices.


In Customer Agility, a self-organising team develops working software in a two-week iteration called a sprint.


The Product Owner provides the vision for the CRM system, decides on the release dates, describes and prioritises the requirements, and accepts completed work as done. The team agrees on the definition of done as the project starts. The CRM team is a cross-functional, self-organizing group of up to nine members. Working on the highest priority items, the CRM team analyses, designs, develops and tests some items in each sprint. An Agile Coach guides the team and removes any impediments they encounter.


We run a release planning workshop at the start of each release to determine the major goals for the release. The story mapping practice provides a shared understanding of the desired business outcomesuser rolesepics and releases.

At the start of each sprint is the sprint planning workshop to discuss and commit to  the items for the current sprint.

During the sprint, the team holds a daily standup meeting each day to check-in on each others’ progress. Story previews provide the product owner with an opportunity to provide feedback on features mid-sprint before they are done.

A periodic storytime workshop reviews items in the backlog for future sprints. Once items meet our definition of ready, we play a game of planning poker to estimate their complexity using relative point estimation.

The team demonstrates the completed items to the project’s stakeholders in the sprint review meeting at the end of each sprint. Then they hold a sprint retrospective workshop to reflect on their work.


The product backlog represents all the required work, known as product backlog items. A product backlog item can be a feature, bug, chore or spike. We use a user story to describe each feature and its acceptance criteria. We split large stories into smaller ones that we can deliver within one sprint as we being to work on them.

The sprint goal describes the team’s focus during the sprint. The sprint backlog represents the tasks the team needs to complete to complete the stories and reach the goal. The sprint board displays the CRM team’s progress with the stories’ tasks and gets updated daily. The sprint burndown chart tracks our progress during the sprint. Velocity is   the amount of work completed in each sprint and gets tracked in a release burndown chart. Documentation produced during the sprint includes the system design statementtest cases, and user guide.

The CRM team use pair programming to provide collective ownership of the features they develop. Automated releases combine continuous integration, automated deployments, and automated testing to ensure that completed features are released frequently into test environments for continuous acceptance testing by the customer.

Putting it all together

Customer Agility is a framework of recommended practices. It’s not a prescriptive methodology you have to follow. You’re welcome to learn how to apply some of Customer Agility’s practices to your CRM projects but you don’t have to apply all of them to experience the benefits.

The Futility of RFPs

26 July 2016


The traditional procurement process

There’s a well-worn procurement process used by buyers to reduce risk, save time and money. Its aim is to evaluate the market and select the best provider available balancing quality, cost and timeliness.

Most CRM software procurement processes look a little bit like this:

  1. Determine need. Write your CRM requirements specification and obtain stakeholder approval.
  2. Engage potential providers. Write a request-for-proposal (RFP) with lots of evaluation questions. Include a generic, draft contract and a CRM requirements specification. Perform a market scan and select a long list of potential suppliers. Send your requirements specification and RFP to the potential suppliers and give them a couple of weeks to respond. If you are a public sector organisation you might need to publish your RFP so that anyone can respond to it.
  3. Evaluate providers. Grade suppliers’ responses and ask the top two or three to perform a demonstration.
  4. Appoint supplier. Select the preferred supplier, and sometimes a spare. Negotiate a contract to implement your new CRM platform.

Most CRM customers use this procurement process or something like it. I have used this approach once or twice as a CRM customer. More often, perhaps more than a hundred times, I have been involved as the potential supplier.

And it sometimes works. It’s better than random selection. But it’s not a perfect process. Let’s have a look at the challenges of the traditional procurement process.

8 Challenges with the traditional CRM procurement process

  1. The fallacy of requirements. Your requirements specification has been written when you know the least about the problems you’re trying to solve. There’s a good chance you’ll receive poor proposals and select the wrong CRM software if you have missing, incomplete, ambiguous or gold-plated requirements.
  2. Reliance on references. Many RFPs ask for several client references and case studies. Often the contact information requested is private and the project details are confidential. Even when great references are provided, there’s little chance that the same team that performed the reference customer’s project will be assigned to your project. The consultants that performed the reference project could even work for one of the other suppliers by now.
  3. Clarification questions. The best consultants ask great questions to clarify your requirements. Some buyers only accept questions in writing then circulate answers to all the suppliers. This creates an incentive not to ask any clarifying questions. Instead, suppliers make lots of assumptions while responding to the RFP. Relying on assumptions means that any solutions proposed and estimates given are likely to be inaccurate.
  4. Lack of qualifying information. You are more likely to receive proposals from the most suitable providers if you provide comprehensive RFPs that are easily qualified. Potential providers qualify your RFP by evaluating its quality, scale, risk, timetable, and complexity. Then they compare your project to their strengths and decide whether to participate or qualify out. This keeps down the cost of sale for the providers, and the cost of procurement down for buyers too. Too many RFPs omit important qualifying details such as intended number of users, anticipated timescales or expected benefits. I once had a period of six months reading public sector RFPs and not one of them specified the number of CRM users. Some buyers even refused to specify the number of users when asked directly. This increases the chances of receiving unsuitable proposals. Some qualified providers will decide to qualify out and not to respond at all.
  5. No business case. RFPs rarely refer to a business case that states the desired business outcomes or quantifies the value of the expected benefits. So providers are left guessing about which features will have the most value and what budget will justify the investment.
  6. Who is the implementation team? Lots of RFPs ask for resumes of consultants that will implement the software. But there’s usually little chance that the proposed consultants will be assigned to your project. You’ll be spending significant amounts of time with the provider’s CRM team on your project. But the people that you meet before then are CRM pre-sales consultants that don’t work on implementation projects.
  7. Generic contracts. Draft contracts that are rarely suitable for CRM software and services are often included by procurement managers in the RFP. Each potential supplier has to have their legal counsel review the draft contract before they’ve even been shortlisted. Often the contracts are suited for software procurement but not consulting services or force suppliers into situations that unnecessarily drive up costs for the customer (such as forcing fixed-price engagements or customer ownership of intellectual property). The result is that small companies can’t afford to bid. Only large, expensive providers can afford to respond.

Traditional competitive procurement processes work well for acquiring goods and services in lots of industries. They have worked, and sometimes can work, for acquiring CRM software and services. But there are some better procurement practices we can use to engage better-qualified providers, to elicit better proposals from them, to increase our chances of selecting the best provider available, and to reduce the costs of procurement.

Watch the legendary Four Candles sketch by the Two Ronnies if you want to witness all the challenges of traditional procurement in action.

Tryouts: auditions for potential CRM providers

Tryouts involve working closely with potential providers for a couple of days or weeks. During this time, you can assess the outcome of their actual work instead of relying on proposals to evaluate their potential work. The idea was inspired by the CEO of Automattic holding auditions to build a strong team.

Tryouts offer a chance for you to evaluate CRM software and the potential implementation team. You can tackle risky parts of our project early before they become expensive. And you can arrive at an implementation estimate based on a small piece of real working software.

How does a CRM tryout process work?

In a CRM tryout, we obsess over providers’ ability to create valuable CRM software that delivers desirable business outcomes.

Initially, we don’t ask about the CRM providers’ quality management processes, environmental management systems, or workplace health and safety policies. We look at those other qualities too, but they are secondary and come later in the process.

For CRM tryout, the process goes like this:

  1. Determine need. Write your CRM specification and obtain stakeholder approval. The CRM specification should describe your business case and provide a sense of the overall scope. It should describe at least one CRM process in detail so that potential suppliers can qualify your project and prepare a short demo. It doesn’t need to be complete or accurate.
  2. Engage potential providers. Send your requirements specification to your list of potential providers. Include your procurement criteria: quality, environmental, health and safety, financial. Let providers know they’ll be assessed on these qualities later.
  3. Qualification and clarification call.  Give providers a 30-minute call to ask their clarifying questions. During this call, you are evaluating each other. You’ll eliminate some providers at this stage and some will qualify themselves out. Ask tough questions: based on their experience, how much does a project like this cost and how long will it take? What are the riskiest parts of the project? It’s better to drop a potential provider after a 30-minute call than after they’ve spent 5 days writing a proposal that you’ve spent 5 minutes reading.
  4. Demo presentation.  After the call invite a short list of providers to give you a customised 30-minute demo of their software. Ask more tough questions. Your goal is to be able to go forward with two, perhaps three, CRM providers.
  5. Tryout workshops.: Run a couple of project kick-off workshops with one or two shortlisted providers. This is your opportunity to assess their real-world competence and the quality of their approach. The objective is to have a shared understanding of your project scope, requirements, and desired business outcomes. Timebox the workshops to between one and five days depending on the scale of your project.
  6. Tryout project. Run a short project with the preferred provider. This is your opportunity to assess their team members’ ability to meet your initial requirements. Can they deliver your most valuable features? Can they mitigate your riskiest requirements? Timebox the project to between one and four weeks depending on the scale of your project.
  7. Appoint supplier.  Your procurement team should be conducting their own evaluation and contract negotiation while you’re running the tryout. Aim to continue the engagement with the CRM provider (if the tryout was successful).

Aren’t tryouts more effort than traditional procurement?

In the initial stages, there is less effort for the CRM customer and potential providers. Both parties avoid the busy work that goes into preparing and responding to a request for proposal.

As the field narrows and the tryouts begin then the level of effort for both parties ramps up. The tryout begins to feel like an expensive method of evaluation. But that’s exactly what we want. We want customers who are serious enough about their CRM projects that they are willing to invest their time. We want providers qualified and motivated enough that they are willing to do what’s necessary to succeed and passionate enough to make this potential project a priority.

During the process, we try to collect and provide as much feedback as possible. The clarification calls and demo presentations are carefully scored so we can confidently eliminate providers as early as possible out of respect for everyone’s time.

Trying tryouts

The tryout process only works when there is open and honest feedback in both directions. The level of communication required is something that’s difficult and often absent during traditional procurement processes.

Diminishing the role of the request-for-proposal and letting so many potential providers directly engage the evaluation team will be a step too far for many procurement departments.

But tryouts are not all or nothing. You can begin being adopting parts of the tryout process that might work within the culture of your organisation. Experiment with holding clarification calls, running tryout workshops or even a tryout project. Try out tryouts.

I’d love to hear which parts of tryouts work you think might work and which won’t in your organisation. Have you tried tryouts? Let me know if you’d be willing to share your story so that I can add some real world CRM tryout case studies.

The Fallacy of Requirements

17 July 2016

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?

CRM ProjectCartoon1

CRM ProjectCartoon2Created 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,, 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.

Etc. Etc.

“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 processworkflow, 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.

Riva Role Activity Diagram

Credit: Process Architecture for Digital Libraries Using Riva and Role Activity Diagramming

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.