Yesterday, I made a presentation to a small number of optics professionals. The content was, an unbiased, look at the things to consider when buying a new Practice Management System.
I get asked regularly, what is the most important feature to look for in a Practice Management System, and the truth is that while features must be considered on their merit, the single most important thing when buying software is how the SOFTWARE meets YOUR needs.
How long will it take to change my software?
The length of time it takes is subjective based on the complexity of your needs, your current situation, the size of your business and the capacity of the supplier. However, I would suggest that it is a minimum of 3 months should be allowed for regardless.
Before you contact PMS suppliers (~2 weeks):
Regardless of the size of your business and number of staff, I recommend:
- Establish a project team - this could be a mixture of internal and external resource but should include the following roles, some roles could be the same people, usually a minimum of 2-3 people:
- Team Leader/ Project Manager to manage the internal team and supplier relations
- An Optometrist to represent clinical requirements
- A Dispensing Optician/ Dispensing staff to represent dispensing requirements
- A Receptionist to represent reception/ clerical requirements
- Business/ Operational input to represent business requirements (marketing, management figures/ reporting etc)
- IT advisor/ IT input to input/ manage hardware changes/ restrictions
- Business Owner/ Director who is the person that is responsible for making the final decisions that affect the business (system cost/ budget, approve requirements, training, overtime etc) - List current processes - making a list of things that you currently do within your current PMS software is important as you will likely want to continue doing this in the next package. For each of these processes, sketch out the steps to complete each process. Each member of the project team should do this for the area they represent. Everyone should consider what they like and dislike about the current processes.
- Wider staff meeting - hold a full staff meeting with all staff. Ideally this would be an offsite meeting where no patients can interrupt, perhaps out of hours or closing the practice for an hour or so. Discuss the change of PMS and follow this is a rough agenda:
- Introduce the proposed change
- Present the current processes from step 2, capture likes/ dislikes of these processes.
- For each role represented in the project team above, discuss and capture current manual processes (ask staff to tell you which manual processes they'd like to automate, capture why they think this would good, etc)
- Capture nice to have's from the staff. Present the following question(s) "in an ideal world, what would you like to see a new system do? how can we improve through automation what we do in the business? with technology, what could we do better for our patients?
Consider this meeting(s) an opportunity to gain staff buy in for a system change, but also to capture all the processes that staff dislike and/ or others that could be easily automated. - Distill Ideas - the project team should meet to rationalise all the ideas from the staff meetings. And produce a list of requirements which should be organised:
- In groups (i.e. Clinical/ Dispensing/ Reception/ Business etc)
- Rated in Importance (i.e. Must Have, Nice to Have, Wishlist)
- Timeline must have period (i.e. Immediate, <6mths, 6-12mths, 1-2years, 2+years) - Produce a Requirements Document - this document should be a list of everything you have identified in section 4 as stuff that is required/ sought in the new software. This document should clearly highlight for each requirement what the importance is and the go-live timeline.
A requirements document should also include items such as:
- Data Migration
- User Access requirements (generic logins/ login per staff member)
- Multiple Terminals
- Devices/ Platforms (PCs, iPads, Tablets)
- Access type - cloud web/based or installed?~
- Backup protocol/ support
- Technical Support requirements (technical problems
- User Support requirements (training, staff assistance)
The requirements document allows you to:
- Quickly discard suppliers who cannot supply items that are rated 'Must Have' or 'Immediate'- Have a checklist of features that you can make notes against while having demos with prospective suppliers
Initial Supplier Contact (~3 weeks):
The project team should identify a full list of suppliers that it would like to approach for a demo.
- As a first step the project team should contact a supplier and confirm that their system can meet all requirements that are listed as Must Have or Immediate. If the supplier can meet these requirements, then schedule a demo with the project team, the initial demo should be about 1 hour, with an extra 1 hour for the project team to meet in private afterwards.
- At this stage, the aim is just to get a feel for the software and not necessarily drill into extreme detail, but it is important to touch on each of the requirements in your document. It is often better to allow the supplier to follow their standard demo rather than going through the requirements sequentially. The project team should make relevant notes against each requirement as it is presented.
- Before the end of the demo, ensure that all requirements have been touched upon. At this point, the project team should end the demo, and then immediately review the notes in the document. Against each requirement, place a score of 0-5. And then add the scores up in terms of importance. This means each requirement that is rated Must Have add the scores up to give a total Must Have score, each Nice to Have is added up to give a Nice to Have score and so on.
During this step, also note down any questions that may arise now that the demo has ended. These may be used in a later stage. - This process should be repeated for every supplier identified in this stage.
Supplier Shortlist Demos (~1-2 weeks):
A shortlist of suppliers should be made, usually 2-3 suppliers. The project team will contact them again and arrange a second demo. This demo would normally be anything up to two hours. During this demo, the project team would be expected to drill down into each requirement to look at the process and the score against each requirement should be adjusted if required.
On the back of each of the shortlist demos, the project team should again meet in private and review each requirement, both updating the overall scores and making a list of pros/cons of the package.
Appoint Supplier/ Negotiation (1 weeks):
Once all of the final supplier shortlist demos have been completed, a number of variables will be considered by the project team and business owner/ directors. After selecting the software system that most meets the needs of the business crossed with commercials such as hardware renewals/ software costs, the project team will appoint a supplier.
It is at this stage that the job of planning the replacement can begin.
Project Plan/ Rollout (2-10 weeks):
The project team should meet to plan the implementation of the new software. This would sometime include the supplier in terms of their resource requirements but allowances should be given in a rollout plan for the following if applicable:
- Customisation/ Configuration - when will the new system be configured to your needs
- Staff Training - allowing for training time, who will train, staff overtime during training
- Hardware requirements/ installation time
- Data Migration - when the data will be migrated
- Data Input - not migration of data but perhaps new things like stock/ products/ staff members.
- System Downtime - invariably, some system downtime is expected
- Go-Live date - the date the system is first used in the practice. Will this be staggered across multiple practices? Will the implementation of features be staggered across different point?
In summary
The job of replacing a PMS is usually a bigger task than many think, and following the suggestions above or at least tailoring them to your business results in the selection of a system that meets the current and future needs of the business.
The timelines shown against each stage are realistic and can clearly be made expedited by having a dedicated team working on the change. It's normal though that the project team is required to do their normal day job as well as input on the migration.
