This three-part series of blogs form a guide to implementing a successful legal technology project. This is part one. Click below to read part two and three:
While not a comprehensive guide, it highlights the key areas. With consideration and attention to these areas, your legal technology project will run much smoother.
In part one, we will answer the following questions:
- Why use a scope document?
- What should a scope document contain?
- What steps should follow the creation of a scope document?
Why use a scope document?
A lot of legal technology projects fail because the tool doesn’t meet the fundamental needs of the legal department. We recommend first documenting the requirements, then sourcing the right tool/s to meet these needs. At this stage we need to quote the poet Kipling’s: “Six honest serving men – they taught me all I knew; their names are What and Why and When; and How and Where and Who”. By keeping these questions in mind you will be on the right path for defining a successful project scope and initial definition of user needs. It doesn’t need to be complex and comprehensive. A scope document captures your team and other stakeholders’ expectations of what is to be achieved, the steps required to meet these expectations and at what cost and resource effort – both internally and externally.
- Forces you to think through the elements of the legal technology project and software purchase.
- Gives you a document to share with your team and other end users to make sure you have interpreted their needs correctly.
- Verifies the legal technology project’s why, who, what, when, where, and how.
- Provides the basis for the request for proposal (RFP) you will send to vendors and saves time when it comes to compiling it. If you do not scope their project first, you risk multiple iterations of the RFP once vendors are already involved. This wastes time and causes confusion both internally and externally of what the essential requirements are.
What should a scope document contain?
The document’s level of detail will vary based on the complexity of the needs to be addressed. The following is a brief look at what should be documented when scoping a potential technology purchase.
1. The problem or project need
Describe the problem or project request. By doing this, the issues as described by the legal department are documented to avoid miscommunication of expectations and defines the legal technology project’s goals and objectives. This section doesn’t have to be lengthy but needs to include enough detail to ensure the requirements and objectives are clearly outlined.
2. The work plan
This portion of the document will develop once a solution has been selected, at which point key milestones and potential issues will be easier to document. At the pre-solution selection stage, your scope document should include estimate time frames so internal stakeholders and vendors are aware of the expectations. These time-based expectations include go-live dates and how fast you want to on-board various departments around the business.
3. Resource needs
Quantify the internal resources that your legal technology project will need. It is important at this point to identify the key project stakeholders and stakeholder groups. There are a variety of tools and techniques to manage these stakeholders through the process and these are explained in the next blog. Many projects are joint ventures with resources needed from the legal department, other internal teams, software providers, law firms, and consultants. Speak to teams elsewhere in the business who have been through similar projects and learn from their experiences.
There are both internal and external costs. Set a budget for the software itself but also consider the cost of project managers, who use many different cost models, such as billing time and material, giving a fixed project cost, and working on a monthly retainer fee. There may also be a cost for internal IT resource; SaaS based solutions are significantly cheaper in this regard than resource intensive systems hosted by yourself. If opting to build a solution, calculate the costs of this.
The Next Steps
Share your scope document with the users and stakeholders in the legal department and beyond. One of the main benefits is the clarification that requirements have been interpreted correctly, so it’s important the document is checked and approved. Use this document to research potential tools, draft your RFP and begin engaging vendors.
Producing a scope document helps eliminate confusion within the project and manages expectations to avoid dissatisfaction and user adoption issues when a solution is ultimately selected. It saves time when you start to engage software providers as your requirements are clear. It ensures the solution you buy or build actually aligns with the priorities of the legal department to maximise user adoption and business benefits.
Part 2 in this series focuses on identifying and ensuring that the legal technology project stakeholders are on board.
– Blog by Bryan King