In the ‘how to document CRM requirements’ series (part one, if you missed it, can be found here) I noted that there were a lot of areas that people tended to miss when setting out their functional requirements for a CRM system. So the following is a list of twelve items that commonly don’t get fully specified, but may just be important:

Customisation capabilities – most systems require at least some tailoring in order to meet an organisation’s specific needs. This is almost certainly going to require the ability to add new fields, or hide existing, ‘out of the box’, fields, but is often likely to require the development of new custom records, beyond the standard system entities.

Workflow management – in the same vein, when you’re adapting a system to tightly support your business processes, workflow functionality, which allows you to automate actions, for example, if the value in a field changes to ‘X’ send an email alert to user ‘Y’, can be a key capability.

Compatibility with existing infrastructure – I’ve seen some businesses forced to make hefty unforeseen investments in areas such as PC’s, servers, operating systems, desktop software, and email, because their new CRM system proved not to be compatible with their existing infrastructure. If there are standards you need a vendor to adhere to, it’s important these are made clear up front.

De-duplication – maintaining data quality is key to a successful system. Being able to identify potential duplicates, both when a record is being entered, as well by scanning the system to find potential matches is important. As is the means to merge identified duplicates.

Offline access – despite the ubiquity of internet access, there are situations where you may need users to be able to operate offline. For example, you may have users in locations where there isn’t reliable internet access, or who are travelling a lot. In these cases an option to work offline can be an important consideration.

Language and currency – for those with international operations, the ability to support local character sets, translate field names and pick lists, manage different date formats, and track and report on transactions in different currencies, may well be key requirements.

Email integration – a lot of key information can end up locked up in the email system, so an easy ability to write incoming and outgoing emails back into the CRM system from your email platform of choice is generally essential.

Calendar integration – ideally you don’t want to have to maintain activity information in two systems, which means that integration between CRM and the organisation’s calendaring application, so that, for example, a meeting scheduled in CRM is automatically visible in the corporate calendar, may well be needed.

Mobile – mobile access is an increasingly important aspect of CRM use, and it’s important to define aspects such as what platforms need to be supported, whether offline access is required, and if customisations made on your main system carry over to the mobile client.

Different views for different users – if you have users accessing your system for a wide range of reasons, then being able create different views of records based on the user, for example, members of the new business sales team might need to see very different fields on an opportunity record, than say the account management team, may be a very desirable capability.

UAT and training versions – when you are testing changes to your CRM or training users, you ideally don’t want to be doing it on your main live system because of the potential to damage data and functionality. Therefore having the right to create separate test/training environments if you are licensing software, or have access to what’s typically known as ‘sandbox’ environments if you are looking at cloud-based systems, can be important.

Security – perhaps one of the most important functional areas that gets missed is security. I’ve seen CRM projects grind to a halt because the client’s security requirements don’t fit with the selected CRM’s out of the box capabilities. It’s therefore critical to think through, and document up front, any requirement to limit access to data or functionality.

While this isn’t, and isn’t meant to be, an encyclopedic list of potential CRM functionality, the highlighted areas are important by virtue of being commonly overlooked, potentially very important to the success of a project, and that there are significant differences between CRM products, and versions of products, for example the feature may be available in the enterprise edition, but not the professional edition. While a lot of CRM software applications may look similar, there are often significant functional differences, so taking the time to specify as fully as possible your functional needs, is generally a wise investment of time.

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]


If you’re implementing a new CRM system and have been talking to potential vendors about how they would approach a project, I suspect the word ‘agile’ features strongly in their presentations.

Go back a few short years though and you would have been hard-pressed to hear the word ‘agile’ being used in many conversations about implementing CRM systems. Back then the waterfall methodology was king. Today it sometimes feels like heresy just to suggest there’s any viable alternative to agile.

But, does it matter? Does it matter that my implementation partner is planning on using an agile approach or a waterfall approach? The answer is ‘probably’, and a possibly ‘a lot’, and it really does pay to understand how each approach works because each has its strengths and weaknesses and ultimately you may find one works considerably better for you than the other.

First though let’s consider each methodology, what is it, and what are its strengths and weaknesses? I will start with what’s known as the waterfall methodology as this is probably the most traditional of approaches.

The Waterfall Approach

Waterfall is a sequential approach to implementing a system. It tends to follow a series of steps culminating in the delivery of the product. These steps typically include: requirements definition, design, development, testing, fixing and going live. The approach tends to be quite documentation hungry and is centred around the design phase where a detailed specification – which can often run to several hundred pages – defines what the developers will create. If what’s developed doesn’t quite meet the need, then this tends to be handled through a change control process.


The strengths of the waterfall approach include:

  • Deliverables are clear from early in the project
  • It’s relatively easy to estimate time-lines and budgets
  • It’s easy to swap people in an out of the project because of the level of documentation
  • The demands on the customer are relatively light
  • The overall design of the system of the system can be optimised because all deliverables are understood up front


The weaknesses include:

  • Design specifications can be challenging and time-consuming to review and it’s often difficult for customers to envisage the end product, which means that what gets signed off isn’t always what was intended
  • If deliverables don’t match expectations, this is going to be discovered very late in the process which can lead to significant unforeseen additional costs and delays
  • If projects do come under time pressure, then, with testing the last activity, there can be a temptation to cut corners in this key area

The Agile Approach

In contrast to Waterfall’s linear step by step approach, the agile methodology starts with a more simplistic project design and seeks to break the project down into a series of deliverable modules which are built through a series of what’s often referred to as ‘sprints’. Each deliverable is tested and reviewed by the client, and that feedback is incorporated into the next sprint, which means the customer is an essential component of the development team.


The strengths of the agile approach include:

  • The customer gets to see and touch the software early in the project and can directly shape the development of the system
  • Customers are often only able to properly articulate their needs when working with the actual product
  • It’s easier to accommodate change if new business requirements crop up
  • It can be a very quick way of deploying


The weaknesses include:

  • It relies on customer representatives who can make quick decisions on behalf of the business to be heavily available for the project, something that’s not practical for all organisations
  • It’s harder to manage budgets and timelines because the deliverables are less clear up front
  • Some vendors may exploit what is normally time and materials billing rather than fixed or firm costs in the case of waterfall
  • Losing key project team members can be very disruptive because this approach is typically light on documentation
  • The approach does need to be skilfully managed to avoid the risk of the project losing sight of the overarching business objectives

Having worked with both methodologies, in my view waterfall tends to suit situations where:

  • There is a need to have tight control of costs and timelines
  • Where the customer has a clear view of the requirements and deliverables
  • Where active day to day involvement from key customer decision-makers isn’t practical
  • Where there a complex development and integration requirements

And agile tends to suit:

  • Simpler projects
  • Situations where the customer doesn’t have a clear view of the end deliverables
  • Customers who are able to make the appropriate people available to the project
  • Where requirements may be subject to change
  • Where there’s a requirement to deploy fast

The reason for writing the post was to stress that the implementation approach is important. There is no ‘best’ methodology. The choice should depend on the individual circumstances of the project. Buyers of CRM technology should carefully consider what approach is likely to work best for them, or, at the very least, if there’s an approach isn’t going to work for them, and that should be a factor in selecting the implementation partner for the project. Not all partners are proficient in, or practice, both methodologies, so finding someone with a track record in your preferred approach is an important consideration.

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]


A guide to phasing a CRM project

January 11, 2015

In my recent series on requirements gathering, I noted the need to document the phasing of a CRM implementation. I’ve come to the conclusion over the years that phasing is one of the most critical aspects of implementing a CRM system successfully, and so figured this might merit some further elaboration. Perhaps the starting point [...]

Read the full article →

How to document requirements for a CRM system – part 6

January 4, 2015

In a previous post in this series I set out my thoughts on the content and structure of a CRM requirements specification. In this post I want to cover how to go about gathering them. The starting point, if you’re not reasonably familiar with CRM technology, is to do some initial research. It’s very difficult [...]

Read the full article →

How to document requirements for a CRM system – part 5

December 13, 2014

Last time out I described what I’d expect to see in a decent CRM requirements specification. Putting this sort of document together isn’t a trivial exercise, but the payback from the time invested can be huge. Here are some of the key benefits of this sort of approach: Increased return on investment – the focus [...]

Read the full article →

How to document requirements for a CRM system – part 4

November 30, 2014

In the fourth of this series of posts about CRM requirements gathering, I wanted to cover content. So what needs to be included in a CRM requirements document? The following covers the main areas I’d hope to see: Approach This section sets out how the requirements were gathered, and, importantly, who was involved in the [...]

Read the full article →

How to document requirements for a CRM system – part 3

November 23, 2014

I promised in last week’s post that this week I’d set out my views on what should be included in a CRM requirements specification. However, I’m going to put that on hold for a week. I realised there were some points that merit some articulation first. So, to help set the scene, here are a [...]

Read the full article →

How to document requirements for a CRM system – part 2

November 16, 2014

In last week’s post I covered some of the common problems with specifying CRM requirements. In this post I want cover purpose. In other words what are we trying to achieve with a CRM specification. In this respect, I believe there are five key objectives: 1. Identify suitable technologies – by setting out the functional [...]

Read the full article →

How to document requirements for a CRM system – part 1

November 10, 2014

As an independent CRM consultant I get to read a lot of CRM requirements documents, and it seems to be an area that most would-be buyers of CRM technology struggle with – probably because there’s little guidance out there about how to approach the exercise successfully. This would be less of an issue if this [...]

Read the full article →

Last quarter’s CRM market news in 60 seconds…

July 19, 2014

In case you missed them, here’s my 60 second bullet point round-up of the main CRM software stories last quarter: April take a cue from Amazon’s ‘Mayday’ customer support feature on the Kindle Fire to add a new SOS capability to its Service Cloud which enables customers to be connected to a support representative [...]

Read the full article →