This is the second in a series of three articles which are based on our recent Demystifying PMS Implementation’s seminar.
In this article we will suggest a different approach for PMS projects before moving on to how to extract best value from consultants and suppliers.
The final article we will cover considerations when building the project team and preparing the firm for change process.
In Part 1 of this series I may have sounded quite negative about PMS projects and it is fair to say I am very sceptical of the traditional approach. This is largely driven through experience where I have undertaken two engagements in the last few years to turn around failing PMS implementation projects.
On both occasions the firms had relied on the model we have just discussed and had suffered consequences because of it.
Given the 12 – 15-year PMS system lifecycle and the complexity of the project it is not surprising that the internal teams may lack the experience or confidence the project. It’s also well-known secret that there is a high chance that a PMS project will result in a personnel changes in the IT or Finance leadership.
However, rather than relying on consultants to take over the project they should be used strategically / tactically to assist the process.
A Different Approach
Rather than the traditional model of
I would suggest the PMS project should look as below.
I’m afraid there is probably little we can do with the initial “contemplation” stage as the firm needs to determine the needs.
For those firms currently at this stage I would urge you to start undertaking analysis of the existing system and identifying what really is important to the business.
Undertake a high level SWOT analysis and in particular consider why the existing system was not used to its full potential. This will focus the minds as to what is of value and the internal challenges in the system change.
It may be of benefit to bring in an external “critical friend” to assist in reducing the contemplation phase and bringing forward the existing system analysis.
Given the lack of choice in the market (see Part 1) and lack of functional differences the selection piece becomes much simpler. The focus should be on strategic direction of the firm and not on which product can perform your existing business processes.
There are three strategy choices and the resulting decisions could well be driven by your wider application architecture and the level of appetite for change: –
- A Pure PMS with other Best of Breed tools to enhance the end-user experience
- A new approach which will fundamentally change how the business operates
- A Single Supplier solution (accepting the solution will not have all the features of best of bread specialist solutions)
Once the strategy has been settled upon the selection can very quickly focused on a couple of suppliers and therefore turns more into a due diligence exercise rather than a long-winded comparisons of functions.
By approaching the project this way rather than the traditional approach of documenting all existing processes to the nth degree the focus during selection remains on what is of critical importance and what is going to add value to the business.
The approach also removes the aspect of consultants getting “money for old rope” during a prolonged selection process.
The contractual project documents should then be based around these critical aspects rather than functionality – for example process for billing or contents of a time recording window dropdown.
Once you have your identified the preferred supplier then the project team working with the supplier can begin to identify the best way to configure the software and to identify any processes which need to be changed.
By undertaking the analysis and configuration at this phase we are able to focus on the best way to get efficiencies from the new system rather than attempting to make the new software work in the same way as the existing platform which is often the case if the supplier has to deliver processes defined in the RTT.
In our proposed model we are also recommending that go-live period is extended, effectively moving the investment from the selection phase into the go-live phase.
This is to ensure that the product is properly embedded in the organisation and there is long term view kept to ensure ROI. It is during this phase that all knowledge is transferred from external to internal resources.
It is good practice to set out a rollout strategy which incorporates
- “go-live” which provides business as usual / must have functions
- 3 months or so begins to introduce enhancements
- 6 months or so should start to see the product maturing.
In other words, go-live should not just be focused on the go-live day it should be a planned and systematic project to achieve value from the investment the firm is making.
Very often firms under estimate the amount of training and support that end-users will need to be able to make full advantage of the new solution and hence the software is never used as envisaged.
This is a major problem as Fee Earners are under pressure to deliver chargeable hour targets and getting buy in from Partners to release staff for IT training is often a challenge, as it trying to teach a huge system in a condensed timeframe.
There should be an expectation that training also needs to be delivered in a phased way with users been initially only been trained on what they need to do to operate on day one. Ideally the concept of regular IT training to improve system efficiencies should be embedded during the
Potential Staffing Model
In this model the internal staff requirements look similar to the Traditional model.
However, rather than outsourcing the decision making the firm retains control and ownership.
Many firms start a PMS project on the premise that internal staff can undertake a project as well as doing their Business as usual jobs. The reality is that this is unrealistic as most people are gainfully employed, especially after the restructuring that most firms have undertaken.
In this model we will identify the critical project team and identify areas of their roles which can be moved to other internal staff or to temporary staff for the duration of the project.
It is only by freeing up those key internal staff that the firm will truly get the ownership and control of the project.
External consultants can add great value as a subject matter expert or “critical friend” during the project. Their experience of other projects from other environments will give a view which is unattainable internally.
One example of this is during the planning of the project. It is easy for suppliers to “bounce” firms into a plan which fits in with their sales cycle but may not deliver for the firm. It is equally easy for a firm to be unrealistic about the internal resources needed to achieve the project.
An experienced external advisor will be able to assist in determining realistic plans and resourcing requirements as well as adding a layer of assurance and continuality throughout the project.
The final element is to extract value from the selected vendor. After all it is they who know their product best and a good vendor can dramatically cut through the design process. The trick is to use this resource in a consultative selection & implementation phase.
Ensure that the vendor proves exactly how the software will work during the selection process and is contractually committed to deliver a consultative approach.