A lot of these comments will apply to many IT projects, especially in the legal/professional services sector.
So the partners tell you that they want to buy a Case Management System or Practice Management System (let’s call it CMS for short). Perhaps they have decided what will be bought, or they leave it to you to decide what would be most appropriate.
Changing your CMS is a massive job, especially if the full benefits of the investment are to be harvested. That would inevitably require a review of
A CMS is a hugely powerful tool, but only a tool. The thinking needs to be done before hand and ‘buy-in’ from senior management essential.
A few things to consider when scoping such a project :
Here are a few comments on each of the above.
What does the firm want to achieve ?
Doing this preparatory thinking is essential. It will guide how you approach things and give you something to fall back on if later questioned on the project. You need a clear brief. On one project where I assisted the reason was that the existing CMS was unsupported, obsolete and was holding up other essential changes. The brief was to only carry out modifications sufficient to ensure that the firm could continue to function on ‘Go Live’. Bells and whistles could come later. That clarity enabled the team to be able to say ‘No’ with confidence to some change requests.
Is there ‘Buy-In’ at top level ?
Quite frankly, if this is not forthcoming then the investment has to be questioned. It is likely to be an expensive white elephant. Such a significant change to the systems of an organisation will affect how everyone works. Ultimately, although you can facilitate ‘buy-in’, it’s got to be led by the management - or someone needs to find a way to make blockers 'want to help' ...
How do you keep track of all the Change Requests ?
Inevitably you will want to make some changes, if nothing else because of changes in your commercial, organisational, legal and regulatory environment. Those changes should go through the following stages : conceptual, design, development, testing and release. It is so easy to lose track of them. Setting in place a robust, efficient system to track and manage them will save time and ensure better delivery.
Adapting the 'out-of-the-box' structure of the CMS
Think about the structure of your organisation. How will that work with what you get from your CMS provider ? Do you adapt the structure of the business or the CMS. If the latter, then I would suggest you consider making those changes before other changes to the software. If your business, then consider how that will affect the delivery and implementation of the project.
Embedding Regulatory Compliance within the system.
Regulatory Compliance Manager is one of the many hats I have worn in business. My aim was always to try to discern the purpose of the regulations and seek to benefit the business if I could as well as to ensure compliance. One needs to walk a balance between compliance and still being able to do the job and deliver to the organisational goals. So often I have seen this out of balance, with the resultant friction and sub-optimal relationships. The Holy Grail is for the process would be that staff have no option but to comply, without any extra effort for them. One can do this through the processes being embedded in the CMS. In one system I designed a new file opening process that embedded an initial risk assessment, with notifications to supervisors where the risk was high. That helped manage risk and also demonstrate an audit trail for the regulators with virtually no extra effort by staff – it took only seconds for the staff to complete the process.
Who tests the technical aspects ?
No matter how good you are, you will not be an expert in all areas of your business. If your business is divided up into specialist areas, you will need people within those areas to test the technical aspects – to ensure that the content and process is correct for achieving smooth operation and quality of service in that area. Try to ensure that the people chosen have adequate knowledge, skill, aptitude and the right attitude. Important also is to ensure that their line managers fully support them, give them clear instruction on policy decisions (see the section on ‘buy-in’ above) and provide them with the resources (including time and a relaxation of other targets) to allow then to do the job properly. You will need to manage this team and ensure that you have a good process for handling their change requests/suggestions (see the section on ‘Tracking Change Request’s above).
Data Mapping, Documents, Screens and Workflows
We are now into the guts of the project. How important each will be will depend upon each product and project, but each aspect needs to be carefully considered. Data mapping is particularly if you are migrating across data from an existing system. It is slow, laborious work where one has to be meticulous in getting things correct. Sadly there are no real short cuts; you just have to get it right. Typically this is dealt with centrally. Documents – it really depends upon the nature of your organisation and the project. The Legal Industry tends to use loads, others use very few. However, attention to this should not be overlooked, as usually this is your interface with your customers. A lot of this work can be dealt with by the team of testers you might have in specific departments/practice areas. Screens – the principal way in which data is input to the system to then be manipulated and used to run processes, populate documents and to be reported upon. They are like the windows into the database. Watch out for inconsistency in naming, positioning and structure, which may make it more difficult to work across areas. Work on these is likely to be a mixture to the testing team and central IT. Workflows – these can offer the greatest efficiency, risk management and profitability gains, but also be the most complex, as they embed processes into the system in the purest form. Watch against over-complicating them by trying to make them cover every eventuality. Two examples from work I have done are :
Do you have adequate resource/expertise for the project ?
It may sound a stupid question, but be under no illusion how big a change this is. Most business don’t do this more often than once a decade, if that. IT departments are normally resourced for the day to day issues and for planned infrastructure upgrades etc. They may well not have expertise of having done this before. The people with the longest tenure in the business will normally be the partners, senior management or in non-IT areas. They will seldom have the skills or inclination to assist you in the guts of the project. You may need to call in external expert assistance for the duration of the contract, during which you can build resource within the organisation upon which you can call (see ‘Training of Staff’ and ‘Future Developments’ below).
‘Go Live’
How well have you thought this through ? Have you asked such questions as :
It is worth while thinking this through at the start of the project and then backwards plan. I would suggest that you do not take what the software supplier tells you as gospel. Test it, challenge it. You are the customer. You will have more bargaining power at the beginning of the project, before you have signed, than when you are totally committed and need them as much as they need you.
Training of staff
This is part of the ‘Go-Live plan, I would suggest, but not exclusively. In one project I the IT Manager sent out little bits of advice on various areas during the course of the preparation so that staff would be aware of momentum, but could also absorb this information in small, bite-sized chunks. I have a series of Road Shows to introduce staff to the look, feel, structure and geography of the system and major screens so that when the more intense training took place just before ‘Go-Live’ they were already familiar with these aspects and could take in more of this training. Don’t fall into the trap of thinking that training will stop on ‘Go-Live’. Indeed it would be good advice to plan follow-up/refresher training for a little time after ‘Go-Live’, once the initial excitement has settled down. This can help to embed good working practices, check bad practices that might have crept in and be a forum for picking up issues that have come to light once the system is being used for real. One final point : I would strongly advise that you try to develop ‘champions’ for the system in each practice area. They can act as your troops on the ground, to filter and deal with the low level issues and pass up to you the more major ones. The team of testers (referred to above in the section entitled ‘Who tests the technical aspects’) could well form the basis of this team of people. All the points made above about senior management ‘Buy-In’, authorisation and facilitation apply again.
Future developments
I know the whole project of bringing in the new CMS will have been exhausting and the last thing you will be contemplating is to have to change things again, but any organisation that wants to flourish will have to keep adapting and reinventing itself. Hopefully your organisation will recognise this. So plan for it. If you have chosen the right CMS, it should assist your organisation in doing this. Having a robust system for documenting change requests (see the section above ‘How do you keep track of all the change requests?) will enable you to refer back to what was done when changes need to be made. It will also help your software suppliers if they need to do something, or when you need to implement their upgrades. You want to make the most out of the blood, sweat and tears you have invested in getting this system in and working.
I hope you have found this article helpful. Feel free to contact me. I am happy to answer questions. Good luck!
