Five lessons learned from legal technology projects

Rachel Edmondson

8 minutes ago

5 min read

No two technology projects are exactly alike. Different firms, different systems, different suppliers and, inevitably, different challenges.

But having worked alongside law firms on a wide variety of technology projects, from system selection and implementation to upgrades and helping get struggling projects back on track, we see certain themes coming up time and again.

Some emerge right at the beginning, when firms are deciding what they actually need. Others only become apparent during testing, training or even after go-live.

So, what have previous projects taught us? Here are five lessons we think are worth considering before you embark on a complex technology project.

1. Leadership buy-in and driving change

Good governance and stakeholder engagement need to start at the beginning of a project.

There should be clarity over who owns the project, an appointed Project Manager to manage delivery, and a senior Project Sponsor able to engage other senior stakeholders and help secure the necessary internal resource.

It is also important to be clear about whose interests are being represented throughout the project. A software supplier usually includes one of its Project Managers, but the firm still needs to ensure its own requirements remain fully considered as the project progresses.

Past experience has highlighted the value of including representatives from different roles and departments when gathering requirements and making decisions. In one project, for example, a key lesson was that the project team should have been larger and included fee earner representation.

Having the right people involved is only part of the challenge. They also need sufficient time to contribute. Subject matter experts will inevitably have responsibilities within their existing roles, whilst project team members may be balancing project activity with business-as-usual work.

Where possible, dedicated time or additional resource should be made available for important project activities rather than expecting these simply to fit around existing responsibilities.

2. Give people enough information to make informed decisions

A recurring lesson we’ve learned is asking people to make decisions before they properly understand the new system, their options or how a future process will work.

This can be particularly problematic during requirements and design phases.

Requirements gathering should involve representatives from different roles and departments across the firm, giving people the opportunity to identify what currently works, what can be improved, what is missing and what they need from the new system.

Those requirements can then be reviewed and agreed by stakeholders, including identifying the firm's 'must haves'.

The sequencing of design activity matters too. Lessons from projects we have worked on have highlighted the problems created when information is provided in the wrong order or decisions are requested too early.

Where possible, people need the opportunity to understand a subject area, see how it will work in practice and then make decisions about requirements and configuration.

The same applies to integrations. Understanding integration requirements (and allowing sufficient time to design, build and test these) must happen early in the project, particularly where a firm has multiple integration points.

3. Make testing reflect the way the firm will actually use the system

Whilst testing and user acceptance testing are essential before a new system is rolled out, previous projects have highlighted the importance of making sure that such testing is sufficiently comprehensive.

Testing should cover different roles and personas and use real-life scenarios. Depending on the project, it may also need to consider configuration, customisation, security, integrations and processes across different areas of the business.

The people undertaking testing also need to understand their roles, responsibilities and escalation routes, while issues should be documented centrally and addressed effectively.

Resource is important here too. We have seen first hand the difficulty of completing sufficient testing when project participants are also dealing with business-as-usual commitments.

For significant projects or future system changes, it is essential to have knowledgeable individuals (SMEs) overseeing testing, including regression testing, and to document a clear testing and regression plan.

4. Make training relevant to different roles

Training is another area where lessons from previous projects point to the importance of understanding different users.

Training should be relevant to the roles and personas attending whilst taking people through real-life examples of the activities they will actually be expected to perform on the system.

One project found that training was too heavily focused on fee earners, leaving people in other roles without sufficient understanding of the functionality they needed to use. Other lessons highlighted variations in trainers' knowledge and the impact that changes in consultants can have on knowledge transfer.

The timing and format of training matter too. Required functionality should be available before training takes place and users should ideally have access to the system afterwards so that they can put what they have learned into practice. The impact of hands on training shouldn’t be underestimated. A classroom demo isn't absorbed and isn't in context and this often stunts adoption.

There should also be clear communication beforehand about what people can expect from the session and why it is relevant to them, together with support afterwards to help them use the system effectively.

5. Plan for what happens after go-live

Go-live is an important project milestone, but lessons from projects we’ve undertaken demonstrate the importance of planning the transition into operational support.

Training and handover sessions alone may not be enough. There needs to be clarity around ownership of different areas of the system, which teams are responsible for providing support and where issues should be escalated.

This can be particularly important while internal knowledge is still developing.

Our experience has also highlighted the difficulties that can arise when there is a lengthy gap between implementation support and formal handover to operational support, particularly where there is no obvious escalation route for unresolved issues.

And the work doesn't necessarily stop once the system is operational. Future releases and changes may need to be understood and planned for, including reviewing release information and carrying out appropriate regression testing.

Make the lessons from one project count on the next

The value of capturing lessons learned is in applying them to future projects. Across governance, requirements, design, testing, training and transition, previous experience can help firms anticipate challenges and make better-informed decisions.

At 3Kites, we bring that experience to firms in different ways, from helping plan a project or mentoring an existing team to providing client-side project management or helping a struggling project to get back on track. We work with firms of all sizes, including those with established project management teams who may simply need additional experience of a particular type of implementation.

If you’re looking at your next complex change project, do get in touch with Rachel Edmondson to understand how 3Kites’ project management team can provide your firm with appropriate support.