In many ways, the way the software implementation industry behaves today is little changed from the early days of computer software implementation. However, the software is radically different.
It is now exceptionally rare for an end-user organisation to develop a solution from scratch – by from scratch I mean coding all of the requirements.
Today, the development phase of the project starts with an application, which will meet the lion’s share of most users’ requirements. The changes that we make are configuration and minor changes to the existing application.
Given that the start point is very different, why is the implementation process still so similar?
Modern projects still look at their requirements in isolation, pass their requirements on to an analyst who passes them on to a solution architect who completes the design and passes it on to a developer, who implements the changes. There are two weaknesses here the requirements in isolation and the number of people in the chain, each with their own specialism.
Requirements in isolation means that the strengths of the application are overlooked unless, by co-incidence, they meet needs. The number of people in the chain means that key detail is lost in translation.
Today, when we are starting from an application it is far more effective to understand what you have already, before mandating what you need. The design should take the existing functionality as the starting point.
Ignoring this existing functionality and treating the application as a development platform is a silly as demolishing a house because the walls are the wrong colour, rather than repainting the walls. Yet this reinvention happens – too often.
Rather than investing the effort and the budget in ensuring that all users understand how to use the application, and have all their hard-won data ready for them when the solution goes live, the investment is made into development – and often into development of functionality that is already there, or almost there. This is justified by a need for this functionality, and technical experts, either believe that they should do as they are told, or do not have the functional knowledge, or are happy to be paid for a job.
To add insult to injury, the functionality developed is usually less effective than the functionality that was already there, which only needed a bit of tweaking to make it work in exactly the way that was required.
I have seen this in many CRM projects, both Dynamics and other CRM technologies. I’m sure that it happens in a wide range of technologies, especially where the ‘experts’ can bamboozle the client.
This seems to happen because people, at all stages of the project, do not have the knowledge to make the best decisions. The key people in the project will be required to understand the selected technology and so must invest in the learning so they can confidently make these decisions.
In the land of the blind, the one-eyed man is king. I have heard of many projects that have challenges because the implementing ‘experts’ were doing their first project. In every case, the project ended up being far more expensive than anticipated, and often failed to deliver.
So what is the solution to ensure a successful software implementation?
The overall owner of the project should be internal. This owner is the driver of the project and must be someone who has the best interests of the organization at heart – they are not necessarily an employee of the organisation. The owner should be closely involved in the scoping and the design of the project, and should willing to discuss decisions and to push back. They must have their eyes wide open to see one-eyed kings. They must spot everyone who is not considering the impacts- now and later- of the changes being made to the selected technology.
Agile, may be part of the solution, but only if done properly. Agile is a software development methodology which allows small amounts of functionality to be developed and released in an orderly way. It is not a user-free-for-all, although it is too often used as such. It certainly is not a replacement for training – which I have also seen.
The implementation team should be kept small with good, tight communication and minimal staff turnover. Everyone involved in the project should have a good understanding of the functionality of the selected solution – from the outset of the project where the scoping is done.
Education should be woven throughout the project, starting from functional education so the scoping can take full advantage of what is already available, then ensuring that all the technical team have both a broad technical knowledge and the functional knowledge which enables them to make the best design and implementation decisions. This functional training so that everyone has this functional understanding is an investment that will be repaid many times over later in the project.
This training is different to the end user training, which will ensure that all users know how to do their job, supported by the technology that will happen immediately prior to go live. The final piece in the training jigsaw is ongoing training which fulfils two roles – firstly extending the knowledge of users, and secondly giving new staff members the skills to hit the ground running.
To ensure success in modern software implementation projects, the keys are knowledge of the technology, internal project ownership and training – not development.