Your Guide to Seamless Legal Tech Implementation: Part 2 — Get Project Stakeholders on Board

Part two of a three-part “Guide to Seamless Legal Tech Implementation” Parts one and three are below.

Part 1 – Scoping the Project Before Buying
Part 3 – Change Management Before and After Implementation

The importance of stakeholder engagement is vital, both during technology project definition and implementation. So how can you identify key project stakeholders and get the buy-in required?

As you read in part one, collecting and analyzing stakeholder and end users’ requirements is a crucial enabler of success when designing and implementing a new system. It is possible to outline solution requirements without considering stakeholder needs, but to do so presents a real but avoidable risk of project failure.

Some of these stakeholder groups or individuals may be fully on board and require little management regarding expectations. However, there are likely to be key stakeholders who will have other priorities or may be resistant to the change that a new software tool brings.

When software projects fail to deliver expected benefits because of stakeholder/end-user issues, these projects fall into two categories:

  • Those that do not independently verify stakeholder requirements (“one of the users said this, so that’s what we must do”)
  • Those that treat project stakeholders and their requirements as a kind of inconvenient truth (“they exist but we don’t really agree with them/want to listen to them”)
  • Neither of these positions are desirable or helpful. However, it is possible to mitigate them.


Effective solution selection requires understanding the needs of all stakeholders and the ultimate users of the application.

As learned in part one, producing a scope document helps eliminate confusion within the project by managing expectations from the start. With the users’ needs captured, you can define the objectives of the software purchase and identify additional project stakeholders.


After defining the project objectives, identify the relevant stakeholders. Gather their requirements and learn the solution’s impact on their teams. A successful project requires the buy-in from not only the legal department, but of the entire management level. If you miss the input of some project stakeholders can seriously affect the successful implementation of your software. Stakeholder identification can be time-consuming as it may include parties beyond immediately obvious ones. Who are typical stakeholders? There are immediate system users (for e-billing, this would be accounting and legal/legal operations), but there are also legal service providers and law firms, sales, IT, and procurement users.

A structured and consistent approach can help you identify stakeholders and their roles. Tools and techniques include focused interviews, multi-media communications, surveys, role-playing, and follow-up action workshops. This will ensure stakeholder groups are fully engaged and supported.


Once you capture the stakeholder requirements, the next stage is interpreting the results and choosing what to act on. At this stage, achieving balance is vital; keep the stakeholder who shouted the loudest from dominating the requirements. Remember what the legal department is trying to accomplish and select only those items of feedback that will help. Try to prevent the project scope from becoming too broad. Remember that the best solutions are both effective and efficient and that a positive ROI will measure success.

If you have access to an experienced project manager/analyst, they can record and interpret the results of the stakeholder and user sessions and feed the conclusions into the overall project requirements.


Finally, it is essential to let stakeholders know what you have done with their feedback and why. This is vital to engage them in the project.

You cannot always please all project stakeholders, so use data-based justification for the decisions taken when you can. Stakeholders, particularly the primary users, can make the new process sink or swim. When it comes to implementation, you will need their support to encourage their teams and peers to use the new system. While they may not like what they hear, they value the reach out (and will find out in the end anyway).

Finally, you will need to continue using the stakeholders for validation of the project as it progresses, primarily to ensure that the delivered system does not “drift” from the agreed objectives and to check that the original requirements are still valid as they may change time. This is also a benefit of having a scope document. Plenty of applications have gone live to a user population that says, “great, but that’s not what we need now!”


So, what lessons are there for those involved in system selection and implementation?

  • Be clear on what the project is trying to accomplish?
  • Identify the project stakeholders in context; what are their roles and responsibilities?
  • Use relevant capture methods; keep them consistent and unbiased.
  • Incorporate the feedback into the solution requirements. Maintain balance and remind yourself of the project objectives.
  • Keep the stakeholders informed of the consultation outcomes and be prepared to adapt the project if it doesn’t achieve the agreed objectives.

Part 1 – Scoping the Project Before Buying
Part 3 – Change Management Before and After Implementation

Thank you for subscribing!