29 April 2017

Design for Success: Your Tech Project Needs a Stakeholder Engagement Plan

It’s something we have all experienced: no matter what organization you work for, no matter what your role or background, we’ve all seen a new technology project fall flat.

The story will sound familiar: weeks of careful planning goes into the development of a detailed plan and specifications. The application development team nails every single requirement. The solution rolls out on-time and on budget. But, after just two weeks and in spite of a warm reception, people stop using the application.

The reason for this is an underlying flaw during development: lack of involvement from key people—stakeholders and end users—when defining the process that the technology solution is meant to enable.

Involving the right people in the design of the solution and engaging them during implementation produces a better solution primed not only for a successful launch, but for continued use.

Engaging the right people ensures that the solution is, first and foremost, a good fit to address the problem for which it was designed, but also ensures that the solution meets the needs of the end users. As an added benefit, these engaged stakeholders and end users will be invested in the solution they helped to create. In this way, the development process itself becomes a part of the change management process and end users involved in the design become champions for the finished solution.

Will (all) the end-users please stand up?

When gathering people to assist with the design and implementation of a project, be sure to identify any user who will interact with the solution itself as well as anybody else whose work will be affected by the business process involved.

This could potentially be a very broad group of people with a lot of individual users offering potentially redundant perspectives. The goal is not to ensure that every user who will one day be use or be affected by the solution actually participates in designing the solution. Rather, the goal is to identify the roles of these stakeholders and ensure that the perspectives of each role is adequately represented.

For example: if engaged by the manager of pizzeria to improve the experience of customers ordering a pizza, I would naturally listen to the manager’s concerns. I’d talk to some of the restaurant’s customers to hear their perspectives. Invariably, we would speak with the employees who interact directly with customers, who manage the interactions in play: those responsible for taking orders. However, the cook who makes the pizza would provide an additional perspective that may be overlooked.

A solution improving communication between the customer and the order-taker, but neglecting communication between the order-taker and the cook, is likely to produce information in a format that is unusable for the cook. This solution would ultimately fail to deliver improvements over the long-term.

Legal is a function that intersects, at one point or another, with most of the other units within a business.

It's important to remember that legal technology projects will probably affect, directly or indirectly, diverse groups of stakeholders. It's identifying all these relationships that helps the law departments maintain a user-centric stance—and ensure that legal-driven technology projects lead to measurable results for the company.  

People provide context, and context brings complex processes to life

In our work to design and build solutions for use in legal environments, the SLC team has had access to a secret weapon: the partners with whom we work side by side, who bring deep knowledge of the legal concepts and risks underlying a particular process. Their insights are critical to design efficient processes and effective technology solutions. They provide the perfect subject-matter expertise.

However, when we also involve associates, paralegals, and administrative staff, we discover an added layer of detail: often, these users are those who live and breathe the practical implications, the keepers of all the hidden tasks by which legal insights are translated into client results. The partners know that a particular filing must be completed 30 days prior to closing on a transaction, but they often don’t realize the full extent of collaboration and back-and-forth steps between the paralegals and administrative staff to prepare these documents.

High-level stakeholders involved in any project have a high-level understanding of the requirements and the problems being solved for: the business objectives of and success criteria for a solution. However, the front-line teams tackling these issues on a daily basis provide important and practical context. These insights are often the missing ingredient and the difference between a solution that meets requirements but sits on the shelf and a solution that solves the every-day needs of its users.

Elevating solutions from demo-ready to field-ready requires the integration of multiple stakeholder perspectives. One great tool to build those perspectives are use cases, or simple stories for how a user might interact with the system. See here for a great tutorial on development of use cases.  

Facilitation key to successful participation from all involved

Harnessing feedback collected from different stakeholders can itself be a major challenge. Here are a few tips to promote more open dialogue and:

  • Bring a diverse group of users together and allow them to contemporaneously provide feedback and build on each other’s suggestions. Ask everyone to discuss their role and elaborate on their goals for the solution.
  • Designate a strong, unbiased facilitator—someone who will not be an end user—responsible for encouraging active participation. This person must empower everyone to contribute and NOT allow any single person to dominate the discussion.
  • Pay careful attention to the involvement level. Look for verbal and non-verbal clues—such as slouching, eye-rolling or short, unproductive answers. Ask direct, probing questions to keep these people engaged.

Active stakeholder participation is a core tenant of Agile. For a further exploration of different strategies for gaining access to and encouraging active participation among key stakeholders, click here.

Involvement does not end at design and scoping

On many projects, a wide variety of stakeholders and business users will be engaged when a project begins. The project team will use their feedback to produce requirements, but forget to consult them throughout the remainder of the project.

This is a mistake.

Continued involvement throughout implementation is also critical to ensure the long-term success of the solution. The people who participate in designing the solution—and others like them—must continue to be involved in the development of the solution. As the designed solution comes to life, progress should be shared with the key stakeholders for review and comment. Ultimately, these stakeholders will be our first testers and, eventually, should be involved in the sign off on the solution produced.

A recent article in Harvard Business Review highlighted for me the importance of iterative design and development to facilitating smooth organizational change. The authors of the article encourages designers to re-engage users throughout the process, first with low-resolution prototypes and then with a product that improves based on the user’s feedback: “Iterative rapid-cycle prototyping didn’t just improve the artifact. It turned out to be a highly effective way to obtain the funding and organizational commitment to bring the new artifact to market.”

Ultimately, the stakeholders that we identify early in our design process should become our first testers and, eventually, should be involved in the sign off on the solution produced. These stakeholders perhaps become most important during launch.  

Feeling a sense of ownership over the solution they helped to design, they will be the most effective component of your internal marketing campaign. These people will become champions, talking up the solution with their co-workers and helping to answer questions when they arise.

For your next legal technology project, look for the hidden users in your ecosystem.  For many law departments, these key stakeholderes may be found in adjacent business functions like finance, HR, or compliance. Sometimes they are embedded in operational roles within business units. Also consider the department's partners outside the organization, across your supply chain: the outside service providers that serve as an extension of your department.  

How will your technology project affect these key partners? The only way to find out is to ask.


Want more like this? Click to subscribe to our mailing list.