logo for information-management-architect.com
leftimage for information-management-architect.com

Project Implementation Plan

Improve efficiency with David Bowman’s information management guidelines for data warehouse project implementation plan

This site is designed for Information Technology professionals who need  to improve effectiveness and require guidance and direction to help teams consistently produce error free results.

It provides a checklist of information management guidelines for project planning and a project implementation plan template that can help jump-start a project.

What is a Project Management Plan?

A project implementation plan is a communications tool, which clearly sets expectations for all team members.

It helps new team members quickly see who is involved with the project and helps minimize project delays due to miscommunication. It also helps other stakeholders know what is expected of them and when.

Some organizations have very large Information technology departments and staff are assigned to numerous projects at one time. A project plan ensures that all team members know what they are expected to deliver, when it is required, who will accept the deliverable and how it will be approved.
 
Scope Planning
  • Should define project objectives and goals for the whole project;
  • Should define project control mechanisms and specify milestones and program implementation plan;
  • Should describe major deliverables;
  • Should describe the general approach this project will follow e.g. iterative development, or prototyping and should provide enough description of the approach but should’t be too detailed; and
  • Should include any assumptions that have been made concerning the planning of this project and the creation of the project schedule; and
  • Should include all non-validated assumptions in the Risk and Issues Management Plan.
Resource Planning
  • Should define the roles and responsibilities for each role and team member;
  • Should document the resource loading describing when each resource is required;
  • Should include a history of level of effort estimates by role by project phase and/or by month;
  • Should identify any other critical resources or non-labor resources that are required for this project, including hardware if applicable;
  • Should describe actions required to eliminate any skill gaps e.g. the project should only be responsible for providing and funding for training on skills specific to the project and outside of the general body of knowledge for the role specified;
  • Should describe the organizational context, both technical and managerial, within which the planned project is to be implemented and might include an organizational chart to identify all organization units that participate in or are responsible for any project activity e.g. organizational units may consist of vendor and customer, prime contractor and subcontractors and different groups within one organization; and
  • Should obtain resource plan approval.
Tasks, Deliverables and Schedule
  • Should define project phases and tasks within each phase;
  • Should list detail project deliverables; and
  • Should provide project schedule.
Communications Planning
  • Should define the person responsible for receiving the communication;
  • Should define the purpose of the communication;
  • Should define the method of communication;
  • Should define the communication schedule; and
  • Should define the person responsible for creating the communication.
Risk Management Planning
  • Should define team members responsible for risk management;
  • Should define the frequency of reviewing risks;
  • Should define where the risk management plan will be located; and
  • Should define the risk escalation plan.
Configuration Management Planning
  • Should define each work product or project deliverable;
  • Should define who is responsible for creating the work product;
  • Should define who is responsible for contributing to each work product;
  • Should define who is responsible for approving the work product;
  • Should define configuration definition for each work product e.g. archive, configurable item, version control;
  • Should identify archive work products that are important to the project but that will not be changed after their creation e.g. archiving is a form of versioning and will add (archive) new work products to the appropriate repositories as needed.  This allows these work products to be referenced later. Examples of work products that should be archived include meeting minutes, audit reports, test reports, etc. Archived items are not subjected to change control for check-in;
  • Should identify configurable items e.g. work products that may be used by two or more groups, are expected to change over time either because of errors or change of requirements, are dependent on each other where a change in one mandates a change in others, are critical for the project, will be provided to the client, are subjected to formal change control i.e. change requests are required for check-in and approval is required prior to checkout. Additionally once a work product is designated a configuration item, it can only be archived, not deleted, when it is determined it is no longer needed; and
  • Should identify work products that undergo continuous change, and do not meet the criteria for a configurable item, make them good candidates for versioning e.g. versioning will add new versions of a work product to the appropriate repositories as needed and include work products such as the project schedule, budget or action item tracker are candidates for versioning. Versioned items are subjected to less formal configuration control (i.e. Change Requests are optional for check-in and approval is optional prior to update).
Change Management Planning
  • Should describe the process for requesting changes e.g. all stakeholders should be encouraged to submit changes that identify defects or enhancements to the project Configuration Items;
  • Should specify the procedures and tool for requesting a change to a baseline configuration item and the information to be documented for the request.
  • Should describe originator’s name and organization, date of request, indication of urgency, the need for the change, description of the requested change and additional information, such as priority or classification, may be included to clarify the significance of the request and to assist in its analysis and evaluation;
  • Should describe who is responsible for obtaining an impact analysis, reviewing and approving/disapproving all requested changes; and
  • Should specify the activities for implementing and verifying an approved change e.g. any associated change requests, the names and versions of affected configuration items, verification dates and responsible person, re-baseline version identifier, the appropriate release or installation date and responsible person.
Project Quality Assurance Planning
  • Should describe the review, approval and base lining methods that will be applied to each configuration item identified in the configuration management section of this project implementation plan;
  • Should describe the review, approval and base lining methods that will be applied to all other project artifacts e.g. meeting minutes, schedule;
  • Should identify how changes to each of the configuration items will be processed;
  • Should identify the project quality assurance structure, reporting and communication methods; and
  • Should describe the escalation path for any identified quality assurance issues.
Requirements Management Plan

Should describe the requirements management process that will be adopted to ensure that the project schedule and budget are not compromised by unauthorized requirement changes and that all requirements are delivered as planned.

Document Management Plan

Should describe the documentation management plan that will be adopted to ensure that the project schedule and budget are not compromised by unauthorized changes to project documentation after it has been base-lined.

Project Implementation Plan Template

Under Construction  


Summary...

A project implementation plan is a communications tool, which clearly sets expectations for all team members.

It helps new team members quickly see who is involved with the project and helps minimize project delays due to miscommunication. It also helps other stakeholders know what is expected of them and when.

This site provided a project planning best practices checklist and a  project implementation plan template template that can help jump-start a project.