Time can make a difference to so much that we do, we can be a slave to it or work with it but we can’t hold it back. Good project managers understand this and plan carefully to ensure that their projects hit the deployment date at the desired time (more often than not)… but what is the desired time?

When we work with clients on a PMS (practice management system) evaluation and replacement project, we may be as little as 15 months away from a deployment or as much as three years and more – this sliding scale equating to the time it takes to select, prepare for and implement a new system. The difference in scale usually reflects the size and complexity of a firm and the systems it is moving from and to, although it can also reflect the additional effort of replacing case management flows and document storage where transitioning away from a full PMS which includes CMS and DMS (case and document management system, respectively) components. 

However, understanding how long it will take to get there doesn’t mean that’s when the client wants to arrive, which is why this is one of the first questions we discuss during the project’s kick-off meeting.

A good starting point is to consider any times in the year to avoid going live – for many, the obvious one is year-end (although some will choose this as a neat way of separating the old system and its transactions from the new one). Other dates which are often avoided are summer holidays and any time around Christmas which, with so many people out, can hamper training.

A half-year target (i.e. bisecting the financial year between year-ends) is often selected as a compromise, especially for those where 1 May is the start of the financial year, as this pushes the deployment date to the end of October. The advantage of October-end (or, more broadly, the autumn) as a deployment date is to allow for year-end processing to be completed in the legacy system while allowing around six months for getting used to a new PMS before undertaking the first year-end using a now slightly more familiar system. The other benefit of aiming at the autumn is that it allows time for a degree of slippage without the likelihood that the project will bump into Christmas or affect year-end.

Some projects will aim at February as a mid-point between Christmas and a 30 April year-end but, in my view, this date is hemmed in by the limited availability of staff for testing and such like over Christmas. It also brings a real possibility of running into year-end if the date slips even by just a few weeks. Either way, once you have settled on a time in the year to deploy, the next step is to agree which year October-end might be your best option – there might not be enough time to complete the project by, say, October-end of next year, in which case you may need to aim for the year after.

The one timescale that I haven’t mentioned yet is the imposed timing of, for example, a licence or subscription renewal looming on the horizon, which may commit the business to another one or maybe three years of costs which it is unlikely to ever use in full and therefore doesn’t want to pay for. Similarly, it may be that support is ending for a product (or the environment that it is operating within) and this is forcing the pace. These are the least favourable timeframes to work within but can be avoided with a suitable degree of planning as long as this happens sufficiently far in advance – if you are unaware of any such fast-approaching dates on your horizon, it would be better to ask about them now.

Where imposed dates are unavoidable, there are still options for reducing the impact of these. The easiest one is to shrink the scope of the project’s deliverables on day one and push any (ideally lower priority) items into a phase 2 project which follows fast on the heels of phase 1 being successfully implemented. As with my introduction above, a good project manager can make the difference here between a scope-creep project that runs out of control or a phase 2 that never happens, as opposed to a tightly controlled plan that delivers what it needs to when it needs to, while managing the firm’s expectations. Equity partners will want to see tangible benefits for a large investment but will be more understanding of a delayed delivery for some of these benefits if told in good time.

Another option for dealing with imposed dates may be asking the supplier for shorter renewal terms, understanding that some may be responsive to this while others will probably be less so… but it is always worth asking. It may also be that while client terms or insurance cover requires support to be fully maintained for all key systems including the PMS and its server environment, a grown-up conversation may allow an overrun where it is only for a month or two – again, this is always worth looking into.

Amid all the internal planning, it is imperative that you check availability for your proposed date with the supplier and ask for this to be locked in to prevent it being bumped by another customer’s needs. Conversely, delays as you approach deployment might mean that it is your firm looking for a date to be pushed out by a month or two at relatively short notice, at which point the supplier’s calendar might already be stacked with other deployments. The earlier you can make any decision for deferring, the more chance you will have of agreeing a suitable alternative with the supplier.

And so, my article is just about out of… time. The reality for many PMS projects we see is that dates are littered across the year, simply fitting in with other plans and constraints rather than agreeing the optimum timeframe with all parties well in advance. We would strongly advocate for planning well in advance and, while I think that autumn is a great target for a deployment where it aligns with your financial half year, I can also see the benefits of going with a year-end deployment which, if this is at the end of April, would allow sufficient time and contingency between Christmas and summer holidays. However, the key point is to discuss this timing with all key parties (especially your finance director, the project manager and the supplier) ahead of any hard and fast decisions being required and with all the relevant facts to hand about end dates.

Paul Longhurst is a director of 3Kites. This is the 42nd article in the series Navigating Legaltech. 

--------------------

About 3Kites and Kemp IT Law  
3Kites is an independent consultancy, which is to say that we have no ties or arrangements with any suppliers so that we can provide our clients with unfettered advice. We have been operating since 2006 and our consultants include former law firm partners (one a managing partner), a GC, two law firm IT directors and an owner of a practice management company. This blend of skills and experience puts us in a unique position when providing advice on IT strategy, fractional IT management, knowledge management, product selections, process review (including the legal process) and more besides. 3Kites often works closely with Kemp IT Law (KITL), a boutique law firm offering its clients advice on IT services and related areas such as GDPR. Where relevant (eg when discussing cloud computing in a future article) this column may include content from the team at KITL to provide readers with a broader perspective including any regulatory considerations.