Monday, November 17, 2008

Identifying Risks by Reviewing Documents

Ling, a project manager (PM) with Simple Software Solutions, feels extremely overwhelmed. She is new to the realm of project management. Her first project with this company is the Key-entry project. This project entails the development of privacy software solutions for a large Internet company.

Ling wonders how she can possibly identify all the risks for this project. A good place for Ling to start is the documentation review.

Every project plan and list of project assumptions will contain risks. Documentation reviews identify the inherent risks in the project plan and assumptions. In order to perform a documentation review, you and your team members should carry out a structured review of project plans and assumptions, files from previous projects, and other available information.

There are three steps that need to be addressed in order to perform effective documentation reviews.

Step 1: Identify the project documents needed.
When you are ready to begin the documentation review for your project, the first step is to gather the necessary documents.

The documents you gather for the review are critical to identifying project risks. You should examine documents available from the current project, plus documents from similar past projects. Some of the most helpful documents are the:
  • Post-project reviews from similar, past projects - Post-project reviews from similar past projects are documents contained in project files that summarize what went as expected during a project and what didn't go according to plan.
  • Lessons learned from similar past projects or any other documents from similar past projects that will be helpful - Lessons-learned documents refer to the learning gained from performing a project. They may be identified at any point in a project and are often considered as project documentation.
  • Other documentation for the current project that will be helpful - Other documentation includes the inputs to the project's risk management plan, such as project charters, the company's risk management policies, defined roles and responsibilities, stakeholder risk tolerances, the company's risk management plan template, and the WBS.
Step 2: Choose how the review will be structured.
Next, you need to decide how the review will be structured. The structure of the review is contingent upon two factors: 1. the size of the project; and 2. the areas of the project being targeted.

Documentation reviews for projects of more than five phases should occur at the management level and are conducted for each phase and subphase. These reviews will be continuous throughout the project and will involve various participants in each phase. Reviews for projects with fewer phases should occur at the team member level for each phase of the project.

PMs must also decide the areas that are being targeted for risk identification. This is project specific and depends on the types of project and risks that may occur.

If a project involves developing new technology, the PM may target the design and marketing risks.

If a project uses a lot of external suppliers, the PM may target the supplier management risks.

If the project involves construction, the PM may target industrial safety risks.

If the project involves construction, the PM may target industrial safety risks.

Step 3: Identify the reviewers for each part of the review.
When selecting the team members for the documentation review, you should ask yourself "Who are the people who have the necessary experience and knowledge for this area of the project and who will bring the most value to a discussion about potential risks?" Generally, the reviewers will be the project team members, subject matter experts (SMEs), team members from similar projects, and other stakeholders, like sponsors. The documentation type, for example, project level, also plays a role in deciding who should be part of the review team.

Ling is ready to begin the documentation review for the Key-entry project. First, Ling gathers files from two similar privacy software development projects that Simple Solutions has recently completed. Then she decides how the documentation review will be structured. She examines the project plan and assumptions for the Key-entry project. She decides this project is rather large.

Finally, Ling identifies the reviewers for each part of the review. She selected Jake because of his extensive experience, Tanya because of her expertise in the field, and Rachel because she is the lead project team member. They have a discussion and successfully identify risks for this project.

Knowing how to perform effective documentation reviews is an important skill. Performing an effective documentation review is a good way to begin the risk identification process.

No comments: