Skip to content

Perfect Sprints for CRM Projects

30 August 2016

A sprint is a time-boxed iteration of software development during which we analyse, design, develop and test working CRM software based on the highest priority items in the product backlog.

How long is a sprint?

In Scrum, sprints can be between one week and one month long.

In the Customer Agility framework, I recommend a two-week sprint for CRM projects. Two weeks is enough time to get enough valuable features developed, but not too long that we miss out on frequent feedback.

Starting a sprint every other week seems to fit most stakeholders’ schedules. A two-week cadence seems to feel right for a lot of people.

Use one-week sprints with caution. If you’re running one-week sprints, you’ll need to run your sprint events efficiently so that they don’t consume too much of your sprint. You can’t afford an all-day sprint planning meeting in a one-week sprint.

Three-week or four-week sprints can be used for much larger projects when you are working with large teams. But longer sprint cycles means more time between feedback sessions so use with caution.

When should a sprint start?

I recommend starting a sprint with a sprint planning workshop scheduled for a mid-week afternoon. We finish that sprint with a morning sprint review meeting two weeks later. I run them as back-to-back meetings with a lunch break and the retrospective workshop in between.

Why start mid-week? Starting a sprint on a Monday is frequently disrupted. Public holidays often occur on Monday in many other countries or team members like to take Mondays as time-off. Monday sprints can also encourage some weekend overtime to finish a feature. Hardly anyone spends the weekend working when your sprints end in the middle of the week.

Can I use Sprint 0 to launch my project?

Some teams like to launch their project with a “Sprint 0” (Sprint Zero). They use this period to run some workshops and prepare the initial product backlog. Some teams also like to use Sprint 0 to get set up: provision the CRM development instance, prepare their development tools and their shared project workspace.

These preparatory activities all need to get done. But let’s not confuse prep work with delivering value. A sprint needs to deliver CRM software. I recommend calling your sprint 0 a planning, preparation or initiation phase and then starting sprint 1 once you’re ready to start delivering stories.

Can I change the sprint length?

At Advantage Sales & Marketing we changed the sprint duration from two weeks to three after about a year. The team seemed to prefer the three-week cadence, but I missed the regularity of sprint reviews every other week.

So it’s possible to change the sprint length, but I would not recommend it. The biggest downside is that changing the sprint length throws your cadence out of whack. Your historical velocity becomes meaningless and other metrics are harder to track too.

Should a sprint ever be extended or aborted?

A sprint is a time-box and it can’t be extended. Even when you just need a few extra days to finish a couple of big stories or there was a public holiday for two days in the middle of the sprint. Stick to a regular cadence.

Occasionally, you might need to abort a sprint. I used a one-week sprint cadence on a recent project that was four weeks long. But we had to abort sprint 2 because the product owner couldn’t match the team’s pace. Towards the end of sprint 2, we still couldn’t start half the stories. So we paused the project for a week to give the product owner some time to refine some of the stories. We resorted to stretching the same effort over two-week sprints giving the product owner time to commit to the sprint events and still perform her marketing job.

Your sprint experience

I’d love to hear about your experience working with different length sprints in your CRM projects. What’s length worked well and what didn’t? Have you ever changed the regular sprint duration in a project or had to abort a sprint? Leave me a comment below.

Embracing the Pillars and Principles of Agility

30 August 2016

Customer Agility’s pillars and principles are based on the same values that underpin Scrum and the Agile Manifesto. Embracing agile’s core values is more important than perfectly adopting any of the practices.

In this article, we’ll explore the pillars and principles in a little more detail and share some examples of the core values in practice.

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.


Transparency should be a defining characteristic of an agile CRM project. In the spirit of transparency, we should be providing information about our project so it can be observed by any stakeholder. This can include:

  • Publishing our story map and release plan for everyone to review
  • Providing all stakeholders with access to review our product backlog
  • Pinning our sprint boards and burndown charts to a wall where everyone can see them
  • Inviting all stakeholders to our sprint review meetings
  • Letting everyone know about the current state, recent progress (and setbacks) and future plans for the project in our internal communications

I like to use a wiki in my CRM projects, usually Atlassian Confluence, where we publish our story maps, release plans, backlogs, retrospective notes, and sometimes videos from the latest sprint reviews. The project’s burndown charts are also published on the wiki so that any stakeholder can visit the wiki site at any time and see where we’re at.

Maintaining the wiki is a team effort. Sometimes, if we’re lucky, there’s someone from a project management office who helps provide guidance so that project wikis are consistent and best practices are shared across other projects.

Inspection and Adaptation

Inspection and adaptation are part of  empirical process control and the scientific method. By adopting these pillars we are acknowledging that it’s impossible to know all our requirements at the outset of the project. We admit that we cannot design the perfect solution before we start to build it.

Empirical process control is the opposite of defined process control. With defined process control we always get the same output given the same set of inputs. There’s very little variance.

Given all the variables in a CRM project, we can’t rely on the same set of outputs given the same set of inputs. We need to do some work, inspect the outputs and be prepared to adapt our next unit of work. We need frequent feedback.

Customer Agility’s events provide lots of opportunity for inspection and adaptation. Each event inspects a smaller scale piece of work. They are release planning, sprint planning and reviews, retrospectives, story previews and daily standups.

If your team finds itself skipping sprint review or retrospective meetings then you’re not giving yourself the opportunity to properly inspect and adapt the CRM system or your way of working.


Customer Agility projects require a commitment on several levels:

  1. Commitment from each team member to the project’s goals.
  2. Commitment from each team member to each other to work together as a team.
  3. Commitment from the team as a whole to work together to achieve the goals of each sprint.

When I’ve worked with high-performing agile CRM teams, commitment has expressed itself through several examples:

  • A team member taking on a task that doesn’t play to their usual skills in order to meet the team’s commitments for the sprint.
  • Team members organising their schedule and any other project work so that they can always attend the Scrum events.
  • A team with spare capacity completing an extra story in the sprint that amplifies the achievement of the sprint goal.


Customer Agility projects aim to improve our customers’ experiences through digital transformation. We do this not because it is easy but because it is hard (to paraphrase a fellow Irishman). The most impactful projects are not the easy ones with reasonable goals but the challenging projects with ambitious goals.

A challenging project doesn’t mean it has an unrealistic timeframe or half the resources it needs. That’s not ambitious. That’s reckless.

A challenging project has lofty goals that will revolutionise organisational performance even if we’re not sure how to achieve those goals at the start of the project.

Courageous CRM teams set ambitious project and sprint goals. They work on risky features early in the project. They aren’t afraid to experiment with new techniques and ideas. They aren’t afraid of feedback from CRM users or real customers. In short, they are not afraid to fail. But when they do they fail fast.


The hardest agile CRM projects I’ve worked on are those where I’m also working on something else. You’ll always perform your best work given the opportunity to focus on one project. Distracted by a second project or support work for another team and you’ll lose focus.

There are several advantages to being able to focus on one CRM project at a time. You’re always available just at the moment when your skills are needed so the team isn’t stuck waiting for your focus to return. There’s also an intellectual focus you can achieve when you only have one project to concentrate on and don’t have to mentally switch your brain into another context.

As far as you can, focus on one agile CRM project at a time.


Hand in hand with the team’s transparency to its stakeholders is each team member’s openness to the team. If you’re stuck on a task,  behind on a story or struggling with a problem then let your team know. At the very least bring it up at the next daily standup but you don’t have to wait until then.

On my best agile CRM projects, I worked alongside talented team members that were always willing to share and declare any blockers. Even when it revealed a deficiency in our own skills. We knew the other team members had our backs and we’d learn something new as we figured out the answer together.


The spirit of openness is really only possible when you also have respect for your fellow team members. Trust them to be capable, talented individuals with a unique combination of skills that enriches the team. We respect the diversity of ideas and contributions because teams that all march to the tune of a single person underperforms over the long term.

I’ve been fortunate enough to work with lots of CRM practitioners on my agile CRM projects, maybe more than one hundred. They’ve all made a valuable contribution to the projects I’ve worked on, and I’m grateful to each of them.

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 an opportunity to provide feedback on features before they are completed.

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. Story previews give the product owner a chance to see and provide feedback on features mid-sprint before they are done.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.


Get every new post delivered to your Inbox.

Join 2,475 other followers