This three-part series of blogs form a guide to implementing a successful legal technology project. This is part two. Click below to read part one and three:

Part 1 – Scoping the project before buying or building the technology
Part 3 – Change management during and after implementation

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.

The importance of stakeholder engagement is vital, both during technology project definition and the implementation. So how can you identify key project stakeholders and get the buy-in required? As you read in part one, the collection and analysis of stakeholder and end users’ requirements is a key enabler of success when designing and implementing a new system. It is of course (and unfortunately, frequently) possible to outline solution requirements without taking into account 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, giving it full support, and will require very little management in terms of 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 nor helpful and both can be mitigated.

What are you trying to achieve?

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

As learnt in part one, producing a scope document helps eliminate confusion within the project as expectations are managed from the start. With the users’ needs captured, the objectives of the software purchase are defined and additional project stakeholders can be identified.

Identifying the project stakeholders

After the project objectives have been defined, identify the relevant stakeholders. Gather their requirements along with the impact the solution will have on their teams. A successful project needs buy-in from beyond the legal department, and from the top-down. If project stakeholders have been ignored, it can seriously affect the successful implementation of your software. Stakeholder identification can be a time-consuming task as they may include parties beyond the immediately obvious ones. Who are typical stakeholders? The immediate system users (for eBilling, this would be accounting and legal/legal operations) but also legal service providers and law firms, sales, IT and procurement are potential other parties.

Using 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.

Using the information

Once you have captured the stakeholder requirements the next stage is to interpret the results and choose what to act on.  At this stage, achieving balance is vital; do not let the stakeholder who shouted the loudest dominate 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 becoming too broad. Remember too that the best solutions are both effective and efficient and that a positive ROI will be a measure of success.

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

Ongoing Communications

Finally, there is the important job of letting stakeholders know what you have done with their feedback and why.  This is key to engaging them in the project.

You cannot please all project stakeholders all of the time, so use data-based justification for the decisions taken when you can.  Stakeholders and particularly the primary users have the power to 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 will value you reaching out to them. Face it, they’ll find out in the end anyway!

Finally you will need to continue using the stakeholders to validate 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 over 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!”

Things to consider for effective stakeholder engagement

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

• Be clear on what it is 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, 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.
• Continue to revalidate the project goals against any changes in stakeholder requirements.

The third and final post in this series deals with change management. Get the ball rolling and request a demo of eBilling.Space, just make sure you have your stakeholders’ requirements first!

Bryan King