Part one of a three-part “Guide to Seamless Legal Tech Implementation.” Parts two and three are below.
Part One focuses on the project scope and gathering the key requirements prior to purchasing legal technology, and addresses 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?
Many legal technology projects fail because the tool doesn’t meet the fundamental needs of the legal department. We recommend first listing the requirements, then sourcing the right tool/s to meet these needs in a “scope document.” By developing this scope document, you will embark on the right path for defining a successful project scope and initial definition of user needs. This doesn’t need to be complex and comprehensive. A scope document captures your team and other stakeholders’ expectations of what to achieve, the steps required to meet these expectations, and at what cost and resource effort internally and externally.
A scope document:
- 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 ensure 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 compiling it. If you do not scope the project first, you risk multiple iterations of the RFP once vendors are already involved. This wastes time and causes internal and external confusion about the essential requirements.
WHAT SHOULD A SCOPE DOCUMENT CONTAIN?
The document’s level of detail will vary based on the complexity of the needs to be addressed. Here’s what to document 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) get documented to avoid miscommunication of expectations and define the legal technology project’s goals and objectives. This section doesn’t have to be lengthy but needs to include enough detail to clearly outline the requirements and objectives.
2. THE WORK PLAN
This portion of the document will develop once a solution is selected, at which point vital milestones and potential issues will be easier to document. At the pre-solution selection stage, your scope document should include estimated time frames so internal stakeholders and vendors know the expectations. These time-based expectations have go-live dates and how fast you want to onboard various departments around the business.
3. RESOURCE NEEDS
Quantify the internal resources that your legal technology project needs. Here, it is important to identify the key project stakeholders and stakeholder groups. There are various tools and techniques to manage these stakeholders through the process; explore these 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. Also, consider the cost of project managers, who use many different cost models (such as billing time and material), give a fixed project cost, and work on a monthly retainer fee. There may also be a cost for internal IT resources; SaaS-based solutions are significantly cheaper than resource-intensive systems hosted by yourself. If opting to build a solution, calculate the costs of this.
Share your scope document with the users and stakeholders in the legal department and beyond. One of the main scope document benefits is a clear interpretation of requirements, so double-check and approve the document. Use this document to research potential tools, draft your RFP, and engage 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 aligns with the legal department’s priorities to maximize user adoption and business benefits.