The Value Proposition of E-Discovery Project Management

It’s been over five years since the Federal Rules of Civil Procedure were revised to clearly instruct and encourage litigators to engage early in managing electronically stored information. I’ve been in the litigation support industry since 1995 and project management skills have always been important to the success of litigation matters for which technology was involved. The Sedona Conference published a proclamation a few years ago stating the value of cooperation and project management methodology best practices in e-discovery. Recently, I shared this article outlining the value of project management with my students and thought you might like to read it as well. Here are the key points with my commentary… you can read the whole article here.

The value proposition for project management goes something like this. It takes time and effort to proactively manage a project. This cost is more than made up for over the life of the project by:

  • Completing projects more quickly and cheaply. – Cost and litigation budgets in general are typically the focus of the client. Most corporations have project managers within their business model and expect that their lawyers and legal teams do also. It’s not just about being quick and cheap but more so about not wasting time and money.
  • Being more predictable.    How can we predict costs and schedules if every litigation or e-discovery project reinvents the wheel? Project documentation includes metrics.
  • Saving effort and cost with proactive scope management. How much data (ESI) do we need to review? How much of it is relevant? What tools and resources exist to help us only review what we need to? An experienced e-discovery project manager can help you to navigate these waters.
  • Better solution “fit” the first time through better planning.  –
    My motto in litigation support has always been: The tools are not as important as the process. Define your process, then select the right tool for the job.
  •  Resolving problems more quickly.  Project management includes a communications and problem solving plan/ protocol.
  •  Resolving future risk before the problems occur.
    Experience and metrics will allow you to assess risks and plan a solution or solution options in advance.
  • Communicating and managing expectations with clients, team members and stakeholders more effectively. Managing expectations is a big deal. This is extremely difficult to do without the guidance of a project manager and a documented plan of action.
  •  Building a higher quality product the first time.  Improved financial management. This article is targeted to an audience of software developers but this sentiment applies in e-discovery, too. Think: document production.
  • Stopping “bad” projects more quickly. If a project is being effectively managed, someone will notice a problem before it turns into a train wreck.
  • More focus on metrics and fact-based decision making. Decisions based in facts derived from well documented metrics will provide the consistency of methodology, the courts are looking for.
  • Improved work environment. Who doesn’t want to work with a bunch of happy people?

 People who complain that project management is a lot of ‘overhead’ forget the point. All projects are managed. The question is how effectively they are managed.

A lot can be said for the value of project management in e-discovery… if you don’t have a project manager on your litigation team don’t worry, you can learn… keep reading this blog. 😉


Will Agile Project Management Practices Reduce the Risk on Your e-Discovery Project?

Maybe. But the best scenario for success requires that you are involved from the beginning of the project. This probably won’t work very well if you’re brought in after all of the key decisions are made and the project schedule and scope are defined… or worse, if the schedule is defined but the scope is not. I follow a project management blog from the U.K. called Project Smart. In today’s post, they discuss how agile project management practices reduce requirements risks in software projects. Since we use software as ediscovery project managers, I didn’t think it was too much of a stretch to think about our ediscovery projects in agile terms. How would I reduce some (or as much as possible) of the risks that are inherent to managing ESI through the discovery phase of litigation? Well, first we have to break the discovery phase into projects. In my (humble) opinion, discovery in itself is not a project. It does not have a clearly defined schedule, scope, resources or quality control workflow. And because it can sometimes drag on for years, I wouldn’t really call it “temporary.”  Some might argue with me on this point but for the sake of practicing ediscovery project managers, lets go with this for now. I’m open for discussion in the comments.

Next, we have to identify the projects that typically take place during the discovery phase. Thanks to the nice folks at the EDRM, we have a lovely chart to work with here. Consider each box on the chart a project and now we’re ready to begin our discussion.

What are the risks for every project? The folks at Project Smart list six common risks for any sort of project:

  1. Unrealistic Customer Expectations and Developer Gold-Plating
  2. Insufficient Customer Involvement
  3. Poor Impact Analysis
  4. Scope Creep
  5. Defective Requirements
  6. New Processes and Tools

How would we manage these risks within the context of electronic discovery? This is an ongoing discussion I’ve had with other ediscovery project managers so I would appreciate your feedback in the comments.

1. In order to manage unrealistic expectations, break your project into smaller goals and objectives. Ask your project sponsor (usually the attorney in charge or maybe the client) what they absolutely must have at a minimum and what are the nice-to-haves. Make sure you document all of this for the project team. The Project Smart author suggests 3-week “timeboxes” where you define goals in terms of what can realistically be accomplished in a 3-week period of time. You may not have 3-weeks, you may only have 3-days …. or you may have 3 months to work with… select a reasonable but short time period as a short term goal and get everyone to sign off on that course of action.  As for the “gold-plating” … I consider this to be similar to selecting software based on bells and whistles rather than making sure that the technology selected to complete the project will match our team’s workflow goals.

2. Agile project management is a collaborative approach to managing a project. While the EDRM chart seems like it passes the “baton” from project to project, if you look closely, the arrows double back on each other. So much so that you really can’t make a decision about how you will convert ESI for the document review without first knowing what production formats your attorneys agreed to or you’d like for them to agree to at the discovery conference. If you need to know what the big picture objectives are for each project within discovery, you need the attention of the key stakeholder or sponsor or customer who can make decisions about which path to take. In the business world, they call litigation support professionals or ediscovery project managers “business analysts.” Your role as an ediscovery project manager is to help the client/attorneys define concise and clear requirements and then document them for approval so that you can execute the plan. It is a huge risk when the attorneys over delegate to litigation support and choose not to understand the technology and best practices for implementing the technology. (I would also add that over delegating to your service providers is just as risky if attorneys take a hands-off approach.)

A real world example can be found here and here’s a key point of the article: “… counsel must be vigilant in conducting oversight of all processes crucial to ESI production and particularly any privilege screening processes.” In other words, don’t over delegate…

3. Litigation is often a moving target. So it might be a nice idea to think that ediscovery PMs will be brought into the discussions earlier enough to make an impact. It might also be a little unrealistic to think that the project scope and definition won’t change if the litigation strategy changes. I like the agile philosophy because in an agile world, change is not a bad word. Change happens. Prepare for it by analyzing alternative workflows and have a “change request” form handy to document that the change requested is authorized. (Send me an email for a sample “change request” form)

4. I have a funny picture that I show in class when I start talking about scope creep. It’s a scary monster creeping up behind an unassuming project manager. Litigation is known for scope creep. Electronic discovery can sometimes feel like the scope isn’t creeping at all… it’s running fast and furious right over you! This is probably the highest risk area of project management. When corporations don’t have a good idea of how much data they have, what starts out as a small project, suddenly turns into 500 gigabytes of data. Or your attorney tells you they have a few CDs they need you to process and when you swing by his office to pick them up, they’re actually DVDs. Scope creep shows up many ways in ediscovery projects. Manage the scope of your projects by revisiting number 1 in this post: short timed goals. If the case team adds to the processing project more data that’s been collected, no worries… it will likely not be completed by the deadline for the first set of data. Be sure to communicate this up front so that you can manage expectations. Adapt the project plan to the changes and be sure to plan ahead for the potential changes that might occur on your project.

5. Has this ever happened to you? You start down the path to completing what seems like a simple project, only to discover that you were missing a major detail for getting it done? Working in smaller “timeboxes” as suggested by Project Smart might work for you and your team. Asking follow up questions to define priority of custodians or search requests, reports, training etc. will also help. A clear communication plan is also necessary to avoid defective requirements on your ediscovery project. Who has the decision-making authority? How will you validate your project requirements? In the classes I teach on ediscovery project management, I suggest to students that they should always take 15 minutes to think of and then ask follow up questions. Communication is crucial to a successful project and taking notes on the palm of your hand in the break room is not a good way to define project scope or requirements.

6. New technology and updates to old technology is an every day occurrence in the world of ediscovery. How do you reduce the risks associated with using new technology? First, your technology should meet the needs of your project workflow. It should not hinder but be intuitive to the team. Periodically, ask the team to give you candid feedback (online surveys of 5 questions or less work well for this) about how the new application is working for this project. Workflow and process are essential management tools for any ediscovery project. You can have a successful project if your workflow is defined and youhave a way to capture metrics to tell the story of your success later. Remember, the tools are not as important as the process. You will reduce the risk in using new tools if you are able to demonstrate (especially to the court) that you have a documented methodology and workflow in place.

Do you think that agile project management practices will help to reduce risks your next ediscovery project?

How would you change the way you’re currently managing your ediscovery projects to take on a more collaborative and defined approach?

How do you deal with change on your ediscovery project? What works? What doesn’t work?

Managing & Tracking Metrics

When you are planning your e-discovery project, your case team will ask you “how did you come up with that number?” That “number” could be associated with a cost or with a schedule/ time line you’re suggesting.  Metrics (or statistics) are information we collect about a current project so that we can use it as a reference for our next project. Typically, we collect information on how long everything takes to be completed and how much it costs. Don’t forget to take good notes on why the ESI conversion took 3 days and why it cost more or less than we thought it would.

Steven Levy talks about metrics from the broader business perspective of a law firm in his Fireside Chats found here.

There are only a few applications dedicated to e-discovery / litigation support project management. One of them is iFramework. The presentation below was uploaded over the weekend… you might find it useful in discussing the value of documentation and metrics with your case team. How are you currently managing and tracking metrics for your e-discovery and litigation support projects?