Podcast: Looking for EDPM template ideas?

EDPMs (e-discovery project managers) have to be creative thinkers but we also have to find ways to stick to a defensible routine. Templates and forms help us to mitigate the risks of project management in the often unpredictable world of litigation. Check out this podcast from a respected project management trainer as he recommends some of his favorite template collections… be creative as you think of ways to apply and modify some of these templates to your work as an EDPM.

 

Leave a comment and let us know which ones you liked best and why!

Documentation Basics

Learning about project management methodologies may seem a bit overwhelming at times but if you start out simply with an Excel spreadsheet or a notebook/ legal pad, the basics can be achieved.  Project management is really about keeping track of what you did and planning what you are going to do.

Here are some tips from a recent article by Brett Burney, an industry expert on e-discovery project management:

You can document your actions on a Word document, an Excel spreadsheet, a yellow legal pad, or using one of the tools mentioned above. It doesn’t matter the medium, as long as it’s being done and can be referred to at a later date.

At a minimum, a documentation protocol should include:

  • client, matter, and task;
  • who requested the task (e.g., stakeholder, lawyer, client);
  • date and time the task was started and completed;
  • name of person who engaged or completed the task;
  • notes, summary, problems encountered, resolutions;
  • software and hardware used; and
  • chain-of-custody considerations (where were the results delivered?).

 

What advice do you have for someone just getting started in e-discovery project management?

 

 

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?