Project Control: Scope Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Scope Management in the Project Control phase is to ensure that the project includes all the work required so that the project is completed successfully. It defines and controls what is or is not included in the project.
This activity is the maintenance of the Business Case, Scope Statement and Requirements Document through the project change request process throughout the project lifecycle. The Business Case, Scope Statement and Requirements Document are all controlled documents which must be approved upon completion and must be re-approved any time changes are made.
Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
For any desired change (impacting scope, resources or costs) a requestor must fill out a project change request form and submit to the project manager.
Project manager will evaluate impact to scope (requirements and deliverables), schedule, resource plan and cost plan and record this information on the project change request form.
Project manager reviews the request with the CCB.
The CCB determines to accept, defer or decline the request.
Project manager notifies the requestor of the CCB decision.
If acceptance of the requested change makes a significant impact on scope, requirements, schedule resources or costs, in addition to approval by the CCB, the GIS Approval Committee must approve the change:
· Project manager sends the project change request form to the PMO.
· PMO includes the project change request in the packet for the next Approval Committee meeting.
· PMO communicates committee’s decision to the project manager.
Project manager communicates the outcome to the CCB.
The project manager is also responsible for updating the Business Case, Scope Statement, Requirements Document, Schedule, Resource Requirements, Status Report, Staff Plan, Effort Plan and Cost Plan as appropriate.
The project manager must communicate changes to all project stakeholders (including TDMs, Business Managers, GIS Managers and Infrastructure Team Leads) as appropriate.
Project manager updates the status report to reflect new commit date if applicable. NOTE: Some changes may result in an earlier commit date. If the earlier commit date is missed, the project is considered red, even if the project deploys prior to the original commit date.
Approved project change requests which impact base-lined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Project Control: Schedule Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of Schedule Management in the
Project Control phase is to control changes to the project schedule
so that the impact of the changes can be identified, mitigated where necessary
and communicated to stakeholders.
The project manager should review the schedule on a regular basis (at least once each week) to:
Update amount of work complete on each activity using percent of work complete. When a task is started, indicate that it is 20% complete. When task is complete, mark it as 100%. This will allow management to interpret data in a common manner.
Add, delete and updated activities/tasks as necessary
Modify durations, work effort, dependencies as necessary
Add, remove and change resources as necessary
Identify activities which should be starting soon and verify the resources are aware, available and ready.
Identify activities that should have finished but haven’t and research the cause.
Determine corrective action plan to get the activity back on schedule and review the corrective action plan with the TDMs, infrastructure team leads and/or area manager.
If commit dates are not affected the project manager updates the schedule to reflect changes.
If commit dates are impacted, the project manager updates the project plan and conducts an internal review with TDMs, infrastructure team leads, area manager and business managers.
Project manager conducts external review with GIS managers and the sponsor and re-baselines the schedule.
New baseline data is documented in the status report.
Approved schedule changes that impact base-lined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Project Control: Cost Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Cost Management in the Project Control phase is to review project costs to so that issues associated with costs (staffing, materials, etc.) are identified and addressed, minimizing impact to project costs, schedule and quality.
The cost plan is a way to identify estimated projects costs, both expense and capital. These costs should be broken out by each month of the project, throughout the project life cycle. The summary of this information is recorded, tracked and monitored in the status report.
Use the Cost Plan portion of the Status Report (instruction are in the Status Report User's Guide) to calculate and document estimated project costs.
Prior to the Design, Cost Plan & Schedule review, make any necessary changes to the cost plan. Be sure to identify and document each change. Along with the Design, Cost Plan & Schedule review, cover the estimated costs with the sponsor and requestor and obtain their approval. This becomes the “baseline”.
Project managers do not usually have visibility to actual budgets. For monitoring and reporting purposes, assume that actual costs are equal to baseline costs unless you are aware of significant differences. If significant negative differences, determine corrective action plans and record in the status report.
Update the "Actual Costs" portion of the "Cost Plan" sheet of the Status Report each month.
Project Control: Quality Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Quality Management in the Project Control phase is to identify, track and measure the project objectives and performance, and to ensure that appropriate standards are followed so that the product will meet the stakeholder expectations.
Quality management covers both the project and the product produced by the project. This activity includes planning, measuring and auditing compliance of the project and product to ISO 9001:2000, Sarbanes-Oxley, corporate policies and practices, requirements, etc.
Periodically throughout the project (as defined by the measurement guidelines) the project manager will review performance toward project objectives and schedules. The project manager also ensures that code reviews are conducted throughout the project lifecycle (see Perform Code Reviews). Results are documented in the Code Review Checklist. Failures are tracked through closure in TestDirector.
In addition the project manager will ensure that the project and product deliverables are compliant to ISO and Sarbanes-Oxley. Documentation must meet ISO requirements including version control, title, owner and indicate page x of y. Control activities must be reviewed and the GIS compliance manager must be notified of any possible changes or additions. The project team may be required to assist in developing and implementing control activities or changes to control activities.
If the project manager discovers that the project is off course on any of these, it is his/her responsibility to develop and implement corrective action plans.
Project Control:
Resource Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of Resource Management in the Project Control phase is to identify, obtain and manage all project resources (all goods and services, including human resources) so that the appropriate resources are available when needed throughout the life cycle of the project.
Obtaining resources is an iterative process throughout all phases of the project. Early in the Analyze phase the project manager identifies as best as possible the roles (skills) and effort needed to complete the project plan. The project manager estimates the project duration and targets using the Resource Requirements sheet from the Status Report (instructions are in the Status Report User's Guide). Any known computer resources which are critical to the success of the project should be documented on the Critical Computer Resource Log (see instructions included in the template).
Resources may come from many organizations, not only GIS. It is especially important to gain approval and commitment for business resources needed by the project team.
Resource requirements are continuously updated throughout
the life of the project as the project progresses and more detail is known.
Updated effort forecasts are entered in the monthly capacity plan.
During the Complete Scope Statement activity, the project manager works with the appropriate managers (and TDMs when needed) to identify the resources that will be required to complete the requirements document, the WBS and the resource requirements (skills).
Project manager also contacts the business managers for business resources needed on the project, including resources needed to support testing throughout various phases of the project.
Managers identify resource availability and assign resources to the project.
Once the requirements document and the WBS are complete, the project manager updates the Resource Requirements by resource role. For example: DBA, Web Developer, Tester. If two or more of the same role are needed (2 DBAs, 3 Testers, etc.) enter each on its own row. This includes business resources required throughout the project. It also includes resources for code reviews, identification and delivery of maintenance & support turnover documentation, backup when key resources are unavailable and resources which will be required for production support once the product is deployed.
Project manager estimates the effort needed per resource role based on the WBS.
Throughout the project lifecycle, the project manager reviews resource requirements with the appropriate managers at agreed-to intervals, to identify changes in resource needs. Due to constrained resource skills and availability, it is imperative that resource changes/needs are communicated as far in advance as possible.
The procurement processes are outside of the GIS PMP and are managed by the Sourcing department. The following URL provides links to related forms, instructions and information: http://gandalf.stortek.com/wwsrc/purchasing.shtml.
See your manager for assistance in determining the specific steps which must be followed for the individual project's circumstances.
At times it may be necessary to obtain resources through external sources, such as consulting firms. At StorageTek, the project manager makes the request to purchase goods and/or services to their manager.
New hardware and software purchases must go to the TRC (contact the architecture manager or the architecture team lead).
Once the forms are complete, they go through a series of approvals and end up in the Sourcing Department which is responsible for procurement management activities.
The project manager’s responsibility is to work with the purchasing agent to clarify and validate the project’s requirements for the goods/services being purchased.
After the document has been completed and approved, save as a baseline version in the Project Control folder.
When updated, save as a new version. If there are significant changes to resource assignments or effort, you must also obtain approval from the appropriate manager.
Project Control:
Communication Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Communication Management in the Project Control phase is to develop, manage and execute the communication plan so that the right people receive the right communication at the right time throughout the project lifecycle.
This activity consists of developing the communication plan, setup and maintenance of the project folder, issue escalation, providing status reports and monthly project reviews.
Part of the overall communication plan includes the Escalation Guidelines. This document provides some basic guidelines to be used in escalating issues or risks which are outside of the project team's sphere of influence.
The purpose of the project folder is so there is a single location to contain all project information so that stakeholders can quickly find the information they need.
Create the folder system for the project. This is also known as the project workbook. Go to G:\Bet\Projects\5-Project Folder Template. Select the folder, make a copy of the folder and rename the folder to the project name. This folder directory contains the latest version of the GIS PMP templates. They are also filed in the correct folder per the GIS PMP Checklist.
Request access to the folder system for business users. All GIS members should already have access to the G:\BET\Projects directories.
When the project has been closed and all of the documentation finalized:
Move the project folder to G:\BET\Projects\0-Archived Projects
Review the testing deliverables and submit any best practice candidate materials and process changes to the Testing SME function by placing them in the appropriate file location at G:\BET\Testing Repository\Best Practice Candidates.
The purpose of the Status Report is to communicate project status to stakeholders, managers and other project teams. The master workbook remains in the root folder while a copy is filed in the appropriate week’s folder. They are due by 5:00 pm each Tuesday. This is a firm cut-off as the data will be uploaded to the database beginning first thing Wednesday mornings.
It is mandatory that this template is used since it is used to update the GIS Project Scorecard and is the format used for monthly project reviews.
For detailed instructions on the Status Report, view the Status Report User's Guide.
All active GIS projects are reviewed on a monthly basis. Project managers use their status report to present the status of their project to the GIS management team, other project managers, and other key stakeholders.
Lessons learned for completed projects are also presented at the monthly project reviews. Project managers use their completed lessons learned document for the presentation.
NOTE: It is the project manager's responsibility to ensure that their status report or lessons learned document are filed in the appropriate location by the documented deadlines in preparation for the monthly project reviews. If they miss those deadlines, it is their responsibility to bring three copies of their documents to the review.
Project Control: Risk Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Risk Management in the Project Control phase is to identify, analyze and document the project risks so that plans can be made to minimize the impact that unfavorable events would have on the project objectives (schedule, budget, resources, deliverables and defects).
Risk is defined as “an uncertain event or condition that,
if it occurs, has a positive or a negative effect on a project objective”.
There are times when plans to mitigate risks are outside the sphere of the
project team's influence. See the Escalation Guidelines for assistance.
Project manager coordinates and facilitates a session with the project team to flush out the project risks. In some cases, the sponsor and requestor may be invited to attend.
Brainstorm and document potential risks. Note: Some risks may be similar and may be grouped together.
Determine how likely it is that the risk will occur and assign a rating to each risk. The group determines the rating system (be sure to document the rating system). An example of a rating system is High, Medium and Low.
Determine the impact that a risk will have on the project if it occurs and assign a rating to each risk. Use the same rating system used above.
Determine and document the mitigation plans.
The combination of the two ratings will help prioritize the risks. For example, a rating of “High, High” would indicate that the risk will probably happen and that it will have a high impact on the project. Develop mitigation plans for all risks.
Mitigation plans should include actions that need to be taken, who will perform the actions, and when the actions need to be completed.
The project manager reviews the risk plan with the TDMs, infrastructure team leads and area manager as appropriate.
Project manager reviews the risk mitigation plan with the sponsor and requestor to ensure they understand the project risks. This becomes the baseline document.
Project manager periodically (at least once a week) reviews the risk mitigation plan to update activities.
NOTE: Through out the life cycle of the project, more risks may be identified. Those should be assessed as above, approved by the sponsor and requestor and incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Project Control: Integration Management
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Integration Management in the Project Control phase is to ensure that the various elements of the project are properly coordinated so that the product will meet stakeholder expectations.
Integration Management is the sum of all the project activities and documents. It ensures that all aspects of the project fit together without conflict. In the event of a “program”, it integrates the management areas of the sub-projects.
This activity includes:
Meetings, project reviews, etc., which integrate multiple stand-alone projects (both Applications and Infrastructure) and programs (a set of related sub-projects) being released at the same time. Some examples are release meetings, code migration meetings and program team meetings.
Documenting and managing project assumptions and constraints.
Tracking and managing action/issue items.
Coordination of changes across the entire project. This is also referred to as “Configuration Management”. All deliverables, including code, must be controlled using version control methods. Each project team must ensure their documents meet ISO requirements. Project teams must also ensure they are following GIS development standards and policies.
Completion of the PMP checklist.
The PMP Checklist is a tracking tool used to indicate at a glance where a project is in the project life cycle. It is used:
As deliverables are developed the project manager indicates the date completed on the PMP Checklist.
If an activity isn't required for a project the project manager puts N/A in the Date Completed column and records an explanation of why the activity is not required for the specific project. NOTE: If the item deemed as not necessary for a project requires an approval, the project manager must obtain approval/agreement from the sponsor and requestor that the activity isn't required.