Budget blowout has almost become the norm in IT projects. Why?
There are many ways that the costs for a project such as CRM grow to well beyond what is expected. Perhaps as many as 80% of CRM projects go over budget – why? [Although this article is about CRM, the content is true for many other types of projects.]
The reasons are many and varied, but if we drill into them we do find some common themes:
However, perhaps the biggest reason of budget overrun is quite simply waste. This waste comes in many forms, and all though the project.
But, before I go into some of the areas of waste in a typical CRM, or perhaps any software implementation, project, I’d like to highlight something that probably catches many buyers unaware – and something that is true in many areas of life and business. When you are talking to a potential supplier, understand how that person is remunerated. In the CRM / software arena, you may be talking to someone who is remunerated by selling licences, to someone who is remunerated by selling services or to someone who is remunerated by results. Their remuneration method will often dictate or at least colour the advice that they give you.
There are three main phases in a project such as CRM:
If you are to avoid waste, you should layer education across all of these.
Most CRM projects now are based on a CRM technology, a COTS (Commercial off the Shelf) product, rather than being built from the ground up. Your selected technology already has much of the functionality that you require and your project is only adding those final details that make it work for you. This is shown here
Most CRM projects now are based on a CRM technology, a COTS (Commercial off the Shelf) product, rather than being built from the ground up. Your selected technology already has much of the functionality - often 80% or more - that you require and your project is only adding those final details that make it work for you. This is shown here
Contrast this to a traditional software development project when you designed what you want and then the developers wrote code to meet most of those needs. These developers were essentially starting from a blank canvas.
But, when you are configuring a COTS product, you are only working with that small layer that gives you that final bit – the bit that makes the solution just what you need, be that your specific processes, reports or data. To get the best value from a COTS product then, it stands to reason that the people identifying the requirements should understand the capability and the limitations that they already have. This is the education that should be included in the planning phase. This education then allows you to move both your business and the selected technology towards each other, rather than making the technology move all the way to meet the business – as would happen with a new build software product. This adjustment alone can remove a lot of potential waste in your project.
Imagine if you wanted to buy a birthday cake – let’s assume that you have already decided not to bake one yourself, although this is obviously possible. You go to the bakery and select a cake, then you choose the decorations that personalise it in the way that you want, perhaps icing, or candles or some specific words. All of these changes are fine, expected and probabgly encouraged by the salesperson. The cake is made to have these. But if you want to change the flavour of the sponge, it would be foolish. You do not select a chocolate cake and then ask the bakery, or even demain that the bakery, makes it caramel.
The planning phase, if done by people who are skilled in this, should give you a detailed plan of what will be delivered, when it will be delivered and your responsibilities. Amazingly, this key phase is often omitted – usually to save money. When the planning phase is omitted, no-one knows what needs to happen when, and the project will grow to fill the time available. This is a huge area of waste, because people will be being paid to fill time without there being any specific goals from the time investment.
Many people set out on a CRM project believing that it is simple or obvious, and they just need more, or different, people to implement the project. They then move to their HR processes (be that internal people, a tender, using social media or recruitment consultancies) to find those people. Needing more, or different, people is expected. But only source those people once you know what skills are required and when – after all CRM people are not all the same.
A CRM implementation project will require the following skills in varying amounts and at different times:
However, these roles may exist in one or several people. Assuming that all 'CRM people', or 'CRM developers' or 'CRM consultants' or whatever term your HR provider has given them are equal is another way to vastly increase your costs.
|Sourcing people for the implementation phase
before the doing the planning phase
is putting the cart before the horse
Sourcing people for the implementation phase before the doing the planning phase is putting the cart before the horse. At this stage you are unlikely to know exactly what you need, and even less likely to know when you will need them. This means that the only way to can resource the project is by over-resourcing it.
Would you start a house renovation by employing a builder? So why are you starting building or renovating your CRM solution by employing the people to do the building or the renovating?
All building and renovating projects need to start with a plan. Even the plans start out in an outline form and become more detailed. In the building scenario this is your sketch of how you see the new or changed home through to the fully refined architect’s plans. For your CRM project it is your high level desires from the project through to a fully developed solution document. I have recently been involved in a project where there was no training of the key people prior to the scoping. This has led to the business constantly asking for very minor changes – changes that will deliver little or no benefit to the users, but their time spent documenting the ‘need’ for these changes has kept them busy.
The execution phase then delivers on the planning phase. This will blow the costs out for any, or a combination, of the following reasons:
In both the building scenario and a CRM project, it is cheaper to correct a mistake when you find it earlier rather than later. For example spotting that a room has no door on the plans is probably quickly rectified. Waiting until you realise that you cannot get into to your new room, breaking down the wall and rebuilding around the new doorway will be much more costly.
The education that is required in this phase is to ensure that people making the changes are broadly aware of the options available to configure the technology. For any business requirement there are probably several possible ways of solving it, and some are better than others. If the implementers do not have anyone who has a broad range of the options, incorrect decisions will be made about implementation. When you only have a hammer, every problem looks like a nail.
|When you only have a hammer, every problem looks like a nail|
The execution phase also includes testing. Testing needs to be constrained to be the testing that the original requirements have been met. Testing is not an opportunity for the users to find more features or functionality that they might like to have. If testing turns into an agile “let’s see what else might be cool” your costs can blow out enormously.
Testing is also not training. I have been involved on a project where the client thought that letting all the users loose onto the provided solution, to learn about it and to see what they thought of it, was testing.
Testing is almost a sub project in itself. Testing requires specific steps to be documented and tested against. The steps should come from the requirements. If this is not done and controlled, testing will deliver a mountain of new requests. And immediately your budget is blown. The testers also need to know how to use the solution. I have seen some unholy disasters because 'generic' testers, who knew neither CRM nor the business requirements were drafted in to test CRM. There is no way generic testers can test to a set of requirements, unless they receive some very thorough training.
The final phase is the post go-live phase. The key requirements during this phase are:
The cost of both of these can be kept down if the earlier phases were completed thoroughly. If all users were trained on the solution that they are using, with training materials that closely match their job processes, and follow on training to answer questions and extend the knowledge of the users is provided, bad habits will not creep in. Bad habits are expensive.
If scoping and training were both done thoroughly the number of bugs will be lower, both because the real number of bugs is lower, and because there will not be false positives, i.e. bugs identified that are not really bugs, but misunderstandings on the part of users. The post go-live phase should be a low cost phase. But if money was saved by scrimping on the scoping and training, the post go-live phase will cost a fortune.
There are two key things that you must do if you want to slash your CRM project budget – perhaps in half:
To scope accurately, what functionality will benefit your business, both now and moving forward, and then mapping that functionality to the functionality provided in the technology requires a knowledge of three things:
and you need one person with adequate knowledge of all of these who can draw the information together. This should be done in a workshop session with key people from your organisation – not just users - as well as people skilled in drawing out holistic, overarching information as well as detailed information.
In my experience, when the old-fashioned approach of detailing requirements and then getting another person to translate them into technical design details for the coders - yet another group - to work from, problems creep in because of the ‘Chinese whispers’ that occurs between stages.
A modern trend that sounds attractive but which can cause challenges, especially if used by people with inadequate skill, is agile development. The idea behind agile development is that the solution comes about in a fluid, iterative fashion with requirements being developed in parallel with the features and testing. However, the idea has been taken by inexperienced people as a way of reducing costs by cutting down on scoping and instead believing that the testing and early use will highlight the additional features required. Agile has its place in implementation projects, but it should never be used in place of scoping. In the building scenario, this could be waiting until the bathroom fittings are installed before deciding on the tiling – so you were sure that the tiles would complement the fittings.
This often leads to a solution that is undocumented and also fails to meet users’ unspoken requirements. A colleague of mine refers to agile development as fragile development – because of how often it fails to deliver as expected.
Over design – this is developing features that are not needed either because they add little value, or because the features already exist in the selected software, but are redeveloped, either from lack of knowledge by the implementer, or because the scoping and design did not identify that the feature already exists.
Underutilising staff - Staff not fully being fully effective, perhaps because they are waiting for responses from elsewhere, or are on a fixed length contract which is longer than required, or are doing a job which they do not fully understand so takes longer.
Training – or rather the lack of training. Training is often seen as expensive, but not training is significantly more expensive. Would you want an untrained, or even inappropriately trained, pilot to fly a plane in which you were travelling – even if the ticket was half the price? The importance of training throughout the project if it is to stay on budget cannot be overemphasised. This is because:
Rework, either during the initial development or later when it returns to support. This occurs either because the features were not correctly and fully scoped initially or when the design was not correctly implemented or tested. This usually happens because of inadequate training. A common example of this is when the initially scope focusses only on data input, so when a data output such as report is required, this is seen as an extra.
The above examples highlight how important scoping and training are to your CRM project if you want to have a realistic budget to begin with and then to stick to that budget. A realistic budget that is kept to, is how you slash your CRM project costs.
If you would like help with your CRM scoping, our scoping workshop materials are available for download, and of course we are happy to help you. Although our focus is Microsoft Dynamics 365 CE, our scoping workshop can be used regardless of the technology that you have chosen - and even if you have not selected your technology.
We also run a range of Microsoft Dynamics 365 training courses in Sydney and elsewhere. If you would like help with your training, please call us on +61 2 82 1234 80
Published by Gill Walker
Gill Walker is many things:
Opsis is an expert Microsoft Dynamics 365 consulting company. Our focus is your Microsoft Dynamics 365 success - not licence sales or billable hours. As Principal Consultant, Gill oversees all business operations and strategic planning and execution, yet she still believes in offering personal attention to each and every client, so as to understand their needs and offer tailored solutions. We are based in Sydney, with clients in Sydney, Canberra, Melbourne, Brisbane and across Australia. We offer Microsoft Dynamics 365 strategy, Microsoft Dynamics 365 scoping, Microsoft Dynamics 365 implementation, Microsoft Dynamics 365 technical support, Microsoft Dynamics 365 advice and guidance, Microsoft Dynamics 365 training and mentoring.