How is it possible when implementing a new practice management system to get the technology right and still finish up failing to deliver the business benefits? The IT directors amongst you may say “with difficulty,” which, technically, is a fair point. However, in the current climate, where IT managers are required to have business skills as well as technical expertise, and are increasingly being asked to demonstrate the benefit and return on their shiny new practice management software, there may be more to it. The objective of this article is to attempt to answer this question. My point is simple but important – regardless of whether or not a new system technically works, unless it is understood and accepted by its end-users who are trained to use it effectively, it is a waste of time and money. What are the key ‘people risks’ which can cause IT projects to fail? How can these risks be controlled?
“Requirements will be defined as we go along”
The objective of the requirements gathering exercise for any new system is to answer the fundamental question of “what do we need the system to do for us?”. Is it just for time and billing or do we need case and document management as well? Often done too late (after supplier selection or later), or in insufficient detail (invitation to tender drawn up by IT department only), the failure to define business requirements effectively up-front can cause no end of project delays and increased costs due to frequent and protracted changes to an undefined scope of work. Requirements for a new system should be gathered from a representative sample of business users even before meeting any potential suppliers. Ideas and expertise offered by, and sought from, suppliers may be valuable add-ons, but often include sales jargon and (empty?) promises which blur the core vision and focus of the project team, tipping the balance of project ownership and control away from the business. This is a separate important point which is covered in more detail below. It is the role of the supplier to provide system functionality to meet the established business needs, not to define your needs. The requirements gathering exercise must therefore be internal in focus; the business as a whole should establish its own clear baseline vision before seeking supplier advice.
“The suppliers are the experts – let them do the project management”
Suppliers commonly take on the role of project managers for new system implementations and this is a good control over delivery. Indeed, where there are staff shortages and tight budgets (is this ever not the case?), it is tempting to sit back and let the supplier run the project for you ¯ this is where problems can start. For example, the risks to the firm of a delayed launch will not usually apply to your supplier and they should therefore be managed independently. As in all healthy relationships, there needs to be balance and so it is important to match (if not exceed) on the firm’s side the project management presence of the supplier. It is the responsibility of senior management to ensure that a competent and experienced project manager is appointed to set up suitable structures and channels within the project for communication to take place both externally with the supplier and internally. Assigning your own project manager and doing your own planning also allows you to retain more control over the project which, in turn, gives users confidence that their requirements will be met and that the project is not being driven externally. Consider also the appointment of a temporary change manager to bridge the potential communication gap between technical managers and the users. With your own project management, you are in a good position to challenge supplier assumptions, maintain good control and project manage your supplier.
As far as planning goes, how many IT project implementations are truly delivered late and how many are just doomed never to meet an impossibly tight deadline? Personally, I suspect a large number of IT projects suffer from poor up-front planning rather than late delivery. Yes, it would be good to go live before the new financial year/Christmas/your annual holiday, but is the timescale realistic? Take assurances from your supplier with a large pinch of salt as they have their own reasons for completing the project sooner rather than later, not least of which is to please their new client. Draw up your own project plan based on common sense and challenge the optimistic plan proposed by your supplier. Above all, plan for contingencies as your project is run by people who call in sick, get stuck on trains and suffer family crises. The go-live date should be derived from the total time it takes to complete all the required tasks (including 10% contingency), not the other way around.
“That’s the way we’ve always done it”
It is easy for firms to continue using their new system in the old way, regardless of any potential gains in efficiency which may be achieved through a change to processes. Are you just replacing the old system like for like, or is new functionality driving the need for new processes? If so, is it better to embrace the new, or work around it? Weigh up the costs and benefits to determine, for the long run, which parts of the system are to be implemented and how they are to be used. If a business process change is involved, this should be communicated to the users up front, and actively managed from the flow-charts through to inclusion in the end-user training materials. Where there is significant business process re-engineering, the use for a change manager could, again, be justified.
“The system sells itself”
Any initial resistance to reorganisations or changes in business processes will dissolve if strong commitment and visible sponsorship of the system is shown, particularly at senior management level from within the firm. This is important as new systems are too often seen as IT projects instead of business projects. When this happens, there is an increased risk of the system being undersold to the users – then it may fail to engage their interest or gain their commitment. Frequent and direct project sponsorship of the new system from managers within the firm to end-users leading up to go-live, whether it be team meeting presentations or training session kick-off, will positively impact on user perceptions of the system, increase user training attendance rates and improve the eventual take-up of the system.
“Users will get used to the new system”
Training is a key area when looking at people risks on IT projects. Unfortunately, it is typically an area skimped on by firms, and there are a number of reasons for this:
- overemphasis on getting the system “up and running”
- perception that users will learn more “on the job”
- the project is already over budget and running late
- failure to acknowledge training as a significant project cost which should typically be around 10-15% of budget
- failure to acknowledge that training can be about learning new processes as well as a new system and so takes longer.
Tips for reducing the risk of training headaches:
- Planning – do a training-needs analysis exercise which assesses who needs to be trained on what and by when. This helps to ensure that users are trained only on what is relevant to them.
- Ensure the system is ready and working before training starts. There is nothing more likely to reduce user confidence than an incomplete system.
- Use “real” data and examples in the training materials and exercises – these will have greater relevance to users.
- Start the training no sooner than six weeks before go-live or people will forget what they learned.
- If using the instructor-led approach, consider using a mix of internal and external trainers in a co-trainer format – this gives a good balance of training and business process expertise.
Yes, the users will get used to the system eventually, but how long will that be and can you afford to wait?
A good project plan for a new system implementation should include all the steps required for the project to progress and the system to work: specification, design, build, test and launch, for example. There may also be provision for appropriate controls such as security, reporting, audit, back-up and recovery. While these are important technical control considerations, of equal significance in terms of impact on the success of an implementation is the involvement of end-users – and that is not confined to just acceptance testing and training. Users should be involved throughout the implementation process from the requirements specification stage onwards. Depending on the size and impact of the project, this may warrant the appointment of a dedicated change manager to represent user interest and coordinate communication with the more technical project managers.
Telling and predictable consequences await the firm which ignores the interests of the end-user in a new system. Not least of these is a total lack of interest and/or take-up amongst users leading to the system not being used. The ultimate consequence is the increased cost from user re-training, system re-building and even project start-over! Business history is littered with well documented examples of IT failures. Software solutions can and invariably do work, but it’s the users who ultimately make them work for the business.
