PMS upgrades and changes value proposition advice from Report Factory

One thing that always interests us and we find quite amazing, is that many PMS replacements and upgrades fail to deliver significant change and desirable outcomes.

It seems to us that if you are spending

• something in the order of 3-5% of annual turnover
• a significant amount of internal resource
• significant additional Infrastructure

on a capital project with a lifespan of 5 years plus, together with

• significant and hopefully short term business disruption
• significant and hopefully short term stress increases on staff and partners

you might want to make sure that the value proposition is sound. If your premise is “like for like” then you will almost certainly fail to deliver anything significant. But it will feel ok, initially.

Remember this is ONE CHANCE in probably 6-10 years to make radical, meaningful changes and blame it on a software project. Don’t waste it…

It is likely that the difference between the ideal software and the next best is not much, but the difference between the right design and the wrong one, is huge.

The key elements (roughly in order) to ensure you get value out of such a project, are logically

• Assume everything you currently do is likely sub-optimal and should be abandoned as a first pass. If anyone says “That’s the way we’ve always done it”, just fire them on the spot, at least from the project.
• Research new innovations in process in the industry.
• Identify all internal and external stakeholders in the project.
• Determine stakeholder output requirements (reports and analysis) and consider where that data will come from in a processed data sense.
• Design, Scrap, Design, Scrap, Design.
• Identify key metrics and values that you expect to change, when and by how much.
• Identify developing and known future pressures on the firm and its processes.
• THEN and only then, look for software.
• Test, Test, Test and Test again. (* A word about testing)
• Provide insane levels of support and training.
• Communicate.
• Be careful how much you listen to Consultants.

Assume everything you currently do is likely sub-optimal and should be abandoned as a first pass.

Yes this seems aggressive, and it should be. Given the size of the project, the disruption and costs, you really want to set aggressive goals. If you don’t want change, don’t start.

Let’s face it, most processes you have presently have grown organically, sporadically and haphazardly. The chance that these processes are efficient and sharp is pretty remote.

New software will likely expose functions and methods you’ve never had before. There’s a very good chance you can use them to do a better job, a new job or better still, eliminate a job.

Not only have people become more attuned to a systems based (paperless) environment, but computer human interfaces have moved forward dramatically, and portable devices and enhanced remote communications. Bringing these into process designs can up-end the whole thing, and should.

Research new innovations in process in the industry. 

Other firms are likely ahead of you and the industry will generally know about innovations, so seek them out. It’s ok to discard an innovation that’s not for you, but don’t do so because it’s new or different. If it’s going to create value for stakeholders, design it in.

Here’s some recent examples from projects we’ve seen.

• Assume a matter should be billed, don’t wait for someone to ask.
• Email Bills automatically once finalised, don’t leave it to partners or secretaries to send them when they get around to it or better still, just send the billing data for the client to upload.
• Use strict automated workflows for opening matters, or better still get the clients to open their own matters for you.
• Report LESS, not more, but make it useful. Ask why certain reported items are being shown to people who can’t actually influence them to change. Is there really a point to this?
• Only actually report critical metrics directly to the people who can influence them. Make other data conveniently and easily available, but make it self serve.
• Workflows and OCR of inbound invoicing removes a lot of load.
• Automate (via workflows where sensible) staff on-boarding and off-boarding, across all systems, not one at a time.
• Assume ANY Spreadsheet is a problem definition, and come up with a good solution for it.

Be careful how much you listen to Consultants

Whilst it sounds counter-intuitive, sometimes accepting what the consultants and implementers tell you without a decent challenge can be a big no-no.

When you think about it, the best way for these teams to reduce their risk and make themselves look good (mainly in their own organisations) is to not rock the boat or challenge the status quo in your processes or indeed their own.

In our opinion both of these need to be challenged, regularly. Make sure that the outcomes of the project, not the so-called success of the project (Timelines, Budgets, lack of drama), define what you are trying to achieve.

Identify all internal and external stakeholders in the project

A lot of people and organisations have a significant interest in the mechanism and outcomes of the upgrade/replacement project. These include but are not limited to:

• Clients and Client Agents
• Partners and Staff
• Government Agencies
• Suppliers and Advisors

There’s potentially other stakeholders in your firm for this project so be careful to nut them all out and try not to leave anyone behind.

Determine stakeholder output requirements (reports and analysis) and consider where that data will come from in a processed data sense.

Crazily the reporting part of many projects is left till last (or sometimes after last). Whilst outputs are indeed the end of the line, they define many things that need to exist in the system, and the data and the inputs, because logically, they can’t otherwise be output.

We would universally begin with outputs in a large project because they literally define the rest of the project.

Design, Scrap, Design, Scrap, Design

Designs of processes and outputs should be lean and aggressive. Don’t bloat designs catering for nuances that might be required by one or two people for 5% use cases. That’s a waste. Better to push back and remove the use cases than bloat your designs.

If a process design needs an explanatory paper, it’s probably too complex. Simplify wherever possible. It’s almost always possible to add nuance later, it’s rarely possible to remove it.

If a design is getting complicated, throw it away and start again. It’s usually much easier (and a LOT smarter) to reconsider the premise of the design and start again, than to constantly build on it and plug holes that should have been previously considered in the premise.

You’re likely going to be living with these new processes for a while, and they will evolve over time. Make them as simple as possible now, so the evolution doesn’t become a house of cards.

Identify key metrics and values that you expect to change, when and by how much.

You probably already have (I hope) key efficiencies and process changes that this project will deliver for you. If you don’t STOP NOW !

If you do, try and monetise or quantify these goals so you have something truly measurable. This might involve doing some baseline measurements of the present solutions before you head off on the journey that is a new ERP software project.

Here’s some examples to get your thinking going:

• Reduce our Account team headcount from three FTE’s per $1M turnover to one FTE per $1M turnover
• Reduce our time cost of each billing event (at wages cost) from $400 to $50
• Improve our Average Time Entry to Cash days from 65 to 25
• Complete month end reporting and finalisation in three business days instead of eight
• Reduce client billing queries from an average of 1 per 100 bills to 1 per 500 bills within 12 months
• Reduce bill reversals from an average of 1 in 50 bills to 1 in 1000 bills
• Remove 6000 duplicate client and contact records, and maintain uniqueness every month with minimal human effort after the fact.
• I could write here for days, you get the picture.

Identify developing and known future pressures on the firm and its processes

The world is far from static.

After many of us bleating on about it for 20 years or so, most firms worked out in the pandemic that they could indeed be largely paperless, but it took a global economic and social catastrophe to motivate the change. That’s pretty poor to be frank.

What other changes are being resisted until the world caves in on you, that you can include in your targets for this project. Think big, radical, and in a measuring framework. If you need help, get help.

Hurry up and wait

In three years time (the half life of a PMS product; and yes the radio-active reference was deliberate), no one will remember a 3 month delay in a go-live, but they’ll sure as eggs remember spending $3M on a project which caused immense stress and delivered what you already had. It won’t be a good outcome for anyone.

Test, Test, Test and Test again. (* A word about testing)

Test your processes and related system functions. Don’t forget stress and performance testing.

No-one EVER tests enough, but here’s a useful tip.

Start testing at the outcome level, not at each point along the process chain. If the outcome is correct, then the processes in between won’t be too far from perfect. If the outcome isn’t correct (and that’s often going to be the case), work backwards from the end of the process, not forwards from the beginning. You’ll save a LOT of time and end up with better test outcomes.

Provide insane levels of support and (good) training

No-one likes feeling alone with a new system or process. Budget to have too many people supporting your staff in the first few days and the first two month end (billing) periods, assuming you stick to month end billing (that’s a whole new paper in itself!).

Get your training right, provide enough of it and make sure people attend (CEO/Managing Partner commitment and communications). The training should be process not software driven. How are our new processes going to work and then how the software supports these processes. Absolutely NOT the other way around.

Training needs to be hands on in small groups with excellent training material and excellent trainers. This is not a part of your budget to skimp on.

Once you’re live offer follow up informal and formal training sessions over the first 6 weeks.

Finally, a word about communication and engagement.

People are afraid, like really afraid, of change. Your project team must ensure that the changes are understood before go live and not all when you get to training either. Communicate often, and in detail with stakeholder groups.

Involve people in process design workshops and don’t always use the same people.

As I often say in such projects, “In the absence of facts, people will make them up”.

It’s your job to make sure they know, understand and are at least reasonably comfortable with the change and disruption that is about to hit them, well in advance.

Finally, good luck management.