3.2 Critical Path (CP)

---

The critical path is a calculated result of interdependent activities of a project that determines the shortest total length of the project. The critical path of a project may change from time to time as activities are completed ahead of or behind schedule. This is most frequently conveyed as a filtered list of critical path elements taken from the project Gantt chart.

Figure 3.5: Project Gantt Template.

3.2.1 Task Duration Estimates (TDE)

This is an estimate of the amount of time each task will take to be completed. The task duration estimate should consider both effort and required wait time (i.e., two hours to code a report and four hours to run it equals six hours duration). While somewhat subjective in nature, making a best guess at the duration of each task is both a good exercise in learning to determine overall project scope and, more importantly, it requires that some thought go into what is actually put into the plan. An important thing to remember is that these estimates can be revised as new or better information is obtained. They are to be used as a tool in making a best guess at the time for task completion.

3.2.2 Dependency Diagrams (DD)

These are simply diagrams illustrating which tasks are dependent on the start or completion of other tasks. The diagram focuses exclusively on logical dependencies, not resource dependencies. These project dependency diagrams are most often seen as PERT charts of the project. They are used to display a visual representation of project dependencies.

3.2.3 Optimization Tradeoff Plan (OTP)

The OTP outlines a process for identifying issues, solutions to issues, and tradeoffs for each solution. The OTP assists in selecting the best solutions based on real project information and incorporating it into your project plan and project schedule. The final deliverable implementing the OTP is an optimized project plan and schedule.

3.2.4 Resource Histogram (RH)

The resource histogram is a display of the number of resources required as a function of time on a graph. Individual, summary, incremental, and cumulative resource curve levels can be shown. Such histograms are autogenerated in many project management software packages and are useful in performing resource allocations and load balancing against multiple projects.

3.2.5 Work Breakdown Structure Dictionary (WBSD)

The WBSD is a task-oriented breakdown of activities that organize, define, and graphically display the total work to be accomplished in order to achieve the final objectives of a project. The WBSD lists every project task, its WBS code, the task owner, and its completion criteria. The astute Project Manager will realize that using the WBSD is a quick means of tracking task assignments and following up on task completions.

3.2.6 Risk Analysis (RA)

The Risk Officer appointed by the Project Manager at the beginning of the project is responsible for delivery of both the Risk Management Matrix and the Risk Analysis Matrix as part of the overall risk assessment provided at this phase of the project. All of the risk deliverables should be reviewed by the Project Manager and the Core Team in a meeting specific to risk analysis where the Risk Officer can formally present his or her findings. Any disagreement over the findings should be resolved at this time by the Project Manager. Once the team agrees on the level of risk, the formal, revised findings are presented to the Project Sponsor.

The Risk Management Matrix (RMM) identifies key risks and their probability of occurrence. This plan also identifies preventive actions and contingencies. The Risk Analysis Matrix (RAM) is a formal review, examination, and recommendation of all known project risks based on the findings of the Risk Officer. A sample RAM is shown as Figure 3.6 below.

Figure 3.6: Risk Analysis Matrix.

Change management is used by the organization to manage product change requests. The process should identify the problem affecting a change, describe the change needed to correct the problem, the impact making the change will have, the consequences of making the change, and the reasons for approval/rejection of the change. Minimal change management forms should contain the following elements:

• Project name (code name)

• Change control number (assigned by the SPMO)

• Name of person requesting change (same person who approves the change)

• Date opened (date assigned by the SPMO, not the date reported)

• Title of the change (name it something all Core Team attendees will relate to)

• Requested close date (requestor specifies a proposed fix date)

• Description of the change (be as specific as possible here)

• Justification for the change (why the change is needed)

• Person assigned to make the change (tracked by a member of the Core Team)

• Impact assessment (SPMO generated)

3.2.7 Status Reports (SR)

Status reports are produced in the design, development, and implementation phases of the SEP project life cycle (regarding the current status of project tasks) before conducting the review meeting. The report should be written specifically for the intended audience (e.g., management, project team, customer) and should include, at a minimum, the two following sections:

Project Management Tasks

Accomplishments

• Budget slippages

• Concerns/issues

• Gains

• Planned activities

• Scope impact/changes

• Timeline slippages

• Variances

Data Development Tasks

• Accessibility

• Availability

• Documentation

• Human factors information

• Program coding status

• Technical tasks

• Training status

• User acceptance

3.2.8 Variance Reports (VR)

Variance reports indicate areas where the project has varied from the approved baselines. These reports should be generated from the corporate project management software tool. The reports should be compiled upon request of the Core Team or Project Sponsor, or at minimum, at the end of each of the eight SEP project phases. Variances are recorded for schedule and project scope changes and for resource and cost changes. The reports should include reasons for variances.

3.2.9 Adaptive Action Plan (AAP)

This is a plan for systematically responding to each variance or change in the project in order to remain focused on achieving all of the project objectives. AAPs should include all issues with a list of solutions for each issue. The plan should discuss benefits and costs or tradeoffs for each solution proposed.

3.2.10 Review Package (RP)

This package is prepared by the Project Manager and the SPMO for review by the Project Sponsor. The package should contain all documents produced in a particular phase of the SEP project life cycle. This includes all project and vendor deliverables as explained previously. This package is sent out usually three to five days before the review meeting and includes all documents produced from the current phase. The review meeting should be held at least once during a phase, before the closeout of the phase, and should conscientiously review the progress made during the phase.

Care should be taken during the review meeting to identify potential risks in the development process and to ensure that the Project Sponsor is comfortable with these risks and the steps taken to mitigate them. The last person you want to be surprised by an outcome of a project is the Sponsor. This person is your advocate and must be kept informed of everything. This relationship builds trust between the Sponsor and the SPMO and the Project Manager. Make sure your folks understand the value of that relationship.

3.2.11 Meeting Agenda (MA)

The meeting agenda is a list of meeting participants and items to be addressed during the meeting. The agenda should be followed closely during the meeting, and one person from the Core Team should be designated to ensure that the meeting actually follows the agenda. That person should be empowered to interrupt the meeting if the topic strays from the agenda and remind the team of the purpose of the current meeting.

3.2.12 Documents from Review Meeting (DRM)

Notes or minutes taken from the review meeting, along with any instructions from the Project Sponsor, approvals or denial letters, and so on are all review meeting documents. They should be incorporated into the project binder and distributed to interested parties following the conclusion of the meeting.

3.2.13 Waiver/Exception to Required Standards (WERS)

This is a written authorization to accept a configuration item or other designated items that are found to depart from specified requirements but are considered suitable for use “as is” or after rework by an approved or designated method. An authorization to depart from the SEP should document the following:

• Form to record waiver/exception

• Explanation of what the deviation from the standard is

• Explanation of why is it needed

• Appropriate signoff (usually by the Sponsor)

3.2.14 Project Team Review Minutes (PTRM)

Minutes should be taken at each review meeting that is conducted by the SPMO. This is particularly necessary during the review/approval cycle of each phase of the SEP project life cycle. The minutes should contain at least the following key information:

• Team name

• Purpose of meeting

• Topics discussed

• Decisions/agreements made

• Action items assigned

3.2.15 Approval Letters (AL)

This document is simply a letter sometimes also called a Project Continuation Approval (PCA) Letter verifying that the Sponsor or his or her designee has reviewed and approved all project documentation, project funding, and/or any particular course of action needed during the review/approval cycle of each phase of the SEP project life cycle. The approval letter is placed in the project binder kept by the SPMO.

The PCA is a letter or document signed by the Sponsor or his or her designee indicating that the project has been approved for continuation into the next stage. A sample PCA is shown as follows:

Phase Completion Approval Signoff

  Every phase of Project <enter project code name> requires  approval before it can continue to the next phase of develop- ment. This document must be reviewed by all affected parties or  their representatives and signed to signify approval. I have  reviewed the deliverables and documents associated with this  phase and verified that all necessary work has been completed. I  hereby authorize work to begin with the next phase of the  project.    SEP Phase Number and Title:    _______________________________________________    Signed: ____<insert Project Sponsor name> _____________    Date: __________   

It should be quite obvious by now that the planning phase of a project can be quite detailed and take considerable time. Studies abound about how the amount of time spent here will save money and effort in later phases of the project life cycle. As a Program Manager, it is your responsibility to ensure that all projects are executed with proper planning and guidance. The function of the SPMO is to provide such a framework for each team to use.

In the next chapter we transition from analysis and planning to design and start building documents that detail how things get done in a project. So far, we have covered what is needed and why. We have covered a formal process that allows a team to understand what needs to be done. The purpose of the design phase is to communicate precisely and exactly how and what is to be done to those tasked to actually go do it in order to achieve the goals outlined in the URD.

---