Year: 2018

Embracing Legal Department Transformation with Technology: Legal Service Requests

Posted on August 3, 2018 by - Business Process Management

In our new white paper, Embracing Legal Department Transformation with Technology, we investigate the new legal department landscape and how a legal service request solution (LSR) is a key player in the makeover.

Legal departments have enough “real” legal work on their plates even without taking into account all of the daily administrative tasks. Now more than ever, legal departments are slowly changing the way they work. Their objectives can come slowly or quickly, and sometimes they get it right; sometimes it’s hit-and-miss. It’s crucial that the legal department be allowed to focus more on the real legal work, without sinking deeper into the administrative quagmire. In many cases, a well-chosen and effective technology solution is the best answer. But driving and implementing change is another key element in the solution. Keeping up to date with the latest technology is always good, but to implement a technology transformation requires buy-in from leadership and IT, as well as an unwavering commitment to see the project through.

A cutting-edge legal service request solution is key in bringing about transformation relatively easily and cost-effectively. By implementing an intelligent, self-service portal to initiate LSRs, the first phase of the battle is already won. The company will also be able to leverage their new system, since information can be shared across departments and systems. Fewer staff members will need to spend time entering data for the same client and matter, which saves money. All of this will allow the legal department to spend more time focusing on the needs of business consumers – not following up on paperwork and other purely administrative and time-consuming tasks.With a well-chosen legal service request solution, the legal department can provide higher quality services, operate more efficiently, and become a driving force in fueling the company’s success.

Download this this white paper to learn more about:

  • Legal service request market trends
  • Industry best practices
  • Benefits of the right solution
  • The mistakes of falling into the “consensual neglect” trap

Enterprise Legal Management Insufficiencies? Don’t Be So Hasty with that RFP

Posted on August 2, 2018 by - Business Process Management, Enterprise Legal Management

Some companies struggle with their current enterprise legal management (ELM) systems that focus on just core matter and spend management. But when the day comes that they discover there are other business processes that also need automated solutions, it’s time to issue another RFP and undergo another long, expensive and drawn-out path to implementation.

But we’d like to offer another solution. We believe we should be looking at the elements of enterprise legal management as processproblems instead of data problems. When we do this, we’re clearly taking more ownership in business process management (BPM), even though we may not immediately realize it. And in order for corporate legal to be a true corporate citizen, it needs to have a deeper stake in business processes. If you already use automated process solutions, congratulations. You already have a stake since business process automation is inseparable from business process management.

Again, ELM systems that are only capable of core matter and spend management have a clear disadvantage. But on the other end of the spectrum are systems that are loaded with features that will never be used; either because the company doesn’t need them or they don’t want to use them. These solutions were likely an outsize investment to begin with, which already puts the company at a distinct disadvantage. But the situation needn’t be so bleak, and it’s not even necessary to proceed on a quest to find a happy spot somewhere on the spectrum.

The ability to scale your Enterprise Legal Management System in a manner consistent with operational requirements is your key to success.

Seems simple, but how do we do it? By breaking up enterprise legal management into discrete, individual task-based processes, it becomes clear that an “app-based” solution is the most logical way to go. With these, users have the ability to develop and incorporate these discrete process capabilities into the larger enterprise system as they are needed – a la carte. The old “ELM as monolith” approach is, for the majority of legal departments, obsolete. The resounding answer is that we should be looking at ELM as a process problem, rather than a data problem.

Smart companies are now seeking core matter management and e-billing functionality that can be augmented with other process solutions as they are needed. With such systems, scaling could not be easier. In many cases, a company will already have an existing ELM installation, and augment it with process solutions from other providers. These add-ons will be completely compatible with their existing ELM system. There are off-the-shelf, focused solutions as well as platforms on which the company can build their own custom solutions. In any case, the ability to enhance and optimize your system without going the painful RFP route is always a good thing.

Staying the Course with Your Subpar Process Automation Strategy? Think Twice

Posted on August 1, 2018 by - Business Process Management, Enterprise Legal Management

In our new white paper, Embracing Legal Department Transformation with Technology, we investigate the new legal department landscape and how a legal service request solution is a key player in the makeover. But this blog focuses on one section in this paper, “The Case of Consensual Neglect,” which we feel deserves a bit more airtime.

Successful transformation with technology usually comes with a price tag attached. Those who are willing to put in the time, effort, research and money likely stand a better chance of success than those who skimp on any or all of these four factors. Which brings us to another point on the spectrum where we find people who insist on being committed to an irrational or failing strategy. In some cases, the strategy in question was once successful, which can add salt to the wound by means of the “sentiment” factor. In the Harvard Business Review Professors Freek Vermeulen and Niro Sivanathan detail a number of biases that explain why leaders stay committed to failing strategies. Dubbed “consensual neglect” by Karl Weick of the University of Michigan this is a very real phenomenon that hurts businesses in the near and long term:

In combination, these biases lead a company’s decision makers to ignore signals that their strategy is no longer working. It is what Karl Weick, of the University of Michigan, calls consensual neglect: the tendency of organizational decision makers to tacitly ignore events that undermine their current strategy and double down on the initial decision in order to justify their prior actions. 1

Here are six of the most common biases as described by Vermeulen and Sivanathan: 2

  1. The sunk cost fallacy, in which people focus on the investment already made in a particular course of action and hope that, if the approach is continued, invested costs will be recouped and the prior investment decision vindicated
  2. Loss aversion, in which people prefer to gamble on the future success of a previous commitment to a currently questionable strategy – even if it means the investment of additional resources – rather than to incur an immediate loss by changing direction
  3. The illusion of control, in which people regularly overestimate their ability to control future events, thus reinforcing the first two biases described above
  4. Preference for completion, the inherent bias of people toward completion of tasks, such as seeing a particular course of action through
  5. Pluralistic ignorance, in which people who might disagree with a particular course of action remain silent because they think they are the only dissenters and that everyone else is on board
  6. Personal identification, in which people perceive that their identities and social status are tied to their commitments and that withdrawing their support for a course of action they previously approved would risk loss of reputation or status

According to research, this phenomenon of consensual neglect is fixed deeply in our brains, making us more apt to stay the course with a particular strategy – even when it is clearly not the best, or even failing. Worse yet, some companies will double down on their old strategy instead of trying something new, sending them further into a downward spiral. This can easily apply to every facet of a company, but we’re focusing on driving technology transformations. Again, the right technology is readily available to those who genuinely want to avoid falling prey to consensual neglect.

1, 2  Freek Vermeulen and Niro Sivanathan, “Stop Doubling Down on Your Failing Strategy – How to Spot (and Escape) One before It’s Too Late,” Harvard Business Review, Nov.-Dec. 2017, at 110-17.

LEGAL TECH ERFOLGREICH IMPLEMENTIEREN: PROJEKTBETEILIGTE MIT INS BOOT HOLEN 

Posted on July 30, 2018 by - Enterprise Legal Management

Diese dreiteilige Blogserie ist ein Leitfaden für die Umsetzung eines erfolgreichen juristischen Technologieprojekts. Dies ist Teil zwei. Klicken Sie unten, um Teil eins und drei zu lesen: 

Teil 1 – Projektumfang vor dem Lauf einer neuen Technologie definieren 
Teil 3 – Change Management während und nach der Implementierung 

Dieser Leitfaden zeigt die wichtigsten Bereiche auf, die es bei der Implementierung einer Rechtstechnologie zu berücksichtigen gilt. 

Die Einbindung von Interessengruppen ist sowohl bei der Definition von Technologieprojekten als auch bei deren Umsetzung von entscheidender Bedeutung. Wie können Sie also die wichtigsten Projektbeteiligten ermitteln und die erforderliche Zustimmung erhalten? Wie Sie im ersten Teil gelesen haben, ist die Erfassung und Analyse der Anforderungen von Interessenvertretern und Endnutzern ein entscheidender Faktor für den Erfolg bei der Entwicklung und Implementierung eines neuen Systems. Natürlich ist es möglich (und leider auch häufig der Fall), die Anforderungen an die Lösung zu skizzieren, ohne die Bedürfnisse der Interessengruppen zu berücksichtigen, aber dies birgt ein reales, aber vermeidbares Risiko des Scheiterns des Projekts. 

Einige dieser Stakeholder-Gruppen oder Einzelpersonen sind möglicherweise voll und ganz dabei, unterstützen das Projekt und benötigen nur sehr wenig Management in Bezug auf ihre Erwartungen. Allerdings gibt es wahrscheinlich auch wichtige Interessengruppen, die andere Prioritäten haben oder sich gegen die Veränderungen wehren, die ein neues Software-Tool mit sich bringt. 

Wenn Softwareprojekte aufgrund von Problemen mit den Beteiligten/Endnutzern nicht den erwarteten Nutzen bringen, lassen sich diese Projekte in zwei Kategorien einteilen: 

  • Diejenigen, die die Anforderungen der Stakeholder nicht unabhängig verifizieren („einer der Benutzer hat das gesagt, also müssen wir das tun“) 
  • Diejenigen, die die Projektbeteiligten und ihre Anforderungen als eine Art unbequeme Wahrheit behandeln („es gibt sie, aber wir stimmen nicht wirklich mit ihnen überein/ wollen ihnen nicht zuhören“) 

Beide Positionen sind weder wünschenswert noch hilfreich, und beide lassen sich relativieren. 

PROJEKTZIELE DEFINIEREN 

Eine effektive Lösungsauswahl erfordert ein Verständnis der Bedürfnisse aller Beteiligten und der Endnutzer der Anwendung. 

Wie im ersten Teil erläutert, trägt die Erstellung eines Scope Dokuments dazu bei, Verwirrung innerhalb des Projekts zu vermeiden, da die Erwartungen von Anfang an gesteuert werden. Mit der Erfassung der Benutzerbedürfnisse werden die Ziele des Softwarekaufs definiert und zusätzliche Projektbeteiligte können identifiziert werden. 

IDENTIFIZIERUNG DER PROJEKTBETEILIGTEN 

Nachdem die Projektziele definiert wurden, ermitteln Sie die relevanten Interessengruppen. Erfassen Sie deren Anforderungen sowie die Auswirkungen der Lösung auf ihre Teams. Ein erfolgreiches Projekt muss nicht nur von der Rechtsabteilung, sondern auch von oben nach unten getragen werden. Wenn die Projektbeteiligten ignoriert wurden, kann dies die erfolgreiche Implementierung Ihrer Software ernsthaft beeinträchtigen. Die Identifizierung der Stakeholder kann eine zeitaufwändige Aufgabe sein, da es sich dabei um Parteien handeln kann, die nicht nur auf den ersten Blick erkennbar sind. Wer sind typische Stakeholder? Die unmittelbaren Systemnutzer (bei eBilling wären dies die Buchhaltung und die Rechtsabteilung/ Legal Operations), aber auch Rechtsdienstleister und Anwaltskanzleien, der Vertrieb, die IT-Abteilung und das Beschaffungswesen sind potenzielle weitere Beteiligte. 

Ein strukturierter und kohärenter Ansatz kann Ihnen helfen, die Interessengruppen und ihre Rollen zu ermitteln. Zu den Instrumenten und Techniken gehören gezielte Interviews, Multimedia-Kommunikation, Umfragen, Rollenspiele und Workshops zur Nachbereitung von Maßnahmen. Auf diese Weise wird sichergestellt, dass die Stakeholder-Gruppen umfassend einbezogen und unterstützt werden. 

VERWENDUNG DER INFORMATIONEN 

Nachdem Sie die Anforderungen der Interessengruppen erfasst haben, geht es in der nächsten Phase darum, die Ergebnisse zu interpretieren und zu entscheiden, welche Maßnahmen ergriffen werden sollen.  In dieser Phase ist Ausgewogenheit wichtig: lassen Sie nicht zu, dass der Stakeholder, der am lautesten ist, die Anforderungen dominiert.  Denken Sie daran, was die Rechtsabteilung zu erreichen versucht, und wählen Sie nur diejenigen Rückmeldungen aus, die dazu beitragen. Versuchen Sie zu vermeiden, dass der Projektumfang zu groß wird. Denken Sie auch daran, dass die besten Lösungen sowohl effektiv als auch effizient sind und dass ein positiver ROI ein Maßstab für den Erfolg sein wird. 

Wenn Sie Zugang zu einem erfahrenen Projektmanager/Analysten haben, wird dieser in der Lage sein, die Ergebnisse der Stakeholder- und Benutzersitzungen aufzuzeichnen und zu interpretieren und die Schlussfolgerungen in die allgemeinen Projektanforderungen einfließen zu lassen. 

KONTINUIERLICHE KOMMUNIKATION 

Abschließend besteht die wichtige Aufgabe darin, den Beteiligten mitzuteilen, was Sie mit ihrem Feedback gemacht haben und warum.  Dies ist der Schlüssel, um sie für das Projekt zu gewinnen. 

Sie können es nicht immer allen Projektbeteiligten recht machen, also begründen Sie Ihre Entscheidungen, wenn Sie können, mit Daten.  Die Stakeholder und insbesondere die Hauptnutzer haben es in der Hand, ob der neue Prozess Erfolg hat oder nicht. Wenn es um die Implementierung geht, brauchen Sie ihre Unterstützung, um ihre Teams und Kollegen zu ermutigen, das neue System zu nutzen. Auch wenn es ihnen vielleicht nicht gefällt, was sie hören, werden sie es zu schätzen wissen, dass Sie auf sie zugehen. 

Letztendlich müssen Sie die Stakeholder auch im weiteren Verlauf des Projekts zur Validierung heranziehen, vor allem um sicherzustellen, dass das gelieferte System nicht von den vereinbarten Zielen abweicht, und um zu prüfen, ob die ursprünglichen Anforderungen noch gültig sind, da sie sich im Laufe der Zeit ändern können. Auch dies ist ein Vorteil eines Scope Dokuments. Viele Anwendungen wurden in Betrieb genommen, und die Benutzer sagten: „Toll, aber das ist nicht das, was wir jetzt brauchen!“ 

FAKTOREN, DIE FÜR EINE EFFEKTIVE BETEILIGUNG DER STAKEHOLDER ZU BEACHTEN SIND 

  • Machen Sie deutlich, was mit dem Projekt erreicht werden soll 
  • Identifizieren Sie die Projektbeteiligten – insbesondere deren Rollen und Verantwortlichkeiten 
  • Verwenden Sie relevante Erfassungsmethoden – halten Sie sie konsistent und unvoreingenommen 
  • Lassen Sie das Feedback in die Lösungsanforderungen einfließen – achten Sie auf Ausgewogenheit und behalten Sie die Projektziele im Blick 
  • Halten Sie die Beteiligten über den Fortschritt auf dem Laufenden und seien Sie bereit, das Projekt anzupassen, wenn es die vereinbarten Ziele nicht erreicht 
  • Überprüfen Sie die Projektziele immer wieder anhand der geänderten Anforderungen der Interessengruppen. 

Der dritte und letzte Beitrag in dieser Reihe befasst sich mit dem Change Management. Wenn  

Wenn Sie bereit sind, Ihr Legal Tech Projekt zu starten, fordern Sie eine Produktdemo für unsere Legal Operations-Lösungen an, die genau auf Ihre Anforderungen zugeschnitten ist. 

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

Posted on July 30, 2018 by - Enterprise Legal Management

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.

WHAT ARE YOU TRYING TO ACHIEVE?

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.

IDENTIFYING THE 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.

USING THE INFORMATION

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.

ONGOING COMMUNICATIONS

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!”

THINGS TO CONSIDER FOR EFFECTIVE STAKEHOLDER ENGAGEMENT

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

A Quick Survey and Good Cause: Your Input Needed on Contract Lifecycle Management in Legal

Posted on July 26, 2018 by - Company News and Events, Contract Lifecycle Management

Onit would like to invite you to participate in Hyperion Research’s 2018 survey on the use and adoption of Contract Lifecycle Management in Legal. This survey is focused on how technology professionals and attorneys are using and getting the most out of their Contract Management technologies and what capabilities they value and prioritize most. The survey will only take about 4-6 minutes to complete.

The excitement doesn’t end there! Hyperion also has a very worthwhile incentive for completing their survey:

“Hyperion proudly presents our Donations for Data program. We honor your investment of time with a deeper investment in our communities. Hyperion proudly presents our Donations for Data program. For every survey completion we receive, Hyperion will donate $10 to accredited charities benefiting youth and education.”

We hope you’ll take the time to complete this meaningful survey, and contribute to a great cause at the same time.

Click here to begin the survey.

Five Reasons to Use an Elite Business Process Platform

Posted on July 25, 2018 by - Business Process Management

Business process automation software should never be an unchangeable, stagnant drain on your resources. It should have the capability to be augmented or modified at some point if it’s going to help your departments meet their business goals. Software also needs to fit the collaborative way that business is now done. There have been a lot of changes in the world of business process automation in recent years and it’s not always easy to keep up with what’s the latest and greatest.

What’s needed is an innovative platform that makes it easy to create, modify and deploy new process solutions with robust workflow, transaction management and reporting capabilities. To cover the many reasons to invest in such a tool would consume a lot of time, so we’ve narrowed the field down to five:

  1. Cost savings – Solve business problems without the need for costly support, training or IT infrastructure. Software as a service (SaaS) is the way to go, freeing up your team members to do their “real work.”
  2. Solutions are easy to create – Some workflow solutions can be created in less than 30 minutes.
  3. Transparency – Business teams have real-time visibility in processes, such as sales quote approvals, NDA requests, or contract negotiations.
  4. Implementation times are fast – Most implementations take place in weeks; not months. ROI can be seen much sooner than with traditional process automation projects.
  5. Highly human-centric – Each solution has four simple but crucial built-in capabilities:
    – A simple intake form
    – A shared workspace
    – Configured and ad hoc workflow
    – Dashboards

Business process automation platforms have been around for years, but the best have only recently emerged. It can be an overwhelming task trying to decide which one is just right for your business. When it comes to state-of-the-art solution development, you must have the workflow, process and collaboration platform that is the best fit for the way your teams work.

 

Onit Appoints Scott Kurtz as Vice President of Professional Services

Posted on July 24, 2018 by - Company News and Events

Onit is excited to announce that Scott Kurtz has joined our executive team. Scott comes to Onit with more than 25 years of professional services experience in software and consulting services.

Scott most recently served as EVP of professional services at Openlink, a leading software company in energy trading and risk management, where he was responsible for client software implementations globally. He was also responsible for driving innovation, automation and best practices implementation and managing more than $100 million of professional services globally. Scott comes to Onit with an arsenal of executive and professional services experience including technology management, business and consulting operations, business process consulting, professional services sales and contract management.

“This is without a doubt one of the best strategic decisions we’ve made,” said Eric M. Elfman, Onit’s CEO and founder. “Scott’s remarkably powerful business judgement and track record of aggressively driving productivity and profitability were two deciding factors in our decision to bring him on board.”

As Vice President of Professional Services at Onit, Scott will be responsible for client implementations and helping build capability for customers as Onit continues to grow its customer base. Scott holds a bachelor’s degree in Finance from the University of Texas at Austin.

Click here to see the full press release.

LEGAL TECH ERFOLGREICH IMPLEMENTIEREN: SCOPE DOKUMENT 

Posted on July 17, 2018 by - Enterprise Legal Management

Diese dreiteilige Blogserie dient als Leitfaden für die Implementierung eines erfolgreichen juristischen Technologieprojekts. Dies ist der erste Teil. Klicken Sie unten, um Teil zwei und drei zu lesen: 

Teil 2 – Sicherstellen, dass die internen und externen Interessengruppen mit an Bord sind 
Teil 3 – Change Management während und nach der Implementierung 

Dieser Leitfaden zeigt die wichtigsten Bereiche auf, die es bei der Implementierung einer Rechtstechnologie zu berücksichtigen gilt. 

Im ersten Teil werden wir die folgenden Fragen beantworten: 

  • Warum ein Scope Dokument verwenden? 
  • Was sollte ein Scope Dokument enthalten? 
  • Welche Schritte sollten auf die Erstellung des Scope Dokuments folgen? 

WARUM EIN SCOPE DOKUMENT VERWENDEN? 

Viele Projekte im Bereich der Rechtstechnologie scheitern, weil das Tool nicht den grundlegenden Anforderungen der Rechtsabteilung entspricht. Wir empfehlen, zunächst die Anforderungen zu dokumentieren und dann das/die richtige(n) Tool(s) zu beschaffen, um diese Anforderungen zu erfüllen. An dieser Stelle müssen wir den Dichter Kipling zitieren: “Six honest serving men – they taught me all I knew; their names are What and Why and When; and How and Where and Who”. Wenn Sie sich die W-Fragen vor Augen halten, sind Sie auf dem richtigen Weg, um einen erfolgreichen Projektumfang und eine erste Definition der Benutzeranforderungen festzulegen. Das Scope Dokument muss nicht komplex und umfassend sein. Es werden die Erwartungen Ihres Teams und anderer Beteiligter in Bezug auf die zu erreichenden Ziele, die zur Erfüllung dieser Erwartungen erforderlichen Schritte und den damit verbundenen Kosten- und Ressourcenaufwand festgehalten – sowohl intern als auch extern. 

Mittels eines Scope Dokuments: 

  • Werden Sie angehalten, die Elemente des Legal Tech Projekts und des Softwarekaufs zu durchdenken. 
  • Erhalten Sie ein Dokument, das Sie mit Ihrem Team und anderen Endbenutzern teilen können, um sicherzustellen, dass Sie deren Bedürfnisse richtig interpretiert haben. 
  • Es verifiziert das Warum, Wer, Was, Wann, Wo und Wie des Legal Tech Projekts. 
  • Es bietet die Grundlage für die Angebotsanfrage (Request for proposal oder RFP), die Sie an die Software-Anbieter senden werden, und spart wertvolle Zeit bei der Erstellung der Ausschreibung. Wenn Sie das Projekt nicht zuerst ausarbeiten, laufen Sie Gefahr, die Ausschreibung mehrfach zu wiederholen, wenn die Anbieter bereits beteiligt sind. Das kostet Zeit und führt sowohl intern als auch extern zu Unklarheiten über die wesentlichen Anforderungen. 

WAS SOLLTE EIN SCOPE DOKUMENT ENTHALTEN? 

Der Detaillierungsgrad des Dokuments hängt von der Komplexität der Anforderungen ab, die erfüllt werden müssen. Im Folgenden wird kurz erläutert, was beim Scoping eines potenziellen Technologiekaufs dokumentiert werden sollte. 

1. PROBLEM ODER PROJEKTBEDARF 

Beschreiben Sie das Problem oder die Projektanforderung. Auf diese Weise werden die von der Rechtsabteilung beschriebenen Herausforderungen dokumentiert, um Missverständnisse bei den Erwartungen zu vermeiden, und die Ziele des Technologieprojekts für den Rechtsbereich definiert. Dieser Abschnitt muss nicht lang sein, aber er muss ausreichend detailliert sein, um sicherzustellen, dass die Anforderungen und Ziele klar umrissen sind. 

2. ARBEITSPLAN 

Dieser Teil des Dokuments wird erstellt, sobald eine Lösung ausgewählt wurde. Zu diesem Zeitpunkt lassen sich wichtige Meilensteine und potenzielle Probleme leichter dokumentieren. In der Phase vor der Auswahl der Lösung sollte Ihr Scope Dokument einen geschätzten Zeitrahmen enthalten, damit die internen Stakeholder und Anbieter über die Erwartungen informiert sind. Zu diesen zeitlichen Erwartungen gehören die Termine für die Inbetriebnahme und wie schnell Sie die verschiedenen Abteilungen des Unternehmens einbinden wollen. 

3. RESSOURCENBEDARF 

Bestimmen Sie die internen Ressourcen, die für Ihr Legal Tech Projekt benötigt werden. Zu diesem Zeitpunkt ist es wichtig, die wichtigsten Projektbeteiligten und Interessengruppen zu ermitteln. Es gibt eine Reihe von Instrumenten und Techniken, um diese Interessengruppen durch den Prozess zu leiten; diese werden im nächsten Blog erläutert. Viele Projekte sind Joint Ventures, bei denen Ressourcen aus der Rechtsabteilung, anderen internen Teams, Softwareanbietern, Anwaltskanzleien und Beratern benötigt werden. Sprechen Sie mit Teams in anderen Unternehmen, die ähnliche Projekte durchgeführt haben, und lernen Sie von deren Erfahrungen. 

4. KOSTEN 

Es gibt sowohl interne als auch externe Kosten. Legen Sie ein Budget für die Softwarelösung selbst fest, aber berücksichtigen Sie auch die Kosten für die Projektmanager, die viele verschiedene Kostenmodelle anwenden, wie z. B. die Abrechnung nach Zeit und Material, feste Projektkosten oder eine monatliche Gebühr für die Arbeit. Es können auch Kosten für interne IT-Ressourcen anfallen; SaaS-basierte Lösungen sind in dieser Hinsicht deutlich billiger als ressourcenintensive Systeme, die Sie selbst hosten. Wenn Sie sich dafür entscheiden, eine Lösung zu entwickeln, kalkulieren Sie die damit verbundenen Kosten. 

NEXT STEPS 

Geben Sie das Dokument über den Anwendungsbereich an die Nutzer und Beteiligten in der Rechtsabteilung und darüber hinaus weiter. Einer der Hauptvorteile ist die Klarstellung, dass die Anforderungen richtig interpretiert wurden. Daher ist es wichtig, dass das Dokument geprüft und genehmigt wird. Nutzen Sie dieses Dokument, um potenzielle Tools zu recherchieren, Ihre Ausschreibung zu verfassen und mit der Beauftragung von Anbietern zu beginnen. 

FAZIT 

Die Erstellung eines Umfangsdokuments trägt dazu bei, Unklarheiten innerhalb des Projekts zu beseitigen und die Erwartungen zu steuern, um Unzufriedenheit und Probleme bei der Benutzerakzeptanz zu vermeiden, wenn schließlich eine Lösung ausgewählt wird. Es spart Zeit, wenn Sie mit der Beauftragung von Softwareanbietern beginnen, da Ihre Anforderungen klar sind. Es wird sichergestellt, dass die Lösung, die Sie kaufen oder entwickeln, tatsächlich mit den Prioritäten der Rechtsabteilung übereinstimmt, um die Benutzerakzeptanz und den geschäftlichen Nutzen zu maximieren. 

Teil 2 dieser Serie befasst sich mit der Identifizierung und Sicherstellung, dass die Stakeholder des Legal Tech Projekts mit an Bord sind. 

Aus dem Original-Blog übersetzt.  

Your Guide to Seamless Legal Tech Implementation: Part 1 — Scoping the Project Before Buying

Posted on July 17, 2018 by - Enterprise Legal Management

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

Part 2 – Ensuring the internal and external stakeholders are on board
Part 3 – Change management during and after implementation

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.

4. COST

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.

NEXT STEPS

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.

Part 2 – Ensuring the internal and external stakeholders are on board
Part 3 – Change management during and after implementation