PMS Practice Primer – Part 2

We then move into the Discovery & Contracting Stage. It is here, when the more informal ‘having a look around’ morphs into a committed exercise with a structured process, that many firms pause: they can quickly feel overwhelmed by the scale of the task, questioning if they have the time and skills to undertake the project successfully.

Their next step is either to turn to external consultants for help or, sometimes, some firms are so overwhelmed (or over-awed) that they simply rely on what was said during the demonstrations rather than having a structured checklist/requirements document to assess their decisions.

Some go as far as looking to the consultant to take full responsibility for the project end-to-end.
The contracting element alone can take several weeks – after all no law firm will sign up to any old contract.

What tends to happen is the contract is given to an internal lawyer who may not have experience in software application contracts and who also has a heavy fee-earning workload – and internal contracts are simply not given priority. Therefore, it is often best to instruct an external IT contracts lawyer to look after this task.
Again, this stage can take between 6 to 18 months

Once contracts are signed, depending on complexity and supplier resources the implementation stage can take between 12–18 months. 
Since the financial crisis of 2008, law firms have become more aware of overheads and ‘the middle’/fee-burning teams have reduced to business-as-usual levels – so thought must be given to how a project will be resourced.

During this time firms often expect the teams implementing the solution (primarily IT, Finance and Marketing) to carry on with their existing day-to-day role as well as the project work. 

This not only introduces pressure and stress to the staff working on the project it can lead to major project issues as work is done in a ‘reactive way’ at the last minute or is slotted in around other priorities.  

For example, during this time there will be multiple data conversions (a minimum of two) and each data testing cycle will take between 5 to 10 days of testing. 

In total the whole project cycle can range from between 18 – 54 months. 
The model is flawed in several ways, not least the disproportionate time taken to make a critical business decision. 
The model also introduces project fatigue points at the end of each phase. 

Figure 6: Traditional Project Timeline 

It is not unknown for firms to be so exhausted by the selection process that they have little energy left for the implementation and can’t actually remember what they were striving to achieve. 

In a project where the firm is reliant on external consultants to lead the project, we usually expect to see this pattern of internal involvement.

Figure 7: Project Resourcing Pattern

Initially there may be a few false starts as the firm moves towards acceptance of the need for the project. Then there will be an event that triggers the ‘enough is enough’ conversation and the project will start in earnest.

With a traditional style engagement, a consultant will tend to be quickly fully allocated to the project, reducing internal control and ownership.

The reliance on internal resources will peak at major project stages.

Typically, project resources are reduced as closely to go-live as possible. This underlines the project fatigue issue and is an indication of the short-term view of a PMS project. This could also explain why most PMS projects result in disappointment.

If we consider the cost vs value equation in this traditional model it is not unusual for the firm to incur significant consultancy costs during the selection process.

We have already discussed the state of the market and highlighted the limited options open. So you have to question what value a bespoke 300-page tender request adds to the process.

Figure 8: Cost vs Value 

Firms following this model are unlikely to receive value for money from their external advisors, who after all cannot predict or protect against supplier merger or strategy direction.

The reality is that there is probably little we can do with the initial ‘contemplation’ stage as the firm needs to determine its needs and start ‘feeling its way’ around the whole undertaking. 

For those firms currently at this stage we would encourage you to start making a detailed analysis of the challenges with your existing system; but more critically to start to identify what is really important to the business. Even if you are being ‘forced’ to change, look to turn that negative to a positive. We’ve seen a significant uptick in requests from firms for presentations to the partnership on how best to move such a daunting project forward.

Given the lack of choice in the market 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 your decision is likely to be largely 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-breed specialist solutions) 

Once the strategy has been settled upon the selection can very quickly focus on a couple of suppliers; that’s an immediate gain as you’re looking more at a due diligence exercise rather than a long-winded comparisons of functions.  

By tackling the project this way rather than the traditional approach of documenting all existing processes to the nth degree, you stay far more aware of what is of critical importance and what is going to add value to the business. Plus, you lessen the risk of buying a new system which works much the same way as the old system and consultants getting ‘money for old rope’ as they drag out the selection process!  

In our approach we have a templated Request to Tender (RTT) which covers the majority of functionality you would require of a PMS solution. This encourages the focus on the firm’s unique aims rather than detailing only standard out-of-the-box functions.  

The contractual project documents should then be based around these critical aspects rather than functionality – for example, the process for billing or workflow for time entry and submission.  

Once you have identified your preferred supplier then the project team and the supplier can come together 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 zero in on the best way to get efficiencies from the new system; rather than attempting to shoehorn the new software in just so it can work the same way as the existing platform. The latter is a frequent consequence of where current processes have been defined in the RTT and the team feels it has to recreate them, as opposed to being encouraged to optimise and reinvent.  

In our proposed model we are also recommending that the go-live period is extended, effectively moving the investment from the selection phase into the go-live phase. It is easier for fee-earners and support staff to adopt incremental changes, rather than wholesale change in one go.  
This is to ensure that the product is properly embedded in the organisation and that a long-term view is maintained 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 that incorporates: 

• Go-live to provide business-as-usual/must-have functions 
• 3 months + for the introduction of enhancements
• 6 months + for the maturing of the product  

In other words, go-live should not just be about the go-live day but planned and treated as a systematic project to achieve value from the investment.  

Very often firms underestimate the amount of training and support that end-users will need to be able to take full advantage of the new solution and hence the software is never used as envisaged – immediately compromising that quest for value.  

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 understandably challenging – as is trying to teach a huge system in a condensed timeframe. 

There should be an expectation that training can be delivered in a phased way with users initially getting trained only on what they need for them to be able to effectively operate on day one. Ideally the concept of regular IT training to improve system efficiencies, expand knowledge and provide general refreshers should be embedded into a firm’s learning and development strategy. 

In this model the internal staff requirements look similar to the traditional model.

Internal resources

However, rather than outsourcing the decision-making as before, the firm now 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 day jobs. The reality is that this is unrealistic as most people are gainfully employed, especially after the restructuring that most firms have undertaken. This can cause delivery timescales to slip, especially during the testing phases when it is essential that any issues are identified and passed back to the vendor as soon as possible.

In this model we will scope out 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 these key internal staff that a firm will truly get ownership and control of its PMS project.

External advisors

External consultants can add great value as a subject matter expert or ‘critical friend’ during the project. Their experience and exposure to other environments will provide a breadth and depth of domain expertise and insight 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 that fits in with their sales cycle but doesn’t fit in with the firm. It is equally easy for a firm to be unrealistic about the internal resources needed to deliver success.

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 continuity throughout the project.

It is highly likely that the PMS will have integration with other software applications and a dependence on a robust infrastructure platform. An external consultant will be able to identify these dependencies at an early stage and provide advice on the best way to tackle these areas.

Vendor experience

The final element is to extract value from the selected vendor. After all it is they who know their product the best and a good vendor can dramatically cut through the design process. The trick is to use this resource in a consultative selection and 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.