How to Avoid Losing (lots of) Money on Your Dynamics 365 Projects

This morning, while perusing the IT News, I came across an article about a $3.5M loss posted by one of the Australian System Integrators, who provide consulting on Microsoft technologies. The loss was said to be caused by poor project governance and controls, and perhaps more specifically professional service contract cost over-runs.

Is this massive financial loss what you want for your CRM project?

How can you prevent your project leading to this sort of financial disaster?

To me, this story raises a number of questions emanating from “how?”

While I cannot be sure of any of the causes, I would like to suggest that the professional service cost over-runs were caused by some (or all) of:

• Scope creep – or perhaps little defined scope at all!
• Rework
• Development changes taking longer than expected
• Staff changes within project teams

I am constantly surprised when talking to my clients, how many organisations embark on a CRM project with less effective planning than they would a personal project - and often a personal project with far less financial risk.

While it appears that system integrator at the centre of this story, took this loss themselves, perhaps because of the contracts in place; how can you avoid this happening to your project, or your company?

Let us drill into each of the loss-causing factors a little more deeply.

Scoping to provide any level of detail on which to base the time, and hence the cost, of a project is extremely difficult when the team comprises business people who know little or nothing of the technology, and technical people who know little of the business. This situation creates a “lost in translation” scenario, which can easily lead to increased costs because of the lack of understanding.

Another cause of scope creep is overly keen team members agreeing to changes that were not originally scoped. This also highlights the tension between agile projects and pricing – a topic that I have written about previously.

The quickest and most cost-effective way to avoid losing money like this is to ensure that everyone involved in the scoping has a reasonable understanding of both the technology and the business, so they understand the broader project. This usually is aided by providing some training around the functionality in the technology - prior to any scoping. I have met several technical people who do not know how what business their client operates in!  This is not helpful if those people are to problem solve around the client's requirements.

Scoping is also usually more effective when workshops involve a few people together, rather than working one-on-one with individuals. People working and brainstorming together and coming to a consensus, tends to prevent requirements that are too single-area centric, that are more likely to create challenges later.

Rework is needed either when the requirement was poorly understood so the initial deliverable was incorrect, or when the technical person or team developing it did not understand the technology well enough, so incorrect techniques were used, or unsupportable development was done. Poor understanding of the requirement often comes from poorly expressed requirements, and again this probability of this occurring can be reduced by building education into the project prior to any scoping.

Development changes taking longer than expected happens when rework is required – not surprisingly. It also happens when the people responsible for the planning do not know the technology well enough to know what the best way is to provide functionality. A third cause of overrun is when the project uses people who are still learning and who are not mentored adequately.

While staff changes are part of life, they do seem to occur more in these projects. Of course, the great resignation has only increased the rate of turnover within projects. When staff move off a project it almost always results in more work, as a replacement team member is brought up to speed with what they are taking over. If you are unlucky, this also uncovers other issues, which in turn leads to more rework.

I ask that anyone on my projects thinks about their work with three hats on:

1. The client’s hat
2. The futuristic hat of a team member who needs to make a change in a year or more
3. Their own hat

While it may be true that bringing in an outside expert should protect you from these issues, this story, and many others, show that it is not always enough.

So, what do you need to do to protect yourself from these costly challenges?

I feel strongly that the best protection is to ensure understanding by all team members of:

• The business
• The technology
• Project methodology

This also ensures that you do not head into a blind-leading-the-blind situation - people with no knowledge of the technology mandating changes be made by people who do not know why those changes may, or may not add value.

Whenever we speak about understanding, we also must remember that many people, especially in Australia, are working in a non-native language. This means that additional care must be taken to ensure that understanding has been reached, not simply that a message has been given.

While this does take time and hence increase cost of the early stage of the project, when done effectively it will keep the project much closer to the planned budget.

I am strong advocate of boosting education across the project. I also strongly recommend confirming the experience and the certifications held by every member of your technical team. It is important to be aware of both experience and certifications because there are people with many years’ experience who have not maintained their skill levels – and as Microsoft Dynamics 365 is evolving very quickly this can cause problems. It is essential also to have people with experience, and not just those who have passed the exams by exam-cramming but are lacking in real experience. Obviously, there is room in most projects for junior people, and these people often provide great value. However, to really get the value from these newer team members, there must be a way of providing mentoring to them.

In summary, avoiding financial loss and often also personal pain from your CRM projects requires:

• internal ownership and responsibility for the project, 
• mentoring of staff and 
• more education across the entire team than is common.

If you would like to discuss how to avoid losing (lots of) money on your Dynamics 365 project, please contact me or call me.