REQUIREMENTS ARE KEY

Gathering requirements for what you want to buy/build/do is key to getting the right solution. I would argue that this applies to any project, in any sector, not just KM technology selection. It seems so simple and obvious as a premise, but it is frequently something which is overlooked in technology projects. The main cause of this in my experience is when the team starts with a solution in mind before having identified the business problem. Many years ago when I worked in an innovation role in another sector it was very common to receive emails from partners saying ‘why don't we have x solution’, where x just happened to be featured in the latest issue of BA highlife. It is relatively common these days for projects to be ‘supply-led’, especially with new and disruptive technologies, and sometimes the solution is unique and the business case so obvious that you don't need to spend a lot of time on requirements. Most of the time, however, this is not the case. Most of the time, there are multiple options, and the key to selecting the right one will depend on your requirements.

Spending some time on requirements doesn't have to be onerous. In fact, investing that time at the beginning can often save you a lot of time and a little pain later in the project process. There are plenty of methodologies and frameworks that you can use at this stage and you can use whatever will work best for you and your firm. There are two common techniques that I like to use at the beginning of such an endeavour.

The first technique is the ‘business case on a page’. Again, I find this a useful technique for almost any project that you are considering investing firm resources into. Write down on one piece of paper the following – what it is you want to do, why you want to do it, and how you will know when you are finished. The main reason to do this before the firm invests too much energy into a new solution is so that you can share this document with the relevant stakeholders in the firm and, crucially, get some feedback and hopefully some consensus. Getting buy-in from the right people is an essential ingredient in the success of your project – the earlier the better. This really shouldn't take you more than an hour to create and will save many times that in discussions later on, especially if it turns out that your stakeholders are not on-board with that original vision.

The second technique is ‘MoSCoW requirements’ gathering. This stands for Must, Should, Could, and Won't, and is a way to write down requirements in a plain English that can be used as the basis for future project selection and evaluation. This technique is often used in Agile software development projects, as it helps not only to capture requirements but forces users to think about prioritisation of those requirements, though I find it works just as well in the early stages of other types of projects. Note that some uses of MoSCoW have different interpretations for the W – I like to use it as Won't as this gives users a way to declare things as explicitly out of scope, and I think the 3 levels of priority are enough for the in-scope items. It's not unusual for users to start by declaring everything as a ‘Must Have’ requirement when they provide these on their own, though if you organise a brainstorming session with a few stakeholders you will often find that the process of discussion will help shift a few requirements from Must to Should and Should to Could.

With both techniques I would encourage you to consult widely within your firm, especially with likely end-users, including lawyers. Get them to review the one-page business case and contribute to the MoSCoW requirements. It is far better to have lots of input at this stage and then rationalise it, than to not have enough input. This consultation exercise can also help you identify potential project team members or testers for later in the selection and implementation process. A common mistake here is to talk exclusively to ‘usual suspects’ or the self-confessed ‘tech geeks’ in the firm. This can lead to bias towards an already identified solution. Don't ignore these groups – they are an important part of the process – but do look more widely for input if you can.

The final recommendation on requirements – make sure the ultimate decision maker is on-board with the one-pager and/or requirements at this stage. As well as the benefits already discussed, one valuable use of a requirements document is to be able to compare competing solutions using something approaching a fair system. Sometimes the selection process can become emotional – people pick favourites or take sides. When the decision maker has agreed to a set of requirements that are created before any technologies are selected, those requirements can be used to measure the potential solutions, and give you a more or less objective score for each.

EXPLORE EXISITING SOLUTIONS

Engage with your IT function and explore existing solutions the firm already owns. I know that this might seem like an odd suggestion in an article about selecting and implementing new knowledge management technology solutions, but this is a suggestion which is more relevant today than ever before. Many firms have a wide range of solutions available that perhaps have been purchased for a narrow purpose but could have wider applicability, or they could be solutions that come as part of another subscription. A good example is SharePoint and MS teams, which are often available to firms as part of their Microsoft license and can be turned to solve many KM business problems. It's possible that you already have a firmwide intranet built on SharePoint, and the firm is using Teams for some initiatives, so you could already have internal experience and expertise with these solutions. Your IT function will appreciate early involvement in any such project and will also likely thank you for trying to reuse existing solutions rather than adding to their already large list of things to support. If you have an existing solution which can be used ‘as-is’ or with only a limited amount of configuration and it meets an acceptable number of your ‘must-have’ requirements then it's possible that you can get a solution quickly and at limited cost.

A significant part of KM is encouraging the reuse of firm assets, and the KM team reusing an existing solution would set a fine example for others in the firm. Some real-world examples of this type of reuse include a solution for tracking KM and Library enquiries. This was achieved through repurposing the IT helpdesk solution, with a small amount of configuration to work for different teams, instead of buying a new product. Another example is using SharePoint to create a matter tracking solution rather than buying an experience management solution, or using an existing Document Management System to capture and profile knowledge rather than buying or building a separate KM system or database.

However, please be cautious about going too far down the home-grown development route, especially if there is a proven off the shelf product that meets your requirements. The reasons for reusing or repurposing existing solutions are to save time and cost, but too much custom development can easily end up taking a long time and tie up internal development resources, and you still might end up with something which is only 80% meeting your requirements. There is a balance here and every firm, every project, is different.

Also, talk to other functions in the business – there might be solutions they are using which could help, or it might be possible to add a module to an existing solution to meet your requirements. Again, going down this route with an existing solution and established vendor can often be quicker and cheaper than getting a new solution in.

Having this kind of conversation with your IT function at this stage is also a good way to get buy-in for your project. If your IT team have explored the existing alternatives with you and concluded that the firm doesn't have something that meets your requirements, the chances are they'll have an opinion on what the options are in the market and may be able to help you in the next stage of identifying possible vendor solutions. They can also give you a steer in terms of things like Cloud and/or security policies that you need to consider when engaging the market.

COMPARE THE MARKET

Whenever possible, try to research the market for competitors before engaging with the first vendor. Some solutions may be so niche that there are no obvious alternatives or competitors, but often in legal tech there are at least 2 or 3 key players, so it is worth trying to find them first. There are free resources that you can use to find details of legal technology (eg. https://legaltechnology.com) and there are a lot of people who can help. Professional networks are great for finding out what others are doing – and legal technologists in particular are very generous when it comes to sharing what they're using and what they think about it. There are independent consultants who can help, as well as plenty of industry events where you can find out more and talk to peers and vendors. Don't underestimate the value of the network at this stage – ask your friends at other firms, ask the experts and presenters at the events, use the discussion board features of any legal platforms you use.

Read the websites and watch the demo videos. Legal tech vendor websites are often very hard to penetrate and it can be challenging to figure out exactly what the solution offers. Demo videos can be helpful where they show the solution in action. Here, having your requirements will be helpful – you should be able to use your requirements to build a couple of examples of a user journey, and see how the demo compares to them.

You will likely find at least two and possibly more vendors with potential solutions that seem like a good fit. It may be tempting at this stage to invite them in to a give a demo to a room full of lawyers and others, but I would recommend not jumping straight to a demo just yet. I have sat through too many such demonstrations where it has been clear within the first 5 minutes that the solution is not a good fit for the firm/problem in hand – and that's a waste of everyone's time. Too many occurrences of that will lose you buy-in at the firm, and it's not fair to vendors who often put in a lot of effort preparing for these meetings. Rather, I recommend that you again work with your IT function to see if the firm already has an existing relationship with the vendor, and then arrange a call with your relationship/account manager (if you have one), or use the website contact form to set something up.

It is useful to first have these calls with vendors to tell them what it is you're looking for. Often the focus of discussions with vendors is on the product and all the bells and whistles which is great, but it doesn't always hit the mark when it comes to your particular use case. Tell the vendor what the business problem is and your Must Have requirements – this will focus the conversation on to how their technology can solve your business problem, rather than simply talking about how wonderful and clever the tech is. Something to watch out for in this conversation is when the vendor says that the solution ‘could’ meet a requirement rather than ‘can’ meet a requirement. Be sure to follow up any statements like that to figure out whether that could is just an easy configuration option, or whether what they really mean is that the solution could do that after some paid-for development work.

By having these early conversations with the potential vendors, I would recommend that you aim to identify what you think are the best 2 or 3 solutions to move forward with, where approx. 80% of your ‘must-have’ requirements are likely to be met out of the box. You should consider asking those vendors to give you a 1-2-1 demonstration that specifically addresses your requirements, rather than a general show and tell demo. This allows you to provide useful feedback to the vendor so that they can refine their presentation before they go in front of other stakeholders in your firm. Ideally, by the time you have the vendor ‘come-in’ to provide the demo to lawyers and others, they will understand your business problem, will have tailored their presentation/demonstration, and you're as confident as you can be that the solution will meet your needs, so you're not wasting anyone's time.

TRY BEFORE YOU BUY

When you have narrowed down your potential solutions then you are ready to start working with your users and other stakeholders to select a vendor to move forward with. Demonstrations are the first next step and hopefully these will be targeted to your firm based on your requirements and the pre-work you put in with the vendor. Try to include as many stakeholders as you can for the demonstrations and make sure to ask plenty of questions, though do try to keep things focused. As some solutions have many dimensions it is very easy for these sessions to divert off track, so it helps to have your requirements front of mind and try to bring any wayward discussions back on track.

For knowledge management technology in particular I would recommend that you explore in more detail at this stage any artefacts that the solution will create or manage, and be sure to understand how this aligns with your existing KM strategy and other solutions. When introducing a new system, it is possible that you are introducing a new place to store data or other content, and a firm should be wary of creating any new data silos. This is especially important if the new solution will create or manage any matter data or content and, if it does, you should also consider carefully how the solution will integrate with your approach to ethical walls and other security policies. Ideally any new solution that manages matter data or content should integrate seamlessly with any policy-based security. Of course, it is possible that the solution doesn't integrate seamlessly, in which case now is the time to consider how (processes, people, policies) the firm will ensure that the content is managed securely and that records can be managed as part of the matter file.

The next step I would recommend is to try the solution, if at all possible. Occasionally this is not pragmatic due to the cost and time required to put a trial solution together, but most of the time it is possible and sensible to run a trial or Proof of Concept (PoC) of the proposed solution. The main purpose of a Proof of Concept is just what it says – you are trying to prove that the solution does what you expect it should do. It's not about a perfect implementation of the solution and many PoCs will be rough around the edges, but it is an exceptionally useful way to find any showstopper issues before you commit to move forward to a full implementation, with all the investment of time and cost which that involves. PoCs should be time limited and have clear, measurable objectives, based on your requirements. The ideal outcome from a PoC is a clear decision to move forward with an implementation project, or less ideal would be a decision not to move forward. An outcome to be cautious of is an implementation by stealth, where the PoC just rolls on and on, becoming the implementation version of the solution. This is usually undesirable as the PoC will have been a slimmed down version of the real thing, probably using dummy data or minimal policies and application of proper security, and not the kind of start you want for your new solution.

Sometime a firm will have 2 or more solutions that they want to trial, and the next question is whether to run the trials in serial or parallel. The first factor to consider is time – if time is short then it would be sensible to run trials in parallel. I would recommend that the same group of participants in the trial use all the solutions on trial, and I would also strongly advise that solutions are tested with cases as near to real as possible. Obviously client and matter confidentiality must be considered and any policies adhered to, even with a PoC, but if it's possible to test things ‘in anger’ then the chances are that this will give you the best information about the solutions suitability. If time is not a factor, then running trials in serial is worth considering. The flipside of running trials in parallel with the same group is that this will likely impact on their time and could result in less than ideal levels of participation in the trials.

KNOW WHERE YOU'RE GOING

When you get to the point of implementing your chosen solution, this is probably where most legal tech projects come unstuck. Often this is because project teams have rushed and skipped the earlier steps, and so arrive at the implementation stage with few to no real requirements, little buy-in from stakeholders, and usually very ambitious timelines in mind to deliver. It is understandable how this happens – energy levels can be very high at the beginning of a new legal tech journey and there can be a desire to push forward quickly with a bias for action over planning, especially when the project is supply-led based on a single product. However, it is never too late to take a breath and check that you have agreement on what it is you are doing. Even at this stage you can apply the requirements techniques described earlier to sense check where things are and get some general agreement from the project participants on requirements. If nothing else, the ‘how do we know when we've finished’ is an essential piece of data to have agreed before implementation starts. Many of the pitfalls of implementation can be avoided simply by getting a project's key players to agree at the start what the project objectives are. These objectives should drive the plan, which will help to determine the resources required and the timeline to implement. I have lost count of the number of projects I have seen that try to specify too early all the constraints of a project – the scope, the resources and the timeline - without appreciating the relationships between them. In most law firm technology project situations the resources available are more or less fixed, so this usually results in the implementation running late because the timeline was unrealistic, or the implementation scope being cut because a project has run out of time. Not infrequently, projects are late, and the scope is cut, leaving everyone unhappy. Even with the best requirements gathering and planning it is still the case that things go wrong, but it is much less likely.

As well as the ‘how do we know when we've finished’ part of the business case, it is also helpful at this stage to think about what happens after the project ends. Many new technology-based solutions require ongoing administration and management. If the firm is replacing an old system or displacing some work then it might be obvious how this is to be managed, and who will be doing it. When the firm is adding something new the question of how it will be managed, or how any service based on the solution will be delivered, can be overlooked. By addressing this early on, the firm can identify the people who will be involved in the service delivery and make sure they are involved as appropriate in the implementation. This could be a brand-new role which needs to be recruited for, and recruitment can take a long time, so this should not be left until you're just about ready to roll out the final version to users. Most knowledge and information management teams are not particularly large and well-staffed and taking on responsibility for managing a new solution or service without any corresponding increase in resource or reduction in other responsibilities is asking for trouble.

There are lots of project management tools and techniques that cover the rest of the implementation phase (as well as all the other phases we've covered) and if your firm has a preferred methodology or framework then use it as best you can for your implementation. If not, then it is worth exploring some formal methodologies and adopting whatever works for your firm. The final element of technology implementation I want to highlight, regardless of the methodology you select, is testing. With the best will in the world, testing always seems to take longer than anticipated and is a major cause of project delays. There are a range of reasons for this, from not having clear requirements to test against resulting in inadequate test scripts and not having the right stakeholders involved in testing, through to simply not allowing enough time in the plan to deal with the changes that arise from user testing. Having good requirements to test against, and having the right stakeholders lined up to test from the beginning will go a long way to helping minimise the risk of delays during testing. Setting short testing deadlines helps – in my experience there are broadly 3 types of tester; those who test immediately, those who test on the last day of the testing window, and those who do not test at all. Short testing windows will very likely yield the same testing results as longer ones. And please, leave some time in the project plan between the end of testing and the start of roll-out. If the testing identifies issues, especially serious or showstopper issues, then you need to fix them and retest.