Pm Process Guide
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Pm Process Guide as PDF for free.
More details
- Words: 41,490
- Pages: 157
Project Management Process Guide Production Version 2.3
Originator: One IT PPM Team Page 1 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Document Information and Revision History File Name
One IT Project Management Process Guide
Original Author(s)
Amy Wagner, Ashok Prasad, Brenda Schultz, Charlene Draine, Chris Hurley, Dan Wilczak, Deborah Harrell, Denise Hussin, Diana Zinn, Duane Lawton, Elaine Medlen, Jeff Robinson, Joe Zhou, John Cackowski, Julia Davis, Paul Gustofson, PPM Working Group, Terry Grover, Tom Maslyk, Heddie O'Connor, Sally Tuma, Vairavelu CRN, Wendi Rhoad
Current Revision Author(s)
SDM PPM Workgroup
Version
Date
Author(s)
Revision Notes
Beta V1.04
04/08/2002
OneIT SDM Project Team
Production 1.0
04/12/2002
OneIT SDM Project Team
Draft 1.04 Release § Added defect management process § Global change to Methods and Applications/Tools title § Changes as called out in Change Request #765 § Added review graphics (CR #767) § Added definition of red, yellow and green status (CR #766) § Added note about GAO Audit requirement – Spisich § Added text to indicate that the configuration management tool should be set up at the same time as the project control book (CR #134) Production Release • Changed title page to say Production Release 1.0 • Reverted to an older definition of an Initiative page 6 • Modified the definitions of a Program Release pg 6 • Deleted the Application Release definition pg 6 • Added a Software Release Definition pg 6 • Incorporated references to the Interim Resource Management Process and the corresponding web site link into the tools section everywhere that the requisition or release of resources were mentioned and everywhere that timesheets were mentioned (CR#777)
Production 1.0
04/19/2002
OneIT SDM Project Team
•
•
Noted possibility that the project may have been the result of a number of change requests being bundled together to produce a new application release. May note of this in Section 1.1.1 Confirm Project Readiness (CR#782) Added task in Section 1.1.1 Confirm Project Readiness for completion of the PQA Metrics Sizing Profile Template (CR#782)
Production 1.1
05/08/2002
OneIT SDM Project Team
•
Completed changes identified in pilot training and earmarked for version 1.1
Production 1.2
05/21/2002
OneIT SDM Project Team
•
Completed changes identified in detailed training and earmarked for version 1.2
Production 1.2.1
06/05/2002
SDM Manager, TPMO
•
Completed changes identified in detailed training and earmarked for version 1.2.1
Production 1.3
06/26/2002
SDM Manager, TPMO
•
Completed changes to match new RMS process as well as changes identified during Classic SDM detailed training.
Production 1.3.1
07/18/2002
SDM Project Team, TPMO
•
Completed changes related to new RMS process. Change project/program data entry from ProSight to ITMS. Updated Review Pyramid Diagram.
• Production 2.0
08/05/2002
SDM Project Team, TPMO
•
• • • • •
CR #1456: incorporate that Project Appropriation Request / PAR process in the introduction. Add step to ensure that the PAR has been entered in MEARS prior to project start-up. Add step to ensure that costs and benefits are accounted for during business case rev iew/confirmation. Add step to ensure that costs are accounted for during hardware/software acquisition. CR #1335, 1439 Incorporated changes for Packaged Product Selection and Implementation CR #1436 Incorporated changes for Six Sigma alignment CR #1516: Include link to MRS guide and quick reference guides CR #1517: Include link to IT tools quick reference. CR #1561: Incorporated SOW workflow
Originator: One IT PPM Team Page 2 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Production 2.0.1
11/04/2002
SDM Development Team
• •
• •
Production 2.1
SDM Development Team
• • • • • •
Production 2.2
August 14, 2003
EPMO – Program Governance Team
Prod 2.3
30Apr2004
Program Governance Office
• • •
CR #1576. Per Mark Bradford, beginning Sunday, November 3rd, 2002 the new URL for ITMS will be http://www.itms.ford.com/ CR #272055: Modified links in SDM Matrix, SDM Guide and PM Guide pointed to QC web site rather than SDM web site for the 35_Quality_Control_Plan_and_Test_Strategy.doc template. Modified links in SDM Matrix, SDM Guide - pointed to QC web site rather than SDM web site for the "85_QC_Final_Report_Metrics_Spreadsheet" template. Modified links in SDM Matrix, SDM Guide - pointed to QC web site rather than SDM web site for the "84_QC_Final_Report_Management_Summary" template. Added new link in SDM Matrix, SDM Guide and PM Guide - pointed to "89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support", which is a stripped-down version of the 35_Quality_Control_Plan_and_Test_Strategy.doc.template. CR #272072: Modified process 1.2.2 Establish Project Procedures to identify SCM constraints (global SCM requirements) rather than establish SCM Plan. CR#272029: Replaced obsolete references to interim resource management process web site with current site and incorporating current process for adding/releasing resources. CR #272077: synchronized role descriptions in SDM Guide and PM Guide CR#272084: Replace selected references of scope management with change management. CR#271983: Correct MRS URL to www.ads.ford.com/mrs CR#271984: Add wording for assess and make recommendation to Confirm/Refine Business Case. CR#333115: Corrected typos in process 1.1.1 Confirm Project Readiness to Start. CR#271982: Add a step to process 5.3.3 Close and Archive Records to mark the project complete in ITMS. Gate Review ICRP Control Concern – obtain signatures of decision-makers to confirm accountability (Section 4.2.6) PQA Strategy update – direct PM to PQA web site (Section 1.1.1) Portfolio Management – updated overview section with new Portfolio Management Process.
Originator: One IT PPM Team Page 3 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Table of Contents PURPOSE ......................................................................................................................................................................................... 6 PORTFOLIO MANAGEMENT .............................................................................................................................................................. 6 PORTFOLI O MANAGEMENT PROCESS FLOW ................................................................................................................................... 6 DEFINITION OF PROJECT MANAGEMENT ......................................................................................................................................... 7 PROJECT MANAGEMENT CORE PROCESSES .................................................................................................................................. 8 PROJECT MANAGEMENT KNOWLEDGE AREAS ................................................................................................................................ 9 THE PROJECT LIFE CYCLE .............................................................................................................................................................. 9 PM ALIGNMENT TO TYPICAL PROJECT LIFE CYCLE ....................................................................................................................... 9 KEY PRINCIPLES OF PROJECT MANAGEMENT............................................................................................................................... 11 Project objectives must be SMART ................................................................................................................... 11 Understanding and managing requirements is crucial ............................................................................ 11 Planning is everything and ongoing ................................................................................................................... 11 Control is a necessity, not a luxury .................................................................................................................... 11 Customers must be part of the process .......................................................................................................... 11 Providing an honest assessment of project health is critical................................................................ 11 We know what works, just do it............................................................................................................................ 11 Metrics should be collected throughout the project life cycle............................................................... 11 PURCHASED PACKAGE SELECTION AND IMPLEMENTATION (PPSI) .............................................................................................. 14 IT MANAGEMENT TOOLS ............................................................................................................................................................... 14 GAO AUDIT GUIDELINES .............................................................................................................................................................. 17 PROJECT AUTHORIZATION REQUESTS AND PURCHASE ORDERS................................................................................................. 17 PROCESS PARTICIPANT ROLES ..................................................................................................................................................... 18 1.0
INITIATE PROJECT ......................................................................................................................................................... 25
1.1 PREPARE FOR THE PROJECT............................................................................................................................................ 26 1.1.1 Confirm Project Readiness to Start.................................................................................................................... 26 1.1.2 Identify and Engage Stakeholders..................................................................................................................... 29 1.1.3 Engage Project Start-up Team............................................................................................................................ 31 1.1.4 Develop Start-up Work Plan................................................................................................................................ 33 1.2 ESTABLISH PM INFRASTRUCTURE ................................................................................................................................... 34 1.2.1 Establish Project Control File .............................................................................................................................. 34 1.2.2 Establish Project Procedures.............................................................................................................................. 36 1.3 DEFINE THE PROJECT....................................................................................................................................................... 38 1.3.1 Develop Initial Charter/Enhancement Request................................................................................................ 38 1.3.2 Develop Project Approach................................................................................................................................... 41 1.3.3 Develop Quality Management Plan.................................................................................................................... 44 1.3.4 Develop Communications Plans......................................................................................................................... 46 1.4 DEVELOP HIGH -LEVEL WORK PLAN ................................................................................................................................. 48 1.4.1 Develop High-Level WBS .................................................................................................................................... 48 1.4.2 Develop Dependency Network ........................................................................................................................... 50 1.4.3 Estimate Effort ....................................................................................................................................................... 52 1.4.4 Develop High-Level Schedule............................................................................................................................. 54 1.5 COMPLETE INVESTMENT ANALYSIS .................................................................................................................................. 55 1.5.1 Complete Initial Risk Assessment...................................................................................................................... 55 1.5.2 Develop Initial SOW.............................................................................................................................................. 59 1.5.3 Confirm/Refine the Business Case.................................................................................................................... 61 1.6 CONFIRM READINESS TO PROCEED ................................................................................................................................. 64 1.6.1 Confirm Requirements/Business Owner View................................................................................................... 64 1.6.2 Obtain Initial Charter/Enhance. Req. Signoff.................................................................................................... 66 2.0
PLAN PROJECT............................................................................................................................................................... 69
2.1 DEVELOP PROJECT MANAGEMENT PLANS ........................................................................................................................ 70 2.1.1 Develop Organizational Chg Mgt (OCM) Plan ................................................................................................. 70 2.1.2 Develop Procurement Plan.................................................................................................................................. 71 2.1.3 Develop Transition Plans..................................................................................................................................... 74 2.1.4 Develop Resource Management Plans............................................................................................................. 76 2.2 REFINE WORK PLANS AND BUDGET ................................................................................................................................. 80 Originator: One IT PPM Team Page 4 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 2.2.1 Refine Project Approach ...................................................................................................................................... 80 2.2.2 Refine Work Plans................................................................................................................................................ 82 2.2.3 Refine Risk Management Plans.......................................................................................................................... 84 2.2.4 Refine Resource Requirements.......................................................................................................................... 86 2.2.5 Refine the SOW..................................................................................................................................................... 88 2.3 CONFIRM READINESS TO PROCEED ................................................................................................................................. 90 2.3.1 Confirm Requirements Specification Signoff.................................................................................................... 90 2.3.2 Obtain Final Charter Approval............................................................................................................................. 92 2.3.3 Conduct Formal Kick -off....................................................................................................................................... 93 3.0
EXECUTE PROJECT....................................................................................................................................................... 97
3.1 MANAGE PROJECT E XECUTION ........................................................................................................................................ 98 3.1.1 Acquire/Release Facilities & Equipment........................................................................................................... 98 3.1.2 Acquire/Release Team Members..................................................................................................................... 100 3.1.3 Direct & Coordinate Plan Execution................................................................................................................. 103 3.2 MANAGE PROJECT INFORMATION ................................................................................................................................... 104 3.2.1 Maintain Project Records................................................................................................................................... 104 3.2.2 Distribute Project Information............................................................................................................................ 106 4.0
CONTROL PROJECT.................................................................................................................................................... 109
4.1 MONITOR AND CONTROL THE PROJECT ......................................................................................................................... 110 4.1.1 Monitor and Control Scope................................................................................................................................ 110 4.1.2 Monitor and Control Schedule/Costs............................................................................................................... 113 4.1.3 Monitor and Control Risks.................................................................................................................................. 115 4.1.4 Monitor and Control Issues................................................................................................................................ 117 4.1.5 Monitor and Control Quality............................................................................................................................... 119 4.2 CONDUCT PROJECT REVIEWS........................................................................................................................................ 124 4.2.1 Conduct Status Reviews .................................................................................................................................... 124 4.2.2 Coordinate Architecture Reviews ..................................................................................................................... 128 4.2.3 Coordinate Metrics Workshops......................................................................................................................... 130 4.2.4 Coordinate Security Reviews & Certification.................................................................................................. 131 4.2.5 Coordinate PQA Reviews .................................................................................................................................. 133 4.2.6 Lead Gate/Tollgate Reviews ............................................................................................................................. 135 4.2.7 Support Operations Reviews............................................................................................................................. 140 5.0
CLOSE PROJECT.......................................................................................................................................................... 143
5.1 FINALIZE DELIVERY......................................................................................................................................................... 144 5.1.1 Finalize Implementation..................................................................................................................................... 144 5.1.2 Finalize Transition............................................................................................................................................... 145 5.2 CONDUCT FINAL PROJECT REVIEW................................................................................................................................ 146 5.2.1 Administer Major Release Survey.................................................................................................................... 146 5.2.2 Conduct Wrap-up Session................................................................................................................................. 148 5.2.3 Prepare Closure Report..................................................................................................................................... 150 5.3 PERFORM ADMINISTRATIVE AND FINANCIAL CLOSURE................................................................................................... 152 5.3.1 Release Resources.............................................................................................................................................. 152 5.3.2 Complete Financial Closure................................................................................................................................ 153 5.3.3 Close & Archive Records................................................................................................................................... 156
Originator: One IT PPM Team Page 5 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
This Project Management Process Guide is intended for use on all types of IT projects. Its purpose is to guide project managers in the execution of project management processes and should be used in conjunction with the Solution Delivery Methodology (SDM) Process Guides developed for specific project types. While this document presents processes for managing projects in a disciplined and consistent manner, it is not a “cookbook”, nor is it a definitive discourse on project management. It is assumed that you have had at least basic project management training and that you are familiar with the Solution Delivery Methodology Guides.
Portfolio Management
Programs and projects originate within the Portfolio Management process. Once approved, they are funded via an Appropriations Request and enter the execution phase. Additional information on Portfolio Management is accessible on their web site http://www.itonline.ford.com/epmo/portman.htm?ID=node3 .
Portfolio Management Process Flow
Originator: One IT PPM Team Page 6 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Definition of Project Management
Project management is defined as directing the activities associated with executing a project, while controlling limited resources efficiently and effectively, and ensuring the project’s end goal is achieved successfully. As shown in figure 1.1 below, projects can be viewed in three dimensions. The Project Life Cycle axis describes the work to be done to deliver the product. The Project Management Core Processes axis delineates the five processes that must be performed to plan, manage and conclude projects. The Project Management Knowledge Areas axis lists ten areas of responsibility that must be addressed by the project manager while managing the project. Each of the three dimensions is discussed in more detail below.
Typical Project Life Cycle
Project Management Knowledge Areas
Support Resources Implement
Procurement Cost
Build
Organizational Impact
Time Scope
Design
Communications Quality
Integration Analysis Risk ID & Assess
Initiate
Plan
Execute
Control
Close
Project Management Core Processes Figure 1.1 – The Three Dimensions of Project Management
Originator: One IT PPM Team Page 7 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Project Management Core Processes
Project management processes as defined by the Project Management Institute (PMI) are shown in figure 1.2 below. Initiate Project Plan Project
Control Project
Execute Project
Close Project
Figure 1.2 - Core Project Management Processes
Originator: One IT PPM Team Page 8 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Project Management Knowledge Areas
The ten project management knowledge areas, shown in figure 1.1 and described below, represent what the project manager manages while executing the project management processes.
Integration Management:
Ensure that all elements of the project are coordinated properly and included in project plans. This includes hardware, software, networks, training, etc.
Scope Management:
Ensure that the project includes all of the work required and only the work required to complete the project successfully, including scope planning, scope definition, scope verification and change management.
Quality Management:
Ensure that the project will satisfy the requirements that have been agreed and that quality assurance and quality control processes are completed.
Time Management:
Ensure timely completion of the project by defining and managing tasks to be completed, the sequencing of work, the resources assigned, task durations, and the project schedule.
Cost Management:
Ensure that the project is completed within the approved budget by estimating, monitoring and controlling project costs.
Risk Management:
Identify, assess and mitigate project risks associated with factors such as new technology, very tight schedule constraints, lack skilled resources, and readiness of the user organization to accept the change.
Communication Management:
Provide timely and appropriate generation and dissemination of project information to management and all other stakeholders to ensure that their expectations are consistent with the realities of the project.
Organizational Impact Management:
Identify organizational changes that must occur and develop appropriate communication and training programs for impacted departments and staff to support the new system or change.
Resource Management:
Provide effective leadership and management of the project team, including project organizational planning, Staff Requisition, and team development.
Procurement Management:
Acquire goods and services from outside vendors as needed by planning procurement, preparing requests for quotes, making source selections, and negotiating and administering contract negotiation.
The Project Life Cycle
IT projects are divided into stages that make up the project life cycle. Each stage has specific processes and deliverables. For example, the processes and deliverables for Classic Systems Development Life Cycle (shown here) are described in the Classic Systems Development Solution Delivery Methodology Guide. Similar guides are planned for different types of projects, including Object Oriented Development and others.
PM Alignment to
As shown in figure 1.3 below, project management activities overlap with and enhance the processes defined in a typical solution delivery life cycle.
Originator: One IT PPM Team Page 9 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Typical Project Life Cycle
Project Life Cycle
Initiate
Plan Core Project
Execute
Mgmt Processes
Control
Close
Figure 1.3 – Project Management alignment to Project Life
As this diagram shows, elements of Execute and Control occur at each stage of the project. It is, therefore, recommended that the reader refer to the Execute and Control sections throughout the project life cycle and take action, as needed, to acquire resources, monitor and control project performance, and review and approve project deliverables.
Originator: One IT PPM Team Page 10 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Key Principles will be placed in this section Key Principles of Project objectives must be SMART Project Project objectives must be Management Specific -- clear and precise Measurable -- quantifiable Achievable – realistic Relevant – linked to business needs Time-based – defined by clear deadlines
Understanding and managing requirements is crucial Each requirement should be traceable to a specific project objective described in the Project Charter. The ability to trace planned and completed requirements assures that the delivered product will satisfy Customer needs and will not include inappropriate or extraneous functionality.
Planning is everything and ongoing The single most important activity that project managers engage in is planning -detailed, ongoing, systematic, team-involved plans are the true foundation for project success.
Control is a necessity, not a luxury Schedule and cost overruns, issues that go unresolved, risks that are not mitigated, and changes that are made to plans and deliverables without adequate review and approval will inevitably lead to project failure. This is why rigorous monitoring and control is an absolute necessity and a key role of the Project Manager.
Customers must be part of the process Customers demand the right to approve deliverables. Along with that authority comes the responsibility to be active participants in the project. It’s the Project manager’s job to ensure that Customers understand what is expected of them and that they are kept informed and active through out the project life cycle.
Providing an honest assessment of project health is critical Assessing project health opening and honestly on a regular basis is critical to the successful management of the Ford IT portfolio. For sponsors and management to make the right decision about a project's future, it must have accurate information about the state of that project.
We know what works, just do it We know what works. Methodologies like those described here today ensure that standards and best practices are built into project plans and deliverables. Not only do these methodologies support quality, they help minimize rework.
Metrics should be collected throughout the project life cycle Metrics should be collected throughout the project life cycle and used to help manage and evaluate productivity, timing, cost, and quality. A good metrics program will enable better trend analysis and more effective process improvement. The following are the OneIT recommended metrics to be captured and reported Function Points (FP)
Function Points are a measure of the functionality delivered by an application and provide an objective quantification of a
Originator: One IT PPM Team Page 11 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Points (FP)
an application and provide an objective quantification of a project's size. They may be used by the Project Manager to help evaluate project scope, determine resources required, estimate project effort and duration, and prioritize deliverables. The Project Manager will work with a Metrics Specialist to schedule and conduct workshops to generate Function Point counts. Often three separate Metrics Workshops will be conducted for a project: Initial, Interim, and Final. An "ad hoc" Function Point Workshop is also an option for very large projects or special situations.
Function Points per Staff Month
Function Points per unit of work is a measure of productivity. Function Points are estimated during the Analysis and Design stages, and a final count is done at the end of the Build stage.
Time to Market, TTM per 1000FP
Time to Market is a measure of speed of delivery. TTM per 1000 Function Points provides a way to evaluate speed of delivery for projects of differing sizes.
Schedule Variance
Start and End Dates for each stage are documented in the work plan. These are compared with the estimated dates to determine schedule variance for each stage and for the project as a whole.
Cost Variance
Cost variance is used to evaluate how well the project met budget goals. Cost variance is calculated by subtracting actual cost of the project from budgeted cost.
Cost per FP
Cost per Function point is a metric that considers project size when evaluating the cost of development efforts. The impacts of variables such as platform and complexity are considered and used to help with comparisons.
Support Cost per FP
The maintainability of an application is measured by dividing support costs by the number of function points calculated for the supported application.
Assignment Scope
Assignment scope is defined as the number of function points supported divided by the number of full-time equivalents supporting the application.
Defects per 1000FP
Defects are non-conformance to requirements. They are identified during Technical Inspections, QC Testing, and User Acceptance Testing. Defects are classified by severity. Defects per 1000 Function Pts provides a scalable measure of quality for projects of differing sizes.
Incidents
Incidents are post-launch defects. Incident data is captured and recorded on an on-going basis after solution implementation. Incident data includes severity, date reported, date closed, and causal factor. Some metrics reported by ADS include Release Quality, Number of Serious/Critical Incidents, Incidents Exceeding the SLA, Mean Time to Repair, and Mean Time Between Incidents.
NCI per Review
Non-compliance issues are identified in the Process Quality Assurance (PQA) reviews. The scores are a measure of adherence to process. They can be reviewed with other metrics to help evaluate the impact to the project of noncompliance to process.
Satisfaction Surveys
Project team members, sponsors, and end users are surveyed
Originator: One IT PPM Team Page 12 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Surveys
at the end of the project to evaluate project performance and satisfaction with deliverables. Other surveys are conducted to evaluate satisfaction with training and with implementation of the project solution. Application surveys are conducted on a time-driven basis to evaluate user and sponsor satisfaction with the application.
Project Variables
A number of variables need to be considered when evaluating project metrics. Some important variables include: • Technology Platform • •
Development Type (New Development, Enhancement, Purchased Package, etc) Complexity
The following diagram illustrates the metrics collected during a typical project's life cycle:
ID &
Support & Analysis
Assess
Design
Build
Implement
Function Points per Staff Month
Maintenance Support Cost per Function Point
Time to Market (TTM) and TTM per 1000 FP Assignment Scope (FP/FTE)
Schedule Variance Cost Variance (Budgeted less Actual Cost of Work) Cost per Function Point
Post Launch Incidents
Defects per 1000 FP (Defects identified during inspections and testing) NCI per Review (Non-compliance issues identified in a Process Quality Assurance Review) Customer Satisfaction Scores
Figure 1.4 Metrics captured over the project life cycle
Originator: One IT PPM Team Page 13 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide See the appropriate SDM Process Guide for more details on that roles and responsibilities that are relevant to a specific project type.
Purchased Package Selection and Implementation (PPSI)
Process changes and special considerations have been incorporated to address the selection and implementation of purchased products, including:
• •
Procurement-related processes include considerations for working with 3 rd party vendors. A special concern with any implementation performed by 3rd party vendors is that the project team must pay special attention to ensuring that requirements are fully understood and incorporated into the solution. Classic SDM addresses this by explicitly including the Vendor/Supplier in Review Processes (ARB, PQA, Gate/Tollgate, Validate Requirements, Validate Design).
•
IT Management Tools
Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Precommitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information. The following picture depicts management tools currently in place for the tracking of applications and IT projects within the ADS organization. A description for each of the tools follows.
§ WebTracs: WebTracs is a web-enhanced budget and cost tracking application intended to assist Project Managers and Supervisors in the creation and updating of detailed Business Plan information. Strategic and Finance Planners will use the information to create Monthly and Quarterly Summaries. WebTracs is closely tied to ITMS. A project must first be entered in ITMS with high level business value information, the detailed costs will entered in WebTracs. The objectives of Web Tracs include:
Originator: One IT PPM Team Page 14 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide o Provide a web-enabled tool for IT personnel to track the complete project cost breakdown – calendarized by month, and separately track Capitalized Costs and Expenses. o Provide consistent information between financial reports produced by Strategic Planners and reports produced by Finance Planners. § ITMS: The IT Management System is a single common repository of all Initiative, Program, Project, and Application Portfolio data enabling effective management of IT’s work across the enterprise. Objectives of ITMS include: o To Deploy a Global Common Project and Application Repository to support the One IT Business Processes. o Support FMC Corporate litigation by serving as the system of record for all applications owned and supported by Ford Motor Company. § Prosight: Prosight is a Portfolio Management Tool, integrated with ITMS, which supports choosing, executing, and evaluating IT project and applications. The concept of Portfolio Management encourages organizations to evaluate the business value to the business when making business decisions. The objective of Prosight is to enable effective portfolio management by providing analytical capabilities to view project and application data based on key business drivers; thereby supporting fact based business decisions. The Prosight URL is http://www.itonline.ford.com/it_tools/Prosight.html. Refer to the ProSight tutorials named ProSight Form Data Entry and Project Manager ProSight Data Entry on the same web site for instructions in the use of Prosight. § IT Billing System: IT Billing will provide IT’s business partners with all their billing detail in an online, web-based system. This system will receive detailed billing data from the various IT departments, consolidate all charges, and create a single “IT Billing” Journal Entry for each business partner. The system will automatically feed the Journal Entries into PeopleSoft/MICS. The major objectives of the IT Billing System is to redistribute internal costs and influence behavior by providing a consolidated, detailed IT bill to the Business Partners. § RMS: ADS Resource Management System will ensure smooth operation of the Application Development Services organization resource management model for both Ford and agency personnel. The system will enable Ford to further develop and strengthen its core Information Technology competencies. Objectives include: o Ensure smooth operation of the ADS resource management model for both Ford and agency personnel. o Manage resource acquisition placement, and release process. o Manage skills inventory of ADS project resources to meet business and IT strategy demands. . o Provide a time keeping, and financial reporting solution. o Establish measures of success for the operational ADS Resource Management tool. § MRS: MRS is the Application Development Services (ADS) metrics repository that provides the functionality for reporting and recording measurements and metrics related to the Software Development Life Cycle. The planned enhancements encompass the collection and reporting of application development, enhancement and maintenance project data used to produce metrics related to productivity, cost, timing, sizing, quality, process assurance and customer satisfaction metrics. Objectives include: o Automate and centralize all ADS project, product and process metrics as input for use in making timely data driven decisions to maximize customer satisfaction, minimize the overall engineering effort and schedule, and to minimize the number of defects produced.
Originator: One IT PPM Team Page 15 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide o Provide metrics that will help to identify opportunities for process improvement and to assess and measure the impact and return on investment of process changes made.
o Include as a minimum, size, effort, estimation, productivity and schedule metrics, technical inspection, detailed defect and customer feedback metrics, and adherence to process metrics.
Originator: One IT PPM Team Page 16 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
GAO Audit Guidelines
The Ford General Auditor's Office (GAO) requires that all documentation (electronic and paper) adhere to security guidelines and retention policies. Also note that electronic documents/data should not reside on desktops, but in an agreed repository (e.g.; electronic project control book on a shared network drive, PVCS, eRoom, etc.).
Project Authorization Requests and Purchase Orders
As indicated in the Ford Financial Manual procedure #55-10-11, no commitments may be made until the overall program (or a long-lead request for the program) of which the action is a part has been approved. For most operations, funding for the specific action is authorized by an approved "Project Appropriation Request / PAR", including a standard set of project detail sufficient for control. Funds for the following items are to be requested through use of appropriations requests (or lease requests):
• • •
• •
• •
• • •
Purchase, from outside sources, of "off-the-shelf" computer software programs. Development of "Internal-Use" custom Ford computer software programs developed by Ford, agency, outside purchased services or any combination of these resources. Acquisition or modifications of fixed assets (land, building, equipment, vehicles, material handling equipment, tooling, etc.), and related expenses including freight and rearrangement costs. Substantial items that are of a fixed asset nature, but for accounting purposes are expensed. Major repair, maintenance, and overhauling of equipment, including all nonrecurring requests or requests that recur at infrequent intervals. (An infrequent interval is a lapse of time greater than a year.) Leases that are of fixed asset nature (represents a greater than 1 year commitments of payment), even though it may expensed for accounting purposes. Supplier agreements involving contingent liabilities (as defined by FM 55-10-70). If a payment of a previously approved contingent liability becomes necessary, a separate project request authorizing payment is required. Acquisition or granting of easements, right of way, or licenses. Acquisition or granting of options to purchase or lease (including leases of office space from Ford subsidiaries). Disposal of capitalized assets.
Actions Not Requiring Appropriation Request - Appropriation requests are not required for the following types of items:
•
•
Items normally included in overhead expense accounts and budgets, such as normal maintenance, preventive maintenance, service contracts, perishable tools, launch costs, training, fire/security cover not of an incremental nature, and similar continuing or recurring items. Items are to be capitalized for the first time upon acquisition. Expenses (freight, dismantling, installation, and similar costs) associated with intra/intercompany fixed asset transfers may be documented with use of an Intercompany Buying Authority, to be approved by the local Controller.
Originator: One IT PPM Team Page 17 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
•
•
Items less than $25,000 at the discretion of the Controller/Finance Manager, provided that an alternative system provides comparable control and that the action is approved by the appropriate approval authority. In developing project detail, line items of less than $25,000 need not be separately identified. For the appropriation request, such items may be grouped in major categories such as building improvements, machinery equipment, office furniture, etc.
Note that for a Purchase Order (PO) can be released by Ford Purchasing, the following steps must occur:
• • • • • •
Cost information must be entered by an authorized MEARS user in the PAR. An Authorized MEARS user (Controller/Finance Manager) reviews and approves the PAR. Cost information from the approved PAR is automatically transferred from MEARS to an intermediate application named PCPAS (North America) or COIN (Europe). The PO is created by the Purchasing Buyer in the purchase order application (CPARS, eVerest, or equivalent) and submitted for approval. A Ford Property Manager will review the PO, confirm that the cost is covered by an entry in PCPAS or COIN and approve/reject the PO. In either case, the Purchasing Buyer will be notified. If approved, the Purchasing Buyer will release the PO. If rejected, the Purchasing Buyer will notify the user that the PAR must be modified to address any issues.
The use of appropriation requests is described in the Financial Manual procedure #5510-11 which is located at http://www.dearborn.ford.com/fm/accntng/apfund55/apfprc55/5510/551011.html. The Project Appropriation Request / PAR description is located in Procedure 55-10-10 of the Ford Financial Manual which is at http://www.dearborn.ford.com/fm/accntng/apfund55/apfprc55/5510/551010.html.
Process Participant Roles For each task, the main participants are listed. Note that the roles in SDM are generic and not associated with an organization. For example, depending on the type and size of a project, the role of Business Analyst may be played by someone from the PTG organization or from the Practice. The bolded participant is the key person responsible for that task. Competency / Competency/Role Role Acronym
Responsibilities
Job Family
6-Sigma
6-Sigma Blackbelt
This is a person trained in 6-Sigma DMAIC and DFSS General IT processes. The 6-Sigma Blackbelt will work with the project Management team in the design of business processes and ensure that those processes will achieve Customer CTQ's. It is expected that all Business Analysts will eventually have Greenbelt or Blackbelt certification. Until a critical mass of 6-Sigma certified Business Analysts has been achieved, the Classic SDM Guide will treat the 6-Sigma role as an additional consultant on the project team.
ADSBusiness
ADS Business Manager
Coordinates service rates, approval of project costs against General IT account codes prior to project execution and billing of incurred Management project costs to account codes.
Originator: One IT PPM Team Page 18 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
ADSMgt
ADS Management ADS Manager with profit and loss responsibility for a project
General IT Management
AMCoord
Architecture Management Coordinator. Ensure that the project team adheres to Ford corporate architecture principles.
Architecture
APM/LOB
Application Portfolio Coordinate application and support activities for a portfolio of General IT Manager/ LOB applications, typically for one line of business. Management Manager
Review architecture selection for compliance with Ford architecture principles and standards.
AppDataAdmin Application Data Administrator
This is the person who has oversight responsibility for application data, including data integrity, adherence to the retention period as defined by GIS1 standards.
AppOwn
Customer with ultimate responsibility for application and N/A related business processes. This person is registered on the ACR as the application owner.
Application Owner
N/A
AppSecAdmin Application Security This is the person who administers security for an application N/A Administrator and defines the type of access allowed. AppSupr
Application Supervisor
Provide oversight for maintenance of one or more applications.
General IT Management
AppTechArch
Application Technology Architect
Plan and design of application platform technology patterns, usage standards, and guidelines used to implement IT solutions. Extend existing architectures to satisfy changing application needs.
Architecture
BusA
Business Analyst
Work with Customer to identify and documenting requirements, perform business process design, measure process capability, and perform Acceptance Test with Customer.
Business Analysis/ Reengineering
CDBA
Corporate / Data Center Database Administrator
Install and configure database products.
Database Administration
CDM
Capacity Demand Works as a liason between with project teams and the Data Management (CDM) Center to select and allocate hardware and software for all Analyst technical environments (e.g.; development, QC, Education, Production, Support) in a timely manner.
Cust
Business Customer(s)
Operations
Person(s) knowledgeable of all requirements and business N/A processes in a subject area, and empowered to define and accept solution. It is expected that the Customer will actively participate throughout the project and will sign-off on designated SDM deliverables. See the section titled " Customer Involvement In Projects" for further information.
DBA
Data Base Administrator
Provides expertise, and performs physical database design, administration and related planning.
Database Administration
DMT
Data Model Team
A peer review team made up of analysts and the lead Information Architect from a Practice that reviews proposed
Architecture
Originator: One IT PPM Team Page 19 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
data model changes for compliance with Ford data standards. These individuals also coordinate cross-application database changes. Espon
Executive Sponsor(s)
IT and Business Sponsors who fund the project and actively participate throughout the life cycle.
EUSupport
End User Support Analyst
Provide consulting services, implementation services, End User production, operational and systems support for distributed Support computing at all locations; serves as a liaison between clients and vendors or other technical groups to resolve client problems. Also provide feedback to corporate application owners on user-base issues and establishing effective support processes Across it support organizations to ensure timely resolution to end user technology issues.
Facilities
Facilities Analyst
Coordinate overall planning, deployment and operations of facilities within computer centers.
FGTI
Intellectual Property Review application and/or business processes and provide attorney from Ford Customer with advice/guidance and support with respect to Global applying for patent. Technologies, Inc.
N/A
FinanceAnal
Financial Analyst
Allocate and release funding for projects (e.g.; hardware, software and services) on behalf of a business area. This person may also assist with development of project cost estimates.
General IT Management
GAO
GAO Prevention Control Specialist (GAO ACR reviewer)
Review ACR documents with the ICC and Application Owner General IT to ensure that the application adheres to Ford security and Management maintenance standards.
ICC
Internal Controls Coordinator
Provide support to project teams that are developing an ACR General IT and/or ICR. This person will provide ongoing ACR coaching, Management review the ACR drafts, and present them to the GAO along with the Project Manager and Application Owner.
ImpA
Implementation Analyst
Develop deployment-related materials, implementing the solution and providing training.
InfoArch
Information Architect
Plan and design data and its relationship to business Architecture processes to ensure correct information boundaries, integrity, security, accuracy and the proper use of information.
InfraArch
Infrastructure Architect
Specifies the computing infrastructure and services needed to Architecture support the development and deployment of the solution, including the proper mix of commercial off-the-shelf products (COTS), hardware, and networking.
IntTest
Systems Integrator Lead integration and testing of application components into a Solutions and Integration completed application. Development/QA Tester
Inventor
Inventor
The originator of concepts, processes or products/software.
N/A
IRR
Independent Risk Reviewer
Evaluate project risk (prior to project start) based on a predefined set of questions.
Project/Program Management
ITET&D
IT Learning – Create application-specific training materials as well as Education, Training provide the training on an as-needed basis. and Development (ET&D)
Originator: One IT PPM Team Page 20 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
N/A
Facilities
End User Support
End User Support
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
KE
Knowledge Engineer
Develop strategy, provide expertise and long-range planning Knowledge in the areas of it knowledge acquisition, capture, analysis, Management dissemination, retention and reuse efforts. Determines relevant sources of it information/knowledge in support of project requirements and provides guidance to implement global information standards as required within project specifications.
LDevl
Lead Developer
Guides and oversees development of application software components.
Solutions Development/QA
Metrics
Metrics Specialist
Ensure consistent metrics gathering. The specialist will collect, review, analyze, and report program/project metrics.
Process and Methodology
NetE
Network Engineer
Individual/group with responsibility for all aspects of the Network networks for a geographical area and the impacts to the rest Engineering of the global network. Assists with the design, evaluation, selection, and integration of networking technologies to meet the needs of the business.
NLM
Next Level Manager The manager directly over the Project Manager from a reporting perspective.
OGC
Office of General Counsel Attorney
Provide legal counsel for legal transactions such as contracts, N/A as well as advice and guidance with respect to legal issues, Office of General Counsel (OGC) Document and record Suspension Orders, etc.
Oper
Data Center Operations
Perform daily data center operations support activities (backup, restore).
PGM
Program Manager
Direct all program -related activities. Initiates, plans executes, Project/Program controls, and closes program, ensures requirements are Management understood across all project teams, prioritized and that what is delivered meets the agreed requirements. Provide oversight in the management and execution of multiple projects or projects that are viewed as large and/or complex.
PM
Project Manager
Direct all project-related activities – initiates, plans executes, Project/Program controls, and closes project, ensures requirements are Management understood, prioritized and that what is delivered meets the agreed requirements.
PQA
Independent Process Quality Assurance Coach
Process coach who will provide coaching with respect to Process and methodology selection, related processes and templates. Methodology They will also participate in project/program reviews to ensure adherence to process quality assurance guidelines.
PracticeMgr
Practice Manager
Provide application management for a particular business General IT function, spanning the entire software development life cycle. Management
PSDevl
Production Support Support and maintain application – performs production Developer/Analyst support, participates in incident/enhancement design, constructs, tests, and documents application code. Ensures the completeness of changes as the version specialist; Coordinates build and packaging for a project as the build specialist; performs SCM audits and reports the results.
Purchasing
Buyer from Ford Purchasing
QCLead
Quality Control Test A senior tester, with an understanding of test processes, templates and tools who may lead the development of the
General IT Management
Operations
Solutions Development/QA
Works with project teams to acquire vendor-provided N/A information, RFP/RFQ, and negotiate the acquisition of goods or services.
Originator: One IT PPM Team Page 21 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Solutions
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym Lead
Responsibilities
Job Family
Quality Control Test Plan and Strategy.
Development/QA
QCTest
Quality Control Test Provide testing expertise and guidance, develop QC Test Specialist Strategy and Plan, develop and execute both functional and system tests.
Solutions Development/QA
RDM
Resource Deployment Manager
The Resource Deployment Manager will manage a pool of General IT ADS resources to ensure that they are being highly utilized as Management well as deployed in a fashion that accounts for Ford's overall resource requirements Responsibility: assign resources; report resource utilization information to management
RS
Reuse Specialist
Develops strategies and leads implementation of knowledge- Process and capture, -retention and -reuse efforts on it projects. Methodology
SAE
Specialized Application Engineering
SCC
Security Control Champion
The security control champion is organization-specific and will General IT ensure that Ford's security needs are recognized and Management addressed in the implementation of policies, business processes and computer applications.
SCCB
Software Configuration Control Board
Group responsible for evaluating and approving/rejecting proposed changes to configuration items and for ensuring implementation of approved changes.
N/A
SCM
Project Software Configuration Management Specialist
Person responsible for coordinating and implementing software configuration management (SCM) for the project.
Solutions Development/QA
SCMTool
SCM Tool Administrator
Install, configure and support software configuration Solutions management (SCM) tools, process, and procedures to ensure Development/QA they are understood and followed .
SDevl
Software Developer Participates in design activity and constructs, tests, and Solutions documents application system code under the guidance of the Development/QA lead developer.
SecE
Security Engineer
SIE
Strategic Work with one or more project team members to test an Technology Infrastructure application to determine whether it is well behaved (e.g.; Analysis Engineering Analyst DLL's installed in correct location, DLL's are not over-written, (was called Ford etc.) and that it is compatible with the Ford Standard desktop. Systems Integration Center / FSIC)
SiteCRM
Site Client Relationship Manager
Manage the application and technical environments at a site End User as well as act a liason between the Customer and application Support development/deployment and support teams.
SME
Subject Matter Expert
Person with sufficient knowledge of a business process as to Business be considered an expert on the subject who will provide Analysis/ guidance on an as -needed basis. Reengineering
SolnArch
Solution Architect
Responsible for the assembly and integration of business processes, data, and application and infrastructure
Specialized Application Engineering
Provide consultation on enterprise security both within the organization and external business units. Provides assessment, vision, expertise, direction and guidance in the implementation of secure solutions.
Originator: One IT PPM Team Page 22 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Security Engineering
Architecture
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
components into optimal solutions that adhere to the Architecture Framework, principles, and standards. Stakeholder
Stakeholder
The term "Stakeholder" is project-specific and refers to any person who has a vested interest in the development and deployment of business processes and computer applications. These people will provide guidance to project team on an ongoing basis.
Steering
Steering Committee A group of individuals (e.g.; managers and subject matter N/A experts) who can provide oversight and guidance to a project/program. From a reporting perspective, the Steering Committee reports to the Executive Sponsor and has the project team report to it on a periodic basis. These people will review project status on a periodic basis; provide guidance on an as -needed basis.
Supplier / Vendor
Any 3 rd party or a Company outside of Ford that either directly or indirectly N/A representative of a provides hardware, software, goods or services to or for Ford. 3rd party that is either supplying software or software services
SysDesAn
Systems Designer/Analyst
Individual who oversees design of business processes, application architecture, user interface and system design.
Systems Design/Analysis
SysE
Systems Engineer
Individual who participates in hardware/software insfrastructure design and installs/configures the related products. This person is a aubject matter expert within specialty domain on future technology, industry trends and direction; Responsible for end-to-end solutions within a specific application area; e.g. Plant floor, CAE.
Systems Engineering
Team
Project Team
In general, these are all members of a project team.
N/A
Tech
Development Tools Individual with expertise in development Tools. Technical Specialist, Technology Analyst
UsabSpec
Usability Specialist Evaluates an application's ease of use and suggests usability Solutions improvements. This individual can plan usability testing; Development/QA execute usability testing; provide usability feedback after testing; provide coaching on an ongoing basis.
WebDesigner
Web Designer
A member of the "Web Creative Services Group" who will assist in the design and development of web-based user interfaces.
N/A
Technology Analysis
Solutions Development/QA
Consult the One IT Competency Center Website at http://www.itonline.ford.com/home/it-prof/it-comp/ for additional information.
Originator: One IT PPM Team Page 23 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 24 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.0
Initiate Project Project Management Processes
Project Proposal Executive Summary Initial Business Case Change Program Request Charter
Initiate Plan Execute
Solution Delivery
Control
Methodology Close
Inputs to Initiate Project Overview
At the start of any project, there will be a variety of ideas and opinions about its purpose and scope, what the final product will be, and how the project will be carried out. Project Initiation is concerned with taking these ideas and intentions and developing them into a formal, planned, resourced and funded project. The purpose of Project Initiation is to define the overall parameters of the project, develop initial project plans, and define the appropriate project management and quality environment required to complete the project. Upon completion of Initiation, the sponsor(s), business analyst, and project manager should have enough information to make a go/no-go decision.
Process Contents
Objective 1.1
Prepare for the Project
1.2
Establish PM Infrastructure
1.3
Define the Project
Note Refer to PM Processes "3.0 Execute Project" and "4.0 Control Project" for processes such as "Maintain Project Records" or "Conduct Status Reviews" for process steps that must be carried out across all five PM Processes (Initiate, Plan, Control, Execute, Close).
1.4
Develop High Level Work Plan
1.5
Complete Investment Analysis
1.6
Confirm Readiness to Proceed
Process Steps 1.1.1 1.1.2 1.1.3 1.1.4 1.2.1 1.2.2
PM Deliverable
1.3.2 1.3.3 1.3.4 1.4.1 1.4.2 1.4.3 1.4.4 1.5.1 1.5.2 1.5.3
Confirm Project Readiness to Start Identify and Engage Stakeholders Engage Project Start-up Team Develop Start-up Work Plan Establish Project Control File Establish Project Procedures Develop Initial Charter/Enhancement Request Develop Project Approach Develop Quality Mgmt Plan Develop Communications Plans Develop High-Level WBS Develop Dependency Network Estimate Effort Develop High-Level Schedule Complete Initial Risk Assessment Develop Initial SOW Confirm/Refine the Business Case
1.6.1
Confirm Requirements/BOV
Bus. Owner View Signoff
1.6.2
Obtain Initial Charter/Enhance. Req. Sign-off
Charter Approval Signoff
1.3.1
Originator: One IT PPM Team Page 25 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Readiness Confirmation Stakeholder Assessment Resource Request/Roster Work Plan for Initiation Project Control File Setup Procedures/Logs Started Commitment Level Charter Methodology/Approach Quality Mgmt Plan Communications Plan Initial Work Breakdown Dependency Network High Level Estimates High Level Schedule Risk Assessment/Plan SOW Financial Scope
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.1
Prepare for the Project
1.1.1
Confirm Project Readiness to Start
The purpose of this process step is to ensure that the project is ready to start by confirming that a record exists for the project in ITMS, RMS and MRS, an initial SOW has been prepared and forwarded to the ADS Business Office, funding has been provided and that required inputs are available. Required inputs include the following: •
The original proposal or application change request(s) that precipitated the project. The high-level business case that was used to justify initial funding for the project (not applicable if the project is the result of change requests being bundled into a project that will lead to a new application release. A Project Scalability Questionnaire that provides a relative sizing for the project. Where appropriate, a Program Charter (i.e., where the project is part of a larger initiative or program).
• • • Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
•
The key considerations include:
• • • • • • •
Diagram
Is the original project proposal or application change request available? Was a high-level business case created to justify project funding? Has funding been provided? Has an initial SOW been created and forwarded to the ADS Business Office? Is the relative size of the project known and documented in a Scalability Questionnaire? Is the project part of a larger initiative or program? The Project Appropriation Request should identify expected services as well as hardware/software costs.
Reference the introductory section in this guide titled "Project Authorization Requests and Purchase Orders" for further information on Project Appropriation Requests / PARs and Purchase Orders POs.
No diagram created for this process step.
Process Tasks No 1
Task Name
Description
Confirm creation of Project Appropriation Request
Confirm that the Project Appropriation Request / PAR has been created and approved. The primary purpose of the appropriation system is to control the Company's expenditures for fixed assets including capitalized facilities and tooling as well as items of fixed asset nature (such as leases with greater than one year payment commitments) even though they may be expensed for accounting purposes. Company management exercises control of the appropriation system by means of the Corporate Cash Flow, the quarterly forecast of facility and tooling spending, and the review of individual funding requests. The principal document in the review of individual funding requests is the appropriation request, and is intended to provide management with a
Originator: One IT PPM Team Page 26 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants PM, PracticeMgr, FinanceAnal
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide uniform presentation of requests for funding. The Project Appropriation Request is the principal document used in the review of individual funding requests, which are intended to provide management with uniform and organized information on expenditure proposals. Mechanized Appropriation Request System / MEARS is the required method to create a Project Appropriation Request / PAR. The MEARS website address is http://www.finance.ford.com/mears/index2.html. 2
Confirm creation of initial SOW and project funding.
Confirm that the initial SOW has been created and forwarded to the ADS Business Office and that the project is funded. If funding has not been resolved or the SOW has not been created and forwarded, ensure that the process titled "Develop Initial SOW" is executed before proceeding. Note: This process assumes the project is being done within ADS. If this is not the case, the process will need to be tailored so that the SOW is forwarded to the appropriate area.
PM, PracticeMgr
3
Confirm Six Sigma Tollgate 0 (Recognize)
Confirm that the Six Sigma Tollgate 0 (Recognize) process has occurred. The Recognize tollgate ensures that:
PM, PracticeMgr, 6-Sigma
• • • • • •
An opportunity has been identified and has been identified as "green field" or "redesign" Primary goals have been identified Customer segmentation has been addressed Linkages have been established to Business Objectives and Customer Satisfaction Sign-off has been obtained from Executive, IT and Financial leadership A general budget has been established
4
Review the Business Case
Review the high-level business case used to justify and secure that funding or the change requests that have been bundled to make a new application release project. Note: A Business Case may not be required for enhancement requests to existing applications.
PM, BusA
5
Review Project Proposal or Change Request
Review the project proposal or change request(s) that precipitated the project to better understand the business need. Ask questions of the pers on who submitted the proposal or request as appropriate.
PM, BusA
6
Confirm Project Records Exist
Confirm that a record has been created for the project in ITMS, RMS and MRS. If not, ask the Business Analyst assigned to the project to create the appropriate records.
PM, BusA
7
Confirm that a Scalability Questionnaire is Completed
Confirm that a Scalability Questionnaire has been completed for the project. If it has not, work with the Business Analyst to Complete one.
PM, BusA
8
Complete a Sizing Profile
Complete a PQA Metrics sizing profile to identify the sizing category of your project as shown below. Note that this sizing profile is used as a guide to the solution delivery methodology deliverables that are required for each project category. The profile is located in the 232_PQA_Metrics_Project_Sizing_Profile.doc template.
PM, BusA
9
Engage Process Quality Assurance
Review the PQA web site: http://www.itonline.ford.com/sdm/classic/pqa/ to determine level of involvement required. If PQA involvement is required or desired, continue with steps 10-11.
PM
Originator: One IT PPM Team Page 27 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 10
Schedule Initial Meeting with PQA Consultant
The Project Manager schedules a meeting with the assigned PQA.
PM
11
Prepare PQA Waiver form
If the PM and NLM feel that the project should be exempt from PQA reviews and involvement, a PQA Wavier form must be completed.
PM, NLM, PQA
Tools/Techniques Summary Methods and Applications/Tools ITMS: http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Appropriation Request / PAR description located in Procedure 55-10-10 of the Ford Financial Manual which is at http://www.dearborn.ford.com/fm/accntng/apfund55/apfprc55/5510/551010.html MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_ Managers.doc
Inputs to Process 241_Project_Proposal.doc 242_business_case.xls 231_Scalability_Classification_Questionnaire 243_program_charter.doc RMS – http://www.rms.ford.com
Outputs Project Appropriation Request / PAR at the MEARS website http://www.finance.ford.com/mears/index2.html. 231_Scalability_Classification_Questionnaire ITMS Number at http://www.itms.ford.com/ RMS Record http://www.rms.ford.com/ Project Record in MRS http://www.ads.ford.com/mrs 232_PQA_Metrics_Project_Sizing_Profile.doc 239_PQA_Review_Report.doc 83_PQA_Waiver_Form.doc
Originator: One IT PPM Team Page 28 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients BusA, PQA, NLM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.1.2 Purpose
Identify and Engage Stakeholders
To ensure project success, the project manager needs to identify stakeholders early in the project life cycle, determine their needs and expectations, and manage and influence those expectations over the course of the project. Project Stakeholders are individuals , groups, or organizations that are actively involved in the project, or whose interests may be positively or negatively impacted as a result of the project. Stakeholders include, but are not be limited to:
• • • • • • •
The Project Sponsor or Sponsors, who provide funding and direction The Customer, who approves requirements, plans and deliverables Functional Managers of organizations that are impacted by the project End Users, who will use the product or service when it is delivered Suppliers, who will be impacted by/use the product or service Any organization involved in project review, approval or administrative processes, including Process Quality Assurance Full-time and part-time project team members who define and produce project deliverables
•
Representatives of the support functions that implement, train end users, and maintain the project deliverable The outputs of stakeholder analysis are used to develop project schedules and communications plans. Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations when identifying stakeholders are •
Who are the key stakeholders?
•
What organizations do they represent?
•
What is their importance to the project?
•
What role will they play on the project?
•
To whom do they report?
•
What strategy will be used to engage and communicate with them?
•
When is their participation anticipated?
The PM should work with stakeholders on the stakeholder assessment and get buyin from them. Diagram
No diagram provided for this process.
Originator: One IT PPM Team Page 29 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Identify Stakeholders
Work with the Business Analyst to identify and classify key stakeholders . Use the project proposal and concept documents as input to the process.
PM, BusA
2
Record Information About Key Stakeholders
Use the Stakeholder Assessment Matrix template to record the following:
PM, BusA
3
Use Stakeholder Information to Plan Project
Organization:
Identify the organization represented by the stakeholder
Name:
Provide the name of the stakeholder
CDSID
Provide the CDSID of the stakeholder
Phone:
Provide the phone number of the stakeholder
Reports To:
Identify to whom the stakeholder reports
Availability
Record the stakeholder’s availability as a percent of time available or as specific dates, if known.
Role on Project:
Describe the stakeholder’s role on the project.
Importance to the Project:
Assess the stakeholders importance to the project as H- High, M- Medium, or L- Low
Engagement Strategy:
Briefly describe the strategy for engaging and communicating with the stakeholder.
Use the stakeholder information to assess risk, develop the charter, plan meetings, and develop communications plans.
PM
Tools/Techniques Summary Methods and Applications/Tools Interview with Sponsor/Business Analyst Microsoft Word
Inputs to Process 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire Org Charts (if available)
Outputs 201_stakeholder_assessment_template.doc
Originator: One IT PPM Team Page 30 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients ESpon, BusA
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.1.3 Purpose
Engage Project Start-up Team
The extent to which the project team has been defined at the beginning of the project may vary. At a minimum the manager for the project and individuals who can provide support in preparing for the project should be identified. This might include representatives of activities responsible for implementing and supporting project deliverables and other subject matter experts who represent both business and technical concerns.
During project initiation, the project concept documents are reviewed to determine the roles required to staff the project. With the help of appropriate stakeholders (i.e., the sponsor(s), program manager, and business analyst), the project manager should identify the roles that are needed to define the project and the names of individuals who will fill those roles.
As the project progresses and more is known about project deliverables and timing, it may be necessary to identify and take on additional roles and resources. It is up to the project manager to ensure that these needs are recognized and addressed.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations when identifying team members are
• • • • • • Diagram
What knowledge/skills are needed to define the project? What knowledge/skills are needed to define requirements? What knowledge/skills are needed to define the solution? What knowledge/skills are needed to produce deliverables? What knowledge/skills are needed to validate deliverables? What knowledge/skills are needed to enforce standards?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Identify Skills Needed
Create a two dimensional matrix. List the skills/knowledge needed on the project – particularly in early stages – down one side.
PM, BusA
2
Identify Candidates
List the potential team members across the top of the matrix.
PM, BusA
3
Map Skills to Candidates
Mark the intersection between skills/knowledge and each candidate. Identify and close gaps.
PM, BusA
4
Obtain Required Resources
Request and engage resources required.
PM, Sponsor
5
Create a Team
Create a team roster identifying team members, their home
PM
Originator: One IT PPM Team Page 31 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Roster
organization, their role, and the amount of time that they will be available.
Tools/Techniques Summary Methods and Applications/Tools Skills needs assessment Microsoft Word Resource Request located at http://www.ads.ford.com/resman/
Inputs to Proce ss 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire 242_business_case.xls
Outputs Resource Request located at http://www.ads.ford.com/resman/ 203_team_directory_template.doc
Originator: One IT PPM Team Page 32 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Espon, BusA, Competency Center, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.1.4
Develop Start-up Work Plan
Purpose
Most of the work that goes on during the first stage of a project is exploratory in nature. The goal is to understand what needs to be done so that detailed plans can be developed to specify how and when it will be done. Therefore, at the end of project initiation, it is expected that the team will have a more detailed, but still high level work plan for the remaining stages. In the meantime, a plan is needed to direct the activities leading to this outcome.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations for developing the Initiation work plan are
• •
Diagram
Have timing constraints already been defined for Initiation? What is the availability of each resource assigned to participate in Project Initiation?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Identify Activities in Initiation
Identify the activities in project initiation, including those outlined in this process guide and any activities identified for the solution delivery methodology (if known).
PM
2
Identify Participants
Use the stakeholder Matrix and Team Roster to identify participants.
PM
3
Estimate Duration
Determine the availability of participants and estimate the duration of activities.
PM
4
Develop Schedule
Develop and publish a schedule detailing the timing of activities and assignments.
PM
Tools/Techniques Summary Methods and Applications/Tools MS Project
Inputs to Process 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire 201_stakeholder_assessment_matrix.doc 203_team_directory_template.doc
Outputs 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 33 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.2
Establish PM Infrastructure
1.2.1
Establish Project Control File
Purpose
Maintaining information about the project in an organized fashion facilitates new team member transition and creates a central point of reference for those developing project deliverables. Most importantly, it provides an audit trail documenting the history and evolution of the project -- documents produced, decisions made, issues raised and resolved, and correspondence exchanged.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations in establishing a Project Control File are
Diagram
•
What form of repository will be used (shared drive, eRoom, file cabinet)?
•
Who, besides the project team, should have access?
•
What will be done to protect sensitive/company confidential materials (if any) from external stakeholders (vendors and suppliers)?
No diagram provided for this process step.
Process Tasks No 1
Task Name
Description
Participants
Establish Project Control File
Decide how project records will be kept and where. The types of records to be maintained include, but are not limited to the following:
PM
• • • • • • • • • • 2
Set Up Version Control Mgmt Tool(s)
3
Maintain Project Records
The Project Charter and Addendums Project Plans Issue, Risk and Change Logs Change Requests Communications Plans Requirements Specifications Assignments Corrective Actions Approvals Procurement Documents Set up electronic control tool for the management of document and software versions. See Create Software Configuration Management section of the Solution Delivery Methodology Guide for suggested tools. Ensure that project records are kept current while at the same time maintaining a complete project history.
PM
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 34 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Shared Drive, File Cabinet or eRoom, PVCS (Program Version Control System) Note: If a shared drive is used, a predefined Control File structure can be downloaded from http://www.itonline.ford.com/sdm/ otherwise the team will need to set-up its own control book in PVCS or whatever other means is used.
Inputs to Process All Project Records
Outputs Project Control File
Originator: One IT PPM Team Page 35 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.2.2
Establish Project Procedures
Purpose
The purpose of this step is to ensure that project management procedures are established and communicated to the project team and stakeholders. This includes control logs, procedures for collecting status reports from team members and incorporating that information into status reports to be provided to team members and stakeholders.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
No key considerations
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Establish Project Logs
Using eTracker or MS Office files set up control logs for Issues, Risk and Change Management.
PM
2
Identify SCM Constraints
On software projects, identify and document any pre-existing constraints (e.g.; global requirements) with respect to software configuration management (SCM) products and procedures. Note: For pre-existing applications, the current SCM plan is an input to this activity. For new applications, the SCM plan will be developed as part of the solution development process.
PM, SCM
3
Communicate Change Procedures
Communicate procedures for submitting change requests and identifying new issues and risks to project team members and stakeholders
PM, BusA, Espon, Cust
4
Communicate Status Reporting Procedures
Communicate how status reports will be collected from project team members and the frequency of meetings conducted to review that status. Ensure that team members understand what information they must provide and when
PM, Team
5
Establish Team Meetings
Establish team meetings to review issues, risks, change requests, and progress. Weekly meetings are recommended. Establish a regular time and place, agenda and procedure for capturing meeting minutes
PM, Team
6
Establish Sponsor Meetings
Establish regular meetings with the Project Sponsor to review issues, risks, change requests that require Sponsor signoff and project progress. Monthly meetings are recommended. Establish a regular time and place, agenda and procedures for capturing meeting minutes
PM, BusA, Espon, Cust
7
Communicate Database Change Request Procedure
Communicate procedures for submitting normal and emergency logical data model, physical data model and database change requests.
PM, Team, DBA, DArch
8
Establish approach for logging defects
If performing Package Product Selection and Implementation / PPSI, the team will have to establish approach for logging defects and
PM, Team
Originator: One IT PPM Team Page 36 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide enhancement reques ts, then forwarding to vendor. Note that Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Pre-commitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information.
Tools/Techniques Summary Methods and Applications/Tools eTracker can be used to created the required logs, see http://www.etracker.ford.com or logs can be created in Word. See outputs below for the Work templates available.
Inputs to Process Project Control File 09_SCM_Plan.doc (for existing applications)
Outputs http://www.etracker.ford.com 212_risk_management_log.doc 213_issue_log.doc 211_change_request_log.doc 210_change_request_template.doc 220_meeting_minutes_template.doc 221_weekly_status_report_template.doc Database Change Request http://www.its.ford.com/as/dmts/lob/cgibin/dbchgreq.cgi
Originator: One IT PPM Team Page 37 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.3
Define the Project
1.3.1
Develop Initial Charter/Enhancement Request
The project charter or enhancement request is a critical tool for managing the expectations of the project sponsor(s) and other stakeholders. Its purpose is to help the project manager:
• •
Document the agreement reached with the sponsor/Customer Provide a clear statement of the project’s purpose and of what the team is committed to deliver • Define project roles and responsibilities • Make visible the work process and the approach that will be used to manage the project • Provide a baseline for scope and expectation management Chartering is an iterative process and demands a high level of stakeholder involvement – particularly the involvement of the sponsor(s) and business analyst. In the first stage of a project not enough is known to complete the charter in its entirety. The idea of the initial charter is to provide enough information for the sponsor to feel comfortable in continuing the project. Even a simple Enhancement Request may require several iterations to reach agreement on scope, timing, and deliverables. Note: The project charter should be tailored to the needs of the project. The information presented here is a guideline. Use professional judgment to present as much or as little information as is necessary for the project situation.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
Key considerations in developing the charter are
Diagram
• • • •
Why is the project taking place? What will be accomplished by the project? How will project success be demonstrated? What will be delivered and when?
No diagram created for this process.
Process Tasks No
Task Name
Description
Participants
1
Review Existing Information
Review the project proposal, business case, and concept profile delivered with the project assignment and any existing documentation to understand the project’s purpose.
PM, BusA, Team
2
Identify Project Goal & Objectives
Identify the goals and objectives of the project. Project goals and objectives should align with the goals and objectives of the organization and that of the program to which the project belongs (if applicable). By definition, a project should have only one goal and
PM, Sponsor, BusA, Team,
Originator: One IT PPM Team Page 38 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3
Define Project Scope
multiple objectives that support that goal. Objectives must be measurable.
Stakeholders
Describe the scope as follows:
PM, Sponsor, BusA, Team, Stakeholders
Deliverable
Deliverable scope refers to the deliverables that the project will produce.
Logical
Logical scope delineates the boundaries of the information systems to be included in the project.
Organizational
Organizational scope s pecifies which organizations will participate in or be impacted by the project.
Temporal
Temporal scope defines the start date and end of the project, milestones, and any external dates that constrain it.
Financial
Financial scope summarized the project budget plan.
4
Identify Assumptions
Describe the key aspects of the project that are believed to be true, but should be expressly stated to ensure validity and concurrence, including items that should already in place.
PM, BusA, Team
5
Define Risks
Identify the high probability/high impact risks factors that may jeopardize a successful project outcome and their mitigation strategies and contingency plans (to be completed after the Investment Analysis is completed below).
PM, BusA, Team
6
ID Related Projects
Identify other projects that will impact your project. Include projects that are in progress and those that are planned.
PM, BusA
7
Describe The Project Organization
Describe the project organization, including key roles and responsibilities and the identities of individuals assigned to those roles, if known.
PM
8
Describe Approach
Describe, at a high-level, the solution delivery methodology chosen and the project management approach (to be completed after the "Define Project Approach" process is completed (below).
PM
Originator: One IT PPM Team Page 39 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Facilitated Sessions and Interviews Microsoft Word
Inputs to Process
Outputs
Recipients
242_business_case.xls 231_Scalablity_Classification_Questionaire.doc 243_program_charter.doc ∗ 241_Project_Proposal.doc Existing documentation, if any
200_project_charter_template.doc 230_enhancement_and_small_project_request_template 231_Scalablity_Classification_Questionaire.doc
Control File, Project Sponsor, BusA, Team, Stakeholders
∗
A program charter will be provided if the project is part of a larger initiative or program.
Originator: One IT PPM Team Page 40 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.3.2 Purpose
Develop Project Approach
The purpose of this process is to determine what project methodology, processes, accelerators, tools & techniques that will be used to achieve that project objectives. The primary objective is to ensure that the selected approach is the optimum method for managing the project and producing deliverables. The methodology that is used, the team’s experience, and management philosophy provide guidelines for establishing the project framework. Some paths through a methodology mandate a specific approach but, generally, some decisions must be made about the way the project is to be conducted. A benefit of this process is that it will help the project team to establish a common understanding of processes to be performed. The Project Manager will use this information as input when developing the project workplan.
Trigger
Key sections of an initial charter have been drafted, including the project goals and objectives and scope.
Key Considerations
•
•
•
Diagram
When selecting the methodology, processes and templates, the project team should understand the differences between Classic SDM and Unified SDM. See the If the team is not familiar with both methods, a PQA coach will be able to present the related concepts for both methodologies and help with the selection process. Developing and refining the Project Approach can occur throughout the project lifecycle. The process titled "Develop Project Approach" develops the initial Project Approach, and the process titled "Refine Project Approach" does refinement. Accelerators are proven techniques for delivering value to the Customer quickly. Examples of accerators include prototyping, co-locating the customer with the project team, and time-boxing. At this stage in the project lifecycle, you may not have all of the information you need to select some of the accelerators that will be appropriate for the project. However, you should know enough to begin looking at them and selecting the ones that will obviously apply. The Accelerator Use Plan template can be used as a starting point for selecting and documenting accelerators that will be used.
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Review Requirements
Review requirements, initial scope definition, and any technology decisions made to date.
2
Review method options and determine methodology
Review the methodologies available to the team. Note that the 246_Classic_SDM_and_Unified_SDM_Comparative_Overview.ppt presentation provides a comparison between Classic SDM and Unified SDM methodologies. Additionally, the PQA coaches can aid in
Originator: One IT PPM Team Page 41 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM, BusA, Cust, SysDesAn, SolnArch, PQA PM, BusA, Cust, SysDesAn,
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide understanding the methodologies and aid in the making of method tailoring decisions. Determine what methodology or methodologies will be used to meet project objectives.
SolnArch, PQA
3
Select processes and deliverables
Determine the processes and deliverables appropriate for the size and characteristics of the project. Document variances from the "standard methodology" in the Project PQA Plan. The plan should note any deviations from the standard methodology and justification for those decisions.
PM, BusA, Cust, SysDesAn, SolnArch, PQA
4
Select Project Accelerators
Review the list of potential project accelerators identified in the Accelerator Use Plan template and determine which ones will be applied. Note that, at this stage of the project, you may not know enough to make a final commitment on priorities and the accelerators that will be used, but it is a good idea to begin thinking about them now as some may require up front work to organize (e.g., co-location of the project team may require that different or additional facilities be arranged for the project once the Sponsor has signed the Initial Charter and given his approval to proceed).
PM, BusA, Cust, SysDesAn, SolnArch, PQA
5
Prioritize functionality and determine timing
Work with the customer to begin prioritizing functionality to be delivered as part of solution. Force rank the list of functions outlined in the Initial Charter and record that information on the Accelerator Use Plan. This information will be used to negotiate content of iterations/releases, scope, project timing and cost. These priorities will have to be taken into consideration if new functionality is requested or a corrective action is needed to recover a slippage in the project plan. Note: the Project Priorities Matrix in the Classic SDM Requirements Specification can be used to determine whether scope/quality, schedule or cost should be optimized.
PM, BusA, Cust, SysDesAn, SolnArch, PQA, ESpon
6
Review and Communicate Project Approach
Review the proposed Project Approach, PQA Plan and Accelerator Use Plan the Customer, project team, and stakeholders. Note: if significant variances from the identified methodology exist, consider gaining written authorization from the Practice Manager, PTG Customer Relationship Manager and Customer.
PM, BusA, Cust, SysDesAn, SolnArch, PQA, ESpon
7
Adjust Initial Charter
Ensure that decisions made here are appropriately reflected in the Project Management Approach section of the Initial Charter If this is a Six Sigma project, consider filling out the "PM Outline" tab in the DFSS MS-Excel workbook named "DCOV overview with forms.XLS".
PM, 6-Sigma
Originator: One IT PPM Team Page 42 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Facilitated Sessions PQA presentation titled 246_Classic_SDM_and_Unified_SDM_Comparative_Overview.ppt 247_Project_Approach_Questionaire.xls (job aid)
Inputs to Process
Outputs
241_Project_Proposal.doc
214_project_pqa_plan_template.doc
242_business_case.xls
200_project_charter_template.doc
231_Scalability_Classification_Questionnaire
204_Accelerator_Use_Plan.doc
200_project_charter_template.doc 02_Requirements_Specification.doc or 230_SDM_Enhancement_and_Small_Project_Re quest.doc
Recipients Control File, Espon, Team
--02_Requirements_Specification.doc or 230_SDM_Enhancement_and_Small_Project_Re quest.doc
Originator: One IT PPM Team Page 43 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.3.3 Purpose
Develop Quality Management Plan
The purpose of project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Accordingly, quality management includes the following: Quality Planning includes identifying which quality standards are relevant to the project and how to satisfy them. Incorporating quality standards into project design is a key part quality planning. For an IT project, quality planning might include planning a reasonable response time for a system or ensuring that consistent and accurate information is produced. Quality Control involves monitoring specific project results to ensure that they comply with the relevant quality standards while identifying ways to improve overall quality. Quality Assurance involves periodically evaluating project performance to ensure the project will satisfy the relevant quality standards. The quality assurance process generally involves independent review of project deliverables and processes (see 4.2.3 Coordinate Quality Reviews below).
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
For purposes of this methodology, quality is: Measured from the Customer perspective. One of the key components of a quality product is Customer satisfaction. A flawlessly design, defect-free product that does not meet the Customer’s needs cannot be considered to be high quality. Viewed as both a process and a product. A consistently high quality product cannot be produced by a faulty process. Everyone’s Responsibility. There must be a consistent and generalized set of principles that all parties can agree to and universally apply to make quality improvement a reality rather than simply a slogan. Measurable. Without baselines, it is impossible to take advantage of any measurements. Without data, it is impossible to know how the progress of the project relates to baselines.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Establish Completeness & Correctness Criteria
Review the deliverables outlined in the Scope section of the Project Charter. Establish completeness and correctness criteria for determining when each deliverable meets specifications. Use these criteria as standards when conducting deliverable reviews.
PM
2
Ensure Quality through
Ensure the consistency of the work within each deliverable and across
PM,
Originator: One IT PPM Team Page 44 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Reviews
deliverables through the appropriate reviews. Examples include peer reviews of deliverables, independent quality reviews with the Process Quality Assurance group, and gate reviews to assess overall project health with the Sponsor and IT Management. See 4.2 Conduct Project Reviews below for more details.
Team, PQA
3
Document Requirements for Metrics Gathering
The project work plan must include tasks that allow the project manager to gather and analyze metric data. Use metrics to measure and monitor the quality of the work process. Much of this data will come in the form of status reports, issues logs and change request logs.
PM
4
Document Planned Deviations
Document any planned deviations from the standards defined by the solution delivery methodology. Record those deviations and their justification in the Quality Management Plan section of the project charter.
PM
5
Review Quality Mgmt Plan
Review the quality management plan with the Business Analyst and project team. Make adjustments as necessary.
PM, BusA, Team
Tools/Techniques Summary Methods and Applications/Tools Review of initial project charter and the guide for the selected solution delivery methodology. Microsoft Word
Inputs to Process 200_project_charter_template.doc Solution Delivery Methodology Process Guide 57_PQA_Review_Checklists.xls
Outputs 200_project_charter_template.doc 214_project_pqa_plan_template.doc
Originator: One IT PPM Team Page 45 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.3.4 Purpose
Develop Communications Plans
Plan the way you will communicate to avoid chaos and confusion. Projects involve the transfer, use and retention of information. The more clearly and concisely you communicate and manage the information in your project, the fewer problems you will have. As the following diagram shows, the lines of communication on project can be very complicated. A well-thought out communications plan is needed to manage all of these crossing lines of hierarchy and functional relationships.
Corporate Executives IT Customer Relationship Managers Sponsor/Customer
IT Project Managers
Solution Architects
Business Managers
Users Developers
Support Groups
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
The communication plan should
•
Set out rules for the project management team; regarding who decides what, who tells who what, how they file and retrieve information, and how they manage documents.
•
Establish the concrete aspects of project management communication.
•
Define rules for notifying others about changes to the Project Plan.
•
Describe the media and communications channels that will be used.
•
Identify the information needs of the stakeholders and how they will be filled.
Originator: One IT PPM Team Page 46 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Diagram
No diagram provided for this process.
Process Tasks No 1
Task Name Identify Information to be Shared
Description
Participants
Determine what should be shared/made available to stakeholders. For example:
PM, BusA
• • • • • • • •
Project Charter and Plans Project Standards and Procedures Change Requests, Logs and Resolutions Status Reports and Plan Changes Key Issues and Decisions with Backup Specification and Design Documentation Roles and Responsibilities Approvals and Contracts Ensure that plans cover all of the items identified. 2
Complete a Communications Plan Template
3
Review and File Plan
4
Refine Plan as Needed
Using the Project Communications Plan Template record the following information for each communication planned:
PM
• • • • • •
The purpose of the communication Who will be responsible for preparing the communication Who needs to approve the communication From whom will the communication come Who will receive the communication What method will be used to convey the message (e.g., in a status report, in a newsletter, etc.)? • What communications vehicle will be used (e.g., the web, email, meetings) • How frequently will the information be communicated Review the Communication Plan with the Business Analyst and Project Team to assess completeness and file the Plan in the Project Control File. Refine the communication plan as project plans are finalized and changes occur.
PM, BusA, Team PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word
Inputs to Process 200_project_charter_template.doc 201_stakeholder_assessment_template.doc
Outputs 215_communication_plan_template.doc
Originator: One IT PPM Team Page 47 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.4
Develop High-Level Work Plan
1.4.1
Develop High-Level WBS
A Work Breakdown Structure is a hierarchical representation of the work that needs to be completed to deliver the product(s) that will satisfy the project’s objectives. It is the single most important tool for project planning, because it provides a framework from which:
•
Trigger
The total scope of the project can be described as a summation of the decomposed elements • Work activities can be defined and estimated • Dependencies and iterations can be identified • Costs and budgets can be established or confirmed • Time, cost and performance can be tracked • Responsibility can be established Development of an initial charter.
Key Considerations
The key considerations in developing the WBS are:
• • Diagram
Is there a representative WBS already in existence that can be modified for rapid reuse? Does the methodology being used provide a pre-defined work breakdown? The diagram below depicts the high-level process flow for this activity. Review Methodology for Existing WBS
Project Charter Requirements Specification
WBS PreDefined?
No
Identify Work Activities to Produce Deliverables
Decompose & Sequence Work Activities
Solution Delivery Methodology
Project
Note: The High-Level WBS generally stops at the Activity Level.
Yes
Ensure Completeness
Stage Activity
WBS Worksheet and/or MS Project Plan
Record WBS
Task
Process Tasks
Originator: One IT PPM Team Page 48 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Review Standards
Determine if the methodology being used pre-defines the work breakdown. If it does, skip to step 4. Note: The Classic Systems Development Methodology is an example of the methodology that pre-defines the work breakdown structure.
PM
2
Identify Work Activities
Using the project charter, work with team members to review the project deliverables and identify the work activities required to produce them.
PM, Team
3
Decompose & Sequence Work Activities
Decompose the work to the point where a high-level plan can be created.
PM, Team
4
Ensure Completeness
Review the breakdown to ensure that all of the work on the project is accounted for including Project Management and support activities.
PM, Team
5
Record the WBS
Use a WBS Worksheet to record the breakdown. If preferred, the breakdown can be entered directly into MS Project. Note: An MS Project Plan Template has been developed for the Classic Systems Development Methodology. See Tools/Technique Summary below.
PM
During Project Initiation, it may not be possible to develop a task-level WBS and, in fact, it is not necessary. A WBS that is decomposed two or three levels will suffice for initial estimates and schedule development.
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request
Outputs 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Originator: One IT PPM Team Page 49 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File BusA Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.4.2
Develop Dependency Network
Purpose
In order for the project manager to accurately determine the cost and duration of a project, a detailed schedule must be created. One of the first steps in creating that schedule is determining how many activities in the project are related to one another and the nature of their dependencies.
Trigger
Completion of the development of an activity-based work breakdown.
Key Considerations
Several items may affect activity sequencing and interdependence:
Diagram
•
Product description – characteristics, such as a subsystem interface on a software product may affect activity sequencing.
•
Mandatory dependencies – those dependencies that are inherent in the nature of the work underway. They often involve a physical limitation such as the availability of a specific test facility.
•
Discretionary dependencies – those that are defined by the project management team, such as deciding not to start a series of activities until after moving into new office space.
•
External dependencies – those that involve an external interface with other projects or events. For example, the testing activity in a software project may be dependent on delivery of hardware from another project.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
1
Record WBS in MS Project
Enter the high-level work breakdown structure into MS Project. Note: If you are using the Classic Systems Development Methodology, the work breakdown and dependencies have been entered into an MS Project Plan Template for you.
PM
2
Identify Links
Establish the finish to start, start-to-start, start to finish, and finish-to-finish relationships between dependent activities.
PM
3
Incorporate Iterations
Develop the appropriate iteration cycles for the development of deliverables and work products.
PM
4
Partition & Split Activities
Partition the work and split activities to make the work more manageable.
PM
Originator: One IT PPM Team Page 50 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Outputs 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Originator: One IT PPM Team Page 51 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File BusA Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.4.3 Purpose
Estimate Effort
Estimating is the art and science of using historical data, personal expertise, institutional memory, and the project scope statement to predict the resource expenditures, total cost, and duration of a project. The purpose of estimates created during Project Initiation is to provide the means for the project manager and sponsor to assess the viability of the project and make a reasoned go/no-go decision. Estimates provided at this point are order-of-magnitude and should include sufficient contingency to offset the degree of uncertainty inherent in the early stages of a project.
Trigger
Completion of the development of a task-based work breakdown and prior to development of the SOW.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Select Estimating Tool/Technique
Determine what method/model will be used to produce initial estimates.
PM, Team
2
Determine How Far Out Estimates Will Go
Decide how far out you should try to estimate in detail. Estimates can be produced in detail for the first few stages of the project and at a higher level further out.
PM, Team
3
Determine Amount of Contingency
Determine how much contingency to include in early estimate to offset uncertainty.
PM, Team
4
Estimate Project Duration
Use estimates to determine expected duration of the project or the number of Full Time Equivalent (FTE’s) resources needed to meet a finish date that was identified at the beginning of the project as a constraint. Discuss with the Business Analyst and Sponsor any scope, quality, time or budgetary requirements and constraints. The estimating goal helps specify the balance between the three project factors: quality, schedule, and cost.
PM, BusA, Espon, Team, ImpA
Examples of an estimating goal are:
•
Good quality, shortest possible schedule
•
Fair quality, lowest cost
•
High quality, reasonable schedule and cost
Note that estimating is not negotiating. Estimate the work as you see it, and then work with the Sponsor to determine how the work can be modified (scope reduction, added resources) to make the charter agreeable. Originator: One IT PPM Team Page 52 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 5
Define Temporal Scope
Complete the temporal scope section of the charter by filling in the high-level time line. Document your estimating assumptions as well.
PM
6
Refine the WBS and Initial Work Plan
Incorporate estimate data into the Work Breakdown Structure Worksheet (if in use) and the MS Project Plan.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project Microsoft Excel
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Outputs 205_wbs_worksheet_template.doc 228_Classic_SDM_Estimating_Model.xls 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 53 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.4.4
Develop High-Level Schedule
Purpose
The purpose of this process step is to produce an initial high-level project schedule with milestones identified.
Trigger
Completion of the development of a task-based work breakdown.
Key Considerations
No key considerations provided for this process step.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Develop Highlevel Schedule
Develop a high-level schedule. Where possible assign individuals to activities and roles to others.
PM
2
Identify Interim Milestones
Identify interim milestones – major checkpoints or deliverables.
PM
3
Update Initial Charter
Update the initial charter to reflect the schedule and milestones.
PM
4
Update Project Records
Update the project record in ITMS, RMS and MRS to reflect the updated schedule and file documents in project Control File.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp
Outputs
Recipients
200_project_charter_template.doc 229_Classic_SDM_Work_Plan.mpp 230_Enhancement_and_Small_Project_Request 232_PQA_Metrics_Project_Sizing_Profile.doc Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs ITMS Record at http://www.itms.ford.com/
Originator: One IT PPM Team Page 54 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, BusA, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.5
Complete Investment Analysis
1.5.1
Complete Initial Risk Assessment
There are always risks associated with a project. The purpose of risk management is to ensure levels of risk and uncertainty are properly managed so that the project is successfully completed. It enables those involved to identify possible threats, the manner in which they can be contained and the likely cost of countermeasures. Risk assessment is used during project initiation as one of the major criteria in deciding whether to do a project or not. Here, risk is compared to expected reward to see if it is worth taking.
Trigger
Definition of scope in an Initial Charter and completion the High-Level Plan.
Key Considerations
•
Risk response development may result in any combination of contingency plans, additional activities or tasks, changes in contractual agreements, etc. Estimates and schedules must be changed accordingly.
•
Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Complete a Risk Assessment
Complete the risk assessment checklist for the first time to obtain an initial numerical risk assessment score and risk rating. Use the calculated risk score to determine the amount of contingency to be included in the project plan.
PM, BusA, Team
2
Identify Risks Factors
Define the potential areas of risk that may affect the project and record them on the Risk Management Log. The following risk factors are common in projects.
PM, BusA, Team
Threat •
Threat due to changes in nature and/or strategy of competitors
Capability of Developer or Organization •
Capability of developing organization to perform the task at hand, including technical or management (project and/or program management processes, tools and techniques, and how they fit together).
•
Incorporates experience, tools, skills, documented processes and capacity, influence of external factors such
Originator: One IT PPM Team Page 55 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide as strikes, etc. •
Communication planning and execution skills and resource availability.
•
Includes ability of organization to provide adequate resources (SME’s, BA’s, systems analysts, testers, PM’s, etc.).
Cost •
Sufficiency of funds allocated for the life cycle of the system
•
Includes errors in cost estimating
Engineering •
Ability of system configuration to achieve program’s engineering objectives
•
Includes test environment, tools, O/S and software version levels, etc,
Logistics •
Ability of system configuration to achieve logistics objectives based on system design, maintenance concept, support system design, and availability of support resources.
•
Ability to provide 24x7 support if developers are geographically distributed
Manufacturing •
Ability of system configuration to achieve manufacturing objectives
•
Includes manufacturing processes, availability of manufacturing resources.
Schedule •
The adequacy of the time allocated for the defined tasks
•
Includes effects of schedule decisions, errors in estimating, and external influences such as launch window (e.g., holiday, or 01-JAN-2000).
•
Time to develop and/or approve contracts, Requirements Specifications, technical specifications, work plans, charters, and funding.
•
Misunderstood schedule dependencies
Technical •
Degree to which proposed technology has been proven
•
Reliability of product, product certification
•
Reliability / coverage by test tools
•
Internal
•
Scope changes
Originator: One IT PPM Team Page 56 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide External •
Vendor unable/unwilling to perform Year 2000 modifications to systems and/or applications
•
Supplier unable to provide goods and/or services as a result of internal, external or upstream Year 2000 problems
•
Changing reporting requirements (e.g.; Government Compliance and Reporting / Regulatory)
Other common risk factors can be found in the E&Y Risk Management Strategies job aid (see Tools/Techniques Summary below). 3
Classify Risk Factors
Classify the potential risks into risk categories (e.g., scope, technology, etc., see Risk Management Log Template).
PM, BusA, Team
4
Assess Impact and Likelihood
Evaluate the potential impact of each risk on the project’s success (High, Medium or Low) and the likelihood that the risk will occur (High, Medium, or Low).
PM, BusA, Team
5
Develop Risk Response Plans
Risk response development is the process of determining what to do (or not to do) about the risk. Some choices are:
PM, BusA, Team
• •
Avoid (Eliminate the cause of negative events)
•
Reduce the probability of occurrence (Change methods or procedures, etc.)
•
Transfer the risk (Obtain insurance to eliminate the cost burden of negative events, or use a vendor with a fixedprice contract to transfer the risk of cost overrun)
Moderate impact (Define mitigation strategies and create contingency plans to follow if a negative events occurs)
•
Accept the risk The E&Y Risk Management Strategies job aid contains specific recommendations for mitigating strategies for commonly encountered risks. 6
Record HH Risks in Charter
Enter the risks that are determined to be high risk and high probability in the Risk section of the Project Charter.
Originator: One IT PPM Team Page 57 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project 207_risk_strategies_jobaid.pdf
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp
Outputs 206_risk_assessment_template.xls 212_risk_management_log.doc
Originator: One IT PPM Team Page 58 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Team, Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.5.2 Purpose
Develop Initial SOW
The SOW serves as the cost baseline for the monitoring and controlling of the project activity. The budget contained in the SOW can be distributed across milestones or across calendar periods. Additionally, costs may be associated with specific deliverables to assess and validate each deliverable’s value. Budgeted costs include labor, travel and living expenses, training, facilities, computing, and other costs that are to be consumed by the project. During Project Initiation you will be developing a high-level SOW that focuses mainly on labor costs calculated on the basis of the initial man-hour estimates and estimated non-labor costs.
Trigger
Development of a draft initial charter, high-level plan, and risk assessment.
Key Considerations
Some key considerations for this process are:
Diagram
• • • • • •
What human resources will be utilized on the project? What facilities and equipment will be required? What are the estimated support costs for the delivered product? What training and documentation costs will be incurred? What travel and living expenses will be incurred? Only Ford employees are authorized to access the SOW. Non-Ford employees should work with their Practice Manager to complete it.
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Determine Labor Budget
Review the initial estimates of the project to determine the total hours of effort required. Apply the appropriate resource cost rates to derive a total budget amount.
PM, BusA, Team, ImpA
2
Estimate Remaining Budget Categories
Estimate any significant non-labor costs. Consider training, facilities, computing, implementation, and project support costs. Use 209_budget_considerations_checklist.doc to help identify costs that should be considered.
PM, BusA, Team, ImpA
3
Author SOW and submit for approval
Author the SOW using the template located at http://www.ads.ford.com.
PM
Submit the SOW for review and approval using the SOW Workflow Process (ADS Funding Authorization Workflow Process) and tool documented at that site.
Originator: One IT PPM Team Page 59 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 4
Enter Summary Data into the Initial Charter and Business Case
Record the budget summary data in the Financial Scope section of the Initial Charter document and the Business Case.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word Microsoft Excel
Inputs to Process 241_Project_Proposal.doc 242_business_case.xls 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 206_risk_assessment_template.xls 228_Classic_SDM_Esimating_Model.xls 229_Classic_SDM_Work_Plan.mpp
Outputs SOW located at http://www.ads.ford.com 209_budget_considerations_checklist 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 242_business_case.xls
Originator: One IT PPM Team Page 60 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Team, Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.5.3 Purpose
Confirm/Refine the Business Case
An effective business case must convince management that the investment is financially sound, realistic for the organization, aligned with other business strategies, and has a clear course of action for implementing deliverables. Organizations can avoid wasting time and money on unnecessary projects by developing initial cost justification criteria in the Project Proposal as part of the Portfolio Management process and confirm/refine it during the ID & Assess stage. Not only will a strong business case make project selection and prioritization more efficient, the business case also serves two additional purposes: it can provide as a foundation for the project charter and as a temperature check throughout the project life cycle. The key element of the business case is the cost/benefit analysis, which must prove that estimated costs are justified by the anticipated benefits. Different from a feasibility study, which is often used as a precursor, a business case emphasizes the opportunity described by long-term goals, and is supported by specific business objectives, cost and risk analysis measurements.
Trigger
Completion of an Initial Charter, High-Level Plan, Risk Assessment and HighLevel Budget Plan.
Key Considerations
•
Participation in this process by a Financial Analyst who is familiar with the business processes in the value chain is essential to creating a reasonable and accurate business case.
•
Organizational benefits and risks may be included in the discussion in order to show productivity improvement expectations by implementing the system, but be careful not to overestimate savings by reducing or redistributing headcount. If associates have multiple responsibilities, reductions often aren’t possible.
•
During the business case development, the benefits should be identified as being either "qualified" or "perceived" based on the degree of certainty achieved during the analysis process.
•
Six Sigma projects may additionally require the use of a Six Sigma template for stating the summary business case and a detailed business case. See the DFSS template titled "DCOV overview with forms.XLS" for details.
•
Numerous references and links on the Ford intranet provide insight on the business case development process. Enter the string "Business Case" as the search criteria.
•
Reference the introductory section in this guide titled "Project Authorization Requests and Purchase Orders" for further information on Project Appropriation Requests / PARs and Purchase Orders POs.
Diagram
No diagram provided for this process step.
Originator: One IT PPM Team Page 61 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No 1
Task Name
Description
Confirm Business Benefits
Review the business opportunities and benefits outlined in the business case provided at project start-up. The Business Case will be stated in terms of costs as well as tangible and/or intangible benefits. The benefits may include but are not limited to: Tangible benefits:
• • • •
Participants PM, BusA, Espon, FinanceAnal
Return on Sales (ROS) Return on Investment (ROI) Return on Assets (ROA) Net Present Value (NPV)
Intangible benefits:
•
Operating necessity. An example of an operating necessity is the sales offering of 0% financing that was offered in the post 9/11 period.
•
Extensions to existing services/products. An example is the addition of additional makes/models to an existing automotive web site. Another is the deployment of an existing application to additional geographies.
•
Competitive necessity. An example is the situation where a customer-facing web site has to be developed because competitors are also developing them, and sales could be lost without a similar offering. If different or additional benefits have been identified during the initial chartering and risk assessments, update the business case accordingly and note the changes. Notes: To perform a true cost/benefit analysis, benefits must be expressed in dollars. The expertise of a financial analyst should be obtained to help drive out and express hard benefits. 2
Confirm or Refine Cost Estimates
Review the cost estimates provided in the original business case. Determine what changes are necessary and note them accordingly.
PM, BusA
3
Consider Timing and Dependencies
Consider external factors that the project is dependent on such as the timing for completion of other projects.
PM, BusA
4
Assess and Make Recommendation
Assess proposed costs against the estimated benefits of the proposed solution. Consider timing and dependencies. Based on this, formulate a recommendation as to the viability of the project.
PM, BusA, ESpon
5
Communicate Changes
Communicate any changes in the cost, benefit or recommendation to the Executive Sponsor, Stakeholders and IT management as appropriate. Provide any changes in project costs or benefits to the Controller/Financial Manager and request that the Project
PM, ESpon, Stakeholders, IT Management, FinanceAnal
Originator: One IT PPM Team Page 62 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Authorization Request /PAR in MEARS is updated.
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel Note: in addition to the project management templates, the DFSS template titled "DCOV overview with forms.XLS" contains a summary business case in the "Charter" tab, and a detailed business case on the "Budget Matrix" tab.
Inputs to Process
Outputs
Recipients
241_Project_Proposal.doc
242_business_case.xls
242_business_case.xls
200_project_charter_template.doc
200_project_charter_template.doc
56_Process_Capability_Scorecard.xls
230_Enhancement_and_Small_Project_Request
SOW located at http://www.ads.ford.com
206_risk_assessment_template.xls
230_SDM_Enhancement_and_Small_Project_Request.doc
229_Classic_SDM_Work_Plan.mpp
241_Project_Proposal.doc
SOW located at http://www.ads.ford.com
PAR at the MEARS website http://www.finance.ford.com/mears/index2.html
56_Process_Capability_Scorecard
Control File, BusA, Team, ESpon, Finance Office, Stakeholders
PAR at the MEARS website http://www.finance.ford.com/mears/index2.html
Originator: One IT PPM Team Page 63 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.6
Confirm Readiness to Proceed
1.6.1
Confirm Requirements/Business Owner View
The purpose of this process is to ensure that that the initial Requirements Specification and the business owner view documents have been completed and reviewed by the Customer. Note: The initial Requirements Specification and Business Owner View are work products that are described in the Classic Solution Delivery Methodology. They are referenced here in the Project Management Guide because of their importance in assuring project readiness and because they are among the key deliverables that must be reviewed and approved by the Customer before the project can proceed.
Trigger
Completion of the Initial Charter, High-Level Plan, Investment Analysis, Initial Business Requirements Specification, Signed Business Owner View
Key Considerations
No key considerations specified for this process.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Confirm Initial Business Requirements Specification
Confirm that an initial Requirements Specification has been completed as per the appropriate Solution Delivery Methodology (SDM) Guide and that the lead Customer has reviewed and approved that specification.
PM, BusA
2
Confirm Customer Signoff of Business Owner View
Confirm that the required process and data models (future state) have been constructed as part of the Business Owner View described in the Solution Delivery Methodology. Ensure that the Business Owner View has been reviewed and approved by the Customer (i.e., that the Customer has signed off on the Business Owner View).
PM, BusA, Cust
3
Ensure Alignment with Initial Charter
Ensure that the scope section of the charter is appropriately aligned with the initial Requirements Specification and Business Owner View
PM
4
File Documents in Control File
File the completed documents in the project Control File.
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 64 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Review of SDM deliverables
Inputs to Process 02_Requirements_Specification.doc 61_Business_Owner_View.doc
Outputs Confirmation of signed Business Owner View and Requirements Specification
Originator: One IT PPM Team Page 65 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.6.2 Purpose
Obtain Initial Charter/Enhance. Req. Signoff
Once the Initial Charter/Enhancement Request, High-level Plan, and Investment Analysis are complete, it is time to seek Sponsor approval to proceed. The Sponsor must decide if the charter is complete and accurate and if the project should go forward or be terminated. The “go/no-go” decision may be based on factors outside the control of the Project Manager (e.g., the organization may have new priorities that are in direct conflict with the project or increased risk may have been introduced to the project.) Approval to proceed is documented by the Sponsor’s signature on the Initial Project Charter. Note: Signing of the charter is viewed as a separate activity from the end of stage gate review. It is treated as a separate step for the following reasons:
•
Signoff of the charter should be done as soon as the Project Manager and Sponsor think that it is both complete and accurate.
•
The Sponsor may find that the anticipated costs and effort that are outlined in the charter do not support expected benefits and decide that no further work should be completed on the project.
•
The Sponsor’s signature on the initial charter should be a key input to the gate review that occurs at the end of the first stage of the project.
Trigger
Completion of the Initial Charter, High-Level Plan and Investment Analysis
Key Considerations
The decision to sign the charter is generally made on the basis of the following key questions:
• •
Do expected benefits justify the estimated costs and effort?
• • •
How important is the project to the business?
• •
Can timing constraints be met?
• •
Will the deliverables identified meet the Sponsor’s criteria for success?
Are there significant risks attached to the project and do they outweigh potential benefits? Is the project required to meet regulatory requirements? Will the resources and skills required to do the project be available when needed? Does the charter accurately capture the goal and objectives defined by the Sponsor and key stakeholders? If the project is part of a program, is the charter completely aligned with the program charter?
•
Diagram
Is the Sponsor prepared to commit the end-user resources and business subject matter experts required to assist the IT project team in developing the end-product? No diagram provided for this process step.
Process Tasks
Originator: One IT PPM Team Page 66 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Schedule & Conduct a PreCharter Signing Review
Before reviewing the charter with the Sponsor ensure that the IT Business Analyst and Program Manager (if appropriate) have a chance to review the charter, high-level plan, and investment analysis documents. Obtain their agreement on the charter content and backup data to be presented to the Sponsor before proceeding.
PM, BusA, Program Mgr, Team, ImpA, Cust
2
Schedule Charter Review with Sponsor
Schedule a charter review and signoff session with the Sponsor.
PM
3
Prepare Approval Package
Prepare an approval package for review with the Sponsor. The package should include the Initial Charter Document and as backup, the High-Level Project Plan, Risk Assessment, Budget Plan, and refined Business Case.
PM
4
Review Charter and Detail
Review the charter and supporting material, as needed, with the Sponsor. Identify and document any issues that must be resolved before the charter can be approved (e.g., any refinements or additions that must be made before the Sponsor will approve the charter). If possible make the changes needed in the session itself.
PM, BusA, Sponsor, Team, Stakeholders, ImpA
5
Obtain Signoff
Obtain the Sponsors signoff. If the Sponsor decides that, based on the charter, the project should not proceed, document that decision.
PM, BusA, ESpon
6
Update Project Records
Update the project record in ITMS, RMS and MRS to reflect the status and file documents in project Control File.
PM
7
Notify Stakeholders
Notify support activities, the project managers of related/dependent projects, the Practice Manager, the Portfolio Manager, and the Competency Center Manager of the results of the charter review.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 02_Requirements_Specification.doc 200_project_charter_template.doc 204_accelerator_use_plan 206_risk_assessment_template.xls 228_Classic_SDM_Estimating_Model.xls 229_Classic_SDM_Work_Plan.mpp 230_Enhancement_and_Small_Project_Request 241_Project_Proposal.doc 242_business_case.xls 56_Process_Capability_Scorecard SOW located at http://www.ads.ford.com
Outputs
Recipients
02_Requirements_Specification.doc 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request Go/No-Decision Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs Updated ITMS Record at http://www.itms.ford.com/
Originator: One IT PPM Team Page 67 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Program Mgr, ESpon, Cust, Team Support Activities Competency Center Metrics
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 68 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.0
Plan Project Project Management Processes
Project Charter Business Case
Initiate
High Level Plan Business Owner View
Plan Requirements Execute
Solution Delivery Methodology
Control Close
Inputs to Plan Project
Overview
Project Planning is an iterative process that occurs throughout the project life cycle. It begins in Initiate Project with the development of the charter and high level plans and continues in subsequent stages with more detailed planning and adjustments made to reflect changes and corrective actions. The process described below picks up where the high level plan that was created in Initiate Project leaves off. Here, however, the results of analysis and design activities are used to identify additional planning requirements and create detailed work plans.
Process Contents
Objective 2.1
Note Refer to PM Processes "3.0 Execute Project" and "4.0 Control Project" for processes such as "Maintain Project Records" or "Conduct Status Reviews" for process steps that must be carried out across all five PM Processes (Initiate, Plan, Control, Execute, Close).
2.2
2.3
Develop Project Management Plans
Refine Work Plans and Budget
Confirm Readiness to Proceed
Process Steps
PM Deliverable
2.1.1
Develop Org Change Mgmt Plan
2.1.2
Develop Procurement Plans
2.1.3
Develop Transition Plans
2.1.4
Develop Resource Mgmt Plans
Resource Mgmt Plan
2.2.1
Refine Project Approach
Accelerator Use Plan
2.2.2
Refine Work Plans
2.2.3
Refine Risk Management Plans
Risk Management Plans
2.2.4
Refine Resource Requirements
Resource Requests
2.2.5
Refine The SOW
2.3.1
Confirm Requirements Spec Signoff
Requirements Signoff
2.3.2
Obtain Final Charter Approval
Final Charter Approval Signoff
2.3.3
Conduct Formal Kick-off
Originator: One IT PPM Team Page 69 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Org Change Mgmt Plans Procurement Plans Support and Launch Plan
Baseline Project Schedule
Refined SOW
Kick-off Metting
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
2.1
Develop Project Management Plans
2.1.1
Develop Organizational Chg Mgt (OCM) Plan
Organization Change Management (OCM) is a process for managing the human aspects of implementing major, complex change resulting in value, delivered through the implementation of stated human, process and technology objectives in support of business objectives. OCM activities are warranted when the change is MAJOR, When there is a high COST of implementation failure, or When there is a high risk that certain human factors could result in implementation failure.
Trigger
The need for engaging in change management has been identified.
Key Considerations
• •
Diagram
See the process "Develop Organizational Change Management (OCM) Plan" in the Classic SDM Process Guide. The "HR Business Partner" for each organization is responsible for identifying OCM resources. An OCM overview and the name of the IT HR Business Partner can be accessed at the IT HR home page at http://www.itonline.ford.com/home/it-prof/it-hr/.
No diagram provided for this process.
Process Tasks No 1
Task Name Coordinate OCM activities
Description Ensure that OCM activities occur. See the Classic SDM Guide for details. Update the work estimates and workplans as appropriate.
Participants PM
Tools/Techniques Summary Methods and Applications/Tools MS Project Organizational Change Management techniques – see http://www.change-management.com/ for articles and books
Inputs to Process
Outputs
200_project_charter_template.doc
200_project_charter_template.doc
230_Enhancement_and_Small_Project_Request
230_Enhancement_and_Small_Project_Request
215_communication_plan_template.doc
215_communication_plan_template.doc
229_Classic_SDM_Work_Plan.mpp
229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 70 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Program Mgr, BusA, Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.1.2
Purpose
Develop Procurement Plan
The procurement plan addresses the methods for the selection and purchasing of project goods and services. It must proactively identify possible needs for products and services. It must also establish standards and procedures for:
•
Make or buy decisions
•
Identifying and selecting prospective suppliers (internal and external)
•
Preparing procurement documents such as requests for quote (RFQ)
•
Making purchasing decisions (including approval to commit)
•
Contracting
Trigger
A decision has been made to purchase goods or services on the project.
Key Considerations
Key considerations for this process are:
Diagram
•
How does the product or service serve the needs of the project?
•
Does the product of something similar already exist within the organization?
•
Is there a service provider available in the marketplace for the product in question?
•
Does the organization have the means (staff, money, contract, etc.) to produce or acquire the product?
•
Classic SDM has incorporated processes for development of a long list of solution alternatives, an RFI process that developments a short list, an RFP/RFQ process that develops a solution recommendation as well as a Best and Final Offer / BAFO negotiation process. It also has incorporated special considerations for purchased package selection and implementation into each of the affected Classic SDM processes.
•
Creation of a project-specific Purchase Order requires that two steps be performed. First the capital expenses must be accounted for in MEARS. Second, the Purchase Order must be created, issued and tracked via CPARS in North America or the equivalent tool in EMEA. Also note that eVerest will replace the existing procurement applications.
No diagram provided for this process.
Originator: One IT PPM Team Page 71 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Complete Make/Buy Decision
Use cost/benefit analysis to determine if purchasing goods or services is the right approach.
2
Determine How Much To Buy
The question of how much to purchase can only be answered by the individual project. However, consideration should be given to the following questions before making that decision:
PM, BusA, ESpon, SMEs PM, BusA, SMEs
•
Will there be need beyond the immediate project for this product? • How much of the budget has been or will be allocated for this product? • Is the need for the product or service clearly defined enough for the organization to know how much is needed? Underestimating or overestimating the cost or quantity of an item can have a big impact on the financial success or failure of the project. Caution should be used when entering into any contract without clearly defined needs and objectives. 3
Determine How to Buy
If a decision is made to purchase an item or service, the next step is to explore the various types of contracts that can be arranged. Work with Purchasing and the Office of The General Council (OGC) on this as appropriate. Some examples include:
•
Fixed Price/Lump Sum Contract. This is a contract that involves paying a fixed, agreed-upon price for a well-defined product or service. Special consideration must be given to these contracts to ensure that the product is well defined to reduce risk to both the Company and the contractor.
•
Cost Reimbursement Contract. This contract type refers to a reimbursement to the contractor for actual cost of producing the product or service. Costs within the contract are classified as direct (e.g., salaries to staff of the contractor) and indirect (e.g., salaries of corporate executives for the contractor). Indirect costs are normally based on a percentage of direct costs.
•
Unit Price Contract. The contractor is paid a preset amount for each unit (e.g., $10 per widget produced) or unit of service (e.g., $50 per hour for service). The contract equals the total value of all units produced.
PM, BusA, Purchasing, OGC
4
Contact Ford Purchasing
Contact Ford Purchasing to discuss project requirements as well as agree to approach/plan for performing vendor contact and product analysis.
PM, BusA, Purchasing
5
Develop Procurement Plan
Determine if an existing contract with a pre-approved vendor can be used to satisfy the need for services. If not, determine what vendors will be asked to solicit the business.
PM, BusA, Purchasing
6
Develop Sollicitation Plan
Work with Purchasing to put a procurement plan together that determines how bids in the form of Contract will be solicited from potential vendors. Agree on how the final decision will be made (i.e., agree on the criteria that will be used to make the buy
PM, BusA, Purchasing
Originator: One IT PPM Team Page 72 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide decision.) 7
Make Decision
Make the final decision to purchase the goods or services and notify stakeholders as appropriate.
PM, BusA, Purchasing
8
Establish Contractual Agreement
Work with Purchasing and the Office of the General Council (OGC) to finalize the contractual arrangements with the vendor.
PM, BusA, Purchasing, OGC
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project Cost/Benefit Analysis – see http://www.mindtools.com/pages/article/newTED_08.htm for brief explanation or http://www.csd.uwo.ca/courses/CS179/lect8/sld008.htm for online presentation of this topic
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request
Outputs Organization-specific procurement plan
Originator: One IT PPM Team Page 73 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Purchasing, OGC
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.1.3 Purpose
Develop Transition Plans
The purpose of the transition plan is to outline the steps that will be taken to promote smooth handover of project deliverables to support activities.
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
Key considerations for this process are:
• •
Will additional or different skills in support services be required?
•
Is the project part of a release within a program or initiative?
•
What actions must be taken to ensure smooth handover?
•
What is the schedule of transition events?
•
Diagram
Will the application be implemented immediately or shelved pending completion of a related project or projects?
What additional coordination activities will be required because an outside vendor is involved?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Initiate the Transition Process
Identify the Practice Application Supervisor that will be responsible for supporting the deliverables produced by the project. Notify that supervisor of the project and schedule an initial meeting to review project plans and anticipated transition events.
PM, AppSupr, ImpA
2
Identify the Transition Team
Identify the transition team members, including their names, roles, cds ids, and phone numbers.
PM, AppSupr, ImpA
3
Schedule Key Transition Events
Identify when key transition events will occur, who will be involved, and what actions will be taken. Transition events include, but are not limited to the following:
PM, AppSupr, ImpA
• • • • • • • •
Knowledge Transfer Meetings Service Level Agreement Reviews Acceptance Testing Reviews Performance Monitoring and Control Reviews Outstanding Change Request Handover Outstanding Issues Handover Outstanding Defects Handover Documentation Handover
Tools/Techniques Summary Originator: One IT PPM Team Page 74 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word and MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp
Outputs 217_transition_support_plan.doc 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 75 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.1.4 Purpose
Develop Resource Management Plans
Project human resource management includes the processes required to make the most effective use of the people involved in the project. This includes the following: Organizational planning, which involves identifying, assigning, and documenting project roles, responsibilities, and reporting relationships. Key outputs of this process include role and responsibility assignments, often shown in a matrix form, and an organizational chart for the project. Staff Requisition, which involves getting the needed personnel assigned to and working on the project. Getting personnel is one of the crucial challenges of information technology projects. Team development, which involves building individual and group skills to enhance project performance. Key outputs of this process include training plans for project team members.
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
Team members have a stake in the success of the project. Consider the following as some of the commitments and understandings needed from team members:
•
A commitment to the goals and objectives of the project.
•
A commitment to the tasks and activities for which they will be responsible.
•
A realistic assessment of the time that the team member can devote to the project.
•
An understanding of functional responsibilities that may cause scheduling conflicts with the project.
Commitment is also needed from the functional managers of the people who will be working on the project:
•
A commitment to support the activities of his or her employees who are working on the project.
•
An agreement that the project is important and that the employee’s participation is required to accomplish project goals.
•
A realistic assessment of time that the employee can devote to the project.
•
An agreement on how conflicts between the need of the project and the needs of the functional department will be resolved.
If performing Purchased Package Selection and Implementation / PPSI, consideration should be given for: •
Vendor provided training
Originator: One IT PPM Team Page 76 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Diagram
§
Vendor participation on project team
§
Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Pre-commitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Identify skills and Resource Levels Required
Refine the list of skills required on the project that was developed at the beginning of the project. Include skills needed as a result of requirements gathered and any other analyses of project deliverables.
PM, Team, BusA
2
Identify Resources
Identify the available resources.
PM
3
Assess Resource Skill Levels
Assess the skills of the people available. It is the project manager’s job is to determine the risks associated with the available skill levels. This information is later used to determine the level of schedule adjustment that should be made to offset any short fall (i.e., to determine how much contingency to incorporate in to the plan to offset any lack of skill or experience on the team). It will also be used to identify any training requirements below.
PM
4
Determine Training Requirements
Identify and price any training that will be required to supplement team knowledge and skills. Refine the proposed budget to include any training costs.
PM
5
Determine Facilities/ Equipment
Identify the facilities and equipment (e.g., computers, cubicles/desks etc.) that will be needed for the people identified. See 3.1.1 Acquire/Release Facilities & Equipment
PM
6
Develop a Staffing Plan
For small projects, the staffing plan may be as simply stated as the assignment of three people full time to the project throughout its duration. On larger projects the plan may need to identify when staff will be brought onto and taken off the project team, with timing specified.
PM
7
Review Resource Plans
Review the resource plans with the Business Analyst and technical subject matter experts on the team.
PM, Team, BusA
Originator: One IT PPM Team Page 77 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 8
Refine the Project Charter
Refine the Financial Scope and Project Organization sections of the Project Charter to reflect the resource management decisions made.
Originator: One IT PPM Team Page 78 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project Skills assessment Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp
Outputs Resource Request located at http://www.ads.ford.com/resman/ 227_project_organization_chart_jobaid.ppt 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 216_project_organization_chart.doc 203_team_directory_template.doc
Originator: One IT PPM Team Page 79 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Competency Center, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
2.2
Refine Work Plans and Budget
2.2.1
Refine Project Approach
The purpose of this process step is to refine the Project Approach, including the project methodology, processes, accelerators, tools & techniques that will be used to achieve the project objectives. (Typically, revising Project Methodology from Unified to Classic or vise-versa is not likely to happen.) The objective of this process is to ensure that the project approach remains optimal throughout the project lifecycle. The methodology that is used, the team’s experience, and management philosophy provide guidelines for establishing the project framework. Some paths through a methodology mandate a specific approach but, generally, some decisions must be made about the way the project is to be conducted.
Trigger
Key Considerations
Signoff of the initial charter, development of project management plans, or the recognition of a need to change the methodology, processes or templates at any point in the project lifecycle. •
•
•
Diagram
When selecting the methodology, processes and templates, the project team should understand the differences between Classic SDM and Unified SDM. See the If the team is not familiar with both methods, a PQA coach will be able to present the related concepts for both methodologies and help with the selection process. Developing and refining the Project Approach can occur throughout the project lifecycle. The process titled "Develop Project Approach" develops the initial Project Approach, and the process titled "Refine Project Approach" does refinement. Accelerators are proven techniques for delivering value to the Customer quickly. Examples of accerators include prototyping, co-locating the customer with the project team, and time-boxing. At this stage in the project lifecycle, you may not have all of the information you need to select some of the accelerators that will be appropriate for the project. However, you should know enough to begin looking at them and selecting the ones that will obviously apply. The Accelerator Use Plan template can be used as a starting point for selecting and documenting accelerators that will be used.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
1
Review Accelerator Use Plan
Review the current Accelerator Use Plan (AUP) and determine if elements need to be updated or added based on information gathered since the initial plan was created.
PM, BusA
2
Update User Types
At this stage, you will know about the users and functionality required. Describe/update and prioritize all user types and enter this information into the AUP template.
PM, BusA, Cust
3
Describe
Work with the Customer to identify and describe the primary areas of
PM,
Originator: One IT PPM Team Page 80 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Business Functionality
functionality to be developed within the project.
BusA, Cust, 6-Sigma
4
Decompose Business Functionality
Work with the business analyst and Customer to decompose the business functionality into logical sub-areas.
PM, BusA, Cust
5
Prioritize Functionality
Work with the Customer to prioritize the business functionality based upon perceived benefit, value to the highest priority user types and the minimization of project risk. Enter this information into the AUP template.
PM, BusA, Cust
6
Select Accelerators
Update the list of accelerators to be employed (e.g.; time-boxing, prototyping, reusable software, co-location, etc.) and update that information in the AUP template.
PM, BusA, Cust
7
Update Plans to Reflect AUP
Update the Charter, Work Breakdown Structure, and Project Plan to reflect any decisions made about the sequence of activities, timing, or dependencies, as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project
Inputs to Process 204_accelerator_use_plan.doc 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc
Outputs 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 204_accelerator_use_plan.doc 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 81 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.2
Refine Work Plans
Purpose
The purpose of this process step is to refine and finalize the project work breakdown structure, dependencies network, estimates, and project schedule. It is also at this time that resources are assigned to tasks.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations
No key considerations provided for this process step.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Refine the Work Breakdown
Refine the work breakdown structure to reflect information gathered since project initiation. Add or remove activities and take the breakdown to its lowest level.
PM, Team
2
Refine Dependencies
Refine the dependency network to reflect task level dependencies.
PM, Team
3
Update Project Schedule
Update the project schedule to reflect the task-level work breakdown and assign specific resources. Make a note of any tasks for which a specific individual cannot be identified. You will need to use this information to refine resource plans and request additional resources.
PM, Team
4
Refine Project Estimates
Refine project estimates taking new work breakdown and resource assignments into consideration. Ensure that adequate contingency is baked into task estimates where resources are less skilled or liable to be distracted by competing responsibilities. Note: If using the SDM Estimating Model a task level plan will already be defined. Follow the instructions in that model to adjust estimating factors, as needed.
PM, BusA, Cust
5
Generate Baseline Work Plan
Update the MS Project Plan to reflect all of the changes identified. If the end-date has moved out, use the accelerator use plan and other factors to determine if the date can be bought back in line by deferring low priority functionality, adding resources, or other means. Baseline the schedule when timing and resource issues have been resolved.
PM, BusA, Cust
6
Update Project Records
Update the project record in ITMS, RMS and MRS to reflect the updated schedule and file documents in project Control File.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project
Inputs to Process
Originator: One IT PPM Team Page 82 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 204_accelerator_use_plan.doc 228_Classic_SDM_Estimating_Model.xls
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 204_accelerator_use_plan.doc 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp 228_Classic_SDM_Esitmating_Model.xls
Originator: One IT PPM Team Page 83 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File BusA Cust Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.3
Refine Risk Management Plans
Purpose
The purpose of this process step is to refine risk management plans based on information gathered since the initial risk assessment was conducted during project initiation.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations
•
Diagram
No diagram provided for this process step.
Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.
Process Tasks No
Task Name
Description
Participants
1
Identified Risk Factors
Review the risk assessment conducted during project initiation to determine if additional risk factors apply. If not, skip the remainder of this process step. If new risks identified, add them to the Risk Management Log (eTracker if in use).
PM, Team
2
Assess Risk Factors
Assess the level of impact, likelihood of occurrence, and potential impact on cost, time, and benefits and record in the Risk Management Log.
PM, Team, Cust
3
Define Mitigation Strategies
Define strategies for mitigating each additional risk. Refer to the Ernst & Young Risk Factor Strategies job aid for ideas on mitigating common risk factors.
PM, Team
4
Define Contingency Plans
Define contingency plans for each risk factor added and record that information in the log.
PM, Team
5
Confirm Risk Rating
Confirm the risk assessment score on the Risk Assessment Checklist and file the refined copy in the Project Control File.
PM
6
Record HH Risks in Charter
Enter any additional high impact, high probability risks into the Project Charter.
PM
7
Address Work Plan Impacts
Ensure that mitigation strategies and contingency plans are accurately reflected in the work plan
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 84 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word and MS Project eTracker at www.etracker.ford.com
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 207_risk_strategies_jobaid.pdf 204_accelerator_use_plan.doc 228_Classic_SDM_Estimating_Model.xls
Outputs 206_risk_assessment_template.xls 212_risk_management_log.doc 200_project_charter_template.doc
Originator: One IT PPM Team Page 85 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File BusA Cust Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.4
Refine Resource Requirements
Purpose
The purpose of this process step is to refine resource requirements based on the information gathered and planning completed since project initiation.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations No key considerations provided for this process step. Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Identify skills and Resource Levels Required
Refine the list of skills required on the project as needed
PM, Team
2
Identify Resources
Identify the available resources and assess their skill levels.
PM
4
Refine Training Plans
Identify and price any training that will be required to supplement team knowledge and skills. Determine the impact on the budget.
PM
5
Refine Staffing Plans
For small projects, the staffing plan may be as simply stated as the assignment of three people full time to the project throughout its duration. On larger projects the plan may need to identify when staff will be brought onto and taken off the project team, with timing specified.
PM
6
Review Resource Plans
Review the resource plans with the Business Analyst and technical subject matter experts on the team.
PM
7
Refine the Project Charter
Refine the Financial Scope and Project Organization sections of the Project Charter to reflect the resource management decisions made.
PM
Originator: One IT PPM Team Page 86 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel and MS Project Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 204_accelerator_use_plan.doc 206_risk_assessment_template.xls
Outputs Online resource request at http://www.ads.ford.com/resman/ 227_project_organization_chart_jobaid 216_project_organization_chart.doc 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request
Originator: One IT PPM Team Page 87 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust, Team, Competency Center, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.5
Refine the SOW
Purpose
The purpose of this process step is to refine the budget plan based the refined risk assessment, baseline schedule, functional requirements, accelerator use plan, and resource requirements.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations Diagram
•
Only Ford employees are authorized to access the SOW. Non-Ford employees should work with their Practice Manager to modify it.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Refine the Labor Budget
Refine initial resource requirements estimates. Use specific labor rates as appropriate.
PM, BusA, ImpA
2
Refine Remaining Budget Elements
Refine estimates and any non-labor costs. Consider additional facilities, equipment, training or travel identified since the initial SOW was created during project initiation.
PM, BusA, ImpA
4
Summarize Costs
Confirm or refine the SOW as appropriate. If changes are required, submit a new SOW to the ADS Business Office via the SOW Workflow process and tool documented at http://www.ads.ford.com. The Business Office review the SOW for completeness and accuracy, then circulate it for signature via the Work Flow Tool.
PM, BusA, ImpA
5
Update the Charter
Update the financial scope section of the charter or enhancement request, as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project
Inputs to Process
Originator: One IT PPM Team Page 88 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 204_accelerator_use_plan.doc 206_risk_assessment_template.xls http://www.ads.ford.com/resman/ SOW located at http://www.ads.ford.com
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 89 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, BusA, Cust, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.3
Confirm Readiness to Proceed
2.3.1
Confirm Requirements Specification Signoff
Purpose
The purpose of this process is to ensure that the Requirements Specification has been reviewed and approved by the Customer and that the final charter accurately reflects the information contained in that specification.
Trigger
Development of detailed Requirements Specifications and a baseline work plan and completion of all sections of the project charter as appropriate.
Key Considerations
For enhancement •
Are the requirements listed on the enhancement list?
•
For Purchased Package Selection and Implementation (PPSI) – ensure Vendor/Supplier understand the Requirments.
Note that Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A precommitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Pre-commitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Confirm Customer Signoff of Requirements Specification
Confirm that the final Requirements Specification has been reviewed and approved by the appropriate parties per the Solution Delivery Methodology. Ensure that the lead Customer(s) on the project has signed the specification document indicating concurrence with its contents.
PM, BusA, Cust, SolnArch, Vendor/Supplier
2
Ensure Alignment of Charter
Ensure that the scope section of the final project charter is aligned to the Requirements Specification.
PM, BusA, Cust
3
File Signed
File the signed Requirements Specification in the appropriate
PM
Originator: One IT PPM Team Page 90 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Requirements Specification
Control File folder.
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word
Inputs to Process 200_project_charter_template.doc 02_Requirements_Specification.doc
Outputs 200_project_charter_template.doc 02_Requirements_Specification.doc 230_Enhancement_and_Small_Project_Request
Originator: One IT PPM Team Page 91 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.3.2
Obtain Final Charter Approval
Purpose
The purpose of this process step is to ensure that all sections of the project charter have been adequately addressed and that the final charter accurately reflects the agreed goal, objectives, scope, project management approach, risk assessment, and project organization.
Trigger
Development of detailed Requirements Specifications and a baseline work plan and completion of all sections of the project charter as appropriate.
Key Considerations
The same key considerations that applied at the initial charter signoff, apply here.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Finalize Objectives
Ensure that project objectives are measurable and still accurately reflect the requirements and business success criteria.
PM
2
Finalize Scope
Ensure that all sections of project scope are defined and accurately reflect the understanding reached with the Customer.
PM
4
Finalize Project Mgt Approach
Ensure that all sections of the project approach are completed and accurately reflect decisions made concerning the methods that will be employed to manage quality, issues, risk, communications, procurement, support, implementation, and resource management.
PM
5
Finalize Risk Section
Ensure that the high impact and high probability risks are recorded in the risk section of the charter.
PM
6
Finalize Project Organization
Ensure that the project organization accurately reflects the team structure. Include an organization chart as appropriate.
PM
7
Review Changes
Review changes with the Business Analyst and Customer and decide if they require Sponsor review. Obtain Sponsor signoff.
PM, BusA, Cust, ESpon
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan.doc 206_risk_assessment_template.xls SOW located at http://www.ads.ford.com
Outputs
Recipients
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 206_risk_assessment_template.xls
Originator: One IT PPM Team Page 92 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, BusA, Cust, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.3.3 Purpose
Conduct Formal Kick-off
The kick-off meeting marks the formal start of the project. Generally, it is the first opportunity for the Sponsor or representative to meet with the entire project team to present a vision of the project, demonstrate support, and advocate project success. Its importance lies in setting the tone for the project and in establishing a common understanding of project goals and plans. The purpose of the Kick-off meeting is to
• • • • • • • •
Introduce team members Communicate project goals and objectives Review work methods and tools Communicate the roles and responsibilities of team members Set direction for the work to be completed Address team member questions Commit to the success of the project Promote team rapport
Trigger
Completion of the charter and development of a baseline plan.
Key Considerations
•
•
Diagram
Key considerations when planning and conducting the meeting include o
What decisions must be made before the meeting?
o o o
What information will be distributed to attendees in advance? What will be presented in the meeting? Who should attend?
Usability best practices training is available from Usability Services on a no-charge basis. This training can be scheduled by contacting Usability Services. This is recommended for all project team members, including the Customer, developers, etc.. For more information go to http://www.usability.ford.com/training.
The following diagram shows inputs and outputs for this activity.
Process Tasks No 1
Task Name Identify Participants
Description Work with the Sponsor, the Practice Manager, and Business Analyst to determine who needs to be at the kick-off.
Originator: One IT PPM Team Page 93 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants PM, PracticeMgr, Sponsor, BusA
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 2
Schedule Kickoff
3
Develop Agenda
PM
Identify the date, time and place. Reserve the meeting room and any presentation equipment required. Introduction:
Sponsor or Rep – Welcome address.
PM, BusA, Sponsor
Project Manager – Describes the agenda. Introduction of Attendees:
Participants introduce themselves, describe their concerns and expectations.
Project Overview:
Sponsor – Background to the project, the Customer, why it is important to be successful, future opportunities, Customer needs and expectations, and high -level project scope.
Project Goals and Objectives:
Project Manager – Presents what’s known of project goals and objectives, key milestones, and critical success factors. The Concept Profile, Executive Summary, and interview with the Sponsor to prepare.
Project Organization:
Project Manager – Presents the organization chart along with roles and responsibilities of each team member.
Project Plan:
Project Manager – Presents the Project plans, including communications & team training plans.
Methods and Tools:
Project Manager – Describes the project management model, the documentation, the processes, and highlights the way progress will be monitored.
Question and Answer:
Project Manager – Leads brief question and answer period.
Summing Up:
Project Manager – Summarizes the meeting and reminds everyone of action points with target completion dates.
4
Distribute Materials
Distribute the agenda, Project Charter, Project Plan, and any other relevant material ahead of the meeting.
PM, Admin Support
5
Conduct the Meeting
Conduct the meeting, taking notes on any issues raised and/or action points
PM, BusA, ESpon
6
Distribute Minutes
Distribute minutes of the kickoff to attendees and appropriate stakeholders who were not in attendance.
PM, Admin Support
Originator: One IT PPM Team Page 94 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 95 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan.doc 206_risk_assessment_template.xls SOW located at http://www.ads.ford.com 201_stakeholder_assessment.doc 203_team_directory_template.doc 215_communication_plan_template.doc
Outputs 218_kickoff_meeting_checklist.doc 219_kickoff_meeting_agenda_template.doc
Originator: One IT PPM Team Page 96 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, ESpon, Team, Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.0
Execute Project Project Management Processes
Resource Plan Procurement Plan
Initiate
Communication Plan
Budget Plan Project Charter
Plan
Transition Plans
Execute
Work Plan Solution Delivery Methodology
Control
Close
Inputs to Execute Project
Overview
Process Contents
Project Execution results in the completion of the work identified in plans created during Project Initiation and Planning. During execution of the project:
•
Facilities and supplies are acquired.
•
Resources are acquired, trained, and assigned work.
•
The project organization, procedures, and reporting mechanisms are established.
•
Work activities are directed, evaluated, and redirected in keeping with project goals and limitations.
•
Project documentation is created and stored for easy access and review by the project team and stakeholders.
•
Records used to describe the project and communicate its status in relation to other projects are maintained (e.g., your project’s record in ITMS) Objectives 3.1
3.2
Manage Project Execution
Manage Project Information
Processes
Key Deliverables
3.1.1
Acquire/Release Facilities and Equipment
Move Request/GIRS
3.1.2
Acquire/Release Team Members
Resource Requests
3.1.3
Direct & Coordinate Plan Execution
Work Products
3.2.1
Maintain Project Records
Documentation
3.2.2
Distribute Project Information
Originator: One IT PPM Team Page 97 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Meeting Minutes, Reports and Notices
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.1
Manage Project Execution
3.1.1
Acquire/Release Facilities & Equipment
Purpose
The purpose of this process is to ensure that facilities (e.g., space for a colocated team) and equipment (e.g., PCs, phones, security badges, etc.) are acquired.
Trigger
Signoff of the final project charter.
Key Considerations
Key Considerations for this process are:
Diagram
•
What hardware and software will be required for team members?
•
Will software licenses be required?
•
Are new security badges and network access required?
•
Do team members need to be moved from one building or room location to another?
•
Will team members be co-located and is a team room required?
•
Is the cost of training and software included in the SOW?
•
Reference the introductory section in this guide titled "Project Authorization Requests and Purchase Orders" for further information on Project Appropriation Requests / PARs and Purchase Orders POs.
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Obtain Team Facilities
Request team room(s) or cubicles as appropriate to the location and resource requirements.
PM
2
Obtain Workstations and Other Equipment
Determine what workstations, network access, shared drives, phones, eRooms, and other facilities or equipment will be needed and submit the appropriate requests through the help desk.
PM
3
Request Software
Determine if specific software licenses will be required (e.g., licenses for MS Project) and submit the appropriate support requests through the help desk (GIRS). The cost of software should be included in the SOW.
PM
4
Schedule Facilities, Hardware, and Software
Ensure that the setup of cubicles, team rooms, equipment and software are scheduled and completed on time.
PM
5
Verify Supplies
Verify that adequate office supplies are available and accessible to the team.
PM
6
Verify
Verify that team hardware and software are functioning properly before
PM,
Originator: One IT PPM Team Page 98 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Workstation and Development Environment
work begins.
Team
Tools/Techniques Summary Methods and Applications/Tools US ADS Move Request use http://www.ads.ford.com/facilities/ All Other Locations Use Ford Land Move Request at http://www.dearborn3.ford.com/fmls/move/ Help Desk Request
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 02_Requirements_Specification.doc SOW located at http://www.ads.ford.com
Outputs Move Request (see Tools Above) GIRS Tickets
Originator: One IT PPM Team Page 99 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Ford Land, Help Desk
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.1.2
Acquire/Release Team Members
Purpose
The timely requisition and development of team members whose skills match the project’s requirements is vital to project success. As a project progresses, the skills needed may change. While a core set of team members may remain throughout the project, other resources may come and go as needed. For example, more experienced resources (subject matter experts) are particularly important in the early stages of the project when objectives are being defined and decisions are made on how those objectives will be met. Later, when plans are firmed, less experienced resources can be taken on board and directed in the work needed to complete the tasks that have been defined. It is up to the project manager to identify the resources and skills that will be required throughout the project and take appropriate action to complete those plans.
Trigger
The trigger for this process will depend on the project plan and what that plan says about the requisition or release of resources in each stage of the project. At this stage, the trigger will be signoff of the final charter.
Key Considerations
The key considerations for this project are:
•
What skills/roles are needed to do the work planned for the current stage?
•
What resources have been identified to fill those roles?
•
What resources are to be released from the project at this point, if any?
•
What training or orientation do new or existing team members need?
• •
•
Diagram
If performing Package Product Selection and Implementation / PPSI, consideration should be given to providing application-specific or package-specific training to team members. Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Precommitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information. If performing Package Product Selection and Implementation / PPSI, consideration should be given to having personnel from the product vendor participate in the design, development, testing, training and roll-out of the solution.
No diagram provided for this process.
Process Tasks No 1
Task Name Identify Skills
Description
Participants
Create a two dimensional matrix. List the skills/knowledge needed on
Originator: One IT PPM Team Page 100 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM,
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Needed
the project – particularly in early stages – down one side.
BusA
2
Identify Candidates
List the potential team members across the top of the matrix.
PM, BusA
3
Map Skills to Candidates
Mark the intersection between skills/knowledge and each candidate. Identify and close gaps.
PM, BusA
4
Interview Candidates
Interview candidates.
PM
5
Obtain Required Resources
Request and engage resources required. Engaging resources includes providing them with background on the project. It may also entail follow through on training plans for resources.
PM, Sponsor
6
Request Badge, Phone or Move
Direct new employees to the web sites or local support functions that they will need to contact to get phones installed and access to the building, printers, and shared drives.
PM, Team
7
Update the Team Roster
Create a team roster identifying team members, their home organization, their role, and the amount of time that they will be available.
PM
8
Orient Team Members
Provide new team members with background on the project and access to any existing documentation.
PM, Team
9
Notify Competency Center of Upcoming Release of a Ford ADS Resource
Send an MS-Outlook note to the appropriate Competency Center Manager 30 days prior to the release and notify him/her that the resource will be released and the date of the release. If the resource doesn't know whom their manager is, the note should be sent to Don Bartkowiak (DBARTKOW).
AppSupr, Competency Center Manager
10
Notify Agency of Upcoming Release of Agency Resource
Send an MS-Outlook note to the appropriate agency representative 2 weeks prior to the release and notify him/her that the resource will be released and the date of the release.
AppSupr, Agency Representative
11
Notify RMS of Resource Release
Send an MS-Outlook note to cdsid RMSHELP to inform them that the resource will no longer be working on the application and should not bill against it any longer.
AppSupr
12
Perform Exit Procedure
Follow the instructions at the exit procedure link located at http://www.ads.ford.com/facilities/. This procedure covers the removal of application access, building access and other tasks.
AppSupr
Note: As per the new Competency Center Guide, Ford ADS resources will have been assigned a Competency Center Manager. The AppSupr should obtain the Competency Center Manager's name from the resource.
Tools/Techniques Summary Methods and Applications/Tools US ADS Only Use Following Link for Move Requests http://www.ads.ford.com/facilities/ All other locations use Ford Land Move Request at http://www.dearborn3.ford.com/fmls/move/ Help Desk Request Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process
Originator: One IT PPM Team Page 101 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp http://www.ads.ford.com/resman/ 203_team_directory_template.doc SOW located at http://www.ads.ford.com
Resource Request located at http://www.ads.ford.com/resman/ 203_team_directory_template.doc Move Requests (see Tools Above)
Originator: One IT PPM Team Page 102 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Competency Center, Resource Mgmt, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.1.3
Direct & Coordinate Plan Execution
Purpose
The execution of project plans is an ongoing process that requires that the project manager ensure that every step in the plan is required and carried out. This includes ensuring that team members and stakeholders understand what is expected of them and following-up to ensure that they fulfill their obligations.
Trigger
Signoff of the charter.
Key Considerations
No key considerations defined for this process step.
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Assign Tasks to Team Members
Ensure that team mem bers are aware of assignments including those added after the plan is baselined to deal with issues, risks, and change requests. Also ensure that team members have a say in the amount of time they are given to complete tasks. Solicit team member input when estimating the duration of added tasks (i.e., tasks added in response to issues, risks, and scope changes that are identified after the plan is baselined.)
PM, Team
2
Ensure Stakeholders Understand their Role
Provide stakeholders who are outside the core team with a copy of the plan so they understand what is expected of them over the life of the project. Stakeholders include, but are not limited to the Sponsor, lead Customer, Business Analyst, and other subject matter experts whose input will be required at various points over the project life cycle.
PM, Stakeholders
3
Execute Project Manager Tasks
Ensure that tasks that rightfully belong to the Project Manager are carried out per the project plan.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel, MS Project RMS-- http://www.rms.ford.com
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 201_stakeholder_assessment_matrix.doc 203_team_directory_template.doc Timesheets http://www.rms.ford.com 210_change_request_template.doc 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc
Outputs 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 103 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, ESpon, BusA, Cust, Team, Other Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.2
Manage Project Information
3.2.1
Maintain Project Records
Purpose
The purpose of this process is to ensure that project records are kept current and available as needed.
Trigger
Charter signoff.
Key Considerations
No key considerations provided for this process step.
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Keep Record in Control File Up to Date
Ensure that the records in the project Control File are kept current and available to stakeholders who need access.
PM
2
Post Actuals to Plan
Ensure that the project plan is kept current by posting actuals and any scope changes that are signed off by the project Sponsor.
PM
Note: Keep project plans current by applying actuals hours and actual start and end dates on each task. 3
Maintain Project Control Logs
Ensure that issue, risk, and change logs are kept current. Provide access to key stakeholders so new issues and risks can be documented in the appropriate logs.
PM
4
Maintain Project Record in ITMS
Ensure that the project record in ITMS is kept current per ITMS procedures.
PM
5
Maintain Project Record in RMS
Ensure that the project record in RMS is kept current per RMS procedures.
PM
6
Maintain Project Record/Metrics in MRS
Ensure that project records are kept current in MRS.
PM
Tools/Techniques Summary Methods and Applications/Tools
Originator: One IT PPM Team Page 104 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Microsoft Word and Excel MRS ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS RMS – http://www.rms.ford.com MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process Timesheets http://www.rms.ford.com 221_weekly_status_report_template.doc 210_change_request_template.doc 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 212_risk_management_log.doc
Outputs Updated project records 221_weekly_status_report_template.doc 210_change_request_template.doc 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc Project Hours http://www.rms.ford.com
Originator: One IT PPM Team Page 105 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.2.2
Distribute Project Information
Purpose
A successful project is one that meets its objectives through appropriate methods and means of collecting and distributing project information. Project Communications Management provides the critical link among people, ideas, and information. Everyone involved in a project must be ready to send and receive communications and must understand how the communications affect the project as a whole. The purpose of this process is to ensure that this distribution of information occurs in a timely fashion and according to the project communication plan.
Trigger
Generation of the weekly status reports, the completion of a stage gate, at a planned point in the communication plan, or at any other critical decision point that occurs during the life of the project.
Key Considerations
No key considerations provided for this process.
Diagram
The following diagram shows where Information Distribution fits into the overall communication management process.
Process Tasks
Originator: One IT PPM Team Page 106 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Execute Communication Plan
On a weekly basis, review the project communication plan to determine what information must be distributed and to whom and act accordingly.
PM, Stakeholders
2
Communicate the Results of Key Decision Points
Notify stakeholders at key decisions points including, but not limited to, charter signing, stage completion, the results of status reports, the results of sponsor reviews, the results of technical reviews (see section 4.2.4 Coordinate Security Reviews & Certification), scope changes, etc.
PM, Stakeholders
3
Respond to Requests for Information
Provide access to information as appropriate, including project logs and other records, and respond to specific questions asked concerning the purpose of the project and the status of the project.
PM, Stakeholders
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word Email Meetings eRoom Web Sites
Inputs to Process 201_stakeholder_assessment_template.doc 203_team_directory_template.doc 215_communication_plan_template.doc See also the SDM Process Guide
Outputs 221_weekly_status_report_template.doc Results of reviews Approval to Proceed
Originator: One IT PPM Team Page 107 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 108 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.0
Control Project Project Management Processes
Resource Plan Procurement Plan
Initiate Communication Plan
Budget Plan
Plan
Work Plans
Project Charter
Execute
Work Products Solution Delivery Methodology
Control Close
Inputs to Control Project Overview
The Project Management Institute (PMI) defines Project Control as follows: A project management function that involves comparing actual performance with planned performance and taking corrective action (or directing or motivating others to do so) to yield the desired outcome when significant differences exist. Monitoring and controlling the project also involves proactive management of scope, risks, quality, and issues and project reviews to ensure that stakeholders are satisfied that the project will succeed and should continue as planned.
Process Contents
Objectives 4.1
4.2
Monitor and Control the Project
Conduct Project Reviews
Processes
Key Deliverables
4.1.1
Monitor and Control Scope
4.1.2
Monitor and Control Schedule/Costs
4.1.3
Monitor and Control Risks
4.1.4
Monitor and Control Issues
Issues Resolution/Log
4.1.5
Monitor and Control Quality
Checklists and Metrics
4.2.1
Conduct Status Reviews
4.2.2
Coordinate Architecture Reviews
4.2.3
Coordinate Metrics Workshops
4.2.4
Coordinate Security Rev/Certification
ACR/ICR/Cert. Results
4.2.5
Coordinate PQA Reviews
Results of QA Reviews
4.2.6
Lead Gate Reviews
4.2.7
Support Operations Reviews
Originator: One IT PPM Team Page 109 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Change Requests/Log Updated Plans Risk Management Log
Status Reviews Architecture Rev. Results Function Point Counts
Go/No-Go Decisions Input to Ops Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1
Monitor and Control the Project
4.1.1
Monitor and Control Scope
Purpose
The purpose of Scope Control is to protect the viability of the approved project plans and deliverables. Scope changes can be caused by business changes, technical changes, requirements that were missed or not known when the project was funded, and errors or omissions in design.
Trigger
Submission of a new project change request and the monitoring of change requests during weekly status reviews.
Key Considerations
Diagram Updated Work Plan
Key considerations in controlling project scope are • •
What priority, importance has the requester attached to the change? What impact will the scope have on timing, costs, benefits, and planned and completed deliverables? • Is the change containable within the existing plan? • What impact will the change have on other related projects? • Can the change be deferred until the system is handed over for ongoing support and maintenance? The diagram below depicts the high-level process flow for this activity. Includes:
Investigate Change Request
Updated Records/ Plans
Project Charter ITMS Record
Assign & Schedule Investigation Change Requested
Log New Change Request
Recommend a Course of Action
Resource Request
Risk Assessment Budget Plan
Obtain Approval
Group Requests if Appropriate
Updated Change Log
Originator: One IT PPM Team Page 110 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Change Approved ?
No
Close Request & Communicate Status
Yes
Update Project Plans & Records
Obtain Resources if Required
Complete the Request
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Log New Change Request
Ensure that the change request has been submitted on the appropriate form and that sufficient details have been provided to allow for assessment. Note: All changes are to be logged, even small ones.
Stakeholders
2
Group Requests
Review change log to determine if other similar or related requests are outstanding. Group requests, if appropriate.
PM, Team
3
Schedule Investigation
Assign a resource to investigate the request and add that effort to the project schedule, as appropriate.
PM
4
Investigate the Change Request
Investigate the change and its potential impact on project objectives, resources, budget and schedule, and any related projects. Estimate the effort to complete the change and determine if additional funding and/or resources/skills will be required.
Team
5
Recommend a Course of Action
Based on the investigation recommend a course of action.
PM
•
Reject or defer the request
•
Contain the change within the existing plan
•
Defer some other deliverable to contain the change
• •
Request a change to the project timing, resources, and/or budget or use of reserves to satisfy request. Request that a new project be planned (i.e., if the change will extend the timeline significantly – by 25% or more, it may make more sense to treat it as a separate project)
6
Obtain Approvals
Any request that requires a change in the approved deliverables, resources, budget or end-date, a new project, or the use of project reserves must be approved. Recommendations to defer or reject changes that have been submitted by the intended recipients of deliverables should also be reviewed and signed off by the Customer and Sponsor.
PM, ESpon, Program Mgr BusA, Cust
7
Update Project Records and Plans
Update project records and work, resource, budget plans, and SOW as appropriate. This includes updating the project record in ITMS, RMS and MRS.
PM
8
Request Resources
Submit a resource request if additional resources are required and approved to complete the change.
PM
9
Close the Request & Communicate Status
Notify the stakeholder who submitted the request of the decision to complete or reject the change request. Notify other stakeholders as appropriate (e.g., the Project Mangers of related projects)
PM
Originator: One IT PPM Team Page 111 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools eTracker – see http://www.etracker.ford.com/ ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs Resource Request located at http://www.ads.ford.com/resman/ MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 210_change_request_template.doc 211_change_request_log.doc 02_Requirements_Specification.doc 213_issue_log.doc 212_risk_management_log.doc SOW located at http://www.ads.ford.com
Outputs
Recipients
210_change_request_template.doc 211_change_request_log.doc Resource Request located at http://www.ads.ford.com/resman/ Project Record in MRS http://www.ads.ford.com/mrs 229_Classic_SDM_Work_Plan.mpp 213_issue_log.doc Logs listed or logs in eTracker SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 112 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
ESpon, Program Mgr, BusA, Stakeholders, Competency Center, Resource Mgmt, Demand Mgmt
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.2
Monitor and Control Schedule/Costs
Purpose
After planning, monitoring and controlling the project schedule and project costs is one of the most important tasks that the project manager performs. Once a plan is in place and work is underway, it is the project manager’s job to collect information from each team member, on a weekly basis, to determine if work and spending are proceeding as agreed. Any variance from plan must be assessed to determine if action is needed to prevent schedule or cost overruns or get the project back on track.
Trigger
This process is triggered by weekly status reporting, or whenever a problem is noted in the timing or costs of the project.
Key Considerations
Diagram
The questions/issues that need to addressed during this process are: • Is the project ahead of or behind schedule? • Has spending exceeded the budget plan? • What are the root causes of schedule or cost variances? • Will the scope of the project be impacted by proposed corrective actions? The diagram below depicts the high-level process flow for this activity.
Process Tasks No
Task Name
Description
Participants
1
Assess Schedule & Cost Performance
Determine project status and spending in relation to the approved plans. Assemble pertinent materials, including the most recent weekly timesheets, expense reports, the current approved Project Plan and Budget, and any other documents that provide quantifiable data. Determine if the work is on track, ahead of plan, or behind plan, based on the resources spent (the burn rate) and the progress made. Assess resource utilization to determine if resources have worked to the level agreed. Review expenses to see if they are in line with the budget plan.
PM, Team
2
Analyze Variances
Analyze variances to determine their root causes and assess their impact on baseline plans. Use Earned Value Analysis to calculate the project’s SPI (Schedule Performance Index) and CPI (Cost Performance Index). Determine if the variances warrant taking corrective action.
PM
Note: A SPI or CPI lower than 1 indicates a problem 3
Log & Track as an Issue
Log any variance that requires corrective action as an issue and track accordingly.
PM
4
Identify Alternative Solutions
Identify the actions that must be taken to get the project back on track or keep it progressing on schedule. Distinguish between minor corrective actions (those that can be managed within the current plan) and those that change the approved project plan (end-date and/or budget) and, thus, require formal approval from the project sponsor and other stakeholders.
PM, Team, Program Mgr
For larger adjustments and those situations in which the current project plan will not suffice, identify alternative solutions. Refer to your Accelerator Use Plan for alternatives. Examine each Originator: One IT PPM Team Page 113 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide alternative for its impact on the project objectives, scope, benefits, schedule, quality, and budget. Determine how changes to the project plan will impact other efforts and what level of coordination is necessary. Select the most effective approach. Note: If the corrective action requires a change in the scope of the project (e.g., a change in deliverables, budget, timing, etc.), generate and log a Change Request and manage accordingly. 5
Identify Corrective Action
Identify what action will be taken to correct the schedule or cost issue.
PM, Team
6
Obtain Approvals (as Required)
Get signoff on actions that will alter the current approved schedule, budget or resource plan. If the schedule is changed, the Project Manager needs to notify the Competency Center. The resource's agency must approve the change. Update ITMS, SOW and record in RMS.
PM, Sponsor
Note: Using reserves, overtime, or additional resources, or rescheduling the project, as a solution, will require approval. 7
Update & Close Issue
Update project plans, as appropriate, and update and close the issue.
PM
Tools/Techniques Summary Methods and Applications/Tools http://www.etracker.ford.com/ Earned Value Analysis see http://www.ads.ford.com/eva/ MS Project Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan 210_change_request_template.doc 213_issue_log 02_Requirements_Specification.doc Timesheets http://www.rms.ford.com SOW located at http://www.ads.ford.com
Outputs Resource Request located at http://www.ads.ford.com/resman/ 204_accelerator_use_plan 210_change_request_template.doc 213_issue_log 229_Classic_SDM_Work_Plan.mpp Earned Value Analysis located at http://www.ads.ford.com/eva/ SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 114 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients ESpon, Program Mgr, BusA, Stakeholders, Competency Center, Resource Mgmt, Demand Mgmt
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.3 Purpose
Monitor and Control Risks
The goal of risk management is to ensure that risks are identified, analyzed, monitored and controlled, proactively. Risks are factors that have the potential to interfere with successful completion of a project. Risks are not issues – issues have already occurred, whereas risks may or may not occur. By addressing risks as soon as they are identified, the project team can assess their potential impact on the project and develop plans to manage them. Note: This process follows the initial risk assessment that is completed during Initiate Project and the development of risk management strategies that is completed during Plan Project. However, is assumed that additional risks may be identified during project execution and control. For this reason, the entire risk lifecycle is described here, including risk identification, analysis and planning.
Trigger
This process is triggered by weekly status reporting, or whenever a new risk is identified.
Key Considerations
Some questions to be addressed in identifying and controlling project risk are:
• • • • • Diagram
Are existing risk strategies working? Have any new risks been identified since the initial risk assessments and planning were completed? Have any risks been resolved (i.e., no longer a threat to the project)? Will new mitigation strategies or contingency plans impact project timing, resource plans or budget and require approval? Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.
The diagram below depicts the high-level process flow for this activity.
New Risk Identified
Log Risk
Weekly Status Review
Assess the Risk
Develop Plans to Manage
Track & Control Risk
Risk Under Control?
No
Raise Issue
Yes
No
Risk Resolved ? Yes
Updated Risk Log & Plans
Close Risk & Update Plans
Process Tasks Originator: One IT PPM Team Page 115 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Identify and Log Risk
Identify a new Risk and log it into the Risk Management Log. Note: Most project risks should have been identified during Project Initiation as part of the Initial Risk Assessment. Those risks along with any new ones identified over the course of the project will be monitored and controlled here to ensure that mitigation strategies and contingency plans are effective.
Stakeholders
2
Analyze Risk
Work with project team mem bers to transform risk data into decision-making information. Categorize the risk in terms of how it impacts the project. Determine the level of impact of each risk (High, Medium or Low), the probability that each risk will occur (High, Medium or Low). Estimate the impact that the risk might have on costs, effort, timing, and benefits.
PM, Team
3
Develop Plans to Manage
Identify mitigation strategies (strategies to help minimize or avoid the risk) and develop contingency plans (plans to go into effect if mitigation strategies should fail). Ensure that mitigation actions are incorporated into the project plans, as appropriate Note: The E&Y Risk Management Strategies Document provide suggested mitigation strategies for many common risk factors.
PM, Team
4
Track & Control Risk Review actions against plan to determine if mitigation strategies are working. Institute contingency plans if necessary or develop new strategies to manage the risk.
PM, Team
5
Raise Issue
Where risk management strategies are not working, raise an issue for immediate action.
PM, Team
6
Close Risk & Update Plans
Close risks that are no longer a potential threat to the timing, cost or quality of project deliverables or risks that have been converted to an issue.
PM
Tools/Techniques Summary Methods and Applications/Tools MS Project
Inputs to Process 206_risk_assessment_template.xls 212_risk_management_log.doc 207_risk_strategies_jobaid.pdf
Outputs 206_risk_assessment_template.xls 212_risk_management_log.doc 213_issue_log.doc or eTracker located at http://www.etracker.ford.com/ 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 116 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Sponsor Program Mgr BusA Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.4 Purpose
Monitor and Control Issues
An issue is an immediate problem that will be detrimental to the success of the project if it is not resolved quickly. If there is no urgency to resolve the issue or if the issue has been active for some time, then it may not really be an issue. It may be a potential problem (risk), or it may be an action item that needs to be resolved at some later point. Issues, by their nature, must be resolved with a sense of urgency. The resolution of an issue usually requires the assignment of one or more action items. Each action item should have a responsible person and a due date clearly identified. The Project Manager should have an activity in the work plan every week to follow-up on issues to ensure they are diligently resolved.
Trigger
Weekly status review or the identification/resolution of an issue.
Key Considerations
The key considerations in monitoring and controlling issues are
• What impact will the issue have on the schedule, costs and quality of deliverables?
• Who will be responsible for resolving the issue and by what due date? • How much time is required to investigate the issue and what impact will that have on the project plan?
• Will approval and/or action be required from other organizations to resolve the issue?
• What level of management needs to be involved to resolve the issue? Diagram
The diagram below depicts the high-level process flow for this activity.
Issue Identified
Log Issue
Weekly Status Review Assign To Resource for Resolution
Updated Work Plan
Develop Resolution Strategy
Scope Change Required?
Resolve or Escalate Issue
No
Monitor Issue Status
Issue Resolv ed?
No
Yes
Yes Submit Change Request Updated Issue Log
Close Issue
Originator: One IT PPM Team Page 117 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Process Tasks No 1
Task Name Identify & Log Issue
Description
Participants Stakeholders
Identify the issue and supply the following information to assess it properly: Description
A description of the issue
Level of Issue
An assessment of the issues overall potential impact: High, Medium or Low
Impact of Issue
The estimated impact of the issue on costs, effort, timing, and gross benefits, if known.
Proposed Solution
A proposed resolution or plan of action if known.
Comments
Any other comments that will help the Project Manager assign or escalate the issue
Note: Anyone involved in or impacted by the project can submit an issue, including team members, users, support functions, etc. 2
Assign for Resolution
Assign the issue for further investigation and resolution. Identify a due date and enter the information into the Issue Log (eTracker, if in use). Update the work plan to reflect the new assignment.
PM, Team
3
Develop Resolution Strategy
Develop a resolution strategy and review it with the project team. Determine if the strategy will require a change in the project scope. If it does, close the issue, submit a Change Request and manage accordingly.
PM, Team, BusA, Cust
4
Monitor Issue Status
Review the status of the issue in weekly project status review meetings.
PM
5
Resolve or Escalate the Issue
Resolve the issue within the project team or escalate it to the Sponsor, Program Manager, or Business Analyst.
PM, Team, BusA, ESpon
6
Close Issue
Close Issues that are resolved and update the log entries accordingly.
PM, Team
Tools/Techniques Summary Methods and Applications/Tools http://www.etracker.ford.com/ MS Project
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 213_issue_log.doc 02_Requirements_Specification.doc 35_Quality_Control_Plan_and_Test_Strategy.doc or 89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support
Originator: One IT PPM Team Page 118 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Issues in 213_issue_log.doc or eTracker 229_Classic_SDM_Work_Plan.mpp 210_change_request_template.doc 211_change_request_log.doc
Control File, Program Mgr, BusA, ESpon, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.5
Monitor and Control Quality
Purpose
The primary purpose of quality control is to keep errors out of the hands of the Customer through prevention (keeping errors out of the process) and inspection (finding and removing errors from deliverables). Quality control is performed to ensure that the product and interim deliverables are acceptable. Quality Control consists of technical inspections and tests. Quality control should be performed incrementally throughout the project life cycle so that defects (errors and omissions) can be identified and rectified as early as possible.
Trigger
Project deliverable ready for inspection and weekly status reviews.
Key Considerations
As shown on the diagram below, which depicts the relative cost of addressing defects over the life of the project, the earlier in the life cycle a defect is found, the less costly it is to correct. 120 100 80 60 40 20 0 Analysis
Diagram
Design
Build
Implement Source: International Institute of Learning
The diagram below depicts the high-level process flow for this activity.
Methodology/ Quality Standards
Yes Monitor Process & Deliverables
Project Plans & Deliverables
Record Results
Results Acceptable ?
No No
Implement Rework or Improvement
Yes
Rework or Improvement Required?
Originator: One IT PPM Team Page 119 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Determine Course of Action
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No 1
Task Name Monitor Process & Deliverables
Description
Participants
Inspect deliverables and monitor the performance of required processes.
PM, Team
Inspections include activities such as measuring, examining, and testing undertaken to determine whether deliverables conform to requirements. Monitoring of the process involves the use of checklists and reviews to confirm that the process is being followed. It also involves the use of control mechanisms to monitor cost and schedule variances (earned value reports), the volume and frequency of changes (change logs), the timely resolution of issues (issues management logs), and other management results that help determine that the process is in control and, thereby, that quality is control. 2
Record Results
Capture results on acceptance documents, control charts, trend analyses, checklists, and defect or incident reports, as appropriate. Maintain records for use in project reviews.
PM, Team
3
Identify Issues and Determine Course of Action
Where defects or unacceptable results have been identified, determine what course of action is required. Defects in deliverables must be corrected before moving on. Failure to complete some process steps or adhere to standards may also require rework or the improvement of some deliverables.
PM, Team
4
Complete Rework or Improvement
Schedule and complete any rework or improvement required.
PM, Team
Defect Management Within Quality Management Process
A defect is defined as a non-conformance to requirements. The purpose of Defect Management is to ensure that defects are documented and resolved with a minimum impact on the project. Defects that are found during inspections and testing are documented using the defect log and tracked to ensure that a resolution occurs. If Test Director is being used as the testing repository, the Defect Tracking portion of Test Director will be used. The following diagram depicts the defect management process within the Quality Management Process.
Originator: One IT PPM Team Page 120 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Defect Management Process Flow A
Adds a defect, status=“New”
No
The defect is rejected, status=Rejected
Is it a defect?
Yes No
Will it be addressed in the current release?
No
Yes
Convinced with this resolution?
Yes Assign the defect to a developer status = “open”
B
Status=“Rejected” Developer fixes the defect, status=“fixed” Rebuild the deliverable and roll to the test environment where the developer verifies the fix, status=rolled
Was the defect associated with a change?
No
Update test cases as needed, test the fix in test environment
Yes
A
New Defect
Current/New/ Old found?
Defect Still Exists
Defect Closed The defect is deferred, Status=“Deferred”
Status=“Closed”
Status=“Reopen”
Done
Root Cause Change Follow the Change Management Process
B
No
Task Name
1
Log Defect
2
Analyze Defect
Description
Participants
Enter the defect in TestDirector as 'New' and categorize the defect (e.g.; Critical, Serious, Moderate, Cosmetic). Note: test status should be sent on a periodic basis to the Project Manager, usually after the completion of a logical group of tests or at suitable intervals Analyze the defects reported and change their status to either 'Open', 'Deferred' or 'Reject'.
Person who found the defect
PM, LDevl, QCTest
If 'Reject' or 'Deferred', specify in the 'R&D Column' on why it is being rejected or deferred. If defects are 'Opened', assign them for correction/fixing 3
Correct Defect
Correct the defect. Using the configuration management system (e.g.; PVCS, ChangeMan, etc.), check the corrected deliverable back into the source control area and change the status of the defect in TestDirector from 'Open' to 'Fixed'. Also enter the 'Root Cause' of the defect (e.g.; Requirements, Design, Coding, Data, database, Environment, Configuration, Change). Note: changes to documents as a result of the defect correction should be logged either in the project issue log or as a change request.
SDevl
4
Rebuild
Rebuild the deliverable using the configuration management
SCM
Originator: One IT PPM Team Page 121 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide application
system and "roll it forward" to the QC environment, informing all the version number of application with a list of defect-IDs fixed
5
Confirm Application Readiness
6
Test Application
Confirm that the application is functioning properly in the QC environment prior to testing. Make sure that the correct deliverable has been rolled to QC environment, and change the status to 'Rolled' Update Test Case(s) if necessary. Re-run the tests as documented in the TestDirector. If the defect is seen again – change the status to 'Re-Open'.
SDevl
QC Team, BusA, Sdevl, Cust (e.g.; who ever raised the defect)
If the defect is addressed (not seen) – change the status to 'Closed'.
7
Update Defect Status
If a new defect is discovered, then log as "New". If a defect is 'Re-Opened' – all steps from step 2 are repeated.
Originator: One IT PPM Team Page 122 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
QC Team, BusA, Sdevl, Cust (e.g.; who ever raised the defect)
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools eTracker at http://www.etracker.ford.com/ MS Project
Inputs to Process
Outputs
212_risk_management_log.doc
212_risk_management_log.doc
213_issue_log.doc
213_issue_log.doc or eTracker
229_Classic_SDM_Work_Plan.mpp
Acceptance Decisions
233_Gate_Review_Checklists.xls
Defects in 32_Defect_Log or Test Director
239_PQA_Review_Report.doc 32_Defect_Log or Test Director
Recipients Control File, Program Mgr, BusA, ESpon, Team, Metrics
Process Adjustments
52_Technical_Inspection_Summary_Form 57_PQA_Review_Checklists.xls 73_ARB_Workbook 35_Quality_Control_Plan_and_Test_Strategy.doc or 89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support All Project Work Products Issues in 213_issue_log.doc or eTracker
Originator: One IT PPM Team Page 123 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2
Conduct Project Reviews
4.2.1
Conduct Status Reviews
Purpose
Status reviews are an important tool in ensuring that project team members, Customers, sponsors, and other stakeholders are kept informed of progress, issues, risks, and changes. It is also an opportunity for the team to review the overall state of the project in relation to the original commitment to determine if the project is still viable.
Trigger
Approval of the initial project charter and high level plan (see Initiate Project).
Key Considerations
Key considerations in conducting status reviews are:
Diagram
•
Is the project still viable (i.e., is the business case still valid)?
•
Is the project plan sill aligned with external dependencies (i.e., are external events proceeded as expected)?
•
Is resource utilization in line with the approved project plan?
•
Is spending in line with the approved project plan?
•
Is the project on schedule?
•
Are deliverables being produced as planned and to the level of quality agreed with the Customer?
•
What issues are outstanding and what issues have been resolved?
•
What is the status of known risks and have any new risks been identified?
The following diagram shows the periodic reviews that must be supported, including PQA and gate reviews at the end of each stage, weekly status reviews (see items highlighted by red arrows) and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Originator: One IT PPM Team Page 124 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly
To Business Manager From Project Manager to IT Manager and Business Partner
At End of SDM Stage
During SDM Stage
From IT Manager
Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Process Tasks No
Task Name
Description
Participants
1
Schedule Weekly Status Reviews
Schedule a standing weekly status review meeting with core project participants (the Customer, Business Analys t, and Project Team). If appropriate, include the Sponsor and Program Manager in one or more of those meetings each month. Create a standing agenda.
PM
2
Prepare Materials
Prepare the standard weekly status report. Ensure that both the Project Manager assessment and the Customer assessment are completed. Gather supporting documents, including Earned Value Reports, and the results of gate reviews, etc.
PM, Cust
The GYR status is defined as follows: Green:
Target dates and/or deliverables are on track.
Yellow:
Target dates and/or deliverables are at risk, but a resourced recovery work plan is available and has been approved by the appropriate stakeholders Note: The status can only be returned to GREEN when the recovery work pan is executed and he risk is resolved. However, if the recovery work plan is not on track by the next review and the risk remains, the status should be changed to RED.
Red:
Target dates and/or deliverables are at risk and an approved recovery work plan is not yet available or the work plan does not achieve targets. The status remains RED until an approved work plan is available.
Note: The Weekly Status Report Template calculates the GYR status based on the percent over schedule or over budget, the significance of Originator: One IT PPM Team Page 125 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
changes requested during the period. See the template for details. The Project Manager has the ability to override the default GYR status value determined by the template, but if this is done, an explanation should be provided. The diagram below depicts the decision making process concerning GYR once a Yellow or Red condition has been identified. Green
Red
NO
YES
Target dates & deliverables are on track
NO
Recovery Plan is in Place
YES
Yellow
NO
Recovery Plan is Resourced
NO
YES
NO
Recovery Plan Approved by Stakeholders
YES YES
Recovery on Track Since Last Review
3
Provide Access to Materials
Be sure that participants have access to issue, change, and risk logs, and the most current version of the project plan. Distribute relevant materials at least 1 day before the meeting or make available to participants in an electronic folder on shared drive or in an eRoom.
PM
4
Review Status with Participants
Review and agree on the project GYR status with the team. Analyze any Yellow or Red items to determine root causes and agree on an action plan to address, accordingly.
PM, Cust, Team
5
Review Open Issues, Risks and Change Requests
Review the open items in the Issues, Risk and Change Request Logs. Identify work completed and any items that can be closed. Agree on a course of action and team assignments for addressing for any new items.
PM, Cust, Team
6
Assess Results of Quality Controls
Review the results of inspections, testing, technical reviews (see section 4.2.4) and the most recent gate review to determine if the project is adhering to quality standards. Make assignments, as necessary, to deal with any issues identified.
PM, Cust, Team
7
Review Team Assignments
Allow each participant to provide a brief report out on work in progress. Work with the team to determine if additional help is needed or other corrective measures are warranted.
Team
8
Assess Viability of the Project
Look at the actual work completed in comparison to the project plan to determine if the business case is still valid. Determine if anything has changed since the project started that would invalidate the assumptions made in the goals and objectives. Review forecasts of project completion and costs to determine if the project will deliver to promise.
PM, ESpon, Program Mgr, Cust, Team
Tools/Techniques Summary Methods and Applications/Tools eTracker at http://www.etracker.ford.com/ Earned Value Analysis template at http://www.ads.ford.com/eva/ MS Project RMS -- http://www.rms.ford.com
Inputs to Process Originator: One IT PPM Team Page 126 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 229_Classic_SDM_Work_Plan.mpp 211_change_request_template.doc 212_risk_management_log.doc 213_issue_log.doc 221_weekly_status_report_template.doc Timesheets http://www.rms.ford.com 220_meeting_minutes_template.doc 32_Defect_Log.doc
221_weekly_status_report_template.doc Earned Value Analysis Template at http://www.its.ford.com/eva/ 211_change_request_template.doc 212_risk_management_log.doc Issues in 213_issue_log.doc or eTracker at http://www.etracker.ford.com 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 127 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Program Mgr, BusA, ESpon, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.2 Purpose
Coordinate Architecture Reviews
If appropriate to the project type, an architecture review must be completed before the end of the first stage. See the Classic Solution Delivery Methodology Process Guide. It is The Project Manager’s job to ensure that the architecture technical reviews (see section 4.2.4) occur as required and that any issues, action items, or decisions that are made as a result of these reviews are approved, as appropriate, and reflected in project plans and documentation.
Trigger
Initial Charter signoff and completion of stage.
Key Considerations
No key considerations provided for this process.
Diagram The following diagram shows the periodic reviews that must be supported, including Architecture, PQA and gate reviews at the end of each stage, weekly status reviews (see items highlighted by red arrows) and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Originator: One IT PPM Team Page 128 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Coordinate Architecture Review
Ensure that a required Architecture Review occurs. Refer to the appropriate SDM Process Guide for details.
PM
2
Ensure Review Results are Documented
Review results and ensure that any action items are reflected in project plans and completed.
PM
3
Update Project Records
Ensure that review documentation is stored in the project Control File as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tool s Classic_SDM_Process_Guide Architecture Management Guidebook located at http://www.fsic.ford.com/architecturemanagement/ OneIT Architecture Review Board Workbook located at http://www.fsic.ford.com/architecturemanagement/
Inputs to Process
Outputs
ARB review meeting minutes in 220_meeting_minutes_template.doc
ARB review meeting minutes in 220_meeting_minutes_template.doc
73_ARB_Workbook.xls completed to appropriate level in system development lifecycle.
Update 73_ARB_Workbook.xls
Originator: One IT PPM Team Page 129 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.3
Coordinate Metrics Workshops
Purpose
The deliverables from the Metrics Workshops are valuable tools to help project managers evaluate project scope, determine resources required, estimate project effort and duration, prioritize deliverables, and evaluate productivity. A key output of each session is a function point count for the project.
Trigger
The Initial Metrics Workshop is triggered by completion of the conceptual design. The Interim Metrics Workshop is triggered by completion of the physical design process -- per the Classic SDM. The Final Metrics Workshop is triggered by conclusion of the build stage.
Key Considerations
Instructions for preparing for metrics workshops (Initial, Interim, and Final) are provided by the Metrics Specialists. Details on the Metrics workshop processes are documented in the Solution Delivery Methodology Process Guide.
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Coordinate Interim and Final Metrics Workshops
Ensure that a required Interim and Final Metrics Workshop occur. Refer to the appropriate SDM Process Guide for details.
PM, Team, Metrics
2
Ensure Workshop Results are Documented
Review results and ensure that any action items are reflected in project plans and completed, as appropriate.
PM, Team, BusA, Cust
3
Update Project Records
Ensure that workshop documentation is stored in the project Control File as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Classic_SDM_Process_Guide
Inputs to Process Metrics meeting minutes in 220_meeting_minutes_template.doc
Outputs Metrics meeting minutes in 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 130 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.4 Purpose
Coordinate Security Reviews & Certification
Most project types undertaken by IT will involve various technical reviews that occur across the project life cycle. These include, but are not limited to, the following:
•
Application Control Reviews (ACR) which are required to ensure that adequate security measures have been designed into an application that is being developed – see the following link for more information
HTTP://WWW.DEARBORN.FORD.COM/SECURITY/INTERNALCONTROL/552/ACRPROC.HTM
•
Infrastructure Control Reviews (ICR) which are required on projects that involve the implementation of infrastructure components that have not been previously been submitted for formal review at Ford.
•
Certification Reviews which are required for any application that makes changes to the standard Ford Client – see the following link for more information http://www.its.ford.com/fsic/.
The details of these reviews will be found in the appropriate solution delivery methodology guide for the project type (e.g., the Classic, Object Oriented, and Purchased Package methodology guides.) It is The Project Manager’s job to ensure that these technical reviews occur as required and that any issues, action items, or decisions that are made as a result of these reviews are approved, as appropriate, and reflected in project plans and documentation.
Trigger
Approval of the project charter and baseline plan.
Key Considerations
The main consideration here is •
what type of project is being conducted
•
what reviews are stipulated for that type of project
•
3 party products need to go through the SIE certification test if there is no prior SIE certification
rd
See the Solution Delivery Methodology Guide for details of these reviews.
Diagram
No diagram provided for this process.
Process Tasks No 1
2 3
Task Name Verify Submissions/ Registrations Coordinate Scheduling Participate in
Description
Participants
Verify that the appropriate submissions and registrations have been completed.
PM
Coordinate scheduling of review sessions.
PM
Make self and team members available for participation in the review
SCC,
Originator: One IT PPM Team Page 131 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
4
5
Task Name
Description
Participants
Review Sessions
sessions as appropriate. Identify a team member to record the session and make note of any changes required to satisfy requirements or issues that need to be resolved.
Monitor Resolution of Issues Verify final approval
Monitor completion of the changes identified in the session or issues that need to be resolved. Verify that final approval is obtained prior to launch and archive records.
PM, Team, Reviewers as appropriate PM
PM
Tools/Techniques Summary Methods and Applications/Tools Classic_SDM_Process_Guide
Inputs to Process Security review meeting minutes in 220_meeting_minutes_template.doc
Outputs Security review meeting minutes in 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 132 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.5
Coordinate PQA Reviews
Purpose
Process Quality Assurance (PQA) Reviews occur at the end of each stage in the project. The purpose of the PQA Reviews is to ensure that project processes and deliverables meet standards and will lead to a successful outcome.
Trigger
The trigger for a PQA Review is the completion of work products and processes for a given stage (e.g., Design, Build, or Implement).
Key Considerations
See the appropriate SDM Process Guide.
Diagram
The following diagram shows the periodic reviews that must be supported, including PQA and gate reviews at the end of each stage (see items highlighted by red arrows), weekly status reviews and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Originator: One IT PPM Team Page 133 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Coordinate PQA Review
Ensure that a required PQA Review occurs. Refer to the appropriate SDM Process Guide for details.
PM, Team, PQA
2
Ensure Review Results are Documented
Review results and ensure that any action items are reflected in project plans and completed.
PM, Team
3
Update Project Records
Ensure that review documentation is stored in the project Control File as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Classic_SDM_Process_Guide
Inputs to Process PQA review meeting minutes
Outputs 239_PQA_Review_Report.doc
Originator: One IT PPM Team Page 134 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.6 Purpose
Lead Gate/Tollgate Reviews
Gate reviews are event -driven major milestones during projects that ensure informed decisions are made about the continued viability of a project and/or its readiness to proceed to the next stage. Gate Reviews typically occur at the end of project life cycle stages, before the next major stage is to begin or before a major commitment is to be made. Decision makers (principally, the Sponsor or Customer and Business Analyst and/or IT Management) review the results of actual work effort vs. baseline work effort and projections of the work effort required to complete the project. They make an assessment of the overall project health (R/Y/G rating), a Go/No-Go decision (Is it ready to proceed to the next stage?) and, if necessary, a recommendation to terminate the project. Project cost, business benefit, timing, SDM process adherence and architecture compliance are all factors in determining the overall project health. At the Gate Reviews, obtain the appropriate signatures on the Gate Review Checklist forms to ensure accountability of the decisions rendered. Six Sigma Tollgate Reviews are checkpoints within the Six Sigma DFSS process that ensure that the project is aligned with business requirements / customer expectations and that the criteria listed below for this point in the DFSS lifecycle have been achieved. Verification that Tollgate 0 occurred is confirmed by the PM process "Confirm Project Readiness to Start". Tollgates 1 and 5 are explicitly called out in the Classic SDM methodology. Tollgates 2, 3 and 4 are embedded within the Gate review.
Trigger
The remaining gate reviews are triggered by completion of the work products and processes for each stage (e.g., Design, Build, or Implement).
Key Considerations
At this point in the process, there are two key decisions that must be made: 1) should the project continue and 2) is it ready to proceed to the next stage.
The following must be considered in deciding if the project should continue:
•
Expected costs vs. expected benefits (i.e., do expected benefits outweigh projected costs to complete?)
•
Risk and feasibility (i.e., is the project feasible given the current understanding of risks, project constraints, issues, and the volume and nature of outstanding change requests?)
•
Strategic importance (i.e., given expected costs, benefits, risks, issues, and outstanding change requests, is the project of significant importance to warrant continued funding?)
•
Regulatory compliance (i.e., is the project mandated by the need to comply with governmental regulations?)
The following must be considered in deciding if the project should proceed to the next stage:
Originator: One IT PPM Team Page 135 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Diagram
• • • •
Have all deliverables of the stage been completed?
•
Must any outstanding issues be resolved, before the project can proceed?
Has the initial charter been signed by the Sponsor? Has the Architecture Review Board (ARB) for this stage been conducted? Has the Project Quality Assurance (PQA) review for this stage been conducted?
The following diagram shows the periodic reviews that must be supported, including PQA and gate reviews at the end of each stage (see items highlighted by red arrows), weekly status reviews and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Originator: One IT PPM Team Page 136 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Schedule Review
The end date of each stage should be clearly identified in the project plan. Before that date, confirm the date that the project will reach the stage gate and confirm or adjust the scheduled gate review. Notify participants (the Sponsor, IT Project Owner, Business Analyst, Program Manager, and if appropriate, the PQA Reviewer, AM Coordinator and Project Managers of related projects, and other interested parties).
PM
2
Collect Backup Materials for Meeting
Pull together all of the materials that may be required to explain the current state of the project, including the PQA R/Y/G rating, ARB R/Y/G rating, the status of issues, risks, and change requests, and recent status reports, current metrics, etc., to have ready if needed during gate review discussions. Ensure that these materials are current and accurate. Include the signed charter.
PM
Just prior to the meeting collect data on progress against plan and actual costs from project team members. Complete the weekly status report form and earned value analysis to determine the project’s current GYR (Green, Yellow, Red) status, earned value, and Schedule Performance Index (SPI) and Cost Performance Index (CPI). Identify planned milestones achieved or missed. Review the current risk assessment and update as needed to arrive at a current risk rating score. 3
Complete the Review Checklists
Obtain the appropriate Gate Review Checklist and complete the Yes/No checkboxes. Note that 6-Sigma Tollgate questions have been included in the Gate Review Checklist.
PM, Cust
4
Assess Project Viability
PM, BusA Cust Program Mgr
5
Conduct Review
Review the completed Gate Review checklist, current status, risk rating, change logs, issue log, risk management log, with the Customer and Business Analyst to jointly arrive at a recommendation as to the viability of the project prior to the actual gate review. Typically this is performed at a regular project status meeting. During the gate review, present and review the completed Gate Review checklist and, if necessary, any backup/supporting materials needed to explain the current state of the project. Review recommendations made by the Project Manager, Business Analyst and Customer on the continued viability of the project.
As necessary: ESpon, AppOwn, Program Mgr, PQA, AMCoord, PM for related projects, APM/LOB, Practice Mgr, 6-Sigma, Stakeholders, Vendor/Suppli er
Make Overall Project R/Y/G Rating, Go/No-Go Decision, and if appropriate, a recommendation to terminate the project. These decisions may take the following forms:
• • • • •
Overall R/Y/G rating becomes the lowest of the ARB, PQA and Project Status R/Y/G ratings Continue as planned Continue in a watch state for a specified short-interval and review the status again at the end of that period Continue the project under the condition of specified changes in the current plan (create Change Requests, as appropriate)
PM, BusA, Cust
Terminate the project
Guidelines on When to Consider Terminating a Project When it no longer has business/ strategic value
When the project is no longer contributing to the organization’s long- or short-term business strategies.
Originator: One IT PPM Team Page 137 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
When it is no longer feasible
When the project cannot be done properly with the available resources or under the current circumstances.
When deliverables continually fail to appear
When even the best efforts of the project team and aggressive corrective action (changes to the plan, scope, or resources) fail to produce desired results.
When there are more issues than successes
When issues outnumber the successfully completed milestones and deliverables.
When the budget stops representing reality
When budget or resource allocations are continually exceeded or substantial unreported overtime is required to meet milestones.
6
Obtain Signatures
Obtain signatures on the Gate Review Checklist Forms from the appropriate decision makers including the customer responsible.
PM Cust Others, as necessary
7
Communicate Decision
Communicate the overall project R/Y/G rating and the go/no-go decision (and if appropriate, the recommendation to terminate the project) to key stakeholders, including related projects and support activities per the project communications plan.
PM
If the project is to be continued, advise those impacted by the decisions (e.g., ITS, application support groups, etc.) to reaffirm or adjust the direction of the project's progress and schedule. 8
Update Project Records
Store minutes and other documentation of the review in the project Control File. Update the project record in ITMS, RMS and MRS.
Originator: One IT PPM Team Page 138 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools eTracker at http://www.etracker.ford.com/ Earned Value Analysis template at http://www.ads.ford.com/eva/ Microsoft Word and Excel ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs MS Project MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process
Outputs
Recipients
Results of ARB Reviews
211_change_request_template.doc
Results of PQA Reviews
220_meeting_minutes_template.doc
200_project_charter_template.doc
221_weekly_status_report_template.doc
206_risk_assessment_template.xls
233_Gate_Review_Checklist
211_change_request_template.doc
Go/No-Go Decision / Recommendation to Terminate (if appropriate)
212_risk_management_log.doc 213_issue_log.doc 215_communication_plan_template.doc 221_weekly_status_report_template.doc 229_Classic_SDM_Work_Plan.mpp Current Earned Value Report
BusA, Control File, Cust, IT Management, Stakeholders, Team, ITMS, ESpon
Issues in 213_issue_log.doc or eTracker Overall Project R/Y/G Rating Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs Risks in 206_risk_assessment_template.xls and 212_risk_management_log.doc
SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 139 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.7
Support Operations Reviews
Purpose
Operations reviews provide the means to assess programs and projects within the context of an organization’s entire portfolio of work.
Trigger
Monthly or quarterly review or a project portfolio.
Key No key considerations specified for this process. Considerations Diagram
The following diagram shows the periodic reviews that must be supported, including gate reviews at the end of each stage, weekly status reviews and various levels of operations reviews that are conducted on a monthly and quarterly basis (see items identified by red arrows).
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Originator: One IT PPM Team Page 140 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Ensure Project Records are Kept Current
Ensure that project records in ITMS, RMS and MRS are kept current and accurately reflect the true status of the project.
PM
2
Provide Current Status Report
Be prepared to provide a current status report if requested.
PM, Cust
3
Prepare Backup Material as Required
Ensure that project records (documentation) are ready for review if requested – particularly if the current status of the project is yellow or red.
PM
Tools/Techniques Summary Methods and Applications/Tools Earned Value Analysis template at http://www.ads.ford.com/eva/ Microsoft Word and Excel MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 221_weekly_status_report_template.doc Project Control File Results of Gate Reviews Results of ARB Reviews Results of PQA Reviews
Outputs
Recipients
Project Record in MRS http://www.ads.ford.com/mrs Project Record in RMS http://www.rms.ford.com Project Record in ITMS http://www.itms.ford.com/
Originator: One IT PPM Team Page 141 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Sponsor, IT Management, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 142 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.0
Close Project Project Management Processes
Resource Plan Procurement Plan
Initiate Communication Plan
Budget Plan
Plan
Work Plans
Project Charter
Execute
Work Products Solution Delivery Methodology
Control
Close
Inputs to Close Project
Overview
Closure is the formal end-point of a project, either because it is completed or because it has been terminated. Termination may occur because the project is no longer viable or because the risks associated with it have become unacceptably high. Formal closure finalizes the project in the eyes of the stakeholders and provides a learning opportunity. It is also the point at which issue and change logs are closed, project accounts are reconciled, resources are released, feedback is solicited from stakeholders, and work products are archived for future reference.
Process Contents
Objective 5.1
Note Refer to PM Processes "3.0 Execute Project" and "4.0 Control Project" for processes such as "Maintain Project Records" or "Conduct Status Reviews" for process steps that must be carried out across all five PM Processes (Initiate, Plan, Control, Execute, Close).
5.2
5.3
Finalize Delivery Conduct Final Project Review
Perform Administrative and Financial Closure
Process Steps
PM Deliverable
5.1.1
Finalize Implementation
5.1.2
Finalize Transition
Handover to Support
5.2.1
Administer Major Release Survey
Feedback on Project
5.2.2
Conduct Wrap-up Session
5.2.3
Prepare Closure Report
5.3.1
Release Resources
5.3.2
Complete Financial Closure
Budget/Contract Closure
5.3.3
Close & Archive Records
Closed/Archived Records
Originator: One IT PPM Team Page 143 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Implementation as Planned
Lessons Learned/Metrics Completion Documents Released Resources
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.1
Finalize Delivery
5.1.1
Finalize Implementation
Purpose
The purpose of this step is to ensure completion of implementation plans created during the analysis and planning stages of the project.
Trigger
Project closure.
Key Considerations
Key considerations for this process step include:
Diagram
•
Is the project closing because it has completed successfully or because it has been terminated before being completed?
•
If it was terminated, are there still elements that will be implemented or handed-over to another team?
•
What implementation tasks have already been completed, if any?
No diagram provided for this process
Process Tasks No
Task Name
Description
Participants
1
Execute Implementation Plans
Ensure that final implementation tasks are executed as planned. If the project is closing because it has been terminated, finish any implementation steps that are appropriate.
PM, Cust, Support Activities
2
Update Project Records
Update project records to reflect that implementation plans have been executed as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process Implementation Plans
Outputs Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs
Originator: One IT PPM Team Page 144 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, AppSupr
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.1.2
Finalize Transition
Purpose
The purpose of this step is to ensure completion of transition plans made during the planning stage. This includes execution of handover and follow-up tasks.
Trigger
Project closure.
Key Considerations
Key considerations for this process step include:
Diagram
•
Is the project closing because it has completed successfully or because it has been terminated before being completed?
•
If it was terminated, are there still elements that will be implemented or handed-over to another team?
•
What transition tasks have already been completed, if any?
No diagram provided for this process
Process Tasks No
Task Name
Description
Participants
1
Execute Transition Plans
Ensure that final transition tasks are executed as planned. If the project is closing because it has been terminated, finish any transition steps that are appropriate.
PM, Cust, Support Activities
2
Update Project Records
Update project records to reflect that transition plans have been executed as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Referenc e_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 217_transition_support_plan.doc
Outputs 217_transition_support_plan.doc
Originator: One IT PPM Team Page 145 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, AppSupr
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.2
Conduct Final Project Review
5.2.1
Administer Major Release Survey
Purpose
At the end of the Category 2 and 3 projects, it is important to solicit feedback from Customers and sponsors on the way that the project has been planned, managed, and concluded and on final deliverables. The feedback, obtained can be an important source inspiration for process improvements and professional growth. It is also an important tool in assessing overall professionalism and effectiveness of the Ford IT organization.
Trigger
Project Manager indicates that a Category 2 or 3 project has completed. MRS sends the Major Release Survey to listed users 30 days after Project Implementation.
Key Considerations
The key considerations in soliciting and obtaining Customer feedback are:
Diagram
• •
Which Customers will be asked to complete a Satisfaction Survey?
•
If the project in question a pilot project?
How much time will Customers be given to complete the survey?
No diagram provided for this process
Process Tasks No
Task Name
Description
Participants
1
Solicit User Feedback
Project Manager will add/update user list in MRS with names of individuals who should receive a support survey from MRS, being sure to include the Business Analyst, Program Manager, Customer, and Sponsor.
PM Cust(s)
2
Solicit QC Feedback
Ask the Quality Control Test Specialist (QCTest) to provide the QC final reports for filing in the Project Control File.
PM, QCTest
3
Assess Feedback Results
Review and summarize completed results.
PM
4
Share results and thank participants
Share summarized results with participants. Add completed surveys and summary report to Project Control File. Thank participants.
PM, ESpon(s), Cust(s), Team
Originator: One IT PPM Team Page 146 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word / Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process
Outputs
Recipients
201_stakeholder_assessment_template.doc
Major Release Survey
203_team_directory_template.doc
85_QC_Final_Report_Metrics_Spreadsheet located at QC web site http://www.sdg.ford.com/qc/
ESpon (s), Cust(s), Team, Metrics
84_QC_Final_Report_Management_Summary located at QC web site http://www.sdg.ford.com/qc/
Originator: One IT PPM Team Page 147 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.2.2
Conduct Wrap-up Session
Purpose
The project wrap-up session provides an opportunity for team members (including any support resources that have participated on the project as needed) to review what transpired on the project, and agree on what went well and what could have been done better. Outputs of the review process will be a set of lessons learned and recommendations for improvements in project management processes and the solution delivery methodology.
Trigger
Project closure.
Key Considerations
The key questions to be addressed in the final assessment are:
Diagram
•
What went right and why?
•
What went wrong and why?
•
How well did the methodology work to guide the project?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Schedule and Hold the Meeting
Schedule a wrap-up session with members of the project team. Arrange for a facilitator if possible. Ask participants to review documents in the Project Control File ahead of time to refresh their memory on the status of the meeting at closure, the project goals and objectives, and outcomes. Provide or direct team members to the results of team, Customer, and sponsor feedback.
PM, Team, Metrics
2
Compare Actuals to Project Plans
Compare the final project schedule, resource utilization, budget, and deliverables to the original plan:
PM, Team, Metrics
• •
What was really created versus what was planned?
•
Were there deviations from the project plan?
•
Why did the deviations occur?
•
Could they have been avoided?
Did the deliverables comply with the Customers’ and sponsors’ acceptance criteria?
3
Evaluate Methodology
Evaluate the project management and solution delivery methodologies used on the project. Determine what worked well and what could have been improved.
PM, Team
4
Review Team Make-up
Assess the make up of the team to determine if it was effective.
PM, Team
•
Were the right people/skill-sets on the team?
Originator: One IT PPM Team Page 148 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
•
Participants
Were ad hoc members useful?
5
Review the Results of Gate Reviews
Review the results of gate reviews conducted during the life of the project. Determine if lessons can be learned from those results.
PM, Team
6
Review Feedback
Review feedback obtained as part of the Solicit Feedback process. Identify lessons learned from that feedback.
PM, Team
7
Document & File Lessons Learned
Document all lessons learned and any recommendations made by the group and add to Project Control File. Share lessons learned with local management as required.
PM, Team
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word Brainstorming Facilitated Session
Inputs to Process Results of Customer and team satisfaction surveys 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 221_weekly_status_report_template.doc 220_meeting_minutes_template.doc
Outputs 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 222_lessons_learned.doc 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 149 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Team, Metrics
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.2.3
Prepare Closure Report
Purpose
The Closure Report performs two functions. First, it summarizes the reason for the closure (i.e., successful completion of the project or termination), the deliverables produced, and relevant productivity metrics (e.g., function point productivity measures on application development projects, the number of change requests submitted and resolved, the number of defects reported, etc). It also highlights the lessons learned as agreed in the Team Wrap-up Session.
Trigger
Project Closure
Key Considerations
No key considerations provided for this process
Diagram
No diagram provided for this process.
Process Tasks No 1
Task Name
Create Project Closure Report
Description
Participants PM
Create a report with the following sections: Reason for Closure:
State the circumstances under which the project is being closed.
Objectives Achieved:
Import the Deliverables section from the Project Charter and identify which ones are completed.
Project Proficiency:
Describe metrics that demonstrate how effective the project was in resolving issues, managing risks and scope, and producing deliverables.
Lessons Learned:
Summarize highlights of the lessons learned as determined in the Team Wrap-up Session.
Results of Feedback:
Summarize feedback obtained from the project team, Customer(s) and sponsor(s).
Acknowledge ments:
Acknowledge individuals who have made special contributions to the project.
2
Issue Notification Letter
Complete and distribute a Completion Notification Letter.
PM, Cust
3
Review & Finalize Closure Report
Review the Closure Report with the Customer and obtain sign-off.
PM, Cust
4
Archive Signed Closure Report
Add the signed Closure Report to the Project Control File.
PM
5
Change Project Status in RMS
Send a note to RMSHELP to change the project status to "Closed".
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 150 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word
Inputs to Process 200_project_charter_template.doc 229_Classic_SDM_Work_Plan.mpp 222_lessons_learned.doc
Outputs 223_closure_report_template.doc 224_completion_notification_template.doc
Originator: One IT PPM Team Page 151 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, ESpon, Cust, Local Mgmt
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.3 Perform Administrative and Financial Closure 5.3.1
Release Resources
Purpose
Once the project is closed, resources (personnel, equipment, and facilities) need to be released for use on other projects. If appropriate, the performance and contributions of individual team members should be assessed and documented and feedback given. Note that contractual agreements preclude providing direct feedback to contract personnel.
Trigger
Project Closure.
Key Considerations
The key considerations in releasing resources are:
Diagram
•
What guidelines have been established for assessing the performance of contract personnel?
•
What arrangements, if any, have been made for providing feedback on the performance/contributions of non-Ford IT team members and personnel who belong to other IT or Business Activities?
No diagram provided for this report.
Process Tasks No
Description
Participants
Notify Competency Center of Upcoming Releas e of a Ford ADS Resource
Send an MS-Outlook note to the appropriate Competency Center Manager 30 days prior to the release and notify him/her that the resource will be released and the date of the release. If the resource doesn't know whom their manager is, the note should be sent to Don Bartkowiak (DBARTKOW).
AppSupr, Competency Center Manager
2
Notify Agency of Upcoming Release of Agency Resource
Send an MS-Outlook note to the appropriate agency representative 2 weeks prior to the release and notify him/her that the resource will be released and the date of the release.
AppSupr, Agency Representative
3
Notify RMS of Resource Release
Send an MS-Outlook note to cdsid RMSHELP to inform them that the resource will no longer be working on the application and should not bill against it any longer.
AppSupr
4
Perform Exit Procedure
Follow the instructions at the exit procedure link located at http://www.ads.ford.com/facilities/. This procedure covers the removal of application access, building access and other tasks.
AppSupr
1
Task Name
Note: As per the new Competency Center Guide, Ford ADS resources will have been assigned a Competency Center Manager. The Application Supervisor should obtain the Competency Center Manager's name from the resource.
Tools/Techniques Summary
Originator: One IT PPM Team Page 152 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word Interim Resource Management Process http://www.ads.ford.com/resman/
Inputs to Process
Outputs
203_team_directory_template.doc 223_closure_report_template.doc
Recipients
Team Evaluations Notification of release of resources
Team Competency Center Resource Management
5.3.2
Complete Financial Closure
Purpose
Financial closure is the process of completing and terminating the financial and budgetary aspects of the project being performed. Financial closure includes both (external) contract closure and (internal) account closure.
Trigger
Project Closure
Key Considerations
The key considerations in completing financial closure are
Diagram
•
Are there any special contractual issues that must be addressed if the project is terminated before the agreed end date?
•
Who needs to be notified ahead of time that a project will be reaching closure and by how much lead time?
•
Are there outstanding contract issues that need to be resolved before the contact can be settled?
•
What project charge codes need to be closed and by when?
The diagram below depicts the high-level process flow for this activity.
Communicate Project Closure
Project Schedule Project Contracts Budget Plan
Confirm Project Completion Date
Close Charge Codes
Confirm Contract Fulfillment
Contract Fulfilled?
Yes
Project Closure Report Resolve Contract Issues
No
Close Contract
Process Tasks No 1
Task Name Confirm the Closure or Completion Date
Description
Participants
Once a project is closed, there should be no need to apply labor or resources against the project because it will be delivered or turned over to operations. Any further work done on the product beyond this
Originator: One IT PPM Team Page 153 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
date should be considered operations and maintenance costs. 2
Communicate Closure Date
Project staff, management, and RMSHELP need to be told as far ahead of time as possible when the project will be concluded. There are several reasons for this.
• •
PM
The staff applied to the project will know the date beyond which they will not be able to charge their time against and purchase resources for the project. Management will be able to plan where their resources will be applied next.
•
Setting a date provides a sense of urgency to resolve issues and complete the activities that have been dragging on without resolution. The planned completion date of the project should be kept current in the project schedule as well as ongoing project documentation. 3
Close Charge Codes
Most projects have account numbers associated with them that allow financial departments to track labor hours and resource procurement. These labor charge codes will be need to be deactivated so that no personnel may continue to charge time against the project or use project charge codes to purchase materials, etc. Closure of these accounts should be formalized via written request that the project manager turns over to the organization’s finance manager. Send a note to RMSHELP with code number and close date.
PM, FinanceAnal
4
Confirm Contract Fulfillment
In order to close a contract, it is important to collect all pertinent documentation for review. This includes all of the original contracts and supporting documentation such as schedules, contract changes, and performance reports. This documentation needs thorough review to ensure that there are no unrealized contract issues that could result in legal liability.
PM, Purchasing, OGC
5
Resolve Contract Issues
Reconcile the actual utilization of contract resources against the planned utilization. Reconcile actual costs against planned costs. Terminate all arrangements for the use of resources, including leases and contractual agreements.
PM, Purchasing, OGC
6
Close Contract
Produce any written contract closure documentation required by the vendor.
PM
Originator: One IT PPM Team Page 154 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS WebTracs Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Referenc e Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 223_closure_report_template.doc
Outputs
Recipients
Charge Code Closure Closed Contracts Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs 229_Classic_SDM_Work_Plan.mpp Project Record in ITMS http://www.itms.ford.com/
Originator: One IT PPM Team Page 155 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Purchasing, OGC, Demand Management, MRS Plans Database
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.3.3
Close & Archive Records
Purpose
The primary purpose of closing and archiving project work products is to ensure that deliverables are handed over to the appropriate parties and that reusable objects are available for use on other projects. This includes closing issues, risk, and change logs and handing over final deliverables to Customers and support activities. It also includes updating the project’s records in ITMS, RMS and MRS to reflect the closure status. Finally, closure involves archiving work products for reuse and historical purposes.
Trigger
Project Closure.
Key Considerations
The key considerations in closing and archiving project records are
Diagram
•
What project deliverables need to be handed over to other project teams, support activities and end-users?
•
What project work products might prove useful on other projects?
•
What project work products and records need to be maintained to support Corporate Records Retention policies?
No Diagram provided for this process
Process Tasks No
Task Name
Description
1
Handover Project Deliverables
Prepare project deliverables and records for handover. Ensure that the correct versions are passed to other teams and that the recipients know how to access and update them, as appropriate.
PM
2
Close Project in ITMS
Update the Project State in ITMS so that it shows a status of "Complete".
BusA
3
Close Project Logs and Records
Close records that describe the project. Ensure that the project is accurately reflected in ITMS, RMS, MRS and any local systems used to track IT projects.
PM
4
Review Work Retention
Review work products in the Project Control File to determine if it should be maintained for reuse or legal purposes.
PM
5
Archive Work Product or Discard
The first rule of archiving project products is -- if it was important to create, it is probably important to keep. Schedule a CD burn of archived materials. Up to 2 copies can be requested. Schedule the burn by submitting a GIRS ticket.
PM
Originator: One IT PPM Team Page 156 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs GIRS MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process Records Retention Policies Project Deliverables Project Control File Records Retention Policies 225_archive_documents_checklist.doc
Outputs
Recipients
225_archive_documents_checklist.doc Updated ITMS Record at http://www.itms.ford.com/ Archived Work Products Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs
Originator: One IT PPM Team Page 157 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Metrics
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
Originator: One IT PPM Team Page 1 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Document Information and Revision History File Name
One IT Project Management Process Guide
Original Author(s)
Amy Wagner, Ashok Prasad, Brenda Schultz, Charlene Draine, Chris Hurley, Dan Wilczak, Deborah Harrell, Denise Hussin, Diana Zinn, Duane Lawton, Elaine Medlen, Jeff Robinson, Joe Zhou, John Cackowski, Julia Davis, Paul Gustofson, PPM Working Group, Terry Grover, Tom Maslyk, Heddie O'Connor, Sally Tuma, Vairavelu CRN, Wendi Rhoad
Current Revision Author(s)
SDM PPM Workgroup
Version
Date
Author(s)
Revision Notes
Beta V1.04
04/08/2002
OneIT SDM Project Team
Production 1.0
04/12/2002
OneIT SDM Project Team
Draft 1.04 Release § Added defect management process § Global change to Methods and Applications/Tools title § Changes as called out in Change Request #765 § Added review graphics (CR #767) § Added definition of red, yellow and green status (CR #766) § Added note about GAO Audit requirement – Spisich § Added text to indicate that the configuration management tool should be set up at the same time as the project control book (CR #134) Production Release • Changed title page to say Production Release 1.0 • Reverted to an older definition of an Initiative page 6 • Modified the definitions of a Program Release pg 6 • Deleted the Application Release definition pg 6 • Added a Software Release Definition pg 6 • Incorporated references to the Interim Resource Management Process and the corresponding web site link into the tools section everywhere that the requisition or release of resources were mentioned and everywhere that timesheets were mentioned (CR#777)
Production 1.0
04/19/2002
OneIT SDM Project Team
•
•
Noted possibility that the project may have been the result of a number of change requests being bundled together to produce a new application release. May note of this in Section 1.1.1 Confirm Project Readiness (CR#782) Added task in Section 1.1.1 Confirm Project Readiness for completion of the PQA Metrics Sizing Profile Template (CR#782)
Production 1.1
05/08/2002
OneIT SDM Project Team
•
Completed changes identified in pilot training and earmarked for version 1.1
Production 1.2
05/21/2002
OneIT SDM Project Team
•
Completed changes identified in detailed training and earmarked for version 1.2
Production 1.2.1
06/05/2002
SDM Manager, TPMO
•
Completed changes identified in detailed training and earmarked for version 1.2.1
Production 1.3
06/26/2002
SDM Manager, TPMO
•
Completed changes to match new RMS process as well as changes identified during Classic SDM detailed training.
Production 1.3.1
07/18/2002
SDM Project Team, TPMO
•
Completed changes related to new RMS process. Change project/program data entry from ProSight to ITMS. Updated Review Pyramid Diagram.
• Production 2.0
08/05/2002
SDM Project Team, TPMO
•
• • • • •
CR #1456: incorporate that Project Appropriation Request / PAR process in the introduction. Add step to ensure that the PAR has been entered in MEARS prior to project start-up. Add step to ensure that costs and benefits are accounted for during business case rev iew/confirmation. Add step to ensure that costs are accounted for during hardware/software acquisition. CR #1335, 1439 Incorporated changes for Packaged Product Selection and Implementation CR #1436 Incorporated changes for Six Sigma alignment CR #1516: Include link to MRS guide and quick reference guides CR #1517: Include link to IT tools quick reference. CR #1561: Incorporated SOW workflow
Originator: One IT PPM Team Page 2 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Production 2.0.1
11/04/2002
SDM Development Team
• •
• •
Production 2.1
SDM Development Team
• • • • • •
Production 2.2
August 14, 2003
EPMO – Program Governance Team
Prod 2.3
30Apr2004
Program Governance Office
• • •
CR #1576. Per Mark Bradford, beginning Sunday, November 3rd, 2002 the new URL for ITMS will be http://www.itms.ford.com/ CR #272055: Modified links in SDM Matrix, SDM Guide and PM Guide pointed to QC web site rather than SDM web site for the 35_Quality_Control_Plan_and_Test_Strategy.doc template. Modified links in SDM Matrix, SDM Guide - pointed to QC web site rather than SDM web site for the "85_QC_Final_Report_Metrics_Spreadsheet" template. Modified links in SDM Matrix, SDM Guide - pointed to QC web site rather than SDM web site for the "84_QC_Final_Report_Management_Summary" template. Added new link in SDM Matrix, SDM Guide and PM Guide - pointed to "89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support", which is a stripped-down version of the 35_Quality_Control_Plan_and_Test_Strategy.doc.template. CR #272072: Modified process 1.2.2 Establish Project Procedures to identify SCM constraints (global SCM requirements) rather than establish SCM Plan. CR#272029: Replaced obsolete references to interim resource management process web site with current site and incorporating current process for adding/releasing resources. CR #272077: synchronized role descriptions in SDM Guide and PM Guide CR#272084: Replace selected references of scope management with change management. CR#271983: Correct MRS URL to www.ads.ford.com/mrs CR#271984: Add wording for assess and make recommendation to Confirm/Refine Business Case. CR#333115: Corrected typos in process 1.1.1 Confirm Project Readiness to Start. CR#271982: Add a step to process 5.3.3 Close and Archive Records to mark the project complete in ITMS. Gate Review ICRP Control Concern – obtain signatures of decision-makers to confirm accountability (Section 4.2.6) PQA Strategy update – direct PM to PQA web site (Section 1.1.1) Portfolio Management – updated overview section with new Portfolio Management Process.
Originator: One IT PPM Team Page 3 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Table of Contents PURPOSE ......................................................................................................................................................................................... 6 PORTFOLIO MANAGEMENT .............................................................................................................................................................. 6 PORTFOLI O MANAGEMENT PROCESS FLOW ................................................................................................................................... 6 DEFINITION OF PROJECT MANAGEMENT ......................................................................................................................................... 7 PROJECT MANAGEMENT CORE PROCESSES .................................................................................................................................. 8 PROJECT MANAGEMENT KNOWLEDGE AREAS ................................................................................................................................ 9 THE PROJECT LIFE CYCLE .............................................................................................................................................................. 9 PM ALIGNMENT TO TYPICAL PROJECT LIFE CYCLE ....................................................................................................................... 9 KEY PRINCIPLES OF PROJECT MANAGEMENT............................................................................................................................... 11 Project objectives must be SMART ................................................................................................................... 11 Understanding and managing requirements is crucial ............................................................................ 11 Planning is everything and ongoing ................................................................................................................... 11 Control is a necessity, not a luxury .................................................................................................................... 11 Customers must be part of the process .......................................................................................................... 11 Providing an honest assessment of project health is critical................................................................ 11 We know what works, just do it............................................................................................................................ 11 Metrics should be collected throughout the project life cycle............................................................... 11 PURCHASED PACKAGE SELECTION AND IMPLEMENTATION (PPSI) .............................................................................................. 14 IT MANAGEMENT TOOLS ............................................................................................................................................................... 14 GAO AUDIT GUIDELINES .............................................................................................................................................................. 17 PROJECT AUTHORIZATION REQUESTS AND PURCHASE ORDERS................................................................................................. 17 PROCESS PARTICIPANT ROLES ..................................................................................................................................................... 18 1.0
INITIATE PROJECT ......................................................................................................................................................... 25
1.1 PREPARE FOR THE PROJECT............................................................................................................................................ 26 1.1.1 Confirm Project Readiness to Start.................................................................................................................... 26 1.1.2 Identify and Engage Stakeholders..................................................................................................................... 29 1.1.3 Engage Project Start-up Team............................................................................................................................ 31 1.1.4 Develop Start-up Work Plan................................................................................................................................ 33 1.2 ESTABLISH PM INFRASTRUCTURE ................................................................................................................................... 34 1.2.1 Establish Project Control File .............................................................................................................................. 34 1.2.2 Establish Project Procedures.............................................................................................................................. 36 1.3 DEFINE THE PROJECT....................................................................................................................................................... 38 1.3.1 Develop Initial Charter/Enhancement Request................................................................................................ 38 1.3.2 Develop Project Approach................................................................................................................................... 41 1.3.3 Develop Quality Management Plan.................................................................................................................... 44 1.3.4 Develop Communications Plans......................................................................................................................... 46 1.4 DEVELOP HIGH -LEVEL WORK PLAN ................................................................................................................................. 48 1.4.1 Develop High-Level WBS .................................................................................................................................... 48 1.4.2 Develop Dependency Network ........................................................................................................................... 50 1.4.3 Estimate Effort ....................................................................................................................................................... 52 1.4.4 Develop High-Level Schedule............................................................................................................................. 54 1.5 COMPLETE INVESTMENT ANALYSIS .................................................................................................................................. 55 1.5.1 Complete Initial Risk Assessment...................................................................................................................... 55 1.5.2 Develop Initial SOW.............................................................................................................................................. 59 1.5.3 Confirm/Refine the Business Case.................................................................................................................... 61 1.6 CONFIRM READINESS TO PROCEED ................................................................................................................................. 64 1.6.1 Confirm Requirements/Business Owner View................................................................................................... 64 1.6.2 Obtain Initial Charter/Enhance. Req. Signoff.................................................................................................... 66 2.0
PLAN PROJECT............................................................................................................................................................... 69
2.1 DEVELOP PROJECT MANAGEMENT PLANS ........................................................................................................................ 70 2.1.1 Develop Organizational Chg Mgt (OCM) Plan ................................................................................................. 70 2.1.2 Develop Procurement Plan.................................................................................................................................. 71 2.1.3 Develop Transition Plans..................................................................................................................................... 74 2.1.4 Develop Resource Management Plans............................................................................................................. 76 2.2 REFINE WORK PLANS AND BUDGET ................................................................................................................................. 80 Originator: One IT PPM Team Page 4 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 2.2.1 Refine Project Approach ...................................................................................................................................... 80 2.2.2 Refine Work Plans................................................................................................................................................ 82 2.2.3 Refine Risk Management Plans.......................................................................................................................... 84 2.2.4 Refine Resource Requirements.......................................................................................................................... 86 2.2.5 Refine the SOW..................................................................................................................................................... 88 2.3 CONFIRM READINESS TO PROCEED ................................................................................................................................. 90 2.3.1 Confirm Requirements Specification Signoff.................................................................................................... 90 2.3.2 Obtain Final Charter Approval............................................................................................................................. 92 2.3.3 Conduct Formal Kick -off....................................................................................................................................... 93 3.0
EXECUTE PROJECT....................................................................................................................................................... 97
3.1 MANAGE PROJECT E XECUTION ........................................................................................................................................ 98 3.1.1 Acquire/Release Facilities & Equipment........................................................................................................... 98 3.1.2 Acquire/Release Team Members..................................................................................................................... 100 3.1.3 Direct & Coordinate Plan Execution................................................................................................................. 103 3.2 MANAGE PROJECT INFORMATION ................................................................................................................................... 104 3.2.1 Maintain Project Records................................................................................................................................... 104 3.2.2 Distribute Project Information............................................................................................................................ 106 4.0
CONTROL PROJECT.................................................................................................................................................... 109
4.1 MONITOR AND CONTROL THE PROJECT ......................................................................................................................... 110 4.1.1 Monitor and Control Scope................................................................................................................................ 110 4.1.2 Monitor and Control Schedule/Costs............................................................................................................... 113 4.1.3 Monitor and Control Risks.................................................................................................................................. 115 4.1.4 Monitor and Control Issues................................................................................................................................ 117 4.1.5 Monitor and Control Quality............................................................................................................................... 119 4.2 CONDUCT PROJECT REVIEWS........................................................................................................................................ 124 4.2.1 Conduct Status Reviews .................................................................................................................................... 124 4.2.2 Coordinate Architecture Reviews ..................................................................................................................... 128 4.2.3 Coordinate Metrics Workshops......................................................................................................................... 130 4.2.4 Coordinate Security Reviews & Certification.................................................................................................. 131 4.2.5 Coordinate PQA Reviews .................................................................................................................................. 133 4.2.6 Lead Gate/Tollgate Reviews ............................................................................................................................. 135 4.2.7 Support Operations Reviews............................................................................................................................. 140 5.0
CLOSE PROJECT.......................................................................................................................................................... 143
5.1 FINALIZE DELIVERY......................................................................................................................................................... 144 5.1.1 Finalize Implementation..................................................................................................................................... 144 5.1.2 Finalize Transition............................................................................................................................................... 145 5.2 CONDUCT FINAL PROJECT REVIEW................................................................................................................................ 146 5.2.1 Administer Major Release Survey.................................................................................................................... 146 5.2.2 Conduct Wrap-up Session................................................................................................................................. 148 5.2.3 Prepare Closure Report..................................................................................................................................... 150 5.3 PERFORM ADMINISTRATIVE AND FINANCIAL CLOSURE................................................................................................... 152 5.3.1 Release Resources.............................................................................................................................................. 152 5.3.2 Complete Financial Closure................................................................................................................................ 153 5.3.3 Close & Archive Records................................................................................................................................... 156
Originator: One IT PPM Team Page 5 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
This Project Management Process Guide is intended for use on all types of IT projects. Its purpose is to guide project managers in the execution of project management processes and should be used in conjunction with the Solution Delivery Methodology (SDM) Process Guides developed for specific project types. While this document presents processes for managing projects in a disciplined and consistent manner, it is not a “cookbook”, nor is it a definitive discourse on project management. It is assumed that you have had at least basic project management training and that you are familiar with the Solution Delivery Methodology Guides.
Portfolio Management
Programs and projects originate within the Portfolio Management process. Once approved, they are funded via an Appropriations Request and enter the execution phase. Additional information on Portfolio Management is accessible on their web site http://www.itonline.ford.com/epmo/portman.htm?ID=node3 .
Portfolio Management Process Flow
Originator: One IT PPM Team Page 6 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Definition of Project Management
Project management is defined as directing the activities associated with executing a project, while controlling limited resources efficiently and effectively, and ensuring the project’s end goal is achieved successfully. As shown in figure 1.1 below, projects can be viewed in three dimensions. The Project Life Cycle axis describes the work to be done to deliver the product. The Project Management Core Processes axis delineates the five processes that must be performed to plan, manage and conclude projects. The Project Management Knowledge Areas axis lists ten areas of responsibility that must be addressed by the project manager while managing the project. Each of the three dimensions is discussed in more detail below.
Typical Project Life Cycle
Project Management Knowledge Areas
Support Resources Implement
Procurement Cost
Build
Organizational Impact
Time Scope
Design
Communications Quality
Integration Analysis Risk ID & Assess
Initiate
Plan
Execute
Control
Close
Project Management Core Processes Figure 1.1 – The Three Dimensions of Project Management
Originator: One IT PPM Team Page 7 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Project Management Core Processes
Project management processes as defined by the Project Management Institute (PMI) are shown in figure 1.2 below. Initiate Project Plan Project
Control Project
Execute Project
Close Project
Figure 1.2 - Core Project Management Processes
Originator: One IT PPM Team Page 8 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Project Management Knowledge Areas
The ten project management knowledge areas, shown in figure 1.1 and described below, represent what the project manager manages while executing the project management processes.
Integration Management:
Ensure that all elements of the project are coordinated properly and included in project plans. This includes hardware, software, networks, training, etc.
Scope Management:
Ensure that the project includes all of the work required and only the work required to complete the project successfully, including scope planning, scope definition, scope verification and change management.
Quality Management:
Ensure that the project will satisfy the requirements that have been agreed and that quality assurance and quality control processes are completed.
Time Management:
Ensure timely completion of the project by defining and managing tasks to be completed, the sequencing of work, the resources assigned, task durations, and the project schedule.
Cost Management:
Ensure that the project is completed within the approved budget by estimating, monitoring and controlling project costs.
Risk Management:
Identify, assess and mitigate project risks associated with factors such as new technology, very tight schedule constraints, lack skilled resources, and readiness of the user organization to accept the change.
Communication Management:
Provide timely and appropriate generation and dissemination of project information to management and all other stakeholders to ensure that their expectations are consistent with the realities of the project.
Organizational Impact Management:
Identify organizational changes that must occur and develop appropriate communication and training programs for impacted departments and staff to support the new system or change.
Resource Management:
Provide effective leadership and management of the project team, including project organizational planning, Staff Requisition, and team development.
Procurement Management:
Acquire goods and services from outside vendors as needed by planning procurement, preparing requests for quotes, making source selections, and negotiating and administering contract negotiation.
The Project Life Cycle
IT projects are divided into stages that make up the project life cycle. Each stage has specific processes and deliverables. For example, the processes and deliverables for Classic Systems Development Life Cycle (shown here) are described in the Classic Systems Development Solution Delivery Methodology Guide. Similar guides are planned for different types of projects, including Object Oriented Development and others.
PM Alignment to
As shown in figure 1.3 below, project management activities overlap with and enhance the processes defined in a typical solution delivery life cycle.
Originator: One IT PPM Team Page 9 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Typical Project Life Cycle
Project Life Cycle
Initiate
Plan Core Project
Execute
Mgmt Processes
Control
Close
Figure 1.3 – Project Management alignment to Project Life
As this diagram shows, elements of Execute and Control occur at each stage of the project. It is, therefore, recommended that the reader refer to the Execute and Control sections throughout the project life cycle and take action, as needed, to acquire resources, monitor and control project performance, and review and approve project deliverables.
Originator: One IT PPM Team Page 10 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Key Principles will be placed in this section Key Principles of Project objectives must be SMART Project Project objectives must be Management Specific -- clear and precise Measurable -- quantifiable Achievable – realistic Relevant – linked to business needs Time-based – defined by clear deadlines
Understanding and managing requirements is crucial Each requirement should be traceable to a specific project objective described in the Project Charter. The ability to trace planned and completed requirements assures that the delivered product will satisfy Customer needs and will not include inappropriate or extraneous functionality.
Planning is everything and ongoing The single most important activity that project managers engage in is planning -detailed, ongoing, systematic, team-involved plans are the true foundation for project success.
Control is a necessity, not a luxury Schedule and cost overruns, issues that go unresolved, risks that are not mitigated, and changes that are made to plans and deliverables without adequate review and approval will inevitably lead to project failure. This is why rigorous monitoring and control is an absolute necessity and a key role of the Project Manager.
Customers must be part of the process Customers demand the right to approve deliverables. Along with that authority comes the responsibility to be active participants in the project. It’s the Project manager’s job to ensure that Customers understand what is expected of them and that they are kept informed and active through out the project life cycle.
Providing an honest assessment of project health is critical Assessing project health opening and honestly on a regular basis is critical to the successful management of the Ford IT portfolio. For sponsors and management to make the right decision about a project's future, it must have accurate information about the state of that project.
We know what works, just do it We know what works. Methodologies like those described here today ensure that standards and best practices are built into project plans and deliverables. Not only do these methodologies support quality, they help minimize rework.
Metrics should be collected throughout the project life cycle Metrics should be collected throughout the project life cycle and used to help manage and evaluate productivity, timing, cost, and quality. A good metrics program will enable better trend analysis and more effective process improvement. The following are the OneIT recommended metrics to be captured and reported Function Points (FP)
Function Points are a measure of the functionality delivered by an application and provide an objective quantification of a
Originator: One IT PPM Team Page 11 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Points (FP)
an application and provide an objective quantification of a project's size. They may be used by the Project Manager to help evaluate project scope, determine resources required, estimate project effort and duration, and prioritize deliverables. The Project Manager will work with a Metrics Specialist to schedule and conduct workshops to generate Function Point counts. Often three separate Metrics Workshops will be conducted for a project: Initial, Interim, and Final. An "ad hoc" Function Point Workshop is also an option for very large projects or special situations.
Function Points per Staff Month
Function Points per unit of work is a measure of productivity. Function Points are estimated during the Analysis and Design stages, and a final count is done at the end of the Build stage.
Time to Market, TTM per 1000FP
Time to Market is a measure of speed of delivery. TTM per 1000 Function Points provides a way to evaluate speed of delivery for projects of differing sizes.
Schedule Variance
Start and End Dates for each stage are documented in the work plan. These are compared with the estimated dates to determine schedule variance for each stage and for the project as a whole.
Cost Variance
Cost variance is used to evaluate how well the project met budget goals. Cost variance is calculated by subtracting actual cost of the project from budgeted cost.
Cost per FP
Cost per Function point is a metric that considers project size when evaluating the cost of development efforts. The impacts of variables such as platform and complexity are considered and used to help with comparisons.
Support Cost per FP
The maintainability of an application is measured by dividing support costs by the number of function points calculated for the supported application.
Assignment Scope
Assignment scope is defined as the number of function points supported divided by the number of full-time equivalents supporting the application.
Defects per 1000FP
Defects are non-conformance to requirements. They are identified during Technical Inspections, QC Testing, and User Acceptance Testing. Defects are classified by severity. Defects per 1000 Function Pts provides a scalable measure of quality for projects of differing sizes.
Incidents
Incidents are post-launch defects. Incident data is captured and recorded on an on-going basis after solution implementation. Incident data includes severity, date reported, date closed, and causal factor. Some metrics reported by ADS include Release Quality, Number of Serious/Critical Incidents, Incidents Exceeding the SLA, Mean Time to Repair, and Mean Time Between Incidents.
NCI per Review
Non-compliance issues are identified in the Process Quality Assurance (PQA) reviews. The scores are a measure of adherence to process. They can be reviewed with other metrics to help evaluate the impact to the project of noncompliance to process.
Satisfaction Surveys
Project team members, sponsors, and end users are surveyed
Originator: One IT PPM Team Page 12 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Surveys
at the end of the project to evaluate project performance and satisfaction with deliverables. Other surveys are conducted to evaluate satisfaction with training and with implementation of the project solution. Application surveys are conducted on a time-driven basis to evaluate user and sponsor satisfaction with the application.
Project Variables
A number of variables need to be considered when evaluating project metrics. Some important variables include: • Technology Platform • •
Development Type (New Development, Enhancement, Purchased Package, etc) Complexity
The following diagram illustrates the metrics collected during a typical project's life cycle:
ID &
Support & Analysis
Assess
Design
Build
Implement
Function Points per Staff Month
Maintenance Support Cost per Function Point
Time to Market (TTM) and TTM per 1000 FP Assignment Scope (FP/FTE)
Schedule Variance Cost Variance (Budgeted less Actual Cost of Work) Cost per Function Point
Post Launch Incidents
Defects per 1000 FP (Defects identified during inspections and testing) NCI per Review (Non-compliance issues identified in a Process Quality Assurance Review) Customer Satisfaction Scores
Figure 1.4 Metrics captured over the project life cycle
Originator: One IT PPM Team Page 13 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide See the appropriate SDM Process Guide for more details on that roles and responsibilities that are relevant to a specific project type.
Purchased Package Selection and Implementation (PPSI)
Process changes and special considerations have been incorporated to address the selection and implementation of purchased products, including:
• •
Procurement-related processes include considerations for working with 3 rd party vendors. A special concern with any implementation performed by 3rd party vendors is that the project team must pay special attention to ensuring that requirements are fully understood and incorporated into the solution. Classic SDM addresses this by explicitly including the Vendor/Supplier in Review Processes (ARB, PQA, Gate/Tollgate, Validate Requirements, Validate Design).
•
IT Management Tools
Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Precommitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information. The following picture depicts management tools currently in place for the tracking of applications and IT projects within the ADS organization. A description for each of the tools follows.
§ WebTracs: WebTracs is a web-enhanced budget and cost tracking application intended to assist Project Managers and Supervisors in the creation and updating of detailed Business Plan information. Strategic and Finance Planners will use the information to create Monthly and Quarterly Summaries. WebTracs is closely tied to ITMS. A project must first be entered in ITMS with high level business value information, the detailed costs will entered in WebTracs. The objectives of Web Tracs include:
Originator: One IT PPM Team Page 14 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide o Provide a web-enabled tool for IT personnel to track the complete project cost breakdown – calendarized by month, and separately track Capitalized Costs and Expenses. o Provide consistent information between financial reports produced by Strategic Planners and reports produced by Finance Planners. § ITMS: The IT Management System is a single common repository of all Initiative, Program, Project, and Application Portfolio data enabling effective management of IT’s work across the enterprise. Objectives of ITMS include: o To Deploy a Global Common Project and Application Repository to support the One IT Business Processes. o Support FMC Corporate litigation by serving as the system of record for all applications owned and supported by Ford Motor Company. § Prosight: Prosight is a Portfolio Management Tool, integrated with ITMS, which supports choosing, executing, and evaluating IT project and applications. The concept of Portfolio Management encourages organizations to evaluate the business value to the business when making business decisions. The objective of Prosight is to enable effective portfolio management by providing analytical capabilities to view project and application data based on key business drivers; thereby supporting fact based business decisions. The Prosight URL is http://www.itonline.ford.com/it_tools/Prosight.html. Refer to the ProSight tutorials named ProSight Form Data Entry and Project Manager ProSight Data Entry on the same web site for instructions in the use of Prosight. § IT Billing System: IT Billing will provide IT’s business partners with all their billing detail in an online, web-based system. This system will receive detailed billing data from the various IT departments, consolidate all charges, and create a single “IT Billing” Journal Entry for each business partner. The system will automatically feed the Journal Entries into PeopleSoft/MICS. The major objectives of the IT Billing System is to redistribute internal costs and influence behavior by providing a consolidated, detailed IT bill to the Business Partners. § RMS: ADS Resource Management System will ensure smooth operation of the Application Development Services organization resource management model for both Ford and agency personnel. The system will enable Ford to further develop and strengthen its core Information Technology competencies. Objectives include: o Ensure smooth operation of the ADS resource management model for both Ford and agency personnel. o Manage resource acquisition placement, and release process. o Manage skills inventory of ADS project resources to meet business and IT strategy demands. . o Provide a time keeping, and financial reporting solution. o Establish measures of success for the operational ADS Resource Management tool. § MRS: MRS is the Application Development Services (ADS) metrics repository that provides the functionality for reporting and recording measurements and metrics related to the Software Development Life Cycle. The planned enhancements encompass the collection and reporting of application development, enhancement and maintenance project data used to produce metrics related to productivity, cost, timing, sizing, quality, process assurance and customer satisfaction metrics. Objectives include: o Automate and centralize all ADS project, product and process metrics as input for use in making timely data driven decisions to maximize customer satisfaction, minimize the overall engineering effort and schedule, and to minimize the number of defects produced.
Originator: One IT PPM Team Page 15 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide o Provide metrics that will help to identify opportunities for process improvement and to assess and measure the impact and return on investment of process changes made.
o Include as a minimum, size, effort, estimation, productivity and schedule metrics, technical inspection, detailed defect and customer feedback metrics, and adherence to process metrics.
Originator: One IT PPM Team Page 16 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
GAO Audit Guidelines
The Ford General Auditor's Office (GAO) requires that all documentation (electronic and paper) adhere to security guidelines and retention policies. Also note that electronic documents/data should not reside on desktops, but in an agreed repository (e.g.; electronic project control book on a shared network drive, PVCS, eRoom, etc.).
Project Authorization Requests and Purchase Orders
As indicated in the Ford Financial Manual procedure #55-10-11, no commitments may be made until the overall program (or a long-lead request for the program) of which the action is a part has been approved. For most operations, funding for the specific action is authorized by an approved "Project Appropriation Request / PAR", including a standard set of project detail sufficient for control. Funds for the following items are to be requested through use of appropriations requests (or lease requests):
• • •
• •
• •
• • •
Purchase, from outside sources, of "off-the-shelf" computer software programs. Development of "Internal-Use" custom Ford computer software programs developed by Ford, agency, outside purchased services or any combination of these resources. Acquisition or modifications of fixed assets (land, building, equipment, vehicles, material handling equipment, tooling, etc.), and related expenses including freight and rearrangement costs. Substantial items that are of a fixed asset nature, but for accounting purposes are expensed. Major repair, maintenance, and overhauling of equipment, including all nonrecurring requests or requests that recur at infrequent intervals. (An infrequent interval is a lapse of time greater than a year.) Leases that are of fixed asset nature (represents a greater than 1 year commitments of payment), even though it may expensed for accounting purposes. Supplier agreements involving contingent liabilities (as defined by FM 55-10-70). If a payment of a previously approved contingent liability becomes necessary, a separate project request authorizing payment is required. Acquisition or granting of easements, right of way, or licenses. Acquisition or granting of options to purchase or lease (including leases of office space from Ford subsidiaries). Disposal of capitalized assets.
Actions Not Requiring Appropriation Request - Appropriation requests are not required for the following types of items:
•
•
Items normally included in overhead expense accounts and budgets, such as normal maintenance, preventive maintenance, service contracts, perishable tools, launch costs, training, fire/security cover not of an incremental nature, and similar continuing or recurring items. Items are to be capitalized for the first time upon acquisition. Expenses (freight, dismantling, installation, and similar costs) associated with intra/intercompany fixed asset transfers may be documented with use of an Intercompany Buying Authority, to be approved by the local Controller.
Originator: One IT PPM Team Page 17 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
•
•
Items less than $25,000 at the discretion of the Controller/Finance Manager, provided that an alternative system provides comparable control and that the action is approved by the appropriate approval authority. In developing project detail, line items of less than $25,000 need not be separately identified. For the appropriation request, such items may be grouped in major categories such as building improvements, machinery equipment, office furniture, etc.
Note that for a Purchase Order (PO) can be released by Ford Purchasing, the following steps must occur:
• • • • • •
Cost information must be entered by an authorized MEARS user in the PAR. An Authorized MEARS user (Controller/Finance Manager) reviews and approves the PAR. Cost information from the approved PAR is automatically transferred from MEARS to an intermediate application named PCPAS (North America) or COIN (Europe). The PO is created by the Purchasing Buyer in the purchase order application (CPARS, eVerest, or equivalent) and submitted for approval. A Ford Property Manager will review the PO, confirm that the cost is covered by an entry in PCPAS or COIN and approve/reject the PO. In either case, the Purchasing Buyer will be notified. If approved, the Purchasing Buyer will release the PO. If rejected, the Purchasing Buyer will notify the user that the PAR must be modified to address any issues.
The use of appropriation requests is described in the Financial Manual procedure #5510-11 which is located at http://www.dearborn.ford.com/fm/accntng/apfund55/apfprc55/5510/551011.html. The Project Appropriation Request / PAR description is located in Procedure 55-10-10 of the Ford Financial Manual which is at http://www.dearborn.ford.com/fm/accntng/apfund55/apfprc55/5510/551010.html.
Process Participant Roles For each task, the main participants are listed. Note that the roles in SDM are generic and not associated with an organization. For example, depending on the type and size of a project, the role of Business Analyst may be played by someone from the PTG organization or from the Practice. The bolded participant is the key person responsible for that task. Competency / Competency/Role Role Acronym
Responsibilities
Job Family
6-Sigma
6-Sigma Blackbelt
This is a person trained in 6-Sigma DMAIC and DFSS General IT processes. The 6-Sigma Blackbelt will work with the project Management team in the design of business processes and ensure that those processes will achieve Customer CTQ's. It is expected that all Business Analysts will eventually have Greenbelt or Blackbelt certification. Until a critical mass of 6-Sigma certified Business Analysts has been achieved, the Classic SDM Guide will treat the 6-Sigma role as an additional consultant on the project team.
ADSBusiness
ADS Business Manager
Coordinates service rates, approval of project costs against General IT account codes prior to project execution and billing of incurred Management project costs to account codes.
Originator: One IT PPM Team Page 18 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
ADSMgt
ADS Management ADS Manager with profit and loss responsibility for a project
General IT Management
AMCoord
Architecture Management Coordinator. Ensure that the project team adheres to Ford corporate architecture principles.
Architecture
APM/LOB
Application Portfolio Coordinate application and support activities for a portfolio of General IT Manager/ LOB applications, typically for one line of business. Management Manager
Review architecture selection for compliance with Ford architecture principles and standards.
AppDataAdmin Application Data Administrator
This is the person who has oversight responsibility for application data, including data integrity, adherence to the retention period as defined by GIS1 standards.
AppOwn
Customer with ultimate responsibility for application and N/A related business processes. This person is registered on the ACR as the application owner.
Application Owner
N/A
AppSecAdmin Application Security This is the person who administers security for an application N/A Administrator and defines the type of access allowed. AppSupr
Application Supervisor
Provide oversight for maintenance of one or more applications.
General IT Management
AppTechArch
Application Technology Architect
Plan and design of application platform technology patterns, usage standards, and guidelines used to implement IT solutions. Extend existing architectures to satisfy changing application needs.
Architecture
BusA
Business Analyst
Work with Customer to identify and documenting requirements, perform business process design, measure process capability, and perform Acceptance Test with Customer.
Business Analysis/ Reengineering
CDBA
Corporate / Data Center Database Administrator
Install and configure database products.
Database Administration
CDM
Capacity Demand Works as a liason between with project teams and the Data Management (CDM) Center to select and allocate hardware and software for all Analyst technical environments (e.g.; development, QC, Education, Production, Support) in a timely manner.
Cust
Business Customer(s)
Operations
Person(s) knowledgeable of all requirements and business N/A processes in a subject area, and empowered to define and accept solution. It is expected that the Customer will actively participate throughout the project and will sign-off on designated SDM deliverables. See the section titled " Customer Involvement In Projects" for further information.
DBA
Data Base Administrator
Provides expertise, and performs physical database design, administration and related planning.
Database Administration
DMT
Data Model Team
A peer review team made up of analysts and the lead Information Architect from a Practice that reviews proposed
Architecture
Originator: One IT PPM Team Page 19 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
data model changes for compliance with Ford data standards. These individuals also coordinate cross-application database changes. Espon
Executive Sponsor(s)
IT and Business Sponsors who fund the project and actively participate throughout the life cycle.
EUSupport
End User Support Analyst
Provide consulting services, implementation services, End User production, operational and systems support for distributed Support computing at all locations; serves as a liaison between clients and vendors or other technical groups to resolve client problems. Also provide feedback to corporate application owners on user-base issues and establishing effective support processes Across it support organizations to ensure timely resolution to end user technology issues.
Facilities
Facilities Analyst
Coordinate overall planning, deployment and operations of facilities within computer centers.
FGTI
Intellectual Property Review application and/or business processes and provide attorney from Ford Customer with advice/guidance and support with respect to Global applying for patent. Technologies, Inc.
N/A
FinanceAnal
Financial Analyst
Allocate and release funding for projects (e.g.; hardware, software and services) on behalf of a business area. This person may also assist with development of project cost estimates.
General IT Management
GAO
GAO Prevention Control Specialist (GAO ACR reviewer)
Review ACR documents with the ICC and Application Owner General IT to ensure that the application adheres to Ford security and Management maintenance standards.
ICC
Internal Controls Coordinator
Provide support to project teams that are developing an ACR General IT and/or ICR. This person will provide ongoing ACR coaching, Management review the ACR drafts, and present them to the GAO along with the Project Manager and Application Owner.
ImpA
Implementation Analyst
Develop deployment-related materials, implementing the solution and providing training.
InfoArch
Information Architect
Plan and design data and its relationship to business Architecture processes to ensure correct information boundaries, integrity, security, accuracy and the proper use of information.
InfraArch
Infrastructure Architect
Specifies the computing infrastructure and services needed to Architecture support the development and deployment of the solution, including the proper mix of commercial off-the-shelf products (COTS), hardware, and networking.
IntTest
Systems Integrator Lead integration and testing of application components into a Solutions and Integration completed application. Development/QA Tester
Inventor
Inventor
The originator of concepts, processes or products/software.
N/A
IRR
Independent Risk Reviewer
Evaluate project risk (prior to project start) based on a predefined set of questions.
Project/Program Management
ITET&D
IT Learning – Create application-specific training materials as well as Education, Training provide the training on an as-needed basis. and Development (ET&D)
Originator: One IT PPM Team Page 20 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
N/A
Facilities
End User Support
End User Support
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
KE
Knowledge Engineer
Develop strategy, provide expertise and long-range planning Knowledge in the areas of it knowledge acquisition, capture, analysis, Management dissemination, retention and reuse efforts. Determines relevant sources of it information/knowledge in support of project requirements and provides guidance to implement global information standards as required within project specifications.
LDevl
Lead Developer
Guides and oversees development of application software components.
Solutions Development/QA
Metrics
Metrics Specialist
Ensure consistent metrics gathering. The specialist will collect, review, analyze, and report program/project metrics.
Process and Methodology
NetE
Network Engineer
Individual/group with responsibility for all aspects of the Network networks for a geographical area and the impacts to the rest Engineering of the global network. Assists with the design, evaluation, selection, and integration of networking technologies to meet the needs of the business.
NLM
Next Level Manager The manager directly over the Project Manager from a reporting perspective.
OGC
Office of General Counsel Attorney
Provide legal counsel for legal transactions such as contracts, N/A as well as advice and guidance with respect to legal issues, Office of General Counsel (OGC) Document and record Suspension Orders, etc.
Oper
Data Center Operations
Perform daily data center operations support activities (backup, restore).
PGM
Program Manager
Direct all program -related activities. Initiates, plans executes, Project/Program controls, and closes program, ensures requirements are Management understood across all project teams, prioritized and that what is delivered meets the agreed requirements. Provide oversight in the management and execution of multiple projects or projects that are viewed as large and/or complex.
PM
Project Manager
Direct all project-related activities – initiates, plans executes, Project/Program controls, and closes project, ensures requirements are Management understood, prioritized and that what is delivered meets the agreed requirements.
PQA
Independent Process Quality Assurance Coach
Process coach who will provide coaching with respect to Process and methodology selection, related processes and templates. Methodology They will also participate in project/program reviews to ensure adherence to process quality assurance guidelines.
PracticeMgr
Practice Manager
Provide application management for a particular business General IT function, spanning the entire software development life cycle. Management
PSDevl
Production Support Support and maintain application – performs production Developer/Analyst support, participates in incident/enhancement design, constructs, tests, and documents application code. Ensures the completeness of changes as the version specialist; Coordinates build and packaging for a project as the build specialist; performs SCM audits and reports the results.
Purchasing
Buyer from Ford Purchasing
QCLead
Quality Control Test A senior tester, with an understanding of test processes, templates and tools who may lead the development of the
General IT Management
Operations
Solutions Development/QA
Works with project teams to acquire vendor-provided N/A information, RFP/RFQ, and negotiate the acquisition of goods or services.
Originator: One IT PPM Team Page 21 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Solutions
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym Lead
Responsibilities
Job Family
Quality Control Test Plan and Strategy.
Development/QA
QCTest
Quality Control Test Provide testing expertise and guidance, develop QC Test Specialist Strategy and Plan, develop and execute both functional and system tests.
Solutions Development/QA
RDM
Resource Deployment Manager
The Resource Deployment Manager will manage a pool of General IT ADS resources to ensure that they are being highly utilized as Management well as deployed in a fashion that accounts for Ford's overall resource requirements Responsibility: assign resources; report resource utilization information to management
RS
Reuse Specialist
Develops strategies and leads implementation of knowledge- Process and capture, -retention and -reuse efforts on it projects. Methodology
SAE
Specialized Application Engineering
SCC
Security Control Champion
The security control champion is organization-specific and will General IT ensure that Ford's security needs are recognized and Management addressed in the implementation of policies, business processes and computer applications.
SCCB
Software Configuration Control Board
Group responsible for evaluating and approving/rejecting proposed changes to configuration items and for ensuring implementation of approved changes.
N/A
SCM
Project Software Configuration Management Specialist
Person responsible for coordinating and implementing software configuration management (SCM) for the project.
Solutions Development/QA
SCMTool
SCM Tool Administrator
Install, configure and support software configuration Solutions management (SCM) tools, process, and procedures to ensure Development/QA they are understood and followed .
SDevl
Software Developer Participates in design activity and constructs, tests, and Solutions documents application system code under the guidance of the Development/QA lead developer.
SecE
Security Engineer
SIE
Strategic Work with one or more project team members to test an Technology Infrastructure application to determine whether it is well behaved (e.g.; Analysis Engineering Analyst DLL's installed in correct location, DLL's are not over-written, (was called Ford etc.) and that it is compatible with the Ford Standard desktop. Systems Integration Center / FSIC)
SiteCRM
Site Client Relationship Manager
Manage the application and technical environments at a site End User as well as act a liason between the Customer and application Support development/deployment and support teams.
SME
Subject Matter Expert
Person with sufficient knowledge of a business process as to Business be considered an expert on the subject who will provide Analysis/ guidance on an as -needed basis. Reengineering
SolnArch
Solution Architect
Responsible for the assembly and integration of business processes, data, and application and infrastructure
Specialized Application Engineering
Provide consultation on enterprise security both within the organization and external business units. Provides assessment, vision, expertise, direction and guidance in the implementation of secure solutions.
Originator: One IT PPM Team Page 22 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Security Engineering
Architecture
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Competency / Competency/Role Role Acronym
Responsibilities
Job Family
components into optimal solutions that adhere to the Architecture Framework, principles, and standards. Stakeholder
Stakeholder
The term "Stakeholder" is project-specific and refers to any person who has a vested interest in the development and deployment of business processes and computer applications. These people will provide guidance to project team on an ongoing basis.
Steering
Steering Committee A group of individuals (e.g.; managers and subject matter N/A experts) who can provide oversight and guidance to a project/program. From a reporting perspective, the Steering Committee reports to the Executive Sponsor and has the project team report to it on a periodic basis. These people will review project status on a periodic basis; provide guidance on an as -needed basis.
Supplier / Vendor
Any 3 rd party or a Company outside of Ford that either directly or indirectly N/A representative of a provides hardware, software, goods or services to or for Ford. 3rd party that is either supplying software or software services
SysDesAn
Systems Designer/Analyst
Individual who oversees design of business processes, application architecture, user interface and system design.
Systems Design/Analysis
SysE
Systems Engineer
Individual who participates in hardware/software insfrastructure design and installs/configures the related products. This person is a aubject matter expert within specialty domain on future technology, industry trends and direction; Responsible for end-to-end solutions within a specific application area; e.g. Plant floor, CAE.
Systems Engineering
Team
Project Team
In general, these are all members of a project team.
N/A
Tech
Development Tools Individual with expertise in development Tools. Technical Specialist, Technology Analyst
UsabSpec
Usability Specialist Evaluates an application's ease of use and suggests usability Solutions improvements. This individual can plan usability testing; Development/QA execute usability testing; provide usability feedback after testing; provide coaching on an ongoing basis.
WebDesigner
Web Designer
A member of the "Web Creative Services Group" who will assist in the design and development of web-based user interfaces.
N/A
Technology Analysis
Solutions Development/QA
Consult the One IT Competency Center Website at http://www.itonline.ford.com/home/it-prof/it-comp/ for additional information.
Originator: One IT PPM Team Page 23 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 24 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.0
Initiate Project Project Management Processes
Project Proposal Executive Summary Initial Business Case Change Program Request Charter
Initiate Plan Execute
Solution Delivery
Control
Methodology Close
Inputs to Initiate Project Overview
At the start of any project, there will be a variety of ideas and opinions about its purpose and scope, what the final product will be, and how the project will be carried out. Project Initiation is concerned with taking these ideas and intentions and developing them into a formal, planned, resourced and funded project. The purpose of Project Initiation is to define the overall parameters of the project, develop initial project plans, and define the appropriate project management and quality environment required to complete the project. Upon completion of Initiation, the sponsor(s), business analyst, and project manager should have enough information to make a go/no-go decision.
Process Contents
Objective 1.1
Prepare for the Project
1.2
Establish PM Infrastructure
1.3
Define the Project
Note Refer to PM Processes "3.0 Execute Project" and "4.0 Control Project" for processes such as "Maintain Project Records" or "Conduct Status Reviews" for process steps that must be carried out across all five PM Processes (Initiate, Plan, Control, Execute, Close).
1.4
Develop High Level Work Plan
1.5
Complete Investment Analysis
1.6
Confirm Readiness to Proceed
Process Steps 1.1.1 1.1.2 1.1.3 1.1.4 1.2.1 1.2.2
PM Deliverable
1.3.2 1.3.3 1.3.4 1.4.1 1.4.2 1.4.3 1.4.4 1.5.1 1.5.2 1.5.3
Confirm Project Readiness to Start Identify and Engage Stakeholders Engage Project Start-up Team Develop Start-up Work Plan Establish Project Control File Establish Project Procedures Develop Initial Charter/Enhancement Request Develop Project Approach Develop Quality Mgmt Plan Develop Communications Plans Develop High-Level WBS Develop Dependency Network Estimate Effort Develop High-Level Schedule Complete Initial Risk Assessment Develop Initial SOW Confirm/Refine the Business Case
1.6.1
Confirm Requirements/BOV
Bus. Owner View Signoff
1.6.2
Obtain Initial Charter/Enhance. Req. Sign-off
Charter Approval Signoff
1.3.1
Originator: One IT PPM Team Page 25 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Readiness Confirmation Stakeholder Assessment Resource Request/Roster Work Plan for Initiation Project Control File Setup Procedures/Logs Started Commitment Level Charter Methodology/Approach Quality Mgmt Plan Communications Plan Initial Work Breakdown Dependency Network High Level Estimates High Level Schedule Risk Assessment/Plan SOW Financial Scope
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.1
Prepare for the Project
1.1.1
Confirm Project Readiness to Start
The purpose of this process step is to ensure that the project is ready to start by confirming that a record exists for the project in ITMS, RMS and MRS, an initial SOW has been prepared and forwarded to the ADS Business Office, funding has been provided and that required inputs are available. Required inputs include the following: •
The original proposal or application change request(s) that precipitated the project. The high-level business case that was used to justify initial funding for the project (not applicable if the project is the result of change requests being bundled into a project that will lead to a new application release. A Project Scalability Questionnaire that provides a relative sizing for the project. Where appropriate, a Program Charter (i.e., where the project is part of a larger initiative or program).
• • • Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
•
The key considerations include:
• • • • • • •
Diagram
Is the original project proposal or application change request available? Was a high-level business case created to justify project funding? Has funding been provided? Has an initial SOW been created and forwarded to the ADS Business Office? Is the relative size of the project known and documented in a Scalability Questionnaire? Is the project part of a larger initiative or program? The Project Appropriation Request should identify expected services as well as hardware/software costs.
Reference the introductory section in this guide titled "Project Authorization Requests and Purchase Orders" for further information on Project Appropriation Requests / PARs and Purchase Orders POs.
No diagram created for this process step.
Process Tasks No 1
Task Name
Description
Confirm creation of Project Appropriation Request
Confirm that the Project Appropriation Request / PAR has been created and approved. The primary purpose of the appropriation system is to control the Company's expenditures for fixed assets including capitalized facilities and tooling as well as items of fixed asset nature (such as leases with greater than one year payment commitments) even though they may be expensed for accounting purposes. Company management exercises control of the appropriation system by means of the Corporate Cash Flow, the quarterly forecast of facility and tooling spending, and the review of individual funding requests. The principal document in the review of individual funding requests is the appropriation request, and is intended to provide management with a
Originator: One IT PPM Team Page 26 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants PM, PracticeMgr, FinanceAnal
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide uniform presentation of requests for funding. The Project Appropriation Request is the principal document used in the review of individual funding requests, which are intended to provide management with uniform and organized information on expenditure proposals. Mechanized Appropriation Request System / MEARS is the required method to create a Project Appropriation Request / PAR. The MEARS website address is http://www.finance.ford.com/mears/index2.html. 2
Confirm creation of initial SOW and project funding.
Confirm that the initial SOW has been created and forwarded to the ADS Business Office and that the project is funded. If funding has not been resolved or the SOW has not been created and forwarded, ensure that the process titled "Develop Initial SOW" is executed before proceeding. Note: This process assumes the project is being done within ADS. If this is not the case, the process will need to be tailored so that the SOW is forwarded to the appropriate area.
PM, PracticeMgr
3
Confirm Six Sigma Tollgate 0 (Recognize)
Confirm that the Six Sigma Tollgate 0 (Recognize) process has occurred. The Recognize tollgate ensures that:
PM, PracticeMgr, 6-Sigma
• • • • • •
An opportunity has been identified and has been identified as "green field" or "redesign" Primary goals have been identified Customer segmentation has been addressed Linkages have been established to Business Objectives and Customer Satisfaction Sign-off has been obtained from Executive, IT and Financial leadership A general budget has been established
4
Review the Business Case
Review the high-level business case used to justify and secure that funding or the change requests that have been bundled to make a new application release project. Note: A Business Case may not be required for enhancement requests to existing applications.
PM, BusA
5
Review Project Proposal or Change Request
Review the project proposal or change request(s) that precipitated the project to better understand the business need. Ask questions of the pers on who submitted the proposal or request as appropriate.
PM, BusA
6
Confirm Project Records Exist
Confirm that a record has been created for the project in ITMS, RMS and MRS. If not, ask the Business Analyst assigned to the project to create the appropriate records.
PM, BusA
7
Confirm that a Scalability Questionnaire is Completed
Confirm that a Scalability Questionnaire has been completed for the project. If it has not, work with the Business Analyst to Complete one.
PM, BusA
8
Complete a Sizing Profile
Complete a PQA Metrics sizing profile to identify the sizing category of your project as shown below. Note that this sizing profile is used as a guide to the solution delivery methodology deliverables that are required for each project category. The profile is located in the 232_PQA_Metrics_Project_Sizing_Profile.doc template.
PM, BusA
9
Engage Process Quality Assurance
Review the PQA web site: http://www.itonline.ford.com/sdm/classic/pqa/ to determine level of involvement required. If PQA involvement is required or desired, continue with steps 10-11.
PM
Originator: One IT PPM Team Page 27 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 10
Schedule Initial Meeting with PQA Consultant
The Project Manager schedules a meeting with the assigned PQA.
PM
11
Prepare PQA Waiver form
If the PM and NLM feel that the project should be exempt from PQA reviews and involvement, a PQA Wavier form must be completed.
PM, NLM, PQA
Tools/Techniques Summary Methods and Applications/Tools ITMS: http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Appropriation Request / PAR description located in Procedure 55-10-10 of the Ford Financial Manual which is at http://www.dearborn.ford.com/fm/accntng/apfund55/apfprc55/5510/551010.html MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_ Managers.doc
Inputs to Process 241_Project_Proposal.doc 242_business_case.xls 231_Scalability_Classification_Questionnaire 243_program_charter.doc RMS – http://www.rms.ford.com
Outputs Project Appropriation Request / PAR at the MEARS website http://www.finance.ford.com/mears/index2.html. 231_Scalability_Classification_Questionnaire ITMS Number at http://www.itms.ford.com/ RMS Record http://www.rms.ford.com/ Project Record in MRS http://www.ads.ford.com/mrs 232_PQA_Metrics_Project_Sizing_Profile.doc 239_PQA_Review_Report.doc 83_PQA_Waiver_Form.doc
Originator: One IT PPM Team Page 28 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients BusA, PQA, NLM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.1.2 Purpose
Identify and Engage Stakeholders
To ensure project success, the project manager needs to identify stakeholders early in the project life cycle, determine their needs and expectations, and manage and influence those expectations over the course of the project. Project Stakeholders are individuals , groups, or organizations that are actively involved in the project, or whose interests may be positively or negatively impacted as a result of the project. Stakeholders include, but are not be limited to:
• • • • • • •
The Project Sponsor or Sponsors, who provide funding and direction The Customer, who approves requirements, plans and deliverables Functional Managers of organizations that are impacted by the project End Users, who will use the product or service when it is delivered Suppliers, who will be impacted by/use the product or service Any organization involved in project review, approval or administrative processes, including Process Quality Assurance Full-time and part-time project team members who define and produce project deliverables
•
Representatives of the support functions that implement, train end users, and maintain the project deliverable The outputs of stakeholder analysis are used to develop project schedules and communications plans. Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations when identifying stakeholders are •
Who are the key stakeholders?
•
What organizations do they represent?
•
What is their importance to the project?
•
What role will they play on the project?
•
To whom do they report?
•
What strategy will be used to engage and communicate with them?
•
When is their participation anticipated?
The PM should work with stakeholders on the stakeholder assessment and get buyin from them. Diagram
No diagram provided for this process.
Originator: One IT PPM Team Page 29 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Identify Stakeholders
Work with the Business Analyst to identify and classify key stakeholders . Use the project proposal and concept documents as input to the process.
PM, BusA
2
Record Information About Key Stakeholders
Use the Stakeholder Assessment Matrix template to record the following:
PM, BusA
3
Use Stakeholder Information to Plan Project
Organization:
Identify the organization represented by the stakeholder
Name:
Provide the name of the stakeholder
CDSID
Provide the CDSID of the stakeholder
Phone:
Provide the phone number of the stakeholder
Reports To:
Identify to whom the stakeholder reports
Availability
Record the stakeholder’s availability as a percent of time available or as specific dates, if known.
Role on Project:
Describe the stakeholder’s role on the project.
Importance to the Project:
Assess the stakeholders importance to the project as H- High, M- Medium, or L- Low
Engagement Strategy:
Briefly describe the strategy for engaging and communicating with the stakeholder.
Use the stakeholder information to assess risk, develop the charter, plan meetings, and develop communications plans.
PM
Tools/Techniques Summary Methods and Applications/Tools Interview with Sponsor/Business Analyst Microsoft Word
Inputs to Process 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire Org Charts (if available)
Outputs 201_stakeholder_assessment_template.doc
Originator: One IT PPM Team Page 30 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients ESpon, BusA
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.1.3 Purpose
Engage Project Start-up Team
The extent to which the project team has been defined at the beginning of the project may vary. At a minimum the manager for the project and individuals who can provide support in preparing for the project should be identified. This might include representatives of activities responsible for implementing and supporting project deliverables and other subject matter experts who represent both business and technical concerns.
During project initiation, the project concept documents are reviewed to determine the roles required to staff the project. With the help of appropriate stakeholders (i.e., the sponsor(s), program manager, and business analyst), the project manager should identify the roles that are needed to define the project and the names of individuals who will fill those roles.
As the project progresses and more is known about project deliverables and timing, it may be necessary to identify and take on additional roles and resources. It is up to the project manager to ensure that these needs are recognized and addressed.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations when identifying team members are
• • • • • • Diagram
What knowledge/skills are needed to define the project? What knowledge/skills are needed to define requirements? What knowledge/skills are needed to define the solution? What knowledge/skills are needed to produce deliverables? What knowledge/skills are needed to validate deliverables? What knowledge/skills are needed to enforce standards?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Identify Skills Needed
Create a two dimensional matrix. List the skills/knowledge needed on the project – particularly in early stages – down one side.
PM, BusA
2
Identify Candidates
List the potential team members across the top of the matrix.
PM, BusA
3
Map Skills to Candidates
Mark the intersection between skills/knowledge and each candidate. Identify and close gaps.
PM, BusA
4
Obtain Required Resources
Request and engage resources required.
PM, Sponsor
5
Create a Team
Create a team roster identifying team members, their home
PM
Originator: One IT PPM Team Page 31 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Roster
organization, their role, and the amount of time that they will be available.
Tools/Techniques Summary Methods and Applications/Tools Skills needs assessment Microsoft Word Resource Request located at http://www.ads.ford.com/resman/
Inputs to Proce ss 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire 242_business_case.xls
Outputs Resource Request located at http://www.ads.ford.com/resman/ 203_team_directory_template.doc
Originator: One IT PPM Team Page 32 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Espon, BusA, Competency Center, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.1.4
Develop Start-up Work Plan
Purpose
Most of the work that goes on during the first stage of a project is exploratory in nature. The goal is to understand what needs to be done so that detailed plans can be developed to specify how and when it will be done. Therefore, at the end of project initiation, it is expected that the team will have a more detailed, but still high level work plan for the remaining stages. In the meantime, a plan is needed to direct the activities leading to this outcome.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations for developing the Initiation work plan are
• •
Diagram
Have timing constraints already been defined for Initiation? What is the availability of each resource assigned to participate in Project Initiation?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Identify Activities in Initiation
Identify the activities in project initiation, including those outlined in this process guide and any activities identified for the solution delivery methodology (if known).
PM
2
Identify Participants
Use the stakeholder Matrix and Team Roster to identify participants.
PM
3
Estimate Duration
Determine the availability of participants and estimate the duration of activities.
PM
4
Develop Schedule
Develop and publish a schedule detailing the timing of activities and assignments.
PM
Tools/Techniques Summary Methods and Applications/Tools MS Project
Inputs to Process 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire 201_stakeholder_assessment_matrix.doc 203_team_directory_template.doc
Outputs 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 33 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.2
Establish PM Infrastructure
1.2.1
Establish Project Control File
Purpose
Maintaining information about the project in an organized fashion facilitates new team member transition and creates a central point of reference for those developing project deliverables. Most importantly, it provides an audit trail documenting the history and evolution of the project -- documents produced, decisions made, issues raised and resolved, and correspondence exchanged.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
The key considerations in establishing a Project Control File are
Diagram
•
What form of repository will be used (shared drive, eRoom, file cabinet)?
•
Who, besides the project team, should have access?
•
What will be done to protect sensitive/company confidential materials (if any) from external stakeholders (vendors and suppliers)?
No diagram provided for this process step.
Process Tasks No 1
Task Name
Description
Participants
Establish Project Control File
Decide how project records will be kept and where. The types of records to be maintained include, but are not limited to the following:
PM
• • • • • • • • • • 2
Set Up Version Control Mgmt Tool(s)
3
Maintain Project Records
The Project Charter and Addendums Project Plans Issue, Risk and Change Logs Change Requests Communications Plans Requirements Specifications Assignments Corrective Actions Approvals Procurement Documents Set up electronic control tool for the management of document and software versions. See Create Software Configuration Management section of the Solution Delivery Methodology Guide for suggested tools. Ensure that project records are kept current while at the same time maintaining a complete project history.
PM
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 34 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Shared Drive, File Cabinet or eRoom, PVCS (Program Version Control System) Note: If a shared drive is used, a predefined Control File structure can be downloaded from http://www.itonline.ford.com/sdm/ otherwise the team will need to set-up its own control book in PVCS or whatever other means is used.
Inputs to Process All Project Records
Outputs Project Control File
Originator: One IT PPM Team Page 35 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.2.2
Establish Project Procedures
Purpose
The purpose of this step is to ensure that project management procedures are established and communicated to the project team and stakeholders. This includes control logs, procedures for collecting status reports from team members and incorporating that information into status reports to be provided to team members and stakeholders.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
No key considerations
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Establish Project Logs
Using eTracker or MS Office files set up control logs for Issues, Risk and Change Management.
PM
2
Identify SCM Constraints
On software projects, identify and document any pre-existing constraints (e.g.; global requirements) with respect to software configuration management (SCM) products and procedures. Note: For pre-existing applications, the current SCM plan is an input to this activity. For new applications, the SCM plan will be developed as part of the solution development process.
PM, SCM
3
Communicate Change Procedures
Communicate procedures for submitting change requests and identifying new issues and risks to project team members and stakeholders
PM, BusA, Espon, Cust
4
Communicate Status Reporting Procedures
Communicate how status reports will be collected from project team members and the frequency of meetings conducted to review that status. Ensure that team members understand what information they must provide and when
PM, Team
5
Establish Team Meetings
Establish team meetings to review issues, risks, change requests, and progress. Weekly meetings are recommended. Establish a regular time and place, agenda and procedure for capturing meeting minutes
PM, Team
6
Establish Sponsor Meetings
Establish regular meetings with the Project Sponsor to review issues, risks, change requests that require Sponsor signoff and project progress. Monthly meetings are recommended. Establish a regular time and place, agenda and procedures for capturing meeting minutes
PM, BusA, Espon, Cust
7
Communicate Database Change Request Procedure
Communicate procedures for submitting normal and emergency logical data model, physical data model and database change requests.
PM, Team, DBA, DArch
8
Establish approach for logging defects
If performing Package Product Selection and Implementation / PPSI, the team will have to establish approach for logging defects and
PM, Team
Originator: One IT PPM Team Page 36 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide enhancement reques ts, then forwarding to vendor. Note that Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Pre-commitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information.
Tools/Techniques Summary Methods and Applications/Tools eTracker can be used to created the required logs, see http://www.etracker.ford.com or logs can be created in Word. See outputs below for the Work templates available.
Inputs to Process Project Control File 09_SCM_Plan.doc (for existing applications)
Outputs http://www.etracker.ford.com 212_risk_management_log.doc 213_issue_log.doc 211_change_request_log.doc 210_change_request_template.doc 220_meeting_minutes_template.doc 221_weekly_status_report_template.doc Database Change Request http://www.its.ford.com/as/dmts/lob/cgibin/dbchgreq.cgi
Originator: One IT PPM Team Page 37 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.3
Define the Project
1.3.1
Develop Initial Charter/Enhancement Request
The project charter or enhancement request is a critical tool for managing the expectations of the project sponsor(s) and other stakeholders. Its purpose is to help the project manager:
• •
Document the agreement reached with the sponsor/Customer Provide a clear statement of the project’s purpose and of what the team is committed to deliver • Define project roles and responsibilities • Make visible the work process and the approach that will be used to manage the project • Provide a baseline for scope and expectation management Chartering is an iterative process and demands a high level of stakeholder involvement – particularly the involvement of the sponsor(s) and business analyst. In the first stage of a project not enough is known to complete the charter in its entirety. The idea of the initial charter is to provide enough information for the sponsor to feel comfortable in continuing the project. Even a simple Enhancement Request may require several iterations to reach agreement on scope, timing, and deliverables. Note: The project charter should be tailored to the needs of the project. The information presented here is a guideline. Use professional judgment to present as much or as little information as is necessary for the project situation.
Trigger
The project has been selected and a project manager has been assigned.
Key Considerations
Key considerations in developing the charter are
Diagram
• • • •
Why is the project taking place? What will be accomplished by the project? How will project success be demonstrated? What will be delivered and when?
No diagram created for this process.
Process Tasks No
Task Name
Description
Participants
1
Review Existing Information
Review the project proposal, business case, and concept profile delivered with the project assignment and any existing documentation to understand the project’s purpose.
PM, BusA, Team
2
Identify Project Goal & Objectives
Identify the goals and objectives of the project. Project goals and objectives should align with the goals and objectives of the organization and that of the program to which the project belongs (if applicable). By definition, a project should have only one goal and
PM, Sponsor, BusA, Team,
Originator: One IT PPM Team Page 38 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3
Define Project Scope
multiple objectives that support that goal. Objectives must be measurable.
Stakeholders
Describe the scope as follows:
PM, Sponsor, BusA, Team, Stakeholders
Deliverable
Deliverable scope refers to the deliverables that the project will produce.
Logical
Logical scope delineates the boundaries of the information systems to be included in the project.
Organizational
Organizational scope s pecifies which organizations will participate in or be impacted by the project.
Temporal
Temporal scope defines the start date and end of the project, milestones, and any external dates that constrain it.
Financial
Financial scope summarized the project budget plan.
4
Identify Assumptions
Describe the key aspects of the project that are believed to be true, but should be expressly stated to ensure validity and concurrence, including items that should already in place.
PM, BusA, Team
5
Define Risks
Identify the high probability/high impact risks factors that may jeopardize a successful project outcome and their mitigation strategies and contingency plans (to be completed after the Investment Analysis is completed below).
PM, BusA, Team
6
ID Related Projects
Identify other projects that will impact your project. Include projects that are in progress and those that are planned.
PM, BusA
7
Describe The Project Organization
Describe the project organization, including key roles and responsibilities and the identities of individuals assigned to those roles, if known.
PM
8
Describe Approach
Describe, at a high-level, the solution delivery methodology chosen and the project management approach (to be completed after the "Define Project Approach" process is completed (below).
PM
Originator: One IT PPM Team Page 39 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Facilitated Sessions and Interviews Microsoft Word
Inputs to Process
Outputs
Recipients
242_business_case.xls 231_Scalablity_Classification_Questionaire.doc 243_program_charter.doc ∗ 241_Project_Proposal.doc Existing documentation, if any
200_project_charter_template.doc 230_enhancement_and_small_project_request_template 231_Scalablity_Classification_Questionaire.doc
Control File, Project Sponsor, BusA, Team, Stakeholders
∗
A program charter will be provided if the project is part of a larger initiative or program.
Originator: One IT PPM Team Page 40 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.3.2 Purpose
Develop Project Approach
The purpose of this process is to determine what project methodology, processes, accelerators, tools & techniques that will be used to achieve that project objectives. The primary objective is to ensure that the selected approach is the optimum method for managing the project and producing deliverables. The methodology that is used, the team’s experience, and management philosophy provide guidelines for establishing the project framework. Some paths through a methodology mandate a specific approach but, generally, some decisions must be made about the way the project is to be conducted. A benefit of this process is that it will help the project team to establish a common understanding of processes to be performed. The Project Manager will use this information as input when developing the project workplan.
Trigger
Key sections of an initial charter have been drafted, including the project goals and objectives and scope.
Key Considerations
•
•
•
Diagram
When selecting the methodology, processes and templates, the project team should understand the differences between Classic SDM and Unified SDM. See the If the team is not familiar with both methods, a PQA coach will be able to present the related concepts for both methodologies and help with the selection process. Developing and refining the Project Approach can occur throughout the project lifecycle. The process titled "Develop Project Approach" develops the initial Project Approach, and the process titled "Refine Project Approach" does refinement. Accelerators are proven techniques for delivering value to the Customer quickly. Examples of accerators include prototyping, co-locating the customer with the project team, and time-boxing. At this stage in the project lifecycle, you may not have all of the information you need to select some of the accelerators that will be appropriate for the project. However, you should know enough to begin looking at them and selecting the ones that will obviously apply. The Accelerator Use Plan template can be used as a starting point for selecting and documenting accelerators that will be used.
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Review Requirements
Review requirements, initial scope definition, and any technology decisions made to date.
2
Review method options and determine methodology
Review the methodologies available to the team. Note that the 246_Classic_SDM_and_Unified_SDM_Comparative_Overview.ppt presentation provides a comparison between Classic SDM and Unified SDM methodologies. Additionally, the PQA coaches can aid in
Originator: One IT PPM Team Page 41 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM, BusA, Cust, SysDesAn, SolnArch, PQA PM, BusA, Cust, SysDesAn,
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide understanding the methodologies and aid in the making of method tailoring decisions. Determine what methodology or methodologies will be used to meet project objectives.
SolnArch, PQA
3
Select processes and deliverables
Determine the processes and deliverables appropriate for the size and characteristics of the project. Document variances from the "standard methodology" in the Project PQA Plan. The plan should note any deviations from the standard methodology and justification for those decisions.
PM, BusA, Cust, SysDesAn, SolnArch, PQA
4
Select Project Accelerators
Review the list of potential project accelerators identified in the Accelerator Use Plan template and determine which ones will be applied. Note that, at this stage of the project, you may not know enough to make a final commitment on priorities and the accelerators that will be used, but it is a good idea to begin thinking about them now as some may require up front work to organize (e.g., co-location of the project team may require that different or additional facilities be arranged for the project once the Sponsor has signed the Initial Charter and given his approval to proceed).
PM, BusA, Cust, SysDesAn, SolnArch, PQA
5
Prioritize functionality and determine timing
Work with the customer to begin prioritizing functionality to be delivered as part of solution. Force rank the list of functions outlined in the Initial Charter and record that information on the Accelerator Use Plan. This information will be used to negotiate content of iterations/releases, scope, project timing and cost. These priorities will have to be taken into consideration if new functionality is requested or a corrective action is needed to recover a slippage in the project plan. Note: the Project Priorities Matrix in the Classic SDM Requirements Specification can be used to determine whether scope/quality, schedule or cost should be optimized.
PM, BusA, Cust, SysDesAn, SolnArch, PQA, ESpon
6
Review and Communicate Project Approach
Review the proposed Project Approach, PQA Plan and Accelerator Use Plan the Customer, project team, and stakeholders. Note: if significant variances from the identified methodology exist, consider gaining written authorization from the Practice Manager, PTG Customer Relationship Manager and Customer.
PM, BusA, Cust, SysDesAn, SolnArch, PQA, ESpon
7
Adjust Initial Charter
Ensure that decisions made here are appropriately reflected in the Project Management Approach section of the Initial Charter If this is a Six Sigma project, consider filling out the "PM Outline" tab in the DFSS MS-Excel workbook named "DCOV overview with forms.XLS".
PM, 6-Sigma
Originator: One IT PPM Team Page 42 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Facilitated Sessions PQA presentation titled 246_Classic_SDM_and_Unified_SDM_Comparative_Overview.ppt 247_Project_Approach_Questionaire.xls (job aid)
Inputs to Process
Outputs
241_Project_Proposal.doc
214_project_pqa_plan_template.doc
242_business_case.xls
200_project_charter_template.doc
231_Scalability_Classification_Questionnaire
204_Accelerator_Use_Plan.doc
200_project_charter_template.doc 02_Requirements_Specification.doc or 230_SDM_Enhancement_and_Small_Project_Re quest.doc
Recipients Control File, Espon, Team
--02_Requirements_Specification.doc or 230_SDM_Enhancement_and_Small_Project_Re quest.doc
Originator: One IT PPM Team Page 43 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.3.3 Purpose
Develop Quality Management Plan
The purpose of project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Accordingly, quality management includes the following: Quality Planning includes identifying which quality standards are relevant to the project and how to satisfy them. Incorporating quality standards into project design is a key part quality planning. For an IT project, quality planning might include planning a reasonable response time for a system or ensuring that consistent and accurate information is produced. Quality Control involves monitoring specific project results to ensure that they comply with the relevant quality standards while identifying ways to improve overall quality. Quality Assurance involves periodically evaluating project performance to ensure the project will satisfy the relevant quality standards. The quality assurance process generally involves independent review of project deliverables and processes (see 4.2.3 Coordinate Quality Reviews below).
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
For purposes of this methodology, quality is: Measured from the Customer perspective. One of the key components of a quality product is Customer satisfaction. A flawlessly design, defect-free product that does not meet the Customer’s needs cannot be considered to be high quality. Viewed as both a process and a product. A consistently high quality product cannot be produced by a faulty process. Everyone’s Responsibility. There must be a consistent and generalized set of principles that all parties can agree to and universally apply to make quality improvement a reality rather than simply a slogan. Measurable. Without baselines, it is impossible to take advantage of any measurements. Without data, it is impossible to know how the progress of the project relates to baselines.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Establish Completeness & Correctness Criteria
Review the deliverables outlined in the Scope section of the Project Charter. Establish completeness and correctness criteria for determining when each deliverable meets specifications. Use these criteria as standards when conducting deliverable reviews.
PM
2
Ensure Quality through
Ensure the consistency of the work within each deliverable and across
PM,
Originator: One IT PPM Team Page 44 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Reviews
deliverables through the appropriate reviews. Examples include peer reviews of deliverables, independent quality reviews with the Process Quality Assurance group, and gate reviews to assess overall project health with the Sponsor and IT Management. See 4.2 Conduct Project Reviews below for more details.
Team, PQA
3
Document Requirements for Metrics Gathering
The project work plan must include tasks that allow the project manager to gather and analyze metric data. Use metrics to measure and monitor the quality of the work process. Much of this data will come in the form of status reports, issues logs and change request logs.
PM
4
Document Planned Deviations
Document any planned deviations from the standards defined by the solution delivery methodology. Record those deviations and their justification in the Quality Management Plan section of the project charter.
PM
5
Review Quality Mgmt Plan
Review the quality management plan with the Business Analyst and project team. Make adjustments as necessary.
PM, BusA, Team
Tools/Techniques Summary Methods and Applications/Tools Review of initial project charter and the guide for the selected solution delivery methodology. Microsoft Word
Inputs to Process 200_project_charter_template.doc Solution Delivery Methodology Process Guide 57_PQA_Review_Checklists.xls
Outputs 200_project_charter_template.doc 214_project_pqa_plan_template.doc
Originator: One IT PPM Team Page 45 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.3.4 Purpose
Develop Communications Plans
Plan the way you will communicate to avoid chaos and confusion. Projects involve the transfer, use and retention of information. The more clearly and concisely you communicate and manage the information in your project, the fewer problems you will have. As the following diagram shows, the lines of communication on project can be very complicated. A well-thought out communications plan is needed to manage all of these crossing lines of hierarchy and functional relationships.
Corporate Executives IT Customer Relationship Managers Sponsor/Customer
IT Project Managers
Solution Architects
Business Managers
Users Developers
Support Groups
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
The communication plan should
•
Set out rules for the project management team; regarding who decides what, who tells who what, how they file and retrieve information, and how they manage documents.
•
Establish the concrete aspects of project management communication.
•
Define rules for notifying others about changes to the Project Plan.
•
Describe the media and communications channels that will be used.
•
Identify the information needs of the stakeholders and how they will be filled.
Originator: One IT PPM Team Page 46 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Diagram
No diagram provided for this process.
Process Tasks No 1
Task Name Identify Information to be Shared
Description
Participants
Determine what should be shared/made available to stakeholders. For example:
PM, BusA
• • • • • • • •
Project Charter and Plans Project Standards and Procedures Change Requests, Logs and Resolutions Status Reports and Plan Changes Key Issues and Decisions with Backup Specification and Design Documentation Roles and Responsibilities Approvals and Contracts Ensure that plans cover all of the items identified. 2
Complete a Communications Plan Template
3
Review and File Plan
4
Refine Plan as Needed
Using the Project Communications Plan Template record the following information for each communication planned:
PM
• • • • • •
The purpose of the communication Who will be responsible for preparing the communication Who needs to approve the communication From whom will the communication come Who will receive the communication What method will be used to convey the message (e.g., in a status report, in a newsletter, etc.)? • What communications vehicle will be used (e.g., the web, email, meetings) • How frequently will the information be communicated Review the Communication Plan with the Business Analyst and Project Team to assess completeness and file the Plan in the Project Control File. Refine the communication plan as project plans are finalized and changes occur.
PM, BusA, Team PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word
Inputs to Process 200_project_charter_template.doc 201_stakeholder_assessment_template.doc
Outputs 215_communication_plan_template.doc
Originator: One IT PPM Team Page 47 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.4
Develop High-Level Work Plan
1.4.1
Develop High-Level WBS
A Work Breakdown Structure is a hierarchical representation of the work that needs to be completed to deliver the product(s) that will satisfy the project’s objectives. It is the single most important tool for project planning, because it provides a framework from which:
•
Trigger
The total scope of the project can be described as a summation of the decomposed elements • Work activities can be defined and estimated • Dependencies and iterations can be identified • Costs and budgets can be established or confirmed • Time, cost and performance can be tracked • Responsibility can be established Development of an initial charter.
Key Considerations
The key considerations in developing the WBS are:
• • Diagram
Is there a representative WBS already in existence that can be modified for rapid reuse? Does the methodology being used provide a pre-defined work breakdown? The diagram below depicts the high-level process flow for this activity. Review Methodology for Existing WBS
Project Charter Requirements Specification
WBS PreDefined?
No
Identify Work Activities to Produce Deliverables
Decompose & Sequence Work Activities
Solution Delivery Methodology
Project
Note: The High-Level WBS generally stops at the Activity Level.
Yes
Ensure Completeness
Stage Activity
WBS Worksheet and/or MS Project Plan
Record WBS
Task
Process Tasks
Originator: One IT PPM Team Page 48 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Review Standards
Determine if the methodology being used pre-defines the work breakdown. If it does, skip to step 4. Note: The Classic Systems Development Methodology is an example of the methodology that pre-defines the work breakdown structure.
PM
2
Identify Work Activities
Using the project charter, work with team members to review the project deliverables and identify the work activities required to produce them.
PM, Team
3
Decompose & Sequence Work Activities
Decompose the work to the point where a high-level plan can be created.
PM, Team
4
Ensure Completeness
Review the breakdown to ensure that all of the work on the project is accounted for including Project Management and support activities.
PM, Team
5
Record the WBS
Use a WBS Worksheet to record the breakdown. If preferred, the breakdown can be entered directly into MS Project. Note: An MS Project Plan Template has been developed for the Classic Systems Development Methodology. See Tools/Technique Summary below.
PM
During Project Initiation, it may not be possible to develop a task-level WBS and, in fact, it is not necessary. A WBS that is decomposed two or three levels will suffice for initial estimates and schedule development.
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request
Outputs 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Originator: One IT PPM Team Page 49 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File BusA Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.4.2
Develop Dependency Network
Purpose
In order for the project manager to accurately determine the cost and duration of a project, a detailed schedule must be created. One of the first steps in creating that schedule is determining how many activities in the project are related to one another and the nature of their dependencies.
Trigger
Completion of the development of an activity-based work breakdown.
Key Considerations
Several items may affect activity sequencing and interdependence:
Diagram
•
Product description – characteristics, such as a subsystem interface on a software product may affect activity sequencing.
•
Mandatory dependencies – those dependencies that are inherent in the nature of the work underway. They often involve a physical limitation such as the availability of a specific test facility.
•
Discretionary dependencies – those that are defined by the project management team, such as deciding not to start a series of activities until after moving into new office space.
•
External dependencies – those that involve an external interface with other projects or events. For example, the testing activity in a software project may be dependent on delivery of hardware from another project.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
1
Record WBS in MS Project
Enter the high-level work breakdown structure into MS Project. Note: If you are using the Classic Systems Development Methodology, the work breakdown and dependencies have been entered into an MS Project Plan Template for you.
PM
2
Identify Links
Establish the finish to start, start-to-start, start to finish, and finish-to-finish relationships between dependent activities.
PM
3
Incorporate Iterations
Develop the appropriate iteration cycles for the development of deliverables and work products.
PM
4
Partition & Split Activities
Partition the work and split activities to make the work more manageable.
PM
Originator: One IT PPM Team Page 50 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Outputs 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Originator: One IT PPM Team Page 51 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File BusA Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.4.3 Purpose
Estimate Effort
Estimating is the art and science of using historical data, personal expertise, institutional memory, and the project scope statement to predict the resource expenditures, total cost, and duration of a project. The purpose of estimates created during Project Initiation is to provide the means for the project manager and sponsor to assess the viability of the project and make a reasoned go/no-go decision. Estimates provided at this point are order-of-magnitude and should include sufficient contingency to offset the degree of uncertainty inherent in the early stages of a project.
Trigger
Completion of the development of a task-based work breakdown and prior to development of the SOW.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Select Estimating Tool/Technique
Determine what method/model will be used to produce initial estimates.
PM, Team
2
Determine How Far Out Estimates Will Go
Decide how far out you should try to estimate in detail. Estimates can be produced in detail for the first few stages of the project and at a higher level further out.
PM, Team
3
Determine Amount of Contingency
Determine how much contingency to include in early estimate to offset uncertainty.
PM, Team
4
Estimate Project Duration
Use estimates to determine expected duration of the project or the number of Full Time Equivalent (FTE’s) resources needed to meet a finish date that was identified at the beginning of the project as a constraint. Discuss with the Business Analyst and Sponsor any scope, quality, time or budgetary requirements and constraints. The estimating goal helps specify the balance between the three project factors: quality, schedule, and cost.
PM, BusA, Espon, Team, ImpA
Examples of an estimating goal are:
•
Good quality, shortest possible schedule
•
Fair quality, lowest cost
•
High quality, reasonable schedule and cost
Note that estimating is not negotiating. Estimate the work as you see it, and then work with the Sponsor to determine how the work can be modified (scope reduction, added resources) to make the charter agreeable. Originator: One IT PPM Team Page 52 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 5
Define Temporal Scope
Complete the temporal scope section of the charter by filling in the high-level time line. Document your estimating assumptions as well.
PM
6
Refine the WBS and Initial Work Plan
Incorporate estimate data into the Work Breakdown Structure Worksheet (if in use) and the MS Project Plan.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project Microsoft Excel
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *
Outputs 205_wbs_worksheet_template.doc 228_Classic_SDM_Estimating_Model.xls 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 53 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.4.4
Develop High-Level Schedule
Purpose
The purpose of this process step is to produce an initial high-level project schedule with milestones identified.
Trigger
Completion of the development of a task-based work breakdown.
Key Considerations
No key considerations provided for this process step.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Develop Highlevel Schedule
Develop a high-level schedule. Where possible assign individuals to activities and roles to others.
PM
2
Identify Interim Milestones
Identify interim milestones – major checkpoints or deliverables.
PM
3
Update Initial Charter
Update the initial charter to reflect the schedule and milestones.
PM
4
Update Project Records
Update the project record in ITMS, RMS and MRS to reflect the updated schedule and file documents in project Control File.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp
Outputs
Recipients
200_project_charter_template.doc 229_Classic_SDM_Work_Plan.mpp 230_Enhancement_and_Small_Project_Request 232_PQA_Metrics_Project_Sizing_Profile.doc Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs ITMS Record at http://www.itms.ford.com/
Originator: One IT PPM Team Page 54 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, BusA, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.5
Complete Investment Analysis
1.5.1
Complete Initial Risk Assessment
There are always risks associated with a project. The purpose of risk management is to ensure levels of risk and uncertainty are properly managed so that the project is successfully completed. It enables those involved to identify possible threats, the manner in which they can be contained and the likely cost of countermeasures. Risk assessment is used during project initiation as one of the major criteria in deciding whether to do a project or not. Here, risk is compared to expected reward to see if it is worth taking.
Trigger
Definition of scope in an Initial Charter and completion the High-Level Plan.
Key Considerations
•
Risk response development may result in any combination of contingency plans, additional activities or tasks, changes in contractual agreements, etc. Estimates and schedules must be changed accordingly.
•
Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Complete a Risk Assessment
Complete the risk assessment checklist for the first time to obtain an initial numerical risk assessment score and risk rating. Use the calculated risk score to determine the amount of contingency to be included in the project plan.
PM, BusA, Team
2
Identify Risks Factors
Define the potential areas of risk that may affect the project and record them on the Risk Management Log. The following risk factors are common in projects.
PM, BusA, Team
Threat •
Threat due to changes in nature and/or strategy of competitors
Capability of Developer or Organization •
Capability of developing organization to perform the task at hand, including technical or management (project and/or program management processes, tools and techniques, and how they fit together).
•
Incorporates experience, tools, skills, documented processes and capacity, influence of external factors such
Originator: One IT PPM Team Page 55 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide as strikes, etc. •
Communication planning and execution skills and resource availability.
•
Includes ability of organization to provide adequate resources (SME’s, BA’s, systems analysts, testers, PM’s, etc.).
Cost •
Sufficiency of funds allocated for the life cycle of the system
•
Includes errors in cost estimating
Engineering •
Ability of system configuration to achieve program’s engineering objectives
•
Includes test environment, tools, O/S and software version levels, etc,
Logistics •
Ability of system configuration to achieve logistics objectives based on system design, maintenance concept, support system design, and availability of support resources.
•
Ability to provide 24x7 support if developers are geographically distributed
Manufacturing •
Ability of system configuration to achieve manufacturing objectives
•
Includes manufacturing processes, availability of manufacturing resources.
Schedule •
The adequacy of the time allocated for the defined tasks
•
Includes effects of schedule decisions, errors in estimating, and external influences such as launch window (e.g., holiday, or 01-JAN-2000).
•
Time to develop and/or approve contracts, Requirements Specifications, technical specifications, work plans, charters, and funding.
•
Misunderstood schedule dependencies
Technical •
Degree to which proposed technology has been proven
•
Reliability of product, product certification
•
Reliability / coverage by test tools
•
Internal
•
Scope changes
Originator: One IT PPM Team Page 56 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide External •
Vendor unable/unwilling to perform Year 2000 modifications to systems and/or applications
•
Supplier unable to provide goods and/or services as a result of internal, external or upstream Year 2000 problems
•
Changing reporting requirements (e.g.; Government Compliance and Reporting / Regulatory)
Other common risk factors can be found in the E&Y Risk Management Strategies job aid (see Tools/Techniques Summary below). 3
Classify Risk Factors
Classify the potential risks into risk categories (e.g., scope, technology, etc., see Risk Management Log Template).
PM, BusA, Team
4
Assess Impact and Likelihood
Evaluate the potential impact of each risk on the project’s success (High, Medium or Low) and the likelihood that the risk will occur (High, Medium, or Low).
PM, BusA, Team
5
Develop Risk Response Plans
Risk response development is the process of determining what to do (or not to do) about the risk. Some choices are:
PM, BusA, Team
• •
Avoid (Eliminate the cause of negative events)
•
Reduce the probability of occurrence (Change methods or procedures, etc.)
•
Transfer the risk (Obtain insurance to eliminate the cost burden of negative events, or use a vendor with a fixedprice contract to transfer the risk of cost overrun)
Moderate impact (Define mitigation strategies and create contingency plans to follow if a negative events occurs)
•
Accept the risk The E&Y Risk Management Strategies job aid contains specific recommendations for mitigating strategies for commonly encountered risks. 6
Record HH Risks in Charter
Enter the risks that are determined to be high risk and high probability in the Risk section of the Project Charter.
Originator: One IT PPM Team Page 57 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word MS Project 207_risk_strategies_jobaid.pdf
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp
Outputs 206_risk_assessment_template.xls 212_risk_management_log.doc
Originator: One IT PPM Team Page 58 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Team, Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.5.2 Purpose
Develop Initial SOW
The SOW serves as the cost baseline for the monitoring and controlling of the project activity. The budget contained in the SOW can be distributed across milestones or across calendar periods. Additionally, costs may be associated with specific deliverables to assess and validate each deliverable’s value. Budgeted costs include labor, travel and living expenses, training, facilities, computing, and other costs that are to be consumed by the project. During Project Initiation you will be developing a high-level SOW that focuses mainly on labor costs calculated on the basis of the initial man-hour estimates and estimated non-labor costs.
Trigger
Development of a draft initial charter, high-level plan, and risk assessment.
Key Considerations
Some key considerations for this process are:
Diagram
• • • • • •
What human resources will be utilized on the project? What facilities and equipment will be required? What are the estimated support costs for the delivered product? What training and documentation costs will be incurred? What travel and living expenses will be incurred? Only Ford employees are authorized to access the SOW. Non-Ford employees should work with their Practice Manager to complete it.
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Determine Labor Budget
Review the initial estimates of the project to determine the total hours of effort required. Apply the appropriate resource cost rates to derive a total budget amount.
PM, BusA, Team, ImpA
2
Estimate Remaining Budget Categories
Estimate any significant non-labor costs. Consider training, facilities, computing, implementation, and project support costs. Use 209_budget_considerations_checklist.doc to help identify costs that should be considered.
PM, BusA, Team, ImpA
3
Author SOW and submit for approval
Author the SOW using the template located at http://www.ads.ford.com.
PM
Submit the SOW for review and approval using the SOW Workflow Process (ADS Funding Authorization Workflow Process) and tool documented at that site.
Originator: One IT PPM Team Page 59 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 4
Enter Summary Data into the Initial Charter and Business Case
Record the budget summary data in the Financial Scope section of the Initial Charter document and the Business Case.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word Microsoft Excel
Inputs to Process 241_Project_Proposal.doc 242_business_case.xls 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 206_risk_assessment_template.xls 228_Classic_SDM_Esimating_Model.xls 229_Classic_SDM_Work_Plan.mpp
Outputs SOW located at http://www.ads.ford.com 209_budget_considerations_checklist 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 242_business_case.xls
Originator: One IT PPM Team Page 60 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Team, Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.5.3 Purpose
Confirm/Refine the Business Case
An effective business case must convince management that the investment is financially sound, realistic for the organization, aligned with other business strategies, and has a clear course of action for implementing deliverables. Organizations can avoid wasting time and money on unnecessary projects by developing initial cost justification criteria in the Project Proposal as part of the Portfolio Management process and confirm/refine it during the ID & Assess stage. Not only will a strong business case make project selection and prioritization more efficient, the business case also serves two additional purposes: it can provide as a foundation for the project charter and as a temperature check throughout the project life cycle. The key element of the business case is the cost/benefit analysis, which must prove that estimated costs are justified by the anticipated benefits. Different from a feasibility study, which is often used as a precursor, a business case emphasizes the opportunity described by long-term goals, and is supported by specific business objectives, cost and risk analysis measurements.
Trigger
Completion of an Initial Charter, High-Level Plan, Risk Assessment and HighLevel Budget Plan.
Key Considerations
•
Participation in this process by a Financial Analyst who is familiar with the business processes in the value chain is essential to creating a reasonable and accurate business case.
•
Organizational benefits and risks may be included in the discussion in order to show productivity improvement expectations by implementing the system, but be careful not to overestimate savings by reducing or redistributing headcount. If associates have multiple responsibilities, reductions often aren’t possible.
•
During the business case development, the benefits should be identified as being either "qualified" or "perceived" based on the degree of certainty achieved during the analysis process.
•
Six Sigma projects may additionally require the use of a Six Sigma template for stating the summary business case and a detailed business case. See the DFSS template titled "DCOV overview with forms.XLS" for details.
•
Numerous references and links on the Ford intranet provide insight on the business case development process. Enter the string "Business Case" as the search criteria.
•
Reference the introductory section in this guide titled "Project Authorization Requests and Purchase Orders" for further information on Project Appropriation Requests / PARs and Purchase Orders POs.
Diagram
No diagram provided for this process step.
Originator: One IT PPM Team Page 61 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No 1
Task Name
Description
Confirm Business Benefits
Review the business opportunities and benefits outlined in the business case provided at project start-up. The Business Case will be stated in terms of costs as well as tangible and/or intangible benefits. The benefits may include but are not limited to: Tangible benefits:
• • • •
Participants PM, BusA, Espon, FinanceAnal
Return on Sales (ROS) Return on Investment (ROI) Return on Assets (ROA) Net Present Value (NPV)
Intangible benefits:
•
Operating necessity. An example of an operating necessity is the sales offering of 0% financing that was offered in the post 9/11 period.
•
Extensions to existing services/products. An example is the addition of additional makes/models to an existing automotive web site. Another is the deployment of an existing application to additional geographies.
•
Competitive necessity. An example is the situation where a customer-facing web site has to be developed because competitors are also developing them, and sales could be lost without a similar offering. If different or additional benefits have been identified during the initial chartering and risk assessments, update the business case accordingly and note the changes. Notes: To perform a true cost/benefit analysis, benefits must be expressed in dollars. The expertise of a financial analyst should be obtained to help drive out and express hard benefits. 2
Confirm or Refine Cost Estimates
Review the cost estimates provided in the original business case. Determine what changes are necessary and note them accordingly.
PM, BusA
3
Consider Timing and Dependencies
Consider external factors that the project is dependent on such as the timing for completion of other projects.
PM, BusA
4
Assess and Make Recommendation
Assess proposed costs against the estimated benefits of the proposed solution. Consider timing and dependencies. Based on this, formulate a recommendation as to the viability of the project.
PM, BusA, ESpon
5
Communicate Changes
Communicate any changes in the cost, benefit or recommendation to the Executive Sponsor, Stakeholders and IT management as appropriate. Provide any changes in project costs or benefits to the Controller/Financial Manager and request that the Project
PM, ESpon, Stakeholders, IT Management, FinanceAnal
Originator: One IT PPM Team Page 62 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Authorization Request /PAR in MEARS is updated.
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel Note: in addition to the project management templates, the DFSS template titled "DCOV overview with forms.XLS" contains a summary business case in the "Charter" tab, and a detailed business case on the "Budget Matrix" tab.
Inputs to Process
Outputs
Recipients
241_Project_Proposal.doc
242_business_case.xls
242_business_case.xls
200_project_charter_template.doc
200_project_charter_template.doc
56_Process_Capability_Scorecard.xls
230_Enhancement_and_Small_Project_Request
SOW located at http://www.ads.ford.com
206_risk_assessment_template.xls
230_SDM_Enhancement_and_Small_Project_Request.doc
229_Classic_SDM_Work_Plan.mpp
241_Project_Proposal.doc
SOW located at http://www.ads.ford.com
PAR at the MEARS website http://www.finance.ford.com/mears/index2.html
56_Process_Capability_Scorecard
Control File, BusA, Team, ESpon, Finance Office, Stakeholders
PAR at the MEARS website http://www.finance.ford.com/mears/index2.html
Originator: One IT PPM Team Page 63 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
1.6
Confirm Readiness to Proceed
1.6.1
Confirm Requirements/Business Owner View
The purpose of this process is to ensure that that the initial Requirements Specification and the business owner view documents have been completed and reviewed by the Customer. Note: The initial Requirements Specification and Business Owner View are work products that are described in the Classic Solution Delivery Methodology. They are referenced here in the Project Management Guide because of their importance in assuring project readiness and because they are among the key deliverables that must be reviewed and approved by the Customer before the project can proceed.
Trigger
Completion of the Initial Charter, High-Level Plan, Investment Analysis, Initial Business Requirements Specification, Signed Business Owner View
Key Considerations
No key considerations specified for this process.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Confirm Initial Business Requirements Specification
Confirm that an initial Requirements Specification has been completed as per the appropriate Solution Delivery Methodology (SDM) Guide and that the lead Customer has reviewed and approved that specification.
PM, BusA
2
Confirm Customer Signoff of Business Owner View
Confirm that the required process and data models (future state) have been constructed as part of the Business Owner View described in the Solution Delivery Methodology. Ensure that the Business Owner View has been reviewed and approved by the Customer (i.e., that the Customer has signed off on the Business Owner View).
PM, BusA, Cust
3
Ensure Alignment with Initial Charter
Ensure that the scope section of the charter is appropriately aligned with the initial Requirements Specification and Business Owner View
PM
4
File Documents in Control File
File the completed documents in the project Control File.
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 64 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Review of SDM deliverables
Inputs to Process 02_Requirements_Specification.doc 61_Business_Owner_View.doc
Outputs Confirmation of signed Business Owner View and Requirements Specification
Originator: One IT PPM Team Page 65 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
1.6.2 Purpose
Obtain Initial Charter/Enhance. Req. Signoff
Once the Initial Charter/Enhancement Request, High-level Plan, and Investment Analysis are complete, it is time to seek Sponsor approval to proceed. The Sponsor must decide if the charter is complete and accurate and if the project should go forward or be terminated. The “go/no-go” decision may be based on factors outside the control of the Project Manager (e.g., the organization may have new priorities that are in direct conflict with the project or increased risk may have been introduced to the project.) Approval to proceed is documented by the Sponsor’s signature on the Initial Project Charter. Note: Signing of the charter is viewed as a separate activity from the end of stage gate review. It is treated as a separate step for the following reasons:
•
Signoff of the charter should be done as soon as the Project Manager and Sponsor think that it is both complete and accurate.
•
The Sponsor may find that the anticipated costs and effort that are outlined in the charter do not support expected benefits and decide that no further work should be completed on the project.
•
The Sponsor’s signature on the initial charter should be a key input to the gate review that occurs at the end of the first stage of the project.
Trigger
Completion of the Initial Charter, High-Level Plan and Investment Analysis
Key Considerations
The decision to sign the charter is generally made on the basis of the following key questions:
• •
Do expected benefits justify the estimated costs and effort?
• • •
How important is the project to the business?
• •
Can timing constraints be met?
• •
Will the deliverables identified meet the Sponsor’s criteria for success?
Are there significant risks attached to the project and do they outweigh potential benefits? Is the project required to meet regulatory requirements? Will the resources and skills required to do the project be available when needed? Does the charter accurately capture the goal and objectives defined by the Sponsor and key stakeholders? If the project is part of a program, is the charter completely aligned with the program charter?
•
Diagram
Is the Sponsor prepared to commit the end-user resources and business subject matter experts required to assist the IT project team in developing the end-product? No diagram provided for this process step.
Process Tasks
Originator: One IT PPM Team Page 66 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Schedule & Conduct a PreCharter Signing Review
Before reviewing the charter with the Sponsor ensure that the IT Business Analyst and Program Manager (if appropriate) have a chance to review the charter, high-level plan, and investment analysis documents. Obtain their agreement on the charter content and backup data to be presented to the Sponsor before proceeding.
PM, BusA, Program Mgr, Team, ImpA, Cust
2
Schedule Charter Review with Sponsor
Schedule a charter review and signoff session with the Sponsor.
PM
3
Prepare Approval Package
Prepare an approval package for review with the Sponsor. The package should include the Initial Charter Document and as backup, the High-Level Project Plan, Risk Assessment, Budget Plan, and refined Business Case.
PM
4
Review Charter and Detail
Review the charter and supporting material, as needed, with the Sponsor. Identify and document any issues that must be resolved before the charter can be approved (e.g., any refinements or additions that must be made before the Sponsor will approve the charter). If possible make the changes needed in the session itself.
PM, BusA, Sponsor, Team, Stakeholders, ImpA
5
Obtain Signoff
Obtain the Sponsors signoff. If the Sponsor decides that, based on the charter, the project should not proceed, document that decision.
PM, BusA, ESpon
6
Update Project Records
Update the project record in ITMS, RMS and MRS to reflect the status and file documents in project Control File.
PM
7
Notify Stakeholders
Notify support activities, the project managers of related/dependent projects, the Practice Manager, the Portfolio Manager, and the Competency Center Manager of the results of the charter review.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 02_Requirements_Specification.doc 200_project_charter_template.doc 204_accelerator_use_plan 206_risk_assessment_template.xls 228_Classic_SDM_Estimating_Model.xls 229_Classic_SDM_Work_Plan.mpp 230_Enhancement_and_Small_Project_Request 241_Project_Proposal.doc 242_business_case.xls 56_Process_Capability_Scorecard SOW located at http://www.ads.ford.com
Outputs
Recipients
02_Requirements_Specification.doc 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request Go/No-Decision Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs Updated ITMS Record at http://www.itms.ford.com/
Originator: One IT PPM Team Page 67 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Program Mgr, ESpon, Cust, Team Support Activities Competency Center Metrics
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 68 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.0
Plan Project Project Management Processes
Project Charter Business Case
Initiate
High Level Plan Business Owner View
Plan Requirements Execute
Solution Delivery Methodology
Control Close
Inputs to Plan Project
Overview
Project Planning is an iterative process that occurs throughout the project life cycle. It begins in Initiate Project with the development of the charter and high level plans and continues in subsequent stages with more detailed planning and adjustments made to reflect changes and corrective actions. The process described below picks up where the high level plan that was created in Initiate Project leaves off. Here, however, the results of analysis and design activities are used to identify additional planning requirements and create detailed work plans.
Process Contents
Objective 2.1
Note Refer to PM Processes "3.0 Execute Project" and "4.0 Control Project" for processes such as "Maintain Project Records" or "Conduct Status Reviews" for process steps that must be carried out across all five PM Processes (Initiate, Plan, Control, Execute, Close).
2.2
2.3
Develop Project Management Plans
Refine Work Plans and Budget
Confirm Readiness to Proceed
Process Steps
PM Deliverable
2.1.1
Develop Org Change Mgmt Plan
2.1.2
Develop Procurement Plans
2.1.3
Develop Transition Plans
2.1.4
Develop Resource Mgmt Plans
Resource Mgmt Plan
2.2.1
Refine Project Approach
Accelerator Use Plan
2.2.2
Refine Work Plans
2.2.3
Refine Risk Management Plans
Risk Management Plans
2.2.4
Refine Resource Requirements
Resource Requests
2.2.5
Refine The SOW
2.3.1
Confirm Requirements Spec Signoff
Requirements Signoff
2.3.2
Obtain Final Charter Approval
Final Charter Approval Signoff
2.3.3
Conduct Formal Kick-off
Originator: One IT PPM Team Page 69 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Org Change Mgmt Plans Procurement Plans Support and Launch Plan
Baseline Project Schedule
Refined SOW
Kick-off Metting
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
2.1
Develop Project Management Plans
2.1.1
Develop Organizational Chg Mgt (OCM) Plan
Organization Change Management (OCM) is a process for managing the human aspects of implementing major, complex change resulting in value, delivered through the implementation of stated human, process and technology objectives in support of business objectives. OCM activities are warranted when the change is MAJOR, When there is a high COST of implementation failure, or When there is a high risk that certain human factors could result in implementation failure.
Trigger
The need for engaging in change management has been identified.
Key Considerations
• •
Diagram
See the process "Develop Organizational Change Management (OCM) Plan" in the Classic SDM Process Guide. The "HR Business Partner" for each organization is responsible for identifying OCM resources. An OCM overview and the name of the IT HR Business Partner can be accessed at the IT HR home page at http://www.itonline.ford.com/home/it-prof/it-hr/.
No diagram provided for this process.
Process Tasks No 1
Task Name Coordinate OCM activities
Description Ensure that OCM activities occur. See the Classic SDM Guide for details. Update the work estimates and workplans as appropriate.
Participants PM
Tools/Techniques Summary Methods and Applications/Tools MS Project Organizational Change Management techniques – see http://www.change-management.com/ for articles and books
Inputs to Process
Outputs
200_project_charter_template.doc
200_project_charter_template.doc
230_Enhancement_and_Small_Project_Request
230_Enhancement_and_Small_Project_Request
215_communication_plan_template.doc
215_communication_plan_template.doc
229_Classic_SDM_Work_Plan.mpp
229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 70 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Program Mgr, BusA, Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.1.2
Purpose
Develop Procurement Plan
The procurement plan addresses the methods for the selection and purchasing of project goods and services. It must proactively identify possible needs for products and services. It must also establish standards and procedures for:
•
Make or buy decisions
•
Identifying and selecting prospective suppliers (internal and external)
•
Preparing procurement documents such as requests for quote (RFQ)
•
Making purchasing decisions (including approval to commit)
•
Contracting
Trigger
A decision has been made to purchase goods or services on the project.
Key Considerations
Key considerations for this process are:
Diagram
•
How does the product or service serve the needs of the project?
•
Does the product of something similar already exist within the organization?
•
Is there a service provider available in the marketplace for the product in question?
•
Does the organization have the means (staff, money, contract, etc.) to produce or acquire the product?
•
Classic SDM has incorporated processes for development of a long list of solution alternatives, an RFI process that developments a short list, an RFP/RFQ process that develops a solution recommendation as well as a Best and Final Offer / BAFO negotiation process. It also has incorporated special considerations for purchased package selection and implementation into each of the affected Classic SDM processes.
•
Creation of a project-specific Purchase Order requires that two steps be performed. First the capital expenses must be accounted for in MEARS. Second, the Purchase Order must be created, issued and tracked via CPARS in North America or the equivalent tool in EMEA. Also note that eVerest will replace the existing procurement applications.
No diagram provided for this process.
Originator: One IT PPM Team Page 71 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Complete Make/Buy Decision
Use cost/benefit analysis to determine if purchasing goods or services is the right approach.
2
Determine How Much To Buy
The question of how much to purchase can only be answered by the individual project. However, consideration should be given to the following questions before making that decision:
PM, BusA, ESpon, SMEs PM, BusA, SMEs
•
Will there be need beyond the immediate project for this product? • How much of the budget has been or will be allocated for this product? • Is the need for the product or service clearly defined enough for the organization to know how much is needed? Underestimating or overestimating the cost or quantity of an item can have a big impact on the financial success or failure of the project. Caution should be used when entering into any contract without clearly defined needs and objectives. 3
Determine How to Buy
If a decision is made to purchase an item or service, the next step is to explore the various types of contracts that can be arranged. Work with Purchasing and the Office of The General Council (OGC) on this as appropriate. Some examples include:
•
Fixed Price/Lump Sum Contract. This is a contract that involves paying a fixed, agreed-upon price for a well-defined product or service. Special consideration must be given to these contracts to ensure that the product is well defined to reduce risk to both the Company and the contractor.
•
Cost Reimbursement Contract. This contract type refers to a reimbursement to the contractor for actual cost of producing the product or service. Costs within the contract are classified as direct (e.g., salaries to staff of the contractor) and indirect (e.g., salaries of corporate executives for the contractor). Indirect costs are normally based on a percentage of direct costs.
•
Unit Price Contract. The contractor is paid a preset amount for each unit (e.g., $10 per widget produced) or unit of service (e.g., $50 per hour for service). The contract equals the total value of all units produced.
PM, BusA, Purchasing, OGC
4
Contact Ford Purchasing
Contact Ford Purchasing to discuss project requirements as well as agree to approach/plan for performing vendor contact and product analysis.
PM, BusA, Purchasing
5
Develop Procurement Plan
Determine if an existing contract with a pre-approved vendor can be used to satisfy the need for services. If not, determine what vendors will be asked to solicit the business.
PM, BusA, Purchasing
6
Develop Sollicitation Plan
Work with Purchasing to put a procurement plan together that determines how bids in the form of Contract will be solicited from potential vendors. Agree on how the final decision will be made (i.e., agree on the criteria that will be used to make the buy
PM, BusA, Purchasing
Originator: One IT PPM Team Page 72 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide decision.) 7
Make Decision
Make the final decision to purchase the goods or services and notify stakeholders as appropriate.
PM, BusA, Purchasing
8
Establish Contractual Agreement
Work with Purchasing and the Office of the General Council (OGC) to finalize the contractual arrangements with the vendor.
PM, BusA, Purchasing, OGC
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project Cost/Benefit Analysis – see http://www.mindtools.com/pages/article/newTED_08.htm for brief explanation or http://www.csd.uwo.ca/courses/CS179/lect8/sld008.htm for online presentation of this topic
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request
Outputs Organization-specific procurement plan
Originator: One IT PPM Team Page 73 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Purchasing, OGC
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.1.3 Purpose
Develop Transition Plans
The purpose of the transition plan is to outline the steps that will be taken to promote smooth handover of project deliverables to support activities.
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
Key considerations for this process are:
• •
Will additional or different skills in support services be required?
•
Is the project part of a release within a program or initiative?
•
What actions must be taken to ensure smooth handover?
•
What is the schedule of transition events?
•
Diagram
Will the application be implemented immediately or shelved pending completion of a related project or projects?
What additional coordination activities will be required because an outside vendor is involved?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Initiate the Transition Process
Identify the Practice Application Supervisor that will be responsible for supporting the deliverables produced by the project. Notify that supervisor of the project and schedule an initial meeting to review project plans and anticipated transition events.
PM, AppSupr, ImpA
2
Identify the Transition Team
Identify the transition team members, including their names, roles, cds ids, and phone numbers.
PM, AppSupr, ImpA
3
Schedule Key Transition Events
Identify when key transition events will occur, who will be involved, and what actions will be taken. Transition events include, but are not limited to the following:
PM, AppSupr, ImpA
• • • • • • • •
Knowledge Transfer Meetings Service Level Agreement Reviews Acceptance Testing Reviews Performance Monitoring and Control Reviews Outstanding Change Request Handover Outstanding Issues Handover Outstanding Defects Handover Documentation Handover
Tools/Techniques Summary Originator: One IT PPM Team Page 74 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word and MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp
Outputs 217_transition_support_plan.doc 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 75 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.1.4 Purpose
Develop Resource Management Plans
Project human resource management includes the processes required to make the most effective use of the people involved in the project. This includes the following: Organizational planning, which involves identifying, assigning, and documenting project roles, responsibilities, and reporting relationships. Key outputs of this process include role and responsibility assignments, often shown in a matrix form, and an organizational chart for the project. Staff Requisition, which involves getting the needed personnel assigned to and working on the project. Getting personnel is one of the crucial challenges of information technology projects. Team development, which involves building individual and group skills to enhance project performance. Key outputs of this process include training plans for project team members.
Trigger
Signoff of the initial project charter and approval to proceed.
Key Considerations
Team members have a stake in the success of the project. Consider the following as some of the commitments and understandings needed from team members:
•
A commitment to the goals and objectives of the project.
•
A commitment to the tasks and activities for which they will be responsible.
•
A realistic assessment of the time that the team member can devote to the project.
•
An understanding of functional responsibilities that may cause scheduling conflicts with the project.
Commitment is also needed from the functional managers of the people who will be working on the project:
•
A commitment to support the activities of his or her employees who are working on the project.
•
An agreement that the project is important and that the employee’s participation is required to accomplish project goals.
•
A realistic assessment of time that the employee can devote to the project.
•
An agreement on how conflicts between the need of the project and the needs of the functional department will be resolved.
If performing Purchased Package Selection and Implementation / PPSI, consideration should be given for: •
Vendor provided training
Originator: One IT PPM Team Page 76 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Diagram
§
Vendor participation on project team
§
Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Pre-commitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Identify skills and Resource Levels Required
Refine the list of skills required on the project that was developed at the beginning of the project. Include skills needed as a result of requirements gathered and any other analyses of project deliverables.
PM, Team, BusA
2
Identify Resources
Identify the available resources.
PM
3
Assess Resource Skill Levels
Assess the skills of the people available. It is the project manager’s job is to determine the risks associated with the available skill levels. This information is later used to determine the level of schedule adjustment that should be made to offset any short fall (i.e., to determine how much contingency to incorporate in to the plan to offset any lack of skill or experience on the team). It will also be used to identify any training requirements below.
PM
4
Determine Training Requirements
Identify and price any training that will be required to supplement team knowledge and skills. Refine the proposed budget to include any training costs.
PM
5
Determine Facilities/ Equipment
Identify the facilities and equipment (e.g., computers, cubicles/desks etc.) that will be needed for the people identified. See 3.1.1 Acquire/Release Facilities & Equipment
PM
6
Develop a Staffing Plan
For small projects, the staffing plan may be as simply stated as the assignment of three people full time to the project throughout its duration. On larger projects the plan may need to identify when staff will be brought onto and taken off the project team, with timing specified.
PM
7
Review Resource Plans
Review the resource plans with the Business Analyst and technical subject matter experts on the team.
PM, Team, BusA
Originator: One IT PPM Team Page 77 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 8
Refine the Project Charter
Refine the Financial Scope and Project Organization sections of the Project Charter to reflect the resource management decisions made.
Originator: One IT PPM Team Page 78 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project Skills assessment Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp
Outputs Resource Request located at http://www.ads.ford.com/resman/ 227_project_organization_chart_jobaid.ppt 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 216_project_organization_chart.doc 203_team_directory_template.doc
Originator: One IT PPM Team Page 79 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Competency Center, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Purpose
2.2
Refine Work Plans and Budget
2.2.1
Refine Project Approach
The purpose of this process step is to refine the Project Approach, including the project methodology, processes, accelerators, tools & techniques that will be used to achieve the project objectives. (Typically, revising Project Methodology from Unified to Classic or vise-versa is not likely to happen.) The objective of this process is to ensure that the project approach remains optimal throughout the project lifecycle. The methodology that is used, the team’s experience, and management philosophy provide guidelines for establishing the project framework. Some paths through a methodology mandate a specific approach but, generally, some decisions must be made about the way the project is to be conducted.
Trigger
Key Considerations
Signoff of the initial charter, development of project management plans, or the recognition of a need to change the methodology, processes or templates at any point in the project lifecycle. •
•
•
Diagram
When selecting the methodology, processes and templates, the project team should understand the differences between Classic SDM and Unified SDM. See the If the team is not familiar with both methods, a PQA coach will be able to present the related concepts for both methodologies and help with the selection process. Developing and refining the Project Approach can occur throughout the project lifecycle. The process titled "Develop Project Approach" develops the initial Project Approach, and the process titled "Refine Project Approach" does refinement. Accelerators are proven techniques for delivering value to the Customer quickly. Examples of accerators include prototyping, co-locating the customer with the project team, and time-boxing. At this stage in the project lifecycle, you may not have all of the information you need to select some of the accelerators that will be appropriate for the project. However, you should know enough to begin looking at them and selecting the ones that will obviously apply. The Accelerator Use Plan template can be used as a starting point for selecting and documenting accelerators that will be used.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
1
Review Accelerator Use Plan
Review the current Accelerator Use Plan (AUP) and determine if elements need to be updated or added based on information gathered since the initial plan was created.
PM, BusA
2
Update User Types
At this stage, you will know about the users and functionality required. Describe/update and prioritize all user types and enter this information into the AUP template.
PM, BusA, Cust
3
Describe
Work with the Customer to identify and describe the primary areas of
PM,
Originator: One IT PPM Team Page 80 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Business Functionality
functionality to be developed within the project.
BusA, Cust, 6-Sigma
4
Decompose Business Functionality
Work with the business analyst and Customer to decompose the business functionality into logical sub-areas.
PM, BusA, Cust
5
Prioritize Functionality
Work with the Customer to prioritize the business functionality based upon perceived benefit, value to the highest priority user types and the minimization of project risk. Enter this information into the AUP template.
PM, BusA, Cust
6
Select Accelerators
Update the list of accelerators to be employed (e.g.; time-boxing, prototyping, reusable software, co-location, etc.) and update that information in the AUP template.
PM, BusA, Cust
7
Update Plans to Reflect AUP
Update the Charter, Work Breakdown Structure, and Project Plan to reflect any decisions made about the sequence of activities, timing, or dependencies, as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project
Inputs to Process 204_accelerator_use_plan.doc 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc
Outputs 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 204_accelerator_use_plan.doc 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 81 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.2
Refine Work Plans
Purpose
The purpose of this process step is to refine and finalize the project work breakdown structure, dependencies network, estimates, and project schedule. It is also at this time that resources are assigned to tasks.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations
No key considerations provided for this process step.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Refine the Work Breakdown
Refine the work breakdown structure to reflect information gathered since project initiation. Add or remove activities and take the breakdown to its lowest level.
PM, Team
2
Refine Dependencies
Refine the dependency network to reflect task level dependencies.
PM, Team
3
Update Project Schedule
Update the project schedule to reflect the task-level work breakdown and assign specific resources. Make a note of any tasks for which a specific individual cannot be identified. You will need to use this information to refine resource plans and request additional resources.
PM, Team
4
Refine Project Estimates
Refine project estimates taking new work breakdown and resource assignments into consideration. Ensure that adequate contingency is baked into task estimates where resources are less skilled or liable to be distracted by competing responsibilities. Note: If using the SDM Estimating Model a task level plan will already be defined. Follow the instructions in that model to adjust estimating factors, as needed.
PM, BusA, Cust
5
Generate Baseline Work Plan
Update the MS Project Plan to reflect all of the changes identified. If the end-date has moved out, use the accelerator use plan and other factors to determine if the date can be bought back in line by deferring low priority functionality, adding resources, or other means. Baseline the schedule when timing and resource issues have been resolved.
PM, BusA, Cust
6
Update Project Records
Update the project record in ITMS, RMS and MRS to reflect the updated schedule and file documents in project Control File.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and MS Project
Inputs to Process
Originator: One IT PPM Team Page 82 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 204_accelerator_use_plan.doc 228_Classic_SDM_Estimating_Model.xls
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 204_accelerator_use_plan.doc 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp 228_Classic_SDM_Esitmating_Model.xls
Originator: One IT PPM Team Page 83 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File BusA Cust Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.3
Refine Risk Management Plans
Purpose
The purpose of this process step is to refine risk management plans based on information gathered since the initial risk assessment was conducted during project initiation.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations
•
Diagram
No diagram provided for this process step.
Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.
Process Tasks No
Task Name
Description
Participants
1
Identified Risk Factors
Review the risk assessment conducted during project initiation to determine if additional risk factors apply. If not, skip the remainder of this process step. If new risks identified, add them to the Risk Management Log (eTracker if in use).
PM, Team
2
Assess Risk Factors
Assess the level of impact, likelihood of occurrence, and potential impact on cost, time, and benefits and record in the Risk Management Log.
PM, Team, Cust
3
Define Mitigation Strategies
Define strategies for mitigating each additional risk. Refer to the Ernst & Young Risk Factor Strategies job aid for ideas on mitigating common risk factors.
PM, Team
4
Define Contingency Plans
Define contingency plans for each risk factor added and record that information in the log.
PM, Team
5
Confirm Risk Rating
Confirm the risk assessment score on the Risk Assessment Checklist and file the refined copy in the Project Control File.
PM
6
Record HH Risks in Charter
Enter any additional high impact, high probability risks into the Project Charter.
PM
7
Address Work Plan Impacts
Ensure that mitigation strategies and contingency plans are accurately reflected in the work plan
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 84 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word and MS Project eTracker at www.etracker.ford.com
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 207_risk_strategies_jobaid.pdf 204_accelerator_use_plan.doc 228_Classic_SDM_Estimating_Model.xls
Outputs 206_risk_assessment_template.xls 212_risk_management_log.doc 200_project_charter_template.doc
Originator: One IT PPM Team Page 85 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File BusA Cust Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.4
Refine Resource Requirements
Purpose
The purpose of this process step is to refine resource requirements based on the information gathered and planning completed since project initiation.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations No key considerations provided for this process step. Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Identify skills and Resource Levels Required
Refine the list of skills required on the project as needed
PM, Team
2
Identify Resources
Identify the available resources and assess their skill levels.
PM
4
Refine Training Plans
Identify and price any training that will be required to supplement team knowledge and skills. Determine the impact on the budget.
PM
5
Refine Staffing Plans
For small projects, the staffing plan may be as simply stated as the assignment of three people full time to the project throughout its duration. On larger projects the plan may need to identify when staff will be brought onto and taken off the project team, with timing specified.
PM
6
Review Resource Plans
Review the resource plans with the Business Analyst and technical subject matter experts on the team.
PM
7
Refine the Project Charter
Refine the Financial Scope and Project Organization sections of the Project Charter to reflect the resource management decisions made.
PM
Originator: One IT PPM Team Page 86 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel and MS Project Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 204_accelerator_use_plan.doc 206_risk_assessment_template.xls
Outputs Online resource request at http://www.ads.ford.com/resman/ 227_project_organization_chart_jobaid 216_project_organization_chart.doc 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request
Originator: One IT PPM Team Page 87 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, Cust, Team, Competency Center, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.2.5
Refine the SOW
Purpose
The purpose of this process step is to refine the budget plan based the refined risk assessment, baseline schedule, functional requirements, accelerator use plan, and resource requirements.
Trigger
Signoff of the initial charter and development of project management plans.
Key Considerations Diagram
•
Only Ford employees are authorized to access the SOW. Non-Ford employees should work with their Practice Manager to modify it.
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Refine the Labor Budget
Refine initial resource requirements estimates. Use specific labor rates as appropriate.
PM, BusA, ImpA
2
Refine Remaining Budget Elements
Refine estimates and any non-labor costs. Consider additional facilities, equipment, training or travel identified since the initial SOW was created during project initiation.
PM, BusA, ImpA
4
Summarize Costs
Confirm or refine the SOW as appropriate. If changes are required, submit a new SOW to the ADS Business Office via the SOW Workflow process and tool documented at http://www.ads.ford.com. The Business Office review the SOW for completeness and accuracy, then circulate it for signature via the Work Flow Tool.
PM, BusA, ImpA
5
Update the Charter
Update the financial scope section of the charter or enhancement request, as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project
Inputs to Process
Originator: One IT PPM Team Page 88 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc 204_accelerator_use_plan.doc 206_risk_assessment_template.xls http://www.ads.ford.com/resman/ SOW located at http://www.ads.ford.com
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 89 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, BusA, Cust, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.3
Confirm Readiness to Proceed
2.3.1
Confirm Requirements Specification Signoff
Purpose
The purpose of this process is to ensure that the Requirements Specification has been reviewed and approved by the Customer and that the final charter accurately reflects the information contained in that specification.
Trigger
Development of detailed Requirements Specifications and a baseline work plan and completion of all sections of the project charter as appropriate.
Key Considerations
For enhancement •
Are the requirements listed on the enhancement list?
•
For Purchased Package Selection and Implementation (PPSI) – ensure Vendor/Supplier understand the Requirments.
Note that Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A precommitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Pre-commitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Confirm Customer Signoff of Requirements Specification
Confirm that the final Requirements Specification has been reviewed and approved by the appropriate parties per the Solution Delivery Methodology. Ensure that the lead Customer(s) on the project has signed the specification document indicating concurrence with its contents.
PM, BusA, Cust, SolnArch, Vendor/Supplier
2
Ensure Alignment of Charter
Ensure that the scope section of the final project charter is aligned to the Requirements Specification.
PM, BusA, Cust
3
File Signed
File the signed Requirements Specification in the appropriate
PM
Originator: One IT PPM Team Page 90 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Requirements Specification
Control File folder.
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word
Inputs to Process 200_project_charter_template.doc 02_Requirements_Specification.doc
Outputs 200_project_charter_template.doc 02_Requirements_Specification.doc 230_Enhancement_and_Small_Project_Request
Originator: One IT PPM Team Page 91 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.3.2
Obtain Final Charter Approval
Purpose
The purpose of this process step is to ensure that all sections of the project charter have been adequately addressed and that the final charter accurately reflects the agreed goal, objectives, scope, project management approach, risk assessment, and project organization.
Trigger
Development of detailed Requirements Specifications and a baseline work plan and completion of all sections of the project charter as appropriate.
Key Considerations
The same key considerations that applied at the initial charter signoff, apply here.
Diagram
No diagram provided for this process step.
Process Tasks No
Task Name
Description
Participants
1
Finalize Objectives
Ensure that project objectives are measurable and still accurately reflect the requirements and business success criteria.
PM
2
Finalize Scope
Ensure that all sections of project scope are defined and accurately reflect the understanding reached with the Customer.
PM
4
Finalize Project Mgt Approach
Ensure that all sections of the project approach are completed and accurately reflect decisions made concerning the methods that will be employed to manage quality, issues, risk, communications, procurement, support, implementation, and resource management.
PM
5
Finalize Risk Section
Ensure that the high impact and high probability risks are recorded in the risk section of the charter.
PM
6
Finalize Project Organization
Ensure that the project organization accurately reflects the team structure. Include an organization chart as appropriate.
PM
7
Review Changes
Review changes with the Business Analyst and Customer and decide if they require Sponsor review. Obtain Sponsor signoff.
PM, BusA, Cust, ESpon
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan.doc 206_risk_assessment_template.xls SOW located at http://www.ads.ford.com
Outputs
Recipients
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 206_risk_assessment_template.xls
Originator: One IT PPM Team Page 92 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, BusA, Cust, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
2.3.3 Purpose
Conduct Formal Kick-off
The kick-off meeting marks the formal start of the project. Generally, it is the first opportunity for the Sponsor or representative to meet with the entire project team to present a vision of the project, demonstrate support, and advocate project success. Its importance lies in setting the tone for the project and in establishing a common understanding of project goals and plans. The purpose of the Kick-off meeting is to
• • • • • • • •
Introduce team members Communicate project goals and objectives Review work methods and tools Communicate the roles and responsibilities of team members Set direction for the work to be completed Address team member questions Commit to the success of the project Promote team rapport
Trigger
Completion of the charter and development of a baseline plan.
Key Considerations
•
•
Diagram
Key considerations when planning and conducting the meeting include o
What decisions must be made before the meeting?
o o o
What information will be distributed to attendees in advance? What will be presented in the meeting? Who should attend?
Usability best practices training is available from Usability Services on a no-charge basis. This training can be scheduled by contacting Usability Services. This is recommended for all project team members, including the Customer, developers, etc.. For more information go to http://www.usability.ford.com/training.
The following diagram shows inputs and outputs for this activity.
Process Tasks No 1
Task Name Identify Participants
Description Work with the Sponsor, the Practice Manager, and Business Analyst to determine who needs to be at the kick-off.
Originator: One IT PPM Team Page 93 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants PM, PracticeMgr, Sponsor, BusA
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 2
Schedule Kickoff
3
Develop Agenda
PM
Identify the date, time and place. Reserve the meeting room and any presentation equipment required. Introduction:
Sponsor or Rep – Welcome address.
PM, BusA, Sponsor
Project Manager – Describes the agenda. Introduction of Attendees:
Participants introduce themselves, describe their concerns and expectations.
Project Overview:
Sponsor – Background to the project, the Customer, why it is important to be successful, future opportunities, Customer needs and expectations, and high -level project scope.
Project Goals and Objectives:
Project Manager – Presents what’s known of project goals and objectives, key milestones, and critical success factors. The Concept Profile, Executive Summary, and interview with the Sponsor to prepare.
Project Organization:
Project Manager – Presents the organization chart along with roles and responsibilities of each team member.
Project Plan:
Project Manager – Presents the Project plans, including communications & team training plans.
Methods and Tools:
Project Manager – Describes the project management model, the documentation, the processes, and highlights the way progress will be monitored.
Question and Answer:
Project Manager – Leads brief question and answer period.
Summing Up:
Project Manager – Summarizes the meeting and reminds everyone of action points with target completion dates.
4
Distribute Materials
Distribute the agenda, Project Charter, Project Plan, and any other relevant material ahead of the meeting.
PM, Admin Support
5
Conduct the Meeting
Conduct the meeting, taking notes on any issues raised and/or action points
PM, BusA, ESpon
6
Distribute Minutes
Distribute minutes of the kickoff to attendees and appropriate stakeholders who were not in attendance.
PM, Admin Support
Originator: One IT PPM Team Page 94 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 95 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel MS Project
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan.doc 206_risk_assessment_template.xls SOW located at http://www.ads.ford.com 201_stakeholder_assessment.doc 203_team_directory_template.doc 215_communication_plan_template.doc
Outputs 218_kickoff_meeting_checklist.doc 219_kickoff_meeting_agenda_template.doc
Originator: One IT PPM Team Page 96 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, BusA, ESpon, Team, Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.0
Execute Project Project Management Processes
Resource Plan Procurement Plan
Initiate
Communication Plan
Budget Plan Project Charter
Plan
Transition Plans
Execute
Work Plan Solution Delivery Methodology
Control
Close
Inputs to Execute Project
Overview
Process Contents
Project Execution results in the completion of the work identified in plans created during Project Initiation and Planning. During execution of the project:
•
Facilities and supplies are acquired.
•
Resources are acquired, trained, and assigned work.
•
The project organization, procedures, and reporting mechanisms are established.
•
Work activities are directed, evaluated, and redirected in keeping with project goals and limitations.
•
Project documentation is created and stored for easy access and review by the project team and stakeholders.
•
Records used to describe the project and communicate its status in relation to other projects are maintained (e.g., your project’s record in ITMS) Objectives 3.1
3.2
Manage Project Execution
Manage Project Information
Processes
Key Deliverables
3.1.1
Acquire/Release Facilities and Equipment
Move Request/GIRS
3.1.2
Acquire/Release Team Members
Resource Requests
3.1.3
Direct & Coordinate Plan Execution
Work Products
3.2.1
Maintain Project Records
Documentation
3.2.2
Distribute Project Information
Originator: One IT PPM Team Page 97 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Meeting Minutes, Reports and Notices
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.1
Manage Project Execution
3.1.1
Acquire/Release Facilities & Equipment
Purpose
The purpose of this process is to ensure that facilities (e.g., space for a colocated team) and equipment (e.g., PCs, phones, security badges, etc.) are acquired.
Trigger
Signoff of the final project charter.
Key Considerations
Key Considerations for this process are:
Diagram
•
What hardware and software will be required for team members?
•
Will software licenses be required?
•
Are new security badges and network access required?
•
Do team members need to be moved from one building or room location to another?
•
Will team members be co-located and is a team room required?
•
Is the cost of training and software included in the SOW?
•
Reference the introductory section in this guide titled "Project Authorization Requests and Purchase Orders" for further information on Project Appropriation Requests / PARs and Purchase Orders POs.
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Obtain Team Facilities
Request team room(s) or cubicles as appropriate to the location and resource requirements.
PM
2
Obtain Workstations and Other Equipment
Determine what workstations, network access, shared drives, phones, eRooms, and other facilities or equipment will be needed and submit the appropriate requests through the help desk.
PM
3
Request Software
Determine if specific software licenses will be required (e.g., licenses for MS Project) and submit the appropriate support requests through the help desk (GIRS). The cost of software should be included in the SOW.
PM
4
Schedule Facilities, Hardware, and Software
Ensure that the setup of cubicles, team rooms, equipment and software are scheduled and completed on time.
PM
5
Verify Supplies
Verify that adequate office supplies are available and accessible to the team.
PM
6
Verify
Verify that team hardware and software are functioning properly before
PM,
Originator: One IT PPM Team Page 98 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Workstation and Development Environment
work begins.
Team
Tools/Techniques Summary Methods and Applications/Tools US ADS Move Request use http://www.ads.ford.com/facilities/ All Other Locations Use Ford Land Move Request at http://www.dearborn3.ford.com/fmls/move/ Help Desk Request
Inputs to Process 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp 02_Requirements_Specification.doc SOW located at http://www.ads.ford.com
Outputs Move Request (see Tools Above) GIRS Tickets
Originator: One IT PPM Team Page 99 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Ford Land, Help Desk
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.1.2
Acquire/Release Team Members
Purpose
The timely requisition and development of team members whose skills match the project’s requirements is vital to project success. As a project progresses, the skills needed may change. While a core set of team members may remain throughout the project, other resources may come and go as needed. For example, more experienced resources (subject matter experts) are particularly important in the early stages of the project when objectives are being defined and decisions are made on how those objectives will be met. Later, when plans are firmed, less experienced resources can be taken on board and directed in the work needed to complete the tasks that have been defined. It is up to the project manager to identify the resources and skills that will be required throughout the project and take appropriate action to complete those plans.
Trigger
The trigger for this process will depend on the project plan and what that plan says about the requisition or release of resources in each stage of the project. At this stage, the trigger will be signoff of the final charter.
Key Considerations
The key considerations for this project are:
•
What skills/roles are needed to do the work planned for the current stage?
•
What resources have been identified to fill those roles?
•
What resources are to be released from the project at this point, if any?
•
What training or orientation do new or existing team members need?
• •
•
Diagram
If performing Package Product Selection and Implementation / PPSI, consideration should be given to providing application-specific or package-specific training to team members. Ford's policy is to eliminate the practice of pre-committing orders because they can lead to misunderstandings and delays in payments. A pre-commitment occurs each time your firm is engaged to deliver a good or service without the appropriate authority to proceed being given by your Ford Motor Company buyer. Precommitments occur when anyone - regardless of level or location, engages a supplier (in writing or orally) to provide a good or service, directly, without the Ford Motor Company buyer's involvement, a valid release against a blanket purchase order or purchase order that includes authorization from the appropriate finance activity. Purchasing will also have emergency procedures developed to ensure true emergencies can be handled that may require initial contact by those other than your Ford Motor Company buyer. As a result, the Ford Purchasing Department must be included in activities where outside vendors are being contacted for information, proposals and quotes. See the web site http://fcas268b.dearborn.ford.com:8050/ for further information. If performing Package Product Selection and Implementation / PPSI, consideration should be given to having personnel from the product vendor participate in the design, development, testing, training and roll-out of the solution.
No diagram provided for this process.
Process Tasks No 1
Task Name Identify Skills
Description
Participants
Create a two dimensional matrix. List the skills/knowledge needed on
Originator: One IT PPM Team Page 100 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM,
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Needed
the project – particularly in early stages – down one side.
BusA
2
Identify Candidates
List the potential team members across the top of the matrix.
PM, BusA
3
Map Skills to Candidates
Mark the intersection between skills/knowledge and each candidate. Identify and close gaps.
PM, BusA
4
Interview Candidates
Interview candidates.
PM
5
Obtain Required Resources
Request and engage resources required. Engaging resources includes providing them with background on the project. It may also entail follow through on training plans for resources.
PM, Sponsor
6
Request Badge, Phone or Move
Direct new employees to the web sites or local support functions that they will need to contact to get phones installed and access to the building, printers, and shared drives.
PM, Team
7
Update the Team Roster
Create a team roster identifying team members, their home organization, their role, and the amount of time that they will be available.
PM
8
Orient Team Members
Provide new team members with background on the project and access to any existing documentation.
PM, Team
9
Notify Competency Center of Upcoming Release of a Ford ADS Resource
Send an MS-Outlook note to the appropriate Competency Center Manager 30 days prior to the release and notify him/her that the resource will be released and the date of the release. If the resource doesn't know whom their manager is, the note should be sent to Don Bartkowiak (DBARTKOW).
AppSupr, Competency Center Manager
10
Notify Agency of Upcoming Release of Agency Resource
Send an MS-Outlook note to the appropriate agency representative 2 weeks prior to the release and notify him/her that the resource will be released and the date of the release.
AppSupr, Agency Representative
11
Notify RMS of Resource Release
Send an MS-Outlook note to cdsid RMSHELP to inform them that the resource will no longer be working on the application and should not bill against it any longer.
AppSupr
12
Perform Exit Procedure
Follow the instructions at the exit procedure link located at http://www.ads.ford.com/facilities/. This procedure covers the removal of application access, building access and other tasks.
AppSupr
Note: As per the new Competency Center Guide, Ford ADS resources will have been assigned a Competency Center Manager. The AppSupr should obtain the Competency Center Manager's name from the resource.
Tools/Techniques Summary Methods and Applications/Tools US ADS Only Use Following Link for Move Requests http://www.ads.ford.com/facilities/ All other locations use Ford Land Move Request at http://www.dearborn3.ford.com/fmls/move/ Help Desk Request Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process
Originator: One IT PPM Team Page 101 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp http://www.ads.ford.com/resman/ 203_team_directory_template.doc SOW located at http://www.ads.ford.com
Resource Request located at http://www.ads.ford.com/resman/ 203_team_directory_template.doc Move Requests (see Tools Above)
Originator: One IT PPM Team Page 102 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Competency Center, Resource Mgmt, Demand Management
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.1.3
Direct & Coordinate Plan Execution
Purpose
The execution of project plans is an ongoing process that requires that the project manager ensure that every step in the plan is required and carried out. This includes ensuring that team members and stakeholders understand what is expected of them and following-up to ensure that they fulfill their obligations.
Trigger
Signoff of the charter.
Key Considerations
No key considerations defined for this process step.
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Assign Tasks to Team Members
Ensure that team mem bers are aware of assignments including those added after the plan is baselined to deal with issues, risks, and change requests. Also ensure that team members have a say in the amount of time they are given to complete tasks. Solicit team member input when estimating the duration of added tasks (i.e., tasks added in response to issues, risks, and scope changes that are identified after the plan is baselined.)
PM, Team
2
Ensure Stakeholders Understand their Role
Provide stakeholders who are outside the core team with a copy of the plan so they understand what is expected of them over the life of the project. Stakeholders include, but are not limited to the Sponsor, lead Customer, Business Analyst, and other subject matter experts whose input will be required at various points over the project life cycle.
PM, Stakeholders
3
Execute Project Manager Tasks
Ensure that tasks that rightfully belong to the Project Manager are carried out per the project plan.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel, MS Project RMS-- http://www.rms.ford.com
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 201_stakeholder_assessment_matrix.doc 203_team_directory_template.doc Timesheets http://www.rms.ford.com 210_change_request_template.doc 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc
Outputs 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 103 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, ESpon, BusA, Cust, Team, Other Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.2
Manage Project Information
3.2.1
Maintain Project Records
Purpose
The purpose of this process is to ensure that project records are kept current and available as needed.
Trigger
Charter signoff.
Key Considerations
No key considerations provided for this process step.
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Keep Record in Control File Up to Date
Ensure that the records in the project Control File are kept current and available to stakeholders who need access.
PM
2
Post Actuals to Plan
Ensure that the project plan is kept current by posting actuals and any scope changes that are signed off by the project Sponsor.
PM
Note: Keep project plans current by applying actuals hours and actual start and end dates on each task. 3
Maintain Project Control Logs
Ensure that issue, risk, and change logs are kept current. Provide access to key stakeholders so new issues and risks can be documented in the appropriate logs.
PM
4
Maintain Project Record in ITMS
Ensure that the project record in ITMS is kept current per ITMS procedures.
PM
5
Maintain Project Record in RMS
Ensure that the project record in RMS is kept current per RMS procedures.
PM
6
Maintain Project Record/Metrics in MRS
Ensure that project records are kept current in MRS.
PM
Tools/Techniques Summary Methods and Applications/Tools
Originator: One IT PPM Team Page 104 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Microsoft Word and Excel MRS ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS RMS – http://www.rms.ford.com MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process Timesheets http://www.rms.ford.com 221_weekly_status_report_template.doc 210_change_request_template.doc 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 212_risk_management_log.doc
Outputs Updated project records 221_weekly_status_report_template.doc 210_change_request_template.doc 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc Project Hours http://www.rms.ford.com
Originator: One IT PPM Team Page 105 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
3.2.2
Distribute Project Information
Purpose
A successful project is one that meets its objectives through appropriate methods and means of collecting and distributing project information. Project Communications Management provides the critical link among people, ideas, and information. Everyone involved in a project must be ready to send and receive communications and must understand how the communications affect the project as a whole. The purpose of this process is to ensure that this distribution of information occurs in a timely fashion and according to the project communication plan.
Trigger
Generation of the weekly status reports, the completion of a stage gate, at a planned point in the communication plan, or at any other critical decision point that occurs during the life of the project.
Key Considerations
No key considerations provided for this process.
Diagram
The following diagram shows where Information Distribution fits into the overall communication management process.
Process Tasks
Originator: One IT PPM Team Page 106 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Execute Communication Plan
On a weekly basis, review the project communication plan to determine what information must be distributed and to whom and act accordingly.
PM, Stakeholders
2
Communicate the Results of Key Decision Points
Notify stakeholders at key decisions points including, but not limited to, charter signing, stage completion, the results of status reports, the results of sponsor reviews, the results of technical reviews (see section 4.2.4 Coordinate Security Reviews & Certification), scope changes, etc.
PM, Stakeholders
3
Respond to Requests for Information
Provide access to information as appropriate, including project logs and other records, and respond to specific questions asked concerning the purpose of the project and the status of the project.
PM, Stakeholders
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word Email Meetings eRoom Web Sites
Inputs to Process 201_stakeholder_assessment_template.doc 203_team_directory_template.doc 215_communication_plan_template.doc See also the SDM Process Guide
Outputs 221_weekly_status_report_template.doc Results of reviews Approval to Proceed
Originator: One IT PPM Team Page 107 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, Stakeholders
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 108 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.0
Control Project Project Management Processes
Resource Plan Procurement Plan
Initiate Communication Plan
Budget Plan
Plan
Work Plans
Project Charter
Execute
Work Products Solution Delivery Methodology
Control Close
Inputs to Control Project Overview
The Project Management Institute (PMI) defines Project Control as follows: A project management function that involves comparing actual performance with planned performance and taking corrective action (or directing or motivating others to do so) to yield the desired outcome when significant differences exist. Monitoring and controlling the project also involves proactive management of scope, risks, quality, and issues and project reviews to ensure that stakeholders are satisfied that the project will succeed and should continue as planned.
Process Contents
Objectives 4.1
4.2
Monitor and Control the Project
Conduct Project Reviews
Processes
Key Deliverables
4.1.1
Monitor and Control Scope
4.1.2
Monitor and Control Schedule/Costs
4.1.3
Monitor and Control Risks
4.1.4
Monitor and Control Issues
Issues Resolution/Log
4.1.5
Monitor and Control Quality
Checklists and Metrics
4.2.1
Conduct Status Reviews
4.2.2
Coordinate Architecture Reviews
4.2.3
Coordinate Metrics Workshops
4.2.4
Coordinate Security Rev/Certification
ACR/ICR/Cert. Results
4.2.5
Coordinate PQA Reviews
Results of QA Reviews
4.2.6
Lead Gate Reviews
4.2.7
Support Operations Reviews
Originator: One IT PPM Team Page 109 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Change Requests/Log Updated Plans Risk Management Log
Status Reviews Architecture Rev. Results Function Point Counts
Go/No-Go Decisions Input to Ops Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1
Monitor and Control the Project
4.1.1
Monitor and Control Scope
Purpose
The purpose of Scope Control is to protect the viability of the approved project plans and deliverables. Scope changes can be caused by business changes, technical changes, requirements that were missed or not known when the project was funded, and errors or omissions in design.
Trigger
Submission of a new project change request and the monitoring of change requests during weekly status reviews.
Key Considerations
Diagram Updated Work Plan
Key considerations in controlling project scope are • •
What priority, importance has the requester attached to the change? What impact will the scope have on timing, costs, benefits, and planned and completed deliverables? • Is the change containable within the existing plan? • What impact will the change have on other related projects? • Can the change be deferred until the system is handed over for ongoing support and maintenance? The diagram below depicts the high-level process flow for this activity. Includes:
Investigate Change Request
Updated Records/ Plans
Project Charter ITMS Record
Assign & Schedule Investigation Change Requested
Log New Change Request
Recommend a Course of Action
Resource Request
Risk Assessment Budget Plan
Obtain Approval
Group Requests if Appropriate
Updated Change Log
Originator: One IT PPM Team Page 110 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Change Approved ?
No
Close Request & Communicate Status
Yes
Update Project Plans & Records
Obtain Resources if Required
Complete the Request
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Log New Change Request
Ensure that the change request has been submitted on the appropriate form and that sufficient details have been provided to allow for assessment. Note: All changes are to be logged, even small ones.
Stakeholders
2
Group Requests
Review change log to determine if other similar or related requests are outstanding. Group requests, if appropriate.
PM, Team
3
Schedule Investigation
Assign a resource to investigate the request and add that effort to the project schedule, as appropriate.
PM
4
Investigate the Change Request
Investigate the change and its potential impact on project objectives, resources, budget and schedule, and any related projects. Estimate the effort to complete the change and determine if additional funding and/or resources/skills will be required.
Team
5
Recommend a Course of Action
Based on the investigation recommend a course of action.
PM
•
Reject or defer the request
•
Contain the change within the existing plan
•
Defer some other deliverable to contain the change
• •
Request a change to the project timing, resources, and/or budget or use of reserves to satisfy request. Request that a new project be planned (i.e., if the change will extend the timeline significantly – by 25% or more, it may make more sense to treat it as a separate project)
6
Obtain Approvals
Any request that requires a change in the approved deliverables, resources, budget or end-date, a new project, or the use of project reserves must be approved. Recommendations to defer or reject changes that have been submitted by the intended recipients of deliverables should also be reviewed and signed off by the Customer and Sponsor.
PM, ESpon, Program Mgr BusA, Cust
7
Update Project Records and Plans
Update project records and work, resource, budget plans, and SOW as appropriate. This includes updating the project record in ITMS, RMS and MRS.
PM
8
Request Resources
Submit a resource request if additional resources are required and approved to complete the change.
PM
9
Close the Request & Communicate Status
Notify the stakeholder who submitted the request of the decision to complete or reject the change request. Notify other stakeholders as appropriate (e.g., the Project Mangers of related projects)
PM
Originator: One IT PPM Team Page 111 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools eTracker – see http://www.etracker.ford.com/ ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs Resource Request located at http://www.ads.ford.com/resman/ MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 210_change_request_template.doc 211_change_request_log.doc 02_Requirements_Specification.doc 213_issue_log.doc 212_risk_management_log.doc SOW located at http://www.ads.ford.com
Outputs
Recipients
210_change_request_template.doc 211_change_request_log.doc Resource Request located at http://www.ads.ford.com/resman/ Project Record in MRS http://www.ads.ford.com/mrs 229_Classic_SDM_Work_Plan.mpp 213_issue_log.doc Logs listed or logs in eTracker SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 112 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
ESpon, Program Mgr, BusA, Stakeholders, Competency Center, Resource Mgmt, Demand Mgmt
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.2
Monitor and Control Schedule/Costs
Purpose
After planning, monitoring and controlling the project schedule and project costs is one of the most important tasks that the project manager performs. Once a plan is in place and work is underway, it is the project manager’s job to collect information from each team member, on a weekly basis, to determine if work and spending are proceeding as agreed. Any variance from plan must be assessed to determine if action is needed to prevent schedule or cost overruns or get the project back on track.
Trigger
This process is triggered by weekly status reporting, or whenever a problem is noted in the timing or costs of the project.
Key Considerations
Diagram
The questions/issues that need to addressed during this process are: • Is the project ahead of or behind schedule? • Has spending exceeded the budget plan? • What are the root causes of schedule or cost variances? • Will the scope of the project be impacted by proposed corrective actions? The diagram below depicts the high-level process flow for this activity.
Process Tasks No
Task Name
Description
Participants
1
Assess Schedule & Cost Performance
Determine project status and spending in relation to the approved plans. Assemble pertinent materials, including the most recent weekly timesheets, expense reports, the current approved Project Plan and Budget, and any other documents that provide quantifiable data. Determine if the work is on track, ahead of plan, or behind plan, based on the resources spent (the burn rate) and the progress made. Assess resource utilization to determine if resources have worked to the level agreed. Review expenses to see if they are in line with the budget plan.
PM, Team
2
Analyze Variances
Analyze variances to determine their root causes and assess their impact on baseline plans. Use Earned Value Analysis to calculate the project’s SPI (Schedule Performance Index) and CPI (Cost Performance Index). Determine if the variances warrant taking corrective action.
PM
Note: A SPI or CPI lower than 1 indicates a problem 3
Log & Track as an Issue
Log any variance that requires corrective action as an issue and track accordingly.
PM
4
Identify Alternative Solutions
Identify the actions that must be taken to get the project back on track or keep it progressing on schedule. Distinguish between minor corrective actions (those that can be managed within the current plan) and those that change the approved project plan (end-date and/or budget) and, thus, require formal approval from the project sponsor and other stakeholders.
PM, Team, Program Mgr
For larger adjustments and those situations in which the current project plan will not suffice, identify alternative solutions. Refer to your Accelerator Use Plan for alternatives. Examine each Originator: One IT PPM Team Page 113 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide alternative for its impact on the project objectives, scope, benefits, schedule, quality, and budget. Determine how changes to the project plan will impact other efforts and what level of coordination is necessary. Select the most effective approach. Note: If the corrective action requires a change in the scope of the project (e.g., a change in deliverables, budget, timing, etc.), generate and log a Change Request and manage accordingly. 5
Identify Corrective Action
Identify what action will be taken to correct the schedule or cost issue.
PM, Team
6
Obtain Approvals (as Required)
Get signoff on actions that will alter the current approved schedule, budget or resource plan. If the schedule is changed, the Project Manager needs to notify the Competency Center. The resource's agency must approve the change. Update ITMS, SOW and record in RMS.
PM, Sponsor
Note: Using reserves, overtime, or additional resources, or rescheduling the project, as a solution, will require approval. 7
Update & Close Issue
Update project plans, as appropriate, and update and close the issue.
PM
Tools/Techniques Summary Methods and Applications/Tools http://www.etracker.ford.com/ Earned Value Analysis see http://www.ads.ford.com/eva/ MS Project Resource Request located at http://www.ads.ford.com/resman/
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan 210_change_request_template.doc 213_issue_log 02_Requirements_Specification.doc Timesheets http://www.rms.ford.com SOW located at http://www.ads.ford.com
Outputs Resource Request located at http://www.ads.ford.com/resman/ 204_accelerator_use_plan 210_change_request_template.doc 213_issue_log 229_Classic_SDM_Work_Plan.mpp Earned Value Analysis located at http://www.ads.ford.com/eva/ SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 114 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients ESpon, Program Mgr, BusA, Stakeholders, Competency Center, Resource Mgmt, Demand Mgmt
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.3 Purpose
Monitor and Control Risks
The goal of risk management is to ensure that risks are identified, analyzed, monitored and controlled, proactively. Risks are factors that have the potential to interfere with successful completion of a project. Risks are not issues – issues have already occurred, whereas risks may or may not occur. By addressing risks as soon as they are identified, the project team can assess their potential impact on the project and develop plans to manage them. Note: This process follows the initial risk assessment that is completed during Initiate Project and the development of risk management strategies that is completed during Plan Project. However, is assumed that additional risks may be identified during project execution and control. For this reason, the entire risk lifecycle is described here, including risk identification, analysis and planning.
Trigger
This process is triggered by weekly status reporting, or whenever a new risk is identified.
Key Considerations
Some questions to be addressed in identifying and controlling project risk are:
• • • • • Diagram
Are existing risk strategies working? Have any new risks been identified since the initial risk assessments and planning were completed? Have any risks been resolved (i.e., no longer a threat to the project)? Will new mitigation strategies or contingency plans impact project timing, resource plans or budget and require approval? Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.
The diagram below depicts the high-level process flow for this activity.
New Risk Identified
Log Risk
Weekly Status Review
Assess the Risk
Develop Plans to Manage
Track & Control Risk
Risk Under Control?
No
Raise Issue
Yes
No
Risk Resolved ? Yes
Updated Risk Log & Plans
Close Risk & Update Plans
Process Tasks Originator: One IT PPM Team Page 115 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
1
Identify and Log Risk
Identify a new Risk and log it into the Risk Management Log. Note: Most project risks should have been identified during Project Initiation as part of the Initial Risk Assessment. Those risks along with any new ones identified over the course of the project will be monitored and controlled here to ensure that mitigation strategies and contingency plans are effective.
Stakeholders
2
Analyze Risk
Work with project team mem bers to transform risk data into decision-making information. Categorize the risk in terms of how it impacts the project. Determine the level of impact of each risk (High, Medium or Low), the probability that each risk will occur (High, Medium or Low). Estimate the impact that the risk might have on costs, effort, timing, and benefits.
PM, Team
3
Develop Plans to Manage
Identify mitigation strategies (strategies to help minimize or avoid the risk) and develop contingency plans (plans to go into effect if mitigation strategies should fail). Ensure that mitigation actions are incorporated into the project plans, as appropriate Note: The E&Y Risk Management Strategies Document provide suggested mitigation strategies for many common risk factors.
PM, Team
4
Track & Control Risk Review actions against plan to determine if mitigation strategies are working. Institute contingency plans if necessary or develop new strategies to manage the risk.
PM, Team
5
Raise Issue
Where risk management strategies are not working, raise an issue for immediate action.
PM, Team
6
Close Risk & Update Plans
Close risks that are no longer a potential threat to the timing, cost or quality of project deliverables or risks that have been converted to an issue.
PM
Tools/Techniques Summary Methods and Applications/Tools MS Project
Inputs to Process 206_risk_assessment_template.xls 212_risk_management_log.doc 207_risk_strategies_jobaid.pdf
Outputs 206_risk_assessment_template.xls 212_risk_management_log.doc 213_issue_log.doc or eTracker located at http://www.etracker.ford.com/ 229_Classic_SDM_Work_Plan.mpp
Originator: One IT PPM Team Page 116 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Sponsor Program Mgr BusA Sponsor
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.4 Purpose
Monitor and Control Issues
An issue is an immediate problem that will be detrimental to the success of the project if it is not resolved quickly. If there is no urgency to resolve the issue or if the issue has been active for some time, then it may not really be an issue. It may be a potential problem (risk), or it may be an action item that needs to be resolved at some later point. Issues, by their nature, must be resolved with a sense of urgency. The resolution of an issue usually requires the assignment of one or more action items. Each action item should have a responsible person and a due date clearly identified. The Project Manager should have an activity in the work plan every week to follow-up on issues to ensure they are diligently resolved.
Trigger
Weekly status review or the identification/resolution of an issue.
Key Considerations
The key considerations in monitoring and controlling issues are
• What impact will the issue have on the schedule, costs and quality of deliverables?
• Who will be responsible for resolving the issue and by what due date? • How much time is required to investigate the issue and what impact will that have on the project plan?
• Will approval and/or action be required from other organizations to resolve the issue?
• What level of management needs to be involved to resolve the issue? Diagram
The diagram below depicts the high-level process flow for this activity.
Issue Identified
Log Issue
Weekly Status Review Assign To Resource for Resolution
Updated Work Plan
Develop Resolution Strategy
Scope Change Required?
Resolve or Escalate Issue
No
Monitor Issue Status
Issue Resolv ed?
No
Yes
Yes Submit Change Request Updated Issue Log
Close Issue
Originator: One IT PPM Team Page 117 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Process Tasks No 1
Task Name Identify & Log Issue
Description
Participants Stakeholders
Identify the issue and supply the following information to assess it properly: Description
A description of the issue
Level of Issue
An assessment of the issues overall potential impact: High, Medium or Low
Impact of Issue
The estimated impact of the issue on costs, effort, timing, and gross benefits, if known.
Proposed Solution
A proposed resolution or plan of action if known.
Comments
Any other comments that will help the Project Manager assign or escalate the issue
Note: Anyone involved in or impacted by the project can submit an issue, including team members, users, support functions, etc. 2
Assign for Resolution
Assign the issue for further investigation and resolution. Identify a due date and enter the information into the Issue Log (eTracker, if in use). Update the work plan to reflect the new assignment.
PM, Team
3
Develop Resolution Strategy
Develop a resolution strategy and review it with the project team. Determine if the strategy will require a change in the project scope. If it does, close the issue, submit a Change Request and manage accordingly.
PM, Team, BusA, Cust
4
Monitor Issue Status
Review the status of the issue in weekly project status review meetings.
PM
5
Resolve or Escalate the Issue
Resolve the issue within the project team or escalate it to the Sponsor, Program Manager, or Business Analyst.
PM, Team, BusA, ESpon
6
Close Issue
Close Issues that are resolved and update the log entries accordingly.
PM, Team
Tools/Techniques Summary Methods and Applications/Tools http://www.etracker.ford.com/ MS Project
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 213_issue_log.doc 02_Requirements_Specification.doc 35_Quality_Control_Plan_and_Test_Strategy.doc or 89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support
Originator: One IT PPM Team Page 118 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients
Issues in 213_issue_log.doc or eTracker 229_Classic_SDM_Work_Plan.mpp 210_change_request_template.doc 211_change_request_log.doc
Control File, Program Mgr, BusA, ESpon, Team
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.1.5
Monitor and Control Quality
Purpose
The primary purpose of quality control is to keep errors out of the hands of the Customer through prevention (keeping errors out of the process) and inspection (finding and removing errors from deliverables). Quality control is performed to ensure that the product and interim deliverables are acceptable. Quality Control consists of technical inspections and tests. Quality control should be performed incrementally throughout the project life cycle so that defects (errors and omissions) can be identified and rectified as early as possible.
Trigger
Project deliverable ready for inspection and weekly status reviews.
Key Considerations
As shown on the diagram below, which depicts the relative cost of addressing defects over the life of the project, the earlier in the life cycle a defect is found, the less costly it is to correct. 120 100 80 60 40 20 0 Analysis
Diagram
Design
Build
Implement Source: International Institute of Learning
The diagram below depicts the high-level process flow for this activity.
Methodology/ Quality Standards
Yes Monitor Process & Deliverables
Project Plans & Deliverables
Record Results
Results Acceptable ?
No No
Implement Rework or Improvement
Yes
Rework or Improvement Required?
Originator: One IT PPM Team Page 119 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Determine Course of Action
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No 1
Task Name Monitor Process & Deliverables
Description
Participants
Inspect deliverables and monitor the performance of required processes.
PM, Team
Inspections include activities such as measuring, examining, and testing undertaken to determine whether deliverables conform to requirements. Monitoring of the process involves the use of checklists and reviews to confirm that the process is being followed. It also involves the use of control mechanisms to monitor cost and schedule variances (earned value reports), the volume and frequency of changes (change logs), the timely resolution of issues (issues management logs), and other management results that help determine that the process is in control and, thereby, that quality is control. 2
Record Results
Capture results on acceptance documents, control charts, trend analyses, checklists, and defect or incident reports, as appropriate. Maintain records for use in project reviews.
PM, Team
3
Identify Issues and Determine Course of Action
Where defects or unacceptable results have been identified, determine what course of action is required. Defects in deliverables must be corrected before moving on. Failure to complete some process steps or adhere to standards may also require rework or the improvement of some deliverables.
PM, Team
4
Complete Rework or Improvement
Schedule and complete any rework or improvement required.
PM, Team
Defect Management Within Quality Management Process
A defect is defined as a non-conformance to requirements. The purpose of Defect Management is to ensure that defects are documented and resolved with a minimum impact on the project. Defects that are found during inspections and testing are documented using the defect log and tracked to ensure that a resolution occurs. If Test Director is being used as the testing repository, the Defect Tracking portion of Test Director will be used. The following diagram depicts the defect management process within the Quality Management Process.
Originator: One IT PPM Team Page 120 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Defect Management Process Flow A
Adds a defect, status=“New”
No
The defect is rejected, status=Rejected
Is it a defect?
Yes No
Will it be addressed in the current release?
No
Yes
Convinced with this resolution?
Yes Assign the defect to a developer status = “open”
B
Status=“Rejected” Developer fixes the defect, status=“fixed” Rebuild the deliverable and roll to the test environment where the developer verifies the fix, status=rolled
Was the defect associated with a change?
No
Update test cases as needed, test the fix in test environment
Yes
A
New Defect
Current/New/ Old found?
Defect Still Exists
Defect Closed The defect is deferred, Status=“Deferred”
Status=“Closed”
Status=“Reopen”
Done
Root Cause Change Follow the Change Management Process
B
No
Task Name
1
Log Defect
2
Analyze Defect
Description
Participants
Enter the defect in TestDirector as 'New' and categorize the defect (e.g.; Critical, Serious, Moderate, Cosmetic). Note: test status should be sent on a periodic basis to the Project Manager, usually after the completion of a logical group of tests or at suitable intervals Analyze the defects reported and change their status to either 'Open', 'Deferred' or 'Reject'.
Person who found the defect
PM, LDevl, QCTest
If 'Reject' or 'Deferred', specify in the 'R&D Column' on why it is being rejected or deferred. If defects are 'Opened', assign them for correction/fixing 3
Correct Defect
Correct the defect. Using the configuration management system (e.g.; PVCS, ChangeMan, etc.), check the corrected deliverable back into the source control area and change the status of the defect in TestDirector from 'Open' to 'Fixed'. Also enter the 'Root Cause' of the defect (e.g.; Requirements, Design, Coding, Data, database, Environment, Configuration, Change). Note: changes to documents as a result of the defect correction should be logged either in the project issue log or as a change request.
SDevl
4
Rebuild
Rebuild the deliverable using the configuration management
SCM
Originator: One IT PPM Team Page 121 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide application
system and "roll it forward" to the QC environment, informing all the version number of application with a list of defect-IDs fixed
5
Confirm Application Readiness
6
Test Application
Confirm that the application is functioning properly in the QC environment prior to testing. Make sure that the correct deliverable has been rolled to QC environment, and change the status to 'Rolled' Update Test Case(s) if necessary. Re-run the tests as documented in the TestDirector. If the defect is seen again – change the status to 'Re-Open'.
SDevl
QC Team, BusA, Sdevl, Cust (e.g.; who ever raised the defect)
If the defect is addressed (not seen) – change the status to 'Closed'.
7
Update Defect Status
If a new defect is discovered, then log as "New". If a defect is 'Re-Opened' – all steps from step 2 are repeated.
Originator: One IT PPM Team Page 122 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
QC Team, BusA, Sdevl, Cust (e.g.; who ever raised the defect)
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools eTracker at http://www.etracker.ford.com/ MS Project
Inputs to Process
Outputs
212_risk_management_log.doc
212_risk_management_log.doc
213_issue_log.doc
213_issue_log.doc or eTracker
229_Classic_SDM_Work_Plan.mpp
Acceptance Decisions
233_Gate_Review_Checklists.xls
Defects in 32_Defect_Log or Test Director
239_PQA_Review_Report.doc 32_Defect_Log or Test Director
Recipients Control File, Program Mgr, BusA, ESpon, Team, Metrics
Process Adjustments
52_Technical_Inspection_Summary_Form 57_PQA_Review_Checklists.xls 73_ARB_Workbook 35_Quality_Control_Plan_and_Test_Strategy.doc or 89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support All Project Work Products Issues in 213_issue_log.doc or eTracker
Originator: One IT PPM Team Page 123 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2
Conduct Project Reviews
4.2.1
Conduct Status Reviews
Purpose
Status reviews are an important tool in ensuring that project team members, Customers, sponsors, and other stakeholders are kept informed of progress, issues, risks, and changes. It is also an opportunity for the team to review the overall state of the project in relation to the original commitment to determine if the project is still viable.
Trigger
Approval of the initial project charter and high level plan (see Initiate Project).
Key Considerations
Key considerations in conducting status reviews are:
Diagram
•
Is the project still viable (i.e., is the business case still valid)?
•
Is the project plan sill aligned with external dependencies (i.e., are external events proceeded as expected)?
•
Is resource utilization in line with the approved project plan?
•
Is spending in line with the approved project plan?
•
Is the project on schedule?
•
Are deliverables being produced as planned and to the level of quality agreed with the Customer?
•
What issues are outstanding and what issues have been resolved?
•
What is the status of known risks and have any new risks been identified?
The following diagram shows the periodic reviews that must be supported, including PQA and gate reviews at the end of each stage, weekly status reviews (see items highlighted by red arrows) and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Originator: One IT PPM Team Page 124 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly
To Business Manager From Project Manager to IT Manager and Business Partner
At End of SDM Stage
During SDM Stage
From IT Manager
Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Process Tasks No
Task Name
Description
Participants
1
Schedule Weekly Status Reviews
Schedule a standing weekly status review meeting with core project participants (the Customer, Business Analys t, and Project Team). If appropriate, include the Sponsor and Program Manager in one or more of those meetings each month. Create a standing agenda.
PM
2
Prepare Materials
Prepare the standard weekly status report. Ensure that both the Project Manager assessment and the Customer assessment are completed. Gather supporting documents, including Earned Value Reports, and the results of gate reviews, etc.
PM, Cust
The GYR status is defined as follows: Green:
Target dates and/or deliverables are on track.
Yellow:
Target dates and/or deliverables are at risk, but a resourced recovery work plan is available and has been approved by the appropriate stakeholders Note: The status can only be returned to GREEN when the recovery work pan is executed and he risk is resolved. However, if the recovery work plan is not on track by the next review and the risk remains, the status should be changed to RED.
Red:
Target dates and/or deliverables are at risk and an approved recovery work plan is not yet available or the work plan does not achieve targets. The status remains RED until an approved work plan is available.
Note: The Weekly Status Report Template calculates the GYR status based on the percent over schedule or over budget, the significance of Originator: One IT PPM Team Page 125 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
changes requested during the period. See the template for details. The Project Manager has the ability to override the default GYR status value determined by the template, but if this is done, an explanation should be provided. The diagram below depicts the decision making process concerning GYR once a Yellow or Red condition has been identified. Green
Red
NO
YES
Target dates & deliverables are on track
NO
Recovery Plan is in Place
YES
Yellow
NO
Recovery Plan is Resourced
NO
YES
NO
Recovery Plan Approved by Stakeholders
YES YES
Recovery on Track Since Last Review
3
Provide Access to Materials
Be sure that participants have access to issue, change, and risk logs, and the most current version of the project plan. Distribute relevant materials at least 1 day before the meeting or make available to participants in an electronic folder on shared drive or in an eRoom.
PM
4
Review Status with Participants
Review and agree on the project GYR status with the team. Analyze any Yellow or Red items to determine root causes and agree on an action plan to address, accordingly.
PM, Cust, Team
5
Review Open Issues, Risks and Change Requests
Review the open items in the Issues, Risk and Change Request Logs. Identify work completed and any items that can be closed. Agree on a course of action and team assignments for addressing for any new items.
PM, Cust, Team
6
Assess Results of Quality Controls
Review the results of inspections, testing, technical reviews (see section 4.2.4) and the most recent gate review to determine if the project is adhering to quality standards. Make assignments, as necessary, to deal with any issues identified.
PM, Cust, Team
7
Review Team Assignments
Allow each participant to provide a brief report out on work in progress. Work with the team to determine if additional help is needed or other corrective measures are warranted.
Team
8
Assess Viability of the Project
Look at the actual work completed in comparison to the project plan to determine if the business case is still valid. Determine if anything has changed since the project started that would invalidate the assumptions made in the goals and objectives. Review forecasts of project completion and costs to determine if the project will deliver to promise.
PM, ESpon, Program Mgr, Cust, Team
Tools/Techniques Summary Methods and Applications/Tools eTracker at http://www.etracker.ford.com/ Earned Value Analysis template at http://www.ads.ford.com/eva/ MS Project RMS -- http://www.rms.ford.com
Inputs to Process Originator: One IT PPM Team Page 126 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Outputs
Recipients Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide 229_Classic_SDM_Work_Plan.mpp 211_change_request_template.doc 212_risk_management_log.doc 213_issue_log.doc 221_weekly_status_report_template.doc Timesheets http://www.rms.ford.com 220_meeting_minutes_template.doc 32_Defect_Log.doc
221_weekly_status_report_template.doc Earned Value Analysis Template at http://www.its.ford.com/eva/ 211_change_request_template.doc 212_risk_management_log.doc Issues in 213_issue_log.doc or eTracker at http://www.etracker.ford.com 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 127 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Program Mgr, BusA, ESpon, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.2 Purpose
Coordinate Architecture Reviews
If appropriate to the project type, an architecture review must be completed before the end of the first stage. See the Classic Solution Delivery Methodology Process Guide. It is The Project Manager’s job to ensure that the architecture technical reviews (see section 4.2.4) occur as required and that any issues, action items, or decisions that are made as a result of these reviews are approved, as appropriate, and reflected in project plans and documentation.
Trigger
Initial Charter signoff and completion of stage.
Key Considerations
No key considerations provided for this process.
Diagram The following diagram shows the periodic reviews that must be supported, including Architecture, PQA and gate reviews at the end of each stage, weekly status reviews (see items highlighted by red arrows) and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Originator: One IT PPM Team Page 128 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Coordinate Architecture Review
Ensure that a required Architecture Review occurs. Refer to the appropriate SDM Process Guide for details.
PM
2
Ensure Review Results are Documented
Review results and ensure that any action items are reflected in project plans and completed.
PM
3
Update Project Records
Ensure that review documentation is stored in the project Control File as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tool s Classic_SDM_Process_Guide Architecture Management Guidebook located at http://www.fsic.ford.com/architecturemanagement/ OneIT Architecture Review Board Workbook located at http://www.fsic.ford.com/architecturemanagement/
Inputs to Process
Outputs
ARB review meeting minutes in 220_meeting_minutes_template.doc
ARB review meeting minutes in 220_meeting_minutes_template.doc
73_ARB_Workbook.xls completed to appropriate level in system development lifecycle.
Update 73_ARB_Workbook.xls
Originator: One IT PPM Team Page 129 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.3
Coordinate Metrics Workshops
Purpose
The deliverables from the Metrics Workshops are valuable tools to help project managers evaluate project scope, determine resources required, estimate project effort and duration, prioritize deliverables, and evaluate productivity. A key output of each session is a function point count for the project.
Trigger
The Initial Metrics Workshop is triggered by completion of the conceptual design. The Interim Metrics Workshop is triggered by completion of the physical design process -- per the Classic SDM. The Final Metrics Workshop is triggered by conclusion of the build stage.
Key Considerations
Instructions for preparing for metrics workshops (Initial, Interim, and Final) are provided by the Metrics Specialists. Details on the Metrics workshop processes are documented in the Solution Delivery Methodology Process Guide.
Diagram
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Coordinate Interim and Final Metrics Workshops
Ensure that a required Interim and Final Metrics Workshop occur. Refer to the appropriate SDM Process Guide for details.
PM, Team, Metrics
2
Ensure Workshop Results are Documented
Review results and ensure that any action items are reflected in project plans and completed, as appropriate.
PM, Team, BusA, Cust
3
Update Project Records
Ensure that workshop documentation is stored in the project Control File as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Classic_SDM_Process_Guide
Inputs to Process Metrics meeting minutes in 220_meeting_minutes_template.doc
Outputs Metrics meeting minutes in 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 130 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.4 Purpose
Coordinate Security Reviews & Certification
Most project types undertaken by IT will involve various technical reviews that occur across the project life cycle. These include, but are not limited to, the following:
•
Application Control Reviews (ACR) which are required to ensure that adequate security measures have been designed into an application that is being developed – see the following link for more information
HTTP://WWW.DEARBORN.FORD.COM/SECURITY/INTERNALCONTROL/552/ACRPROC.HTM
•
Infrastructure Control Reviews (ICR) which are required on projects that involve the implementation of infrastructure components that have not been previously been submitted for formal review at Ford.
•
Certification Reviews which are required for any application that makes changes to the standard Ford Client – see the following link for more information http://www.its.ford.com/fsic/.
The details of these reviews will be found in the appropriate solution delivery methodology guide for the project type (e.g., the Classic, Object Oriented, and Purchased Package methodology guides.) It is The Project Manager’s job to ensure that these technical reviews occur as required and that any issues, action items, or decisions that are made as a result of these reviews are approved, as appropriate, and reflected in project plans and documentation.
Trigger
Approval of the project charter and baseline plan.
Key Considerations
The main consideration here is •
what type of project is being conducted
•
what reviews are stipulated for that type of project
•
3 party products need to go through the SIE certification test if there is no prior SIE certification
rd
See the Solution Delivery Methodology Guide for details of these reviews.
Diagram
No diagram provided for this process.
Process Tasks No 1
2 3
Task Name Verify Submissions/ Registrations Coordinate Scheduling Participate in
Description
Participants
Verify that the appropriate submissions and registrations have been completed.
PM
Coordinate scheduling of review sessions.
PM
Make self and team members available for participation in the review
SCC,
Originator: One IT PPM Team Page 131 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
4
5
Task Name
Description
Participants
Review Sessions
sessions as appropriate. Identify a team member to record the session and make note of any changes required to satisfy requirements or issues that need to be resolved.
Monitor Resolution of Issues Verify final approval
Monitor completion of the changes identified in the session or issues that need to be resolved. Verify that final approval is obtained prior to launch and archive records.
PM, Team, Reviewers as appropriate PM
PM
Tools/Techniques Summary Methods and Applications/Tools Classic_SDM_Process_Guide
Inputs to Process Security review meeting minutes in 220_meeting_minutes_template.doc
Outputs Security review meeting minutes in 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 132 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.5
Coordinate PQA Reviews
Purpose
Process Quality Assurance (PQA) Reviews occur at the end of each stage in the project. The purpose of the PQA Reviews is to ensure that project processes and deliverables meet standards and will lead to a successful outcome.
Trigger
The trigger for a PQA Review is the completion of work products and processes for a given stage (e.g., Design, Build, or Implement).
Key Considerations
See the appropriate SDM Process Guide.
Diagram
The following diagram shows the periodic reviews that must be supported, including PQA and gate reviews at the end of each stage (see items highlighted by red arrows), weekly status reviews and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Originator: One IT PPM Team Page 133 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Coordinate PQA Review
Ensure that a required PQA Review occurs. Refer to the appropriate SDM Process Guide for details.
PM, Team, PQA
2
Ensure Review Results are Documented
Review results and ensure that any action items are reflected in project plans and completed.
PM, Team
3
Update Project Records
Ensure that review documentation is stored in the project Control File as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Classic_SDM_Process_Guide
Inputs to Process PQA review meeting minutes
Outputs 239_PQA_Review_Report.doc
Originator: One IT PPM Team Page 134 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients See SDM Guide
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.6 Purpose
Lead Gate/Tollgate Reviews
Gate reviews are event -driven major milestones during projects that ensure informed decisions are made about the continued viability of a project and/or its readiness to proceed to the next stage. Gate Reviews typically occur at the end of project life cycle stages, before the next major stage is to begin or before a major commitment is to be made. Decision makers (principally, the Sponsor or Customer and Business Analyst and/or IT Management) review the results of actual work effort vs. baseline work effort and projections of the work effort required to complete the project. They make an assessment of the overall project health (R/Y/G rating), a Go/No-Go decision (Is it ready to proceed to the next stage?) and, if necessary, a recommendation to terminate the project. Project cost, business benefit, timing, SDM process adherence and architecture compliance are all factors in determining the overall project health. At the Gate Reviews, obtain the appropriate signatures on the Gate Review Checklist forms to ensure accountability of the decisions rendered. Six Sigma Tollgate Reviews are checkpoints within the Six Sigma DFSS process that ensure that the project is aligned with business requirements / customer expectations and that the criteria listed below for this point in the DFSS lifecycle have been achieved. Verification that Tollgate 0 occurred is confirmed by the PM process "Confirm Project Readiness to Start". Tollgates 1 and 5 are explicitly called out in the Classic SDM methodology. Tollgates 2, 3 and 4 are embedded within the Gate review.
Trigger
The remaining gate reviews are triggered by completion of the work products and processes for each stage (e.g., Design, Build, or Implement).
Key Considerations
At this point in the process, there are two key decisions that must be made: 1) should the project continue and 2) is it ready to proceed to the next stage.
The following must be considered in deciding if the project should continue:
•
Expected costs vs. expected benefits (i.e., do expected benefits outweigh projected costs to complete?)
•
Risk and feasibility (i.e., is the project feasible given the current understanding of risks, project constraints, issues, and the volume and nature of outstanding change requests?)
•
Strategic importance (i.e., given expected costs, benefits, risks, issues, and outstanding change requests, is the project of significant importance to warrant continued funding?)
•
Regulatory compliance (i.e., is the project mandated by the need to comply with governmental regulations?)
The following must be considered in deciding if the project should proceed to the next stage:
Originator: One IT PPM Team Page 135 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Diagram
• • • •
Have all deliverables of the stage been completed?
•
Must any outstanding issues be resolved, before the project can proceed?
Has the initial charter been signed by the Sponsor? Has the Architecture Review Board (ARB) for this stage been conducted? Has the Project Quality Assurance (PQA) review for this stage been conducted?
The following diagram shows the periodic reviews that must be supported, including PQA and gate reviews at the end of each stage (see items highlighted by red arrows), weekly status reviews and various levels of operations reviews that are conducted on a monthly and quarterly basis.
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Originator: One IT PPM Team Page 136 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Schedule Review
The end date of each stage should be clearly identified in the project plan. Before that date, confirm the date that the project will reach the stage gate and confirm or adjust the scheduled gate review. Notify participants (the Sponsor, IT Project Owner, Business Analyst, Program Manager, and if appropriate, the PQA Reviewer, AM Coordinator and Project Managers of related projects, and other interested parties).
PM
2
Collect Backup Materials for Meeting
Pull together all of the materials that may be required to explain the current state of the project, including the PQA R/Y/G rating, ARB R/Y/G rating, the status of issues, risks, and change requests, and recent status reports, current metrics, etc., to have ready if needed during gate review discussions. Ensure that these materials are current and accurate. Include the signed charter.
PM
Just prior to the meeting collect data on progress against plan and actual costs from project team members. Complete the weekly status report form and earned value analysis to determine the project’s current GYR (Green, Yellow, Red) status, earned value, and Schedule Performance Index (SPI) and Cost Performance Index (CPI). Identify planned milestones achieved or missed. Review the current risk assessment and update as needed to arrive at a current risk rating score. 3
Complete the Review Checklists
Obtain the appropriate Gate Review Checklist and complete the Yes/No checkboxes. Note that 6-Sigma Tollgate questions have been included in the Gate Review Checklist.
PM, Cust
4
Assess Project Viability
PM, BusA Cust Program Mgr
5
Conduct Review
Review the completed Gate Review checklist, current status, risk rating, change logs, issue log, risk management log, with the Customer and Business Analyst to jointly arrive at a recommendation as to the viability of the project prior to the actual gate review. Typically this is performed at a regular project status meeting. During the gate review, present and review the completed Gate Review checklist and, if necessary, any backup/supporting materials needed to explain the current state of the project. Review recommendations made by the Project Manager, Business Analyst and Customer on the continued viability of the project.
As necessary: ESpon, AppOwn, Program Mgr, PQA, AMCoord, PM for related projects, APM/LOB, Practice Mgr, 6-Sigma, Stakeholders, Vendor/Suppli er
Make Overall Project R/Y/G Rating, Go/No-Go Decision, and if appropriate, a recommendation to terminate the project. These decisions may take the following forms:
• • • • •
Overall R/Y/G rating becomes the lowest of the ARB, PQA and Project Status R/Y/G ratings Continue as planned Continue in a watch state for a specified short-interval and review the status again at the end of that period Continue the project under the condition of specified changes in the current plan (create Change Requests, as appropriate)
PM, BusA, Cust
Terminate the project
Guidelines on When to Consider Terminating a Project When it no longer has business/ strategic value
When the project is no longer contributing to the organization’s long- or short-term business strategies.
Originator: One IT PPM Team Page 137 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
When it is no longer feasible
When the project cannot be done properly with the available resources or under the current circumstances.
When deliverables continually fail to appear
When even the best efforts of the project team and aggressive corrective action (changes to the plan, scope, or resources) fail to produce desired results.
When there are more issues than successes
When issues outnumber the successfully completed milestones and deliverables.
When the budget stops representing reality
When budget or resource allocations are continually exceeded or substantial unreported overtime is required to meet milestones.
6
Obtain Signatures
Obtain signatures on the Gate Review Checklist Forms from the appropriate decision makers including the customer responsible.
PM Cust Others, as necessary
7
Communicate Decision
Communicate the overall project R/Y/G rating and the go/no-go decision (and if appropriate, the recommendation to terminate the project) to key stakeholders, including related projects and support activities per the project communications plan.
PM
If the project is to be continued, advise those impacted by the decisions (e.g., ITS, application support groups, etc.) to reaffirm or adjust the direction of the project's progress and schedule. 8
Update Project Records
Store minutes and other documentation of the review in the project Control File. Update the project record in ITMS, RMS and MRS.
Originator: One IT PPM Team Page 138 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools eTracker at http://www.etracker.ford.com/ Earned Value Analysis template at http://www.ads.ford.com/eva/ Microsoft Word and Excel ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs MS Project MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process
Outputs
Recipients
Results of ARB Reviews
211_change_request_template.doc
Results of PQA Reviews
220_meeting_minutes_template.doc
200_project_charter_template.doc
221_weekly_status_report_template.doc
206_risk_assessment_template.xls
233_Gate_Review_Checklist
211_change_request_template.doc
Go/No-Go Decision / Recommendation to Terminate (if appropriate)
212_risk_management_log.doc 213_issue_log.doc 215_communication_plan_template.doc 221_weekly_status_report_template.doc 229_Classic_SDM_Work_Plan.mpp Current Earned Value Report
BusA, Control File, Cust, IT Management, Stakeholders, Team, ITMS, ESpon
Issues in 213_issue_log.doc or eTracker Overall Project R/Y/G Rating Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs Risks in 206_risk_assessment_template.xls and 212_risk_management_log.doc
SOW located at http://www.ads.ford.com
Originator: One IT PPM Team Page 139 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
4.2.7
Support Operations Reviews
Purpose
Operations reviews provide the means to assess programs and projects within the context of an organization’s entire portfolio of work.
Trigger
Monthly or quarterly review or a project portfolio.
Key No key considerations specified for this process. Considerations Diagram
The following diagram shows the periodic reviews that must be supported, including gate reviews at the end of each stage, weekly status reviews and various levels of operations reviews that are conducted on a monthly and quarterly basis (see items identified by red arrows).
Quarterly
WHEN
CIO
CIO Ops Reviews From To PSC Director
WHAT
IT DIRECTOR Quarterly To CBG/GEC Exec
During SDM Stage
Director Ops Reviews
Manager Ops Reviews
IT MANAGER
Monthly At End of SDM Stage
From IT Manager
To Business Manager From Project Manager to IT Manager and Business Partner Gate Reviews
Architecture
•ARB Health •Occurs for ID & Assess, Analysis, & Design Stages •Once per Stage
Originator: One IT PPM Team Page 140 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Process Reviews •PQA Health •Occurs for all Stages •Once per Stage
Project Status Reviews •Project Cost, Benefit, Timing Health •Occurs for all Stages •Many Times per Stage
Project Reviews
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Process Tasks No
Task Name
Description
Participants
1
Ensure Project Records are Kept Current
Ensure that project records in ITMS, RMS and MRS are kept current and accurately reflect the true status of the project.
PM
2
Provide Current Status Report
Be prepared to provide a current status report if requested.
PM, Cust
3
Prepare Backup Material as Required
Ensure that project records (documentation) are ready for review if requested – particularly if the current status of the project is yellow or red.
PM
Tools/Techniques Summary Methods and Applications/Tools Earned Value Analysis template at http://www.ads.ford.com/eva/ Microsoft Word and Excel MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 221_weekly_status_report_template.doc Project Control File Results of Gate Reviews Results of ARB Reviews Results of PQA Reviews
Outputs
Recipients
Project Record in MRS http://www.ads.ford.com/mrs Project Record in RMS http://www.rms.ford.com Project Record in ITMS http://www.itms.ford.com/
Originator: One IT PPM Team Page 141 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Sponsor, IT Management, Cust
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Originator: One IT PPM Team Page 142 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.0
Close Project Project Management Processes
Resource Plan Procurement Plan
Initiate Communication Plan
Budget Plan
Plan
Work Plans
Project Charter
Execute
Work Products Solution Delivery Methodology
Control
Close
Inputs to Close Project
Overview
Closure is the formal end-point of a project, either because it is completed or because it has been terminated. Termination may occur because the project is no longer viable or because the risks associated with it have become unacceptably high. Formal closure finalizes the project in the eyes of the stakeholders and provides a learning opportunity. It is also the point at which issue and change logs are closed, project accounts are reconciled, resources are released, feedback is solicited from stakeholders, and work products are archived for future reference.
Process Contents
Objective 5.1
Note Refer to PM Processes "3.0 Execute Project" and "4.0 Control Project" for processes such as "Maintain Project Records" or "Conduct Status Reviews" for process steps that must be carried out across all five PM Processes (Initiate, Plan, Control, Execute, Close).
5.2
5.3
Finalize Delivery Conduct Final Project Review
Perform Administrative and Financial Closure
Process Steps
PM Deliverable
5.1.1
Finalize Implementation
5.1.2
Finalize Transition
Handover to Support
5.2.1
Administer Major Release Survey
Feedback on Project
5.2.2
Conduct Wrap-up Session
5.2.3
Prepare Closure Report
5.3.1
Release Resources
5.3.2
Complete Financial Closure
Budget/Contract Closure
5.3.3
Close & Archive Records
Closed/Archived Records
Originator: One IT PPM Team Page 143 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Implementation as Planned
Lessons Learned/Metrics Completion Documents Released Resources
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.1
Finalize Delivery
5.1.1
Finalize Implementation
Purpose
The purpose of this step is to ensure completion of implementation plans created during the analysis and planning stages of the project.
Trigger
Project closure.
Key Considerations
Key considerations for this process step include:
Diagram
•
Is the project closing because it has completed successfully or because it has been terminated before being completed?
•
If it was terminated, are there still elements that will be implemented or handed-over to another team?
•
What implementation tasks have already been completed, if any?
No diagram provided for this process
Process Tasks No
Task Name
Description
Participants
1
Execute Implementation Plans
Ensure that final implementation tasks are executed as planned. If the project is closing because it has been terminated, finish any implementation steps that are appropriate.
PM, Cust, Support Activities
2
Update Project Records
Update project records to reflect that implementation plans have been executed as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word and Excel ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process Implementation Plans
Outputs Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs
Originator: One IT PPM Team Page 144 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, AppSupr
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.1.2
Finalize Transition
Purpose
The purpose of this step is to ensure completion of transition plans made during the planning stage. This includes execution of handover and follow-up tasks.
Trigger
Project closure.
Key Considerations
Key considerations for this process step include:
Diagram
•
Is the project closing because it has completed successfully or because it has been terminated before being completed?
•
If it was terminated, are there still elements that will be implemented or handed-over to another team?
•
What transition tasks have already been completed, if any?
No diagram provided for this process
Process Tasks No
Task Name
Description
Participants
1
Execute Transition Plans
Ensure that final transition tasks are executed as planned. If the project is closing because it has been terminated, finish any transition steps that are appropriate.
PM, Cust, Support Activities
2
Update Project Records
Update project records to reflect that transition plans have been executed as appropriate.
PM
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Referenc e_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 217_transition_support_plan.doc
Outputs 217_transition_support_plan.doc
Originator: One IT PPM Team Page 145 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, AppSupr
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.2
Conduct Final Project Review
5.2.1
Administer Major Release Survey
Purpose
At the end of the Category 2 and 3 projects, it is important to solicit feedback from Customers and sponsors on the way that the project has been planned, managed, and concluded and on final deliverables. The feedback, obtained can be an important source inspiration for process improvements and professional growth. It is also an important tool in assessing overall professionalism and effectiveness of the Ford IT organization.
Trigger
Project Manager indicates that a Category 2 or 3 project has completed. MRS sends the Major Release Survey to listed users 30 days after Project Implementation.
Key Considerations
The key considerations in soliciting and obtaining Customer feedback are:
Diagram
• •
Which Customers will be asked to complete a Satisfaction Survey?
•
If the project in question a pilot project?
How much time will Customers be given to complete the survey?
No diagram provided for this process
Process Tasks No
Task Name
Description
Participants
1
Solicit User Feedback
Project Manager will add/update user list in MRS with names of individuals who should receive a support survey from MRS, being sure to include the Business Analyst, Program Manager, Customer, and Sponsor.
PM Cust(s)
2
Solicit QC Feedback
Ask the Quality Control Test Specialist (QCTest) to provide the QC final reports for filing in the Project Control File.
PM, QCTest
3
Assess Feedback Results
Review and summarize completed results.
PM
4
Share results and thank participants
Share summarized results with participants. Add completed surveys and summary report to Project Control File. Thank participants.
PM, ESpon(s), Cust(s), Team
Originator: One IT PPM Team Page 146 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word / Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process
Outputs
Recipients
201_stakeholder_assessment_template.doc
Major Release Survey
203_team_directory_template.doc
85_QC_Final_Report_Metrics_Spreadsheet located at QC web site http://www.sdg.ford.com/qc/
ESpon (s), Cust(s), Team, Metrics
84_QC_Final_Report_Management_Summary located at QC web site http://www.sdg.ford.com/qc/
Originator: One IT PPM Team Page 147 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.2.2
Conduct Wrap-up Session
Purpose
The project wrap-up session provides an opportunity for team members (including any support resources that have participated on the project as needed) to review what transpired on the project, and agree on what went well and what could have been done better. Outputs of the review process will be a set of lessons learned and recommendations for improvements in project management processes and the solution delivery methodology.
Trigger
Project closure.
Key Considerations
The key questions to be addressed in the final assessment are:
Diagram
•
What went right and why?
•
What went wrong and why?
•
How well did the methodology work to guide the project?
No diagram provided for this process.
Process Tasks No
Task Name
Description
Participants
1
Schedule and Hold the Meeting
Schedule a wrap-up session with members of the project team. Arrange for a facilitator if possible. Ask participants to review documents in the Project Control File ahead of time to refresh their memory on the status of the meeting at closure, the project goals and objectives, and outcomes. Provide or direct team members to the results of team, Customer, and sponsor feedback.
PM, Team, Metrics
2
Compare Actuals to Project Plans
Compare the final project schedule, resource utilization, budget, and deliverables to the original plan:
PM, Team, Metrics
• •
What was really created versus what was planned?
•
Were there deviations from the project plan?
•
Why did the deviations occur?
•
Could they have been avoided?
Did the deliverables comply with the Customers’ and sponsors’ acceptance criteria?
3
Evaluate Methodology
Evaluate the project management and solution delivery methodologies used on the project. Determine what worked well and what could have been improved.
PM, Team
4
Review Team Make-up
Assess the make up of the team to determine if it was effective.
PM, Team
•
Were the right people/skill-sets on the team?
Originator: One IT PPM Team Page 148 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
•
Participants
Were ad hoc members useful?
5
Review the Results of Gate Reviews
Review the results of gate reviews conducted during the life of the project. Determine if lessons can be learned from those results.
PM, Team
6
Review Feedback
Review feedback obtained as part of the Solicit Feedback process. Identify lessons learned from that feedback.
PM, Team
7
Document & File Lessons Learned
Document all lessons learned and any recommendations made by the group and add to Project Control File. Share lessons learned with local management as required.
PM, Team
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word Brainstorming Facilitated Session
Inputs to Process Results of Customer and team satisfaction surveys 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 221_weekly_status_report_template.doc 220_meeting_minutes_template.doc
Outputs 211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 222_lessons_learned.doc 220_meeting_minutes_template.doc
Originator: One IT PPM Team Page 149 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Team, Metrics
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.2.3
Prepare Closure Report
Purpose
The Closure Report performs two functions. First, it summarizes the reason for the closure (i.e., successful completion of the project or termination), the deliverables produced, and relevant productivity metrics (e.g., function point productivity measures on application development projects, the number of change requests submitted and resolved, the number of defects reported, etc). It also highlights the lessons learned as agreed in the Team Wrap-up Session.
Trigger
Project Closure
Key Considerations
No key considerations provided for this process
Diagram
No diagram provided for this process.
Process Tasks No 1
Task Name
Create Project Closure Report
Description
Participants PM
Create a report with the following sections: Reason for Closure:
State the circumstances under which the project is being closed.
Objectives Achieved:
Import the Deliverables section from the Project Charter and identify which ones are completed.
Project Proficiency:
Describe metrics that demonstrate how effective the project was in resolving issues, managing risks and scope, and producing deliverables.
Lessons Learned:
Summarize highlights of the lessons learned as determined in the Team Wrap-up Session.
Results of Feedback:
Summarize feedback obtained from the project team, Customer(s) and sponsor(s).
Acknowledge ments:
Acknowledge individuals who have made special contributions to the project.
2
Issue Notification Letter
Complete and distribute a Completion Notification Letter.
PM, Cust
3
Review & Finalize Closure Report
Review the Closure Report with the Customer and obtain sign-off.
PM, Cust
4
Archive Signed Closure Report
Add the signed Closure Report to the Project Control File.
PM
5
Change Project Status in RMS
Send a note to RMSHELP to change the project status to "Closed".
PM
Tools/Techniques Summary Originator: One IT PPM Team Page 150 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word
Inputs to Process 200_project_charter_template.doc 229_Classic_SDM_Work_Plan.mpp 222_lessons_learned.doc
Outputs 223_closure_report_template.doc 224_completion_notification_template.doc
Originator: One IT PPM Team Page 151 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Recipients Control File, ESpon, Cust, Local Mgmt
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.3 Perform Administrative and Financial Closure 5.3.1
Release Resources
Purpose
Once the project is closed, resources (personnel, equipment, and facilities) need to be released for use on other projects. If appropriate, the performance and contributions of individual team members should be assessed and documented and feedback given. Note that contractual agreements preclude providing direct feedback to contract personnel.
Trigger
Project Closure.
Key Considerations
The key considerations in releasing resources are:
Diagram
•
What guidelines have been established for assessing the performance of contract personnel?
•
What arrangements, if any, have been made for providing feedback on the performance/contributions of non-Ford IT team members and personnel who belong to other IT or Business Activities?
No diagram provided for this report.
Process Tasks No
Description
Participants
Notify Competency Center of Upcoming Releas e of a Ford ADS Resource
Send an MS-Outlook note to the appropriate Competency Center Manager 30 days prior to the release and notify him/her that the resource will be released and the date of the release. If the resource doesn't know whom their manager is, the note should be sent to Don Bartkowiak (DBARTKOW).
AppSupr, Competency Center Manager
2
Notify Agency of Upcoming Release of Agency Resource
Send an MS-Outlook note to the appropriate agency representative 2 weeks prior to the release and notify him/her that the resource will be released and the date of the release.
AppSupr, Agency Representative
3
Notify RMS of Resource Release
Send an MS-Outlook note to cdsid RMSHELP to inform them that the resource will no longer be working on the application and should not bill against it any longer.
AppSupr
4
Perform Exit Procedure
Follow the instructions at the exit procedure link located at http://www.ads.ford.com/facilities/. This procedure covers the removal of application access, building access and other tasks.
AppSupr
1
Task Name
Note: As per the new Competency Center Guide, Ford ADS resources will have been assigned a Competency Center Manager. The Application Supervisor should obtain the Competency Center Manager's name from the resource.
Tools/Techniques Summary
Originator: One IT PPM Team Page 152 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide Methods and Applications/Tools Microsoft Word Interim Resource Management Process http://www.ads.ford.com/resman/
Inputs to Process
Outputs
203_team_directory_template.doc 223_closure_report_template.doc
Recipients
Team Evaluations Notification of release of resources
Team Competency Center Resource Management
5.3.2
Complete Financial Closure
Purpose
Financial closure is the process of completing and terminating the financial and budgetary aspects of the project being performed. Financial closure includes both (external) contract closure and (internal) account closure.
Trigger
Project Closure
Key Considerations
The key considerations in completing financial closure are
Diagram
•
Are there any special contractual issues that must be addressed if the project is terminated before the agreed end date?
•
Who needs to be notified ahead of time that a project will be reaching closure and by how much lead time?
•
Are there outstanding contract issues that need to be resolved before the contact can be settled?
•
What project charge codes need to be closed and by when?
The diagram below depicts the high-level process flow for this activity.
Communicate Project Closure
Project Schedule Project Contracts Budget Plan
Confirm Project Completion Date
Close Charge Codes
Confirm Contract Fulfillment
Contract Fulfilled?
Yes
Project Closure Report Resolve Contract Issues
No
Close Contract
Process Tasks No 1
Task Name Confirm the Closure or Completion Date
Description
Participants
Once a project is closed, there should be no need to apply labor or resources against the project because it will be delivered or turned over to operations. Any further work done on the product beyond this
Originator: One IT PPM Team Page 153 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
PM
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide No
Task Name
Description
Participants
date should be considered operations and maintenance costs. 2
Communicate Closure Date
Project staff, management, and RMSHELP need to be told as far ahead of time as possible when the project will be concluded. There are several reasons for this.
• •
PM
The staff applied to the project will know the date beyond which they will not be able to charge their time against and purchase resources for the project. Management will be able to plan where their resources will be applied next.
•
Setting a date provides a sense of urgency to resolve issues and complete the activities that have been dragging on without resolution. The planned completion date of the project should be kept current in the project schedule as well as ongoing project documentation. 3
Close Charge Codes
Most projects have account numbers associated with them that allow financial departments to track labor hours and resource procurement. These labor charge codes will be need to be deactivated so that no personnel may continue to charge time against the project or use project charge codes to purchase materials, etc. Closure of these accounts should be formalized via written request that the project manager turns over to the organization’s finance manager. Send a note to RMSHELP with code number and close date.
PM, FinanceAnal
4
Confirm Contract Fulfillment
In order to close a contract, it is important to collect all pertinent documentation for review. This includes all of the original contracts and supporting documentation such as schedules, contract changes, and performance reports. This documentation needs thorough review to ensure that there are no unrealized contract issues that could result in legal liability.
PM, Purchasing, OGC
5
Resolve Contract Issues
Reconcile the actual utilization of contract resources against the planned utilization. Reconcile actual costs against planned costs. Terminate all arrangements for the use of resources, including leases and contractual agreements.
PM, Purchasing, OGC
6
Close Contract
Produce any written contract closure documentation required by the vendor.
PM
Originator: One IT PPM Team Page 154 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools Microsoft Word ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS WebTracs Project Record in MRS http://www.ads.ford.com/mrs MRS User and Quick Referenc e Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process 229_Classic_SDM_Work_Plan.mpp 223_closure_report_template.doc
Outputs
Recipients
Charge Code Closure Closed Contracts Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs 229_Classic_SDM_Work_Plan.mpp Project Record in ITMS http://www.itms.ford.com/
Originator: One IT PPM Team Page 155 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Purchasing, OGC, Demand Management, MRS Plans Database
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
5.3.3
Close & Archive Records
Purpose
The primary purpose of closing and archiving project work products is to ensure that deliverables are handed over to the appropriate parties and that reusable objects are available for use on other projects. This includes closing issues, risk, and change logs and handing over final deliverables to Customers and support activities. It also includes updating the project’s records in ITMS, RMS and MRS to reflect the closure status. Finally, closure involves archiving work products for reuse and historical purposes.
Trigger
Project Closure.
Key Considerations
The key considerations in closing and archiving project records are
Diagram
•
What project deliverables need to be handed over to other project teams, support activities and end-users?
•
What project work products might prove useful on other projects?
•
What project work products and records need to be maintained to support Corporate Records Retention policies?
No Diagram provided for this process
Process Tasks No
Task Name
Description
1
Handover Project Deliverables
Prepare project deliverables and records for handover. Ensure that the correct versions are passed to other teams and that the recipients know how to access and update them, as appropriate.
PM
2
Close Project in ITMS
Update the Project State in ITMS so that it shows a status of "Complete".
BusA
3
Close Project Logs and Records
Close records that describe the project. Ensure that the project is accurately reflected in ITMS, RMS, MRS and any local systems used to track IT projects.
PM
4
Review Work Retention
Review work products in the Project Control File to determine if it should be maintained for reuse or legal purposes.
PM
5
Archive Work Product or Discard
The first rule of archiving project products is -- if it was important to create, it is probably important to keep. Schedule a CD burn of archived materials. Up to 2 copies can be requested. Schedule the burn by submitting a GIRS ticket.
PM
Originator: One IT PPM Team Page 156 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Participants
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
One IT Project Management Process Guide
Tools/Techniques Summary Methods and Applications/Tools ITMS – http://www.itms.ford.com/ Refer to the ITMS tutorials on the same web site for instructions in the use of ITMS Project Record in MRS http://www.ads.ford.com/mrs GIRS MRS User and Quick Reference Guides are located at http://www.ads.ford.com/mrs/documentation.htm. An IT Systems Quick Reference For Project Managers and Application Managers is located at http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
Inputs to Process Records Retention Policies Project Deliverables Project Control File Records Retention Policies 225_archive_documents_checklist.doc
Outputs
Recipients
225_archive_documents_checklist.doc Updated ITMS Record at http://www.itms.ford.com/ Archived Work Products Project Record in RMS http://www.rms.ford.com Project Record in MRS http://www.ads.ford.com/mrs
Originator: One IT PPM Team Page 157 of 157 PM_Process_Guide.doc v2.3 Ford/Proprietary/Official/02.02 – Ford Internal Use Only
Control File, Metrics
Date Issued: 2002-Apr-12 Date Revised: 30Apr2004 Retention Period: C+3,T
Related Documents
Pm Process Guide
November 2019 6
Pm Pmbok Process Diagram
November 2019 16
Pm Startup Guide
May 2020 3
Guide To Refinery Process
July 2020 7
