1. What is the EDRM Project Management Framework?
In general, a framework is a logical structure intended to provide a simplified, yet comprehensive representation of a complex process that is independent of the tools and methods used in any particular situation.
The EPMF is a framework designed to maximize the success of e-discovery projects. It is a distillation of the core elements of e-discovery project management into a series of structured models.
The two top level models making up the framework are:
- The Project Management Team Model and
- The Project Management Process Model
The Project Management Team Model defines the project management team structure and roles in e-discovery projects.
The Project Management Process Model defines a high level sequence of activities for managing e-discovery projects. Rather than prescribing a specific series of procedures, it is flexible enough to accommodate a broad range of projects. A number of recommended practices are provided to help project teams use the model successfully.
These models are independent of the scope of the project and the specific services, technologies or processes used to execute the project. Hence, the framework can be used to manage a wide range of e-discovery projects (and litigation support projects in general). Specifically, the ability to use the model does not depend on the following.
- Size, duration or complexity of the project
- Types of services included in the project
- Technologies used
- Discovery processes being used
- Number of sub-teams involved
1.1. Applicability of the Framework for Smaller or Simpler Projects
The framework is designed to handle a wide range of projects. The team model and process model are applicable and can be easily implemented even for the simplest of projects without much overhead. The level of details and documentation covered within each step of the process can be varied based on the scope of the project.
For example, while a large scale project may require a detailed planning document covering a number of different aspects, the planning on a simple project can be accomplished by a short email. It is just important that an appropriate level of planning and communication happens.
2. Implementation Resources
While the framework itself carefully avoids any components related to specific types of projects, processes or technologies, these resources do not have the same stringent requirement.
While the resources are screened and sometimes modified to be useful in a wide range of environments, they are by no means expected to be as universal as the framework. Project teams may have to adapt these resources for their specific processes.
The resources section is expected to evolve as more resources are made available and as the nature of services themselves evolve.
3. Project Management Team Model
The EPMF Project Management Team Model defines the project management team structure and roles in e-discovery projects.
3.1. The Three Entities
In the most general situation, e-discovery projects typically involve a corporation, one or more law firms and one or more vendors. In the interest of simplicity, the model describes one each of the three types of entities. Each entity is represented in the diagram by a dotted circle. Each entity has its own project manager and a set of internal teams involved in the project.
There are numerous projects where multiple law firms or vendors may be involved. There are also projects of limited scope where one of the three entities may not be involved. The framework supports these projects as well. The mechanism to achieve this is described in a separate section.
3.2. The Project Management Roles
As seen in the diagram, each entity (corporation, law firm and vendor) includes a project management role. Note that this is a functional role. The person performing this role may not necessarily have a job title of project manager. Within the law firm, the project management role is usually played by a litigation support manager, paralegal or attorney. Within the corporation, someone from the legal department or IT typically takes on the role.
It is important to explicitly identifying the project manager for each entity at the start of a project. If a team is to perform the project management function for an entity, it is important to designate a lead responsible for coordinating the team.
The responsibilities of each project manager fall under two main categories:
- Management of project execution within their respective entities
- Coordination with the other two entities in managing the overall project
The inward looking role of the project manager is usually defined by their organization’s internal processes. However, it is important that this aspect of their role is consistent with their responsibility to the overall project. For example, a project manager can only provide accurate progress reports only if their organization generates the information and makes it available to the project manager.
The project manager’s outward looking role is driven by their participation in the integrated project management team along with project managers from the other entities.
3.3. The Integrated Project Management Team
The project managers of all participating entities have a combined responsibility for overall project success. Their coordinated performance as an integrated team is one of the fundamental principles of the EPMF.
The framework does not specify any organizational structure among the members of the Integrated Project Management Team. Teams may elect to have one organization take the lead or decide on a team of peers approach. The business relationship between the entities is also likely to have a bearing on the dynamics of the team.
Independent of the organizational structure, a collaborative environment which fosters open communications is a key to success. The team must be able to rally behind common goals, create realistic plans, assess risks honestly, work with accurate status information and react to changes appropriately.
The EPMF Project Management Process Model provides integrated project management teams a structured approach to collaboration and coordination.
3.4. Service Providers and Consumers
The entities involved in a project take on the role of service providers or consumers based on the services being rendered. The most obvious service provider – consumer relationship exists between a vendor and the law firm engaging the vendor.
However, there are other services being rendered as well. For example, the corporation’s IT may be providing the service of identifying data sources relevant to a matter. Hence, within a single project, multiple service provider – consumer relationships might exist.
Understanding who the service provider is and who the consumer is for specific activities helps assign the responsibilities outlined in the Process Model. For example, the consumer is responsible for defining the scope and constraints within which the service is to be rendered, while the service provider is responsible for providing status reports and metrics about the service being provided.
4. EPMF Project Management Process Model
The EPMF Project Management Process Model defines a high level sequence of activities for managing e-discovery projects.
4.1. Maximizing Success
The model relies on the following key principles to maximize success.
- Proactive and open communication
- Alignment of all teams to a common vision and goals
- Comprehensive planning that spans the entire project
- Preparing for and managing unknowns and changes
- Coordinated performance of all teams involved
- Ongoing project monitoring and course correction
- Ongoing risk management
4.2. The Seven Phases
The process is divided into seven distinct phases. Each phase includes a series of activities that culminate in a milestone. Each phase also includes a set of deliverables that the project management team is responsible for producing.
Risk Management, Change Management and Progress Monitoring are performed through the life of the project.
4.2.1. Scoping Phase
The Scoping Phase lays the foundation for project success by aligning all teams to a common vision and goals. By defining the project scope and providing an overview of the context and constraints, this phase lays the foundation for project planning in the following phases.
4.2.2. Preliminary Planning Phase
The Preliminary Planning Phase produces a simple project plan with sufficient details to enable the vendor selection process.
4.2.3. Team and Vendor Selection Phase
During the Team/Vendor Selection Phase, one or more service providers are picked and the engagement is formalized.
4.2.4. Detailed Planning Phase
During the Detailed Planning Phase, the integrated project management team develops a comprehensive plan detailing how the project will be executed.
4.2.5. Startup Phase
During the Startup Phase, project workflows and technology are setup and tested, User training is conducted and project assumptions are validated. Sample data exchanges are done and any piloting is completed during this phase as well.
4.2.6. Execution Phase
The project gets executed during the Execution Phase. The project management team is focused on ensuring that the project is being executed per plan and making adjustments as necessary during this phase.
4.2.7. Closeout Phase
The project is formally closed out during the Closeout Phase as per the Closeout Plan. Closeout includes archival and disposition of data, metrics summarization, project summarization, lessons learned activities and documentation archival.
5. Scoping Phase
The Scoping Phase lays the foundation for project success by aligning all teams to a common vision and goals. By defining the project scope and providing an overview of the context and constraints, this phase lays the foundation for project planning in the following phases.
The main deliverable from the Scoping Phase is a Vision Scope Document that articulates the following:
- Vision and goals for the project
- Context of the project within the overall matter
- Project approach
- Scope of the project
- Assumptions and dependencies
- Special considerations
- Success criteria
By openly communicating the vision, goals, context and success criteria for the project, all teams can work towards a common vision. Moreover, all teams are aligned towards success of the overall project and can set the right priorities and make the right tradeoffs.
Explicitly stating the scope, assumptions, dependencies and special considerations helps make realistic plans along with realistic contingency planning and risk management.
In many cases, the service provider may not be selected until the Team/Vendor Selection Phase. In such cases, the Vision Scope Document produced during the Scoping Phase will help select a service provider who can support the vision. Moreover, once the selection process is completed, the Vision Scope Document helps bring the team up to speed quickly.
Since the consumer usually sets the vision and understands the constraints of the project, the consumer owns responsibility for this phase. If the constitution of the team is already known, other team members may assist in the process.
Risk management begins during the Scoping Phase and continues through the life of the project.
6. Preliminary Planning Phase
The Preliminary Planning Phase culminates in a Preliminary Project Plan with sufficient details to enable the team/vendor selection process.
The preliminary plan addresses items such as technology and process, quality plan, rough timelines, etc. required to help qualify vendors. Preliminary planning is important since the statement of work is often formalized before the Planning Phase as part of the Vendor Selection Phase. The preliminary project plan also outlines the vendor selection process.
A preliminary budget may also be produced during this phase to meet the internal needs of the consumer organization.
A Request for Information (RFI) process may be used to gather preliminary information from multiple vendors to help develop a vendor selection plan.
The Consumer owns responsibility for the Preliminary Project Plan.
7. Team and Vendor Selection Phase
During the Team/Vendor Selection Phase, one or more service providers are picked and the engagement is formalized.
The selection process may take the form of an RFP process, selection from a list of pre-approved vendors or selecting a vendor based on prior experience or references.
The selection process involves many considerations including:
- Ability to produce quality work on time
- Robustness of delivery process
- Experience level and references
- Ability to integrate with the consumer’s processes
- Cost considerations
- Ability to understand and support overall project goals
- Prior relationship
- Cultural fit
Careful evaluation of the multiple criteria is important in picking the right vendor for the project at hand. However, how the selection process is handled also has a significant bearing on project success in other ways.
Providing vendors with sufficient information put together during the Scoping and Preliminary Planning phases helps focus the proposals on the specifics of the project and how each vendor will handle the requirements. This also reduces the risk of problems down the road when some special considerations or unexpected requirements are encountered.
Holding a dialog regarding execution strategies as part of the selection process also helps mitigate the risk of vendors committing to unrealistic deadlines or other risky commitments due to competitive pressures. On the other hand, this also helps identify and fix unrealistic expectations from the scoping and preliminary planning phases.
By the end of the selection process, the selected vendor should already be aligned to the project’s vision and goals and all teams must have a common understanding of the project strategy.
A budget or cost estimate based on the available information and stated assumptions should be generated and approved before final signoff. All assumptions should be made clear. This will help ensure that the relevant parties fully understand the proposed pricing model.
8. Detailed Planning Phase
During the Detailed Planning Phase, the integrated project management team develops a comprehensive plan detailing how the project will be executed.
The detailed plan would address the following areas:
- Communications plan
- Workflow plan
- Detailed specifications (processing specs, database specs, production specs, etc.)
- Quality plan
- Project schedule
- Contingency plan
- Acceptance plan
- Security and data disposition plan
- Other areas the project team deems relevant
The level of detail and the number of areas to be covered by the Detailed Project Plan must be commensurate with the scope of the project. While larger, more complex projects require a very detailed plan, a simple document would suffice for projects with limited scope.
9. Startup Phase
During the Startup Phase, project workflows and technology are setup and tested, User training is conducted and project assumptions are validated. Sample data exchanges are done and any piloting is completed during this phase as well.
Planning and managing the startup phase explicitly highlights any potential gaps in the plan early in the process when issues are easier to address. The Quality Plan should address the types of testing and validation to be performed as part of the Startup Phase Changes to the Detailed Project Plan may be required based on the findings. Change management begins at this phase.
10. Execution Phase
The project gets executed during the Execution Phase. The project management team is focused on ensuring that the project is being executed per plan and making adjustments as necessary during this phase.
The primary project management activities during this phase are:
- Schedule/timeline management
- Quality management
- Change management
- Budget management
- Risk management
- Metrics tracking
Communication is a key part of all these activities. The project management team should communicate on a regular basis and use structured reporting to aid clarity of communication.
11. Closeout Phase
The project is formally closed out during the Closeout Phase as per the Closeout Plan. Closeout includes archival and disposition of data, metrics summarization, project summarization, lessons learned activities and documentation archival.
An explicit Closeout Plan helps ensure that the project is formally closed and data is properly archived and/or disposed.
The closeout phase also provides an opportunity for the teams to memorialize the lessons learned from their experiences on the project towards future process improvement.
12. Risk Management
Risk management is an essential activity that has to be performed through the life of the project.
Risks arise from uncertainty surrounding project parameters, external dependencies and results. Risks in e-discovery projects arise from a number of common uncertainties:
- The competing strategies of the litigants and court decisions
- Evolving issues within the matter based on newly identified facts
- Uncertainty regarding the scope of discovery
- Uncertainty regarding the nature and volume of data
- Uncertainty regarding scheduling of activities and resource contention with other projects
- Uncertainties related to unexpected failures, errors and oversights
When uncertainty ends, the risk ceases to exist. There is no more risk that an event might occur either because we know that the event will definitely not occur or because we know that the event has occurred (in which case, it is now an issue). Most risks have a negative impact on the project from a schedule, budget or quality perspective. Some risks such as loss of data can adversely affect the case in a very serious manner (adverse inferences, sanctions, etc). The outcomes of some uncertainties may have a positive impact. The failure to identify and leverage the positive is a type of risk as well.
The goal of risk management is to minimize the negative impacts associated with project risk while maximizing the positive impacts. Successful risk management is accomplished by:
- Identifying risks as early as possible
- Clearly defining the risk by specifying the following:
- The initiator or the event that would trigger the risk
- The outcome if the risk came true
- The probability of the risk (between 1% and 99%)
- The relative impact of the risk (usually a number between 1 and 10)
- The importance of the risk (probability times impact is a good measure of importance)
- Ensuring that all members of the team have the same understanding of the risk
- Developing a mitigation strategy. A mitigation strategy might include:
- Steps to reduce the probability of the risk coming true or the use of an alternative approach that does not pose the risk
- Steps to clear up the uncertainty early (by conducting pilots or tests or by gathering additional information)
- An explicit decision not to do anything since the probability and impact are not high enough to justify the cost of mitigation.
- Developing a contingency plan. A contingency plan states what is to be done if the risk comes true.
- Monitoring risks regularly and adjusting the risk parameters as new information becomes available
- Assign an owner to the risk. The owner is responsible for implementing the mitigation strategy and monitoring the risk as the project evolves
12.1. Expecting Change
The premise of risk management is that change is to be expected as part of any project. As uncertainties play out either way, change occurs. Expecting change and proactively managing it provides teams the opportunity to plan and develop strategies to reduce the negative impact of change.
12.2. Open Communications
Successful risk management is only possible with open communications. Open, honest discussion of project risk leads to more accurate appraisal of project status and better informed decision making both within the project management team and by external stake holders.
Open communications is aided by a positive approach to risk management. Identifying and detailing risks is the first step to mitigating them. A long list of risks is not an indication of a project in trouble. It is the sign of a project being managed proactively.