Skip to content

Perfect sprints for CRM projects

22 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

16 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

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.

Commitment

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.

Courage

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.

Focus

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.

Openness

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.

Respect

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 got approved

12 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.

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.

Iterations

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

Roles

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.

Events

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.

Practices

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

four-candles

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, Salesforce.com, Oracle CRM or any other CRM implementation.

My experience lies in adapting agile practices to CRM projects and that’s what I wanted to share with you.

Why do we write requirements specifications?

You could just hire a CRM consultant, describe what you want, and sit beside them while they develop the software until it’s perfect. You might end up with exactly what you want without ever writing down your requirements. This is a feasible option if you own the company and don’t have a boss or shareholders to answer to. But it’s not usually the best use of your time.

We write down our requirements so that we can convey what we want to other people. We write specifications for internal stakeholders. We need to persuade them our CRM investment is justified with a business case supported by high-level requirements.

We also write specifications for an internal or external CRM project team. They need detailed requirements to provide us with an estimate of the project’s effort and cost. Then they use the requirements specification to design and configure the CRM software for us.

The person responsible for eliciting your requirements is your CRM business analyst. It’s the business analyst’s job to describe your requirements. Short enough to be understood and approved. Detailed enough to be implemented.

On my mission to write the perfect CRM requirements specification I have tried lots of ideas in my early career as a CRM business analyst. I studied for a Diploma in Business Analysis from the British Computer Society. I read lots of really good books on requirements engineering. I used formal software engineering methods such as the Unified Modeling Language (UML) and Rational Unified Process (RUP). But I may as well have written the requirements in a foreign language.

Fallibility of the written word

As a CRM business analyst, I’ve written requirements using use cases. I have organised lists of functional requirements and non-functional requirement statements with MoSCoW prioritisation. I’ve compiled data dictionaries and business rule catalogues.

But using words to describe  requirements is hard. Even Shakespeare would have struggled to command the words to faithfully, accurately and completely describe users’ CRM requirements. It’s easy to turn misinterpretations into mistakes even when the requirements are carefully spelt out.

Is there a Google Translator for requirements, please?

Imagine that most CRM requests for proposals (RFPs) are a genuine attempt by a client to find the best CRM solution. Imagine they are not rigged. Publishing a good requirements specification will result in a range of potentially suitable proposals. The better the requirements, the better the proposed solution will fit. Providing ambiguous and incomplete requirements will return vague or inaccurate proposals. A bad requirements specification might even cause some suitable providers to qualify out.

I have seen thousands of examples of badly written requirements. I can recognise them because I’ve written lots of bad requirements myself.

Let’s have a look at just a few of the problems with trying to specify requirements in writing.

Understand the requirements

“Req. B-1: The supplier must demonstrate an understanding of, and ability to deliver on, the requirements and objectives in the development and implementation of a Claims Management System.”

So there is a requirement to understand the requirements? This RFP had a small catalogue of vague requirements like this one. It didn’t state any project objectives. Somehow the respondents would magically understand what’s needed. Importantly, they had to be able to provide a fixed-price binding proposal.

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.

Notifications

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

BPMNExecutableModel

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.

Follow

Get every new post delivered to your Inbox.

Join 2,475 other followers