Project Information Repository

“When you fail to plan, you are planning to fail.”

Dr. Robert Schuller

The Project Information Repository (PIREP) is a fundamental tool for managing and administering software development projects. It’s recommended that the PIREP be on an online database, so that all team members can share the information on key information such as milestones, risks, issues, changes, meetings, and decisions. The documents filed in the PIREP are either inputs to or results of your specific project. At a minimum, the following sections (or folders) should be used for your PIREP documents.

• Section 1 – Project Control and Coordination Process
• Section 2 – Standards and Procedures
• Section 3 – Organization
• Section 4 – Requirements
• Section 5 – Deliverables
• Section 6 – Milestones
• Section 7 – Scheduled Plans with Actuals
• Section 8 – Meetings
• Section 9 – Risks
• Section 10 – Issues
• Section 11 – Changes
• Section 12 – Quality Management
• Section 13 – Sponsor and Supplier Agreements

The above PIREP sections are not set in cement and can be customized. For example, you could rename them, put in a different order (e.g., by usage), don’t use if not needed, or add new sections as needed. The main point is that you need a PIREP to help run and add discipline to your project. Having no PIREP will increase your chances of project failure, which is the last thing you and your organization want. Another advantage of having an up-to-date PIREP, management and team members can quickly assess the overall condition of your project. The following are working descriptions of the above PIREP sections.

Section 1 – Project Control and Coordination Process

A project is defined as a temporary endeavor (i.e., a definite start and finish date) aimed at producing a stated measurable objective. A fundamental aspect of good project management is control, and control is best achieved when scope, cost, schedule, and quality are monitored on a routine and continual basis.

The Project Control and Coordination Process for your client addresses management of projects that require more than 160 hours of effort, and the definition of this process needs to be documented in this section. A core component of the process includes a weekly or bi-weekly internal project management control meeting. The purpose of the meeting is to understand how projects are progressing and to identify any areas where assistance is needed to ensure that deliverables, cost, schedule, and quality are met according to plan. Secondary objectives of the meeting are to review project baseline changes and to assign project managers (PMs) to recently approved requests for service.

The following are the process objectives:

• Offer a high level of service to the customer by providing routine and periodic progress updates
• Identify and resolve issues/problems before they become critical
• Provide tighter control over the billing process by anticipating and creating Project Change Requests (PCR’s) early in the cycle
• Control changes to project schedule by ensuring that:
  • Project priorities are established and managed
  • Schedule dependencies and resource conflicts among projects are identified and managed
  • Projects are initiated and managed using a defined project management methodology and tool set
  • Projects meet defined completion criteria
  • Consolidated projects schedules are supported by and interlocked with lower-level detailed individual project schedules

Section 2 – Standards and Procedures

Project standards and procedures describe how project control is to be managed, which is critical for project success. They define the way the project will be run and managed. Procedures provide a comprehensive, consistent, and coherent framework, which all the members of the project can fulfill their responsibilities.

Section 3 – Organization

This identifies all project team members and key people like the project Sponsor and suppliers involved in your project. The PM should describe the roles played by the project team and define the responsibilities and authorities of the key people involved in the project. Items used in this section can include organizational charts and tables that include name, company, location, sub-team, role, working hours, phone number, cell phone number, and email address. Besides the PM, team members can use this information to determine who to contact with questions or information related to the project.

Section 4 – Requirements

This contains all the information regarding requirements, related applications and dependencies underlying the project plan. Most projects will have changes (i.e., Section 11) to the original requirements, so it’s especially important to know the requirements of your project and if they are up to date.

Section 5 – Deliverables

Project deliverables or work products are tracked in this section. Deliverables are related or referenced in the next two sections on Milestones and Scheduled Plans with Actuals. All actions related to deliverables and deliverable components are also recorded in this section. The PM will use this section to assess the progress of the project by reviewing which deliverables are complete and which ones are not.

Section 6 – Milestones

The purpose of milestones is to record significant decisions, accomplishments, events, or turning points in the life of a project. Milestones can easily be reflected in your scheduled plan (see next section) as a task with duration of zero. In general, management likes to look at the overall status of milestones to get a “quick feeling” if the overall project is on schedule, versus getting entrenched in the detail of the next section. The PMs will periodically review and update this “report card” as needed. In addition, the use of this section shows that the PM understands the agreed upon requirements.

Section 7 – Scheduled Plans with Actuals

This is a collection of detailed work plans (and updated actuals) that was created to support the day-to-day activities of running the project. The various plans should at least include a Communications Plan, HR Plan, Quality Assurance Plan, Cost Plan and/or Work Breakdown Schedule (WBS). The WBS should use a project-planning tool (e.g., MS Project) for putting a project plan together and assigning responsibilities. Combined with updated actuals, Project will give you “snapshots” of the plan during different time intervals, which provides a good audit trail and tracks specific details of changes made to the plans.

WBS is a hierarchical decomposition of all the activities that the project team must complete. The hierarchy has as many levels as are required to define the work. An example of such top-down approach would be phase (top level), activity (second level) and task (third level). Without a WBS, the project team doesn’t have a clear definition of the work that is required to conduct and complete the project. Also, WBS is a pictorial view of the solution in terms of work products and deliverables, which is like a “Bill of Materials” in manufacturing.

There are over one hundred add-in products available in the marketplace that will add more features and/or value to Project, depending on the needs of your project. One of my favorite add-ins is WBS Chart Pro from Critical Tools, Inc (512-342-2232). This add-in is a great team and management presentation tool that will sketch your project plan using a top-down approach, which can be displayed graphically in many different styles and colors.

Section 8 – Meetings

This portion contains historical records of all meeting agendas, handouts and minutes. The PM uses this information to make some of the decisions, take needed actions, or track open items in managing the project. Printouts of important emails that relate to this project should also be included.                

Section 9 – Risks

A risk is a potential event or future situation that may adversely affect your project. The uncertainty character of a risk distinguishes it from an issue (covered in next section). In other words, risks address potential events, and issues address know concerns. The components of a risk are the possible event itself, the probability that the event will occur, the impact of the event and the frequency with which the event may occur.

Project risks are risks to the business objectives/critical success factors that are, in the PM’s judgment, sufficiently serious to require project-level attention. The Risk Management Process addresses the identification and management of all risks. This involves a continuing focus on identifying risks and preparing an appropriate response.

The Risk Management Process has four major steps.

• Risk Identification
• Risk Quantification
• Risk Response Development
• Risk Tracking and Control

Risks often surface because of other program management activities. For example, an issue may be related to a single supplier. In researching possible solutions, the issue owner may realize that the same event could occur with all or multiple suppliers. The actions needed to resolve the issue may become part of an ongoing risk mitigation strategy to address this event with other suppliers prior to the event occurring.

When starting the project, risks need to be identified, researched, analyzed, estimated, and documented in this section, which normally includes the effort required to manage or control the risk. During developing and implementing the project, other risks will appear and need to be researched, ranked, documented, and monitored. A risk could be mitigated through a containment plan, transferred to a third party, or be ignored because of a low probability of occurring and/or having low impact to the project. Most people look at risks in a negative manner, but sometimes a risk can be a positive thing for a project by opening a door for new and better approaches or opportunities that were never thought of or were not available when the project first started.

A risk form should be created for each possible project risk and filed in this section. Also, a copy of this standard form (template) that you will be using should be filed in Section 2 – Standards and Procedures. At a minimum, the following risk information should be included in the form – name, ID, description, date identified, date expected to happen, ranking based on severity, identified by, factors, potential consequences if it occurs, response approach strategy, estimated cost to prevent, and the owner of the risk.

Section 10 – Issues

This portion tracks issues associated with the project that require a response. An issue can be raised by team members and requires contributors to resolve it. The resolution could result in an action plan or no action. Also, issues could impact the work schedule and/or costs of the project.

An issue form should be created for each project issue and filed in this section. Also, a copy of this standard form (template) that you will be using should be filed in Section 2 – Standards and Procedures. At a minimum, the following issue information should be included in the form – name, ID, description with root cause, date identified, impact, priority (e.g., high-medium-low), target resolution date, date resolved, originated by, and owner.

Section 11 – Changes

A PCR is used to document an assessment of the workload involved in implementing the requested change. The project Sponsor needs to approve the PCR before the works starts on this change. All projects will have PCRs, which could affect your current deliverables, milestones, and scheduled plans. Occasionally, a PCR will have no cost attached to it and usually doesn’t affect your schedule, but still needs to be documented for historical purposes.

All projects will have changes and can’t be ignored. Thus, a formal change management process must be established and used because changes will alter project baselines and contract requirements. Changes can be technical (e.g., implementation of solution) or contractual (e.g., requirements and cost) and they both require the same attention.

A change form should be created for each project change and filed in this section. Also, a copy of this standard form (template) that you will be using should be filed in Section 2 – Standards and Procedures. At a minimum, the following change information should be included in the form – name, ID, description, date identified, date expected to start, date expected to be finished, resources to be used, estimated cost, the owner of the change and the person (i.e., Sponsor) who approved the change.

Section 12 – Quality Management

The project’s Quality Management (QM) objectives and processes need to be documented. QM consists of quality assurance (QA) which covers the process for improvement and quality control (QC) which describes how to plan to monitor and measure quality performance. There are three types of QM project reviews – deliverable, compliance, and health. It’s recommended to have independent reviews of a project to ensure the project is on the right course or what actions need to be implemented to get the project back on track. Besides performing an outside check-and-balance, QM people will ensure that the project and related documentation are being developed according to an acceptable process. Each project should have periodic mini-reviews that rate its progress against certain defined metrics.

QM overlaps the next section on agreements. Certain words found in agreements can be viewed as “dangerous” and should be viewed with caution. The bottom line: are these words or descriptions found in agreements achievable? If not, there could be legal problems that you want to avoid. For example, words ending in “ly” could turn up words in your agreements such as fully, completely, and satisfactorily which could have different interpretations in a court of law. The last thing you want is to have improper or unrealistic expectations about deliverables. In doing a proposal review, look (i.e., you could develop word processing search macro) for the following dangerous words in agreements to avoid possible litigation.

• Always, never
• Any, all, every, none
• Best efforts or estimate
• But not limited to
• Complete
• For example
• Includes or increase
• Insure, ensure, assure
• Lowest, greatest, earliest, latest
• Optimum, minimum, maximum
• Outputs, inputs
• Partner, partnership
• Uniquely qualified

Section 13 – Sponsor and Supplier Agreements

This portion contains all Sponsor and Supplier agreements, which specify the mutual commitments of the involved parties during the life of this project. The agreements provide project team members with access to the baseline of each agreement and its amendments. Also include the Statement of Work (SOW) that was generated from the request for Proposal (RFP) document. The SOW includes information such as the work to be performed by the vendor, when work is due, how the work will be measured for acceptance, and the working relationship between the vendor and your organization. Finally, the SOW becomes a major part of the eventual contract between your organization and the vendor.

There are three basic contract types – Fixed Price, Best Estimate and Hourly Services. A Fixed Price contract has a system solution, defined requirements, fixed schedule, and has a high-risk factor because of the possibility of cost/schedule overruns. A Best Estimate contract has specific number of hours, defined skills, and minimum risk. An Hourly Services contract or “Body Shop” has an undefined number of hours, rate based on skill type and no risk.

The structure and content of agreements can vary markedly from project to project. Agreements with external sponsors and subcontractors are usually quite different from those with internal organizations. When the parties are from the same enterprise, the agreement is less formal, but should exist to eliminate future misunderstandings.

Your thoughts on this article would be appreciated.