Learn About E-Discovery Project Management

Lately, I’ve been writing most of my e-discovery project management posts on my other blog http://www.learnaboutediscovery.com … Here’s a quick round up of the most recent posts and I invite you to visit me over there some time!


  1. Being the Project Manager
  2. How important is COMMUNICATION to e-discovery projects?

  3. “New Job Title, Same Job? Becoming an E-Discovery Project Manager”
  4. Recently, I recorded a live training on e-discovery project management… the link on this post will soon convert to on-demand registration. Here’s a few extra notes from the webinar.
  5. I delivered a CLE last month on this topic. Here are a few notes from that lecture.
  6. Electronic Discovery Metrics: Why Metrics Matter


Check out my other blog: www.learnaboutediscovery.com or send me an e-mail erika at learnaboutediscovery.com



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?

Succesful Role Definition in EDPM

One of the ways you can ensure success for any type of project (including an e-discovery project) is by making sure that you have the right people doing the tasks that they are best suited to do and do well. Today, I want to explore how to successfully define the project team roles for litigation / e-discovery projects. I will begin by saying that we can not rely or depend on the traditional roles: attorney, paralegal, litigation support specialist, project assistant, secretary, IT person (which could be application specialist, network engineer, help desk specialist) or trainer.

Traditional project management roles include: sponsor, team leader, SME (subject matter expert), project manager, stake holder… these don’t exactly work either.

It is going to be important to define who’s doing what and when before litigation strikes or at the very latest, very early in the case. The EDRM describes the project management team to include the corporate client, the law firm and the service provider (vendor). Within each organization someone is identified as the project manager. However, what happens next gets pretty fuzzy because then everyone wants to fall back on their traditional roles or job titles to define the project team roles.

So how can we take the standard list of project team roles and the traditional law firm/client/vendor relationship and redesign it to work better for e-discovery projects?

There is an increasing trend in the industry today that is looking for the attorney in charge to take on the role of project leader so as to enforce quality control and avoid sanctions. How does this trend help us to understand and define clear team roles?

Do you have to be a techie to manage a litigation support or e-discovery project? Some experts in the PM world would say no, but you do need to have an understanding of what the technology can do, should do and does best.

If you are the project leader? Can you successfully delegate tasks to others on the team? Communicating and discussing everyone’s strengths up front will enable successful task delegation and role identification.

Now that we’ve given this some thought, let’s create our project team checklist:

  • Determine the roles & responsibilities you will need to complete your e-discovery project successfully
  • Consider your team’s strengths and weaknesses
  • Create a “Roles & Responsibilities” Matrix (fill it in, share with whole team, everyone knows what’s expected of them)
  • Keep in mind that everyone on your team may not be employed by your organization (the client, outside counsel, service provider, consultant)

What do you think are the key roles that are necessary for every e-discovery project? Which are optional? Should the partner in charge be the project leader?