What’s slowing down your CRM development?

I was reading an excellent article called Produce more by removing more, it instantly struck me this thought process would be useful for development tasks.  The article Which is based on a the book below (which is on my to read list)

Essentialism: The Disciplined Pursuit of Less

The standard process of speeding up projects is usually to throw more resources at the project, I’m sure you have worked on a project where extra CRM Developers have been added to shorten the delivery time of the CRM project.

Another popular method of delivering a project sooner is by rushing a project, this is achieved by cutting corners, removing developments steps (unit tests, reduce testing, no documentation, removing code reviews).  The outcome of rushing a project is often a build of technical debt and a CRM project of reduced quality.   You can read my article on Why rushed projects/code doesn’t save time and reduces quality.

Rushed projects often gain short term benefits (reduced development time) but incur the cost of reduced quality.  Creating a high quality CRM solution is taking a long term view because the code will be easier to debug, understand, extend and change.  Unit tests will be able to rerun and code reviews help junior members of the team learn more about CRM development.

This article will consider a different way to increase the speed of delivery for a project.

What is the goal of a CRM project

This quote highlights the frame of mind needed to streamline the process of creating a CRM solution

We can’t know what obstacles to remove until we are clear on the desired outcome. When we don’t know what we’re really trying to achieve, all change is arbitrary. So ask yourself, “How will we know when we are done?

The first task is to analyse your CRM project and understand what are the key tasks of a CRM project.

The key tasks are the priority tasks team members should be focusing on, the other tasks we can analyse to see which tasks it’s possible to remove.

CRM development,  development tasks in general can seem illogical or unquantifiable, a lot of unknowns and tasks which are estimated but which contain elements of risk.

Why are tasks hard to estimate

Tasks involve human interaction

  • Collecting requirements
  • Company politics
  • Dealing with different and difficult individuals


  • Integrating with 3rd party software
  • Company policy


  • Design of code
  • Unit Tests
  • Documentation
  • Build and deploying
  • Peer Reviews

Customers can sometimes forget estimates are best guesses, they should be quite accurate because they are created by developers with plenty of experience of similar customizations but each CRM project and piece of CRM development is different and unforeseen circumstances can interfere with the estimates.

Code needs to work and be all structured
A design of a solution can sometimes be found incorrect late in the day when a developer is developing a certain part in more detail, e.g testing the design theory with a practical exam

Learning and development of people

  • CRM Developers might need to research some skills (e.g. search the internet or the Hosk CRM Blog :-))
  • Peer reviews rewrite

What is the end goal of code and customizations

Whilst I have talked about the various different tasks in a CRM project it’s worth reminding ourselves of the goal of a CRM project.

The end goal of CRM development is to create quality CRM code and customizations

  • Deliver functionality
  • Few bugs
  • Easily maintainable
  • Easy to understand
  • Easy to debug
  • Manage complexity and create a CRM solution as simple as possible by creating lots of small simple pieces of development which work together as a whole

Do tasks take time or save time?


I have considered some of the tasks of CRM development, the goal of a CRM project is to create a quality project to deliver the required functionality to the customer on time and bug free.

With this knowledge of CRM projects, CRM development is not straight forward, consider the facts below

  • Quick projects cost you more time
  • Spending more time designing code can save you time later
  • Simple code can be reused
  • Unit tests can save time and find more bugs
  • Peer reviews can help learning, find bugs and keep code quality high but seem to take more time

The tasks above initially seem to make a project take longer but they create better code which has fewer bugs, easy to debug/extend/understand, which will save time later (long term benefits)

What is slowing down your CRM development and CRM projects

So far in this article we have seen a lot of tasks in CRM projects are difficult to estimate because they involve tasks which can only be estimated but which can take longer when the tasks are being done.
Tasks which involve human interaction always have the potential to take longer with misunderstandings, personal and political issues coming into play.

Things which can slow you down

When you think about your CRM project, concentrate on

What are all the obstacles standing between me and getting this done


What is the obstacle that, if removed, would make the majority of other obstacles disappear?

Here is a list of of items which could be slowing down your CRM project

  • Knowledge – Lack of
  • Poor code
  • Inefficient processes
  • A customer who keeps making change requests
  • Poor development environment
  • Hardware
  • Missing requirements
  • Inexperienced team members
  • No Experienced CRM Developer
  • Flawed design
  • Bugs
  • Layers of people
  • Slow IT support

In the book Essentialism: The Disciplined Pursuit of Less it uses the excellent phrase of finding your slowest hiker.

Knowledge – Lack of

A lack of knowledge in your team can slow down the project.  The reason is CRM developer make mistakes when learning new customizations or code/customizations they do not have any experience of.

This should be expected and factored into the project, I view this as an investment in time by the employer.  The employer will be rewarded with a CRM developer who is more experienced.

The real danger can happen when a CRM developer cannot get the customization to work or their design has a fundamental flaw hidden inside, which only becomes apparent later on in the project.   The lack of knowledge can be more of a problem when integrating 3rd party software or WCF services which can be more complicated than more standard CRM development.

The best to method to combat a lack of experience is to have senior developers working on the project.  Senior developers can

  • keep more junior developers on track
  • Help junior developers not to get stuck
  • On hand for quick help
  • Help with the design of solutions

A senior developer acts like a safety net for junior developers, can provide quick answers or advise on the process a junior developer should tackle an unknown problem.  The biggest plus is senior developers can help junior developers from wasting time on problems which senior developers can point them away from before they make them.

Poor code

Poor quality code can be written quickly but afterwards any interaction with the poor code will be difficult, will take longer and is harder to understand.

Poor code usually is created by inexperienced developers who create complex code The problems with complex code and complex CRM Customizations.  Complex code makes any interaction with the code difficult and will take longer.  The code is usually created like this due to inexperienced developers or because the code has been rushed (Rushed Code projects do not save time)

Inefficient processes

Projects can have inefficient processes, one of the main culprits is build processes.  Moving the complex CRM solutions can take a lot of time spent

  • creating and deploying solutions
  • Documenting changes
  • manual steps with deployments
  • testing

A customer who keeps making change requests

The ideal CRM project is a collaboration between CRM supplier and the customer.   When this works it’s a beautiful thing, the CRM supplier brings the CRM expertise,  the customer brings their detailed business knowledge.

Unfortunately many times it doesn’t happen this way.  Sometimes customers can decide to make technical design decisions or demand customizations which are not recommended by the CRM supplier.

A common mistake for the CRM supplier is making incorrect assumptions about business logic or creating code with design flaws or bugs.

A common problem in CRM projects is when a customer constantly changes requirements.  Below are the common reasons for constant requirement change

  • Poorly defined requirements
  • lack of customer time invested in the project
  • changing members of the customer team who have different opinions
  • wrong people creating requirements, which don’t match work practices of users

Poor development environment

Messy and poorly set-up development environments can make development difficult.  Development on CRM projects can often involve multiple developers working from different locations.

Development environments don’t usually make development any easier but a poor development environment can slow things down.


Slow developer computers

Slow development environment

It doesn’t make sense to pay CRM developers lots of money to do their job and to slow them down with poor hardware.  Slow hardware has a cumulative effect of slowing development by small amounts many times  a day, 5 days a week, 52 weeks a year.  It all adds up to many productive hours being lost whilst the CRM Developer waits for his computer or the environment to do it’s thing.

Missing requirements

Missing requirements can cause problems

Inexperienced team members

A project with a lot of inexperienced team members can slow down development

  • Making mistakes whilst doing new development they have no experience
  • creating more complex code (which is harder to maintain, extend, debug)
  • working through mistakes people learn to avoid through experience

In my article Should you hire a rockstar developer for your CRM project, it mentions these points about inexperienced CRM Developers

  • Take longer to do customizations
  • Poor design can lead to problems later in the project
  • Make more mistakes whilst learning and gaining experience
  • Does not always choose the correct type of customization
  • Create complex code and customizations, which are difficult to maintain, debug and extend
  • Can have problems integrating with 3rd party software and tools
  • Increased likelihood of late delivery of the project (due to problems with code and incorrect estimates)

No Experienced CRM Developer

Experience and CRM Development (and possible development in general) can be summed up by this quote

Inexperienced developers make complex solutions to simple problems

Experienced developers make simple solutions to complex problems.

I have previously talked about experienced developers in this articles

Should you hire a rockstar developer for your CRM project

What do Senior/Rockstar Developers bring to a company

  • Avoiding costly development mistakes
  • Create best practice documents
  • Experienced developers are often very good at assessing third-party software
  • Helping other developers
  • Calming influence
  • Create a good team
  • Senior developers mentor
  • Senior developers are a safety net

Experienced developers keep the project on track, help inexperienced members and act as a safety net to stop major problems with a project.  Experienced Developers are particular important for the design stage of projects or if a large problems suddenly appears.

Flawed design

Flawed designs are not usually obvious and the flaw often comes to light when development on a section of the solution is investigating at a deeper level.  A flawed design is usually due to unforeseen limitations of 3rd party software or some missing/misunderstood requirement


complex code and a lack of unit testing/peer reviews can mean many bugs make it into the production environment

Layers of people – bureaucracy

Sometimes projects have too many people to discuss and inform about project decisions.  Like trying to agree a party date with a big family (someone always can’t make one day) you can end up discussing availability and other topics instead of the project.

Needless Meetings

The amount of time wasted in meetings is staggering.  Think about all the pointless meetings and the many times people attended meetings they didn’t need to be in.

In some projects telephone meetings can become a habit.

I’m not against all meetings, an effective meeting can save lots of interactions (email, phone) but I recommend analysing who attends meetings and ensuring you can justify everyone’s attendance.

Slow IT support/procedures

In large organisations IT requests can take weeks, in some situations this can be a bottleneck for CRM projects.

If this is constantly slowing the CRM Project down it needs to be raised with the customer and faster path needs to be arranged


Sometimes certain people can slow down entire projects.  It could be a customer wants to do all the tasks and their workload is too large.

It could be only one person on the team has knowledge about a particular process or 3rd party software.

What steps should you take

I have gone through some of the common problems in CRM projects, the next step is to identify and remove those problems.

Identify your slowest hiker(s)

I will admit I love the saying Identify your slowest hiker but I also like the idea.  Most projects speed up development process by adding more resources, this is usually effective (although you can get in a situation where you have too many developers who are constantly getting in each others way).

Identifying the slowest hiker is looking at your development environment, the team and the processes to see where your bottle necks.

It could be things like

  • Too many releases
  • No senior developer
  • under trained users asking simple questions
  • manual processes
  • poor quality – too many bugs
  • layers of people
  • slow IT change requests
  • slow debugging techniques
  • no unit tests/no code reviews – more bugs

Remove Obstacles

Once you have audited your Development team, processes and environments the next step is to improve them.

Each CRM Project and CRM environment is different but many lessons and improvements found can be made into best practices for other CRM projects.

Like the design of a solution the design of the CRM Project team is an important step before the project begins.

Changing team members and resources after a project has begun will mean the incoming project team members will have to quickly understand the business rules/logic.  The new team members will be considerably less efficient than the current team members (who have a wealth of business logic) who are in the project flow.

It’s better to make project team changes earlier rather than later to give the new team members as much time to learn about the business logic/rules and more time to make a positive impact on the project.

Removing obstacles in CRM projects can sometimes be quick but sometimes can involve changing project processes on a company level

  • making unit testing mandatory
  • peer reviews
  • build processes
  • Automated testing
  • Creating/using software to automate steps

Changes to factors controlled by the customer are best tackled by discussing the issues and both  the CRM solution provider and customer working together to find practical solutions.   Ultimately it will be in the customers benefit to improve the speed of the project but change is never easy.

Changes on the customer side are the customers prerogative but if you don’t raise the issues with the customer then no improvements will be made, if you raise the issues you have a small chance of improvements 🙂


I hoped you enjoyed the article and this was an interesting way to look at the speed/efficency of your CRM Projects.

Some of the solutions focus on improving the quality of your CRM project, the idea being better quality code is easier to work with and results in fewer bugs getting out of the development environment and into the production environment.

Team members of a CRM Project ideally you want to get right at the start of the project due to the time it takes to new members to acclimatise to the new project and learn the business rules/business logic of a project.

Improving the delivery speed of your projects might not always involve adding more people, an interesting thought.