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:
- Unrealistic Customer Expectations and Developer Gold-Plating
- Insufficient Customer Involvement
- Poor Impact Analysis
- Scope Creep
- Defective Requirements
- 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?
Electronic Discovery Project Management 
