PM Process Guide

Originator: One IT PPM Team of 157 Date Issued: 2002-Apr-12 PM_Process_Guide.doc v2.3 Date Revised: 30Apr2004 Ford/Proprietary/Official/02.02 – Ford Internal Use Only Retention Period: C+3,T

Project Management Process Guide

Production Version 2.3

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

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 1.0 04/12/2002 OneIT SDM Project

Team 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)


• Completed changes identified in pilot training and earmarked for version 1.1


• 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


Process Guide


Production 2.0.1 11/04/2002 SDM Development Team

• 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.

Production 2.1 SDM Development

Team • 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.

Production 2.2 August 14, 2003

EPMO – Program Governance Team

• 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) Prod 2.3 30Apr2004 Program

Governance Office • Portfolio Management – updated overview section with new Portfolio

Management Process.


Process Guide


Table of Contents

PURPOSE ......................................................................................................................................................................................... 6 PORTFOLIO MANAGEMENT .............................................................................................................................................................. 6 PORTFOLIO 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


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 EXECUTION ........................................................................................................................................ 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


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


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.

Figure 1.1 – The Three Dimensions of Project Management

ID & Assess

Analysis

Design

Build

Implement

Support

Integration

Scope

Quality

Time

Cost

Risk

Communications

Resources

Procurement

Typical Project

Life Cycle Project Management Knowledge Areas

Organizational Impact

Initiate Plan Execute Control Close

Project Management

Core Processes


Process Guide


Project Management Core Processes

Project management processes as defined by the Project Management Institute (PMI) are shown in figure 1.2 below.

Figure 1.2 - Core Project Management Processes

Initiate Project

Plan Project

Control Project

Close Project

Execute Project


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.


Process Guide


Typical Project Life Cycle

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.

Core

Project

Mgmt

Processes

Project Life Cycle

Initiate

Plan

Execute

Close

Control


Process Guide


Key Principles of Project Management

Key Principles will be placed in this section

Project objectives must be SMART Project objectives must be

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


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 non-compliance to process.

Satisfaction Surveys

Project team members, sponsors, and end users are surveyed


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:

Figure 1.4 Metrics captured over the project life cycle

ID &

Assess Analysis Design Build Implement Support &

Maintenance

Function Points per Staff Month

Time to Market (TTM) and TTM per 1000 FP

Schedule Variance

Cost Variance (Budgeted less Actual Cost of Work)

Defects per 1000 FP (Defects identified during inspections and testing)

Cost per Function Point

NCI per Review (Non-compliance issues identified in a Process Quality Assurance Review)

Support Cost per Function Point

Assignment Scope (FP/FTE)

Post Launch Incidents

Customer Satisfaction Scores


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).

• 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.

IT Management Tools

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:


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.


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.


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.


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 #55-10-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 / Role Acronym

Competency/Role Responsibilities Job Family

6-Sigma 6-Sigma Blackbelt This is a person trained in 6-Sigma DMAIC and DFSS processes. The 6-Sigma Blackbelt will work with the project 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.

General IT Management

ADSBusiness ADS Business Manager

Coordinates service rates, approval of project costs against account codes prior to project execution and billing of incurred project costs to account codes.



Process Guide




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.

Review architecture selection for compliance with Ford architecture principles and standards.

Architecture

APM/LOB Application Portfolio Manager/ LOB Manager

Coordinate application and support activities for a portfolio of applications, typically for one line of business.


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.

N/A

AppOwn Application Owner Customer with ultimate responsibility for application and related business processes. This person is registered on the ACR as the application owner.

N/A

AppSecAdmin Application Security Administrator

This is the person who administers security for an application and defines the type of access allowed.

N/A

AppSupr Application Supervisor

Provide oversight for maintenance of one or more applications.


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 Management (CDM) Analyst

Works as a liason between with project teams and the Data Center to select and allocate hardware and software for all technical environments (e.g.; development, QC, Education, Production, Support) in a timely manner.

Operations

Cust Business Customer(s)

Person(s) knowledgeable of all requirements and business 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.

N/A

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


Process Guide




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.

N/A

EUSupport End User Support Analyst

Provide consulting services, implementation services, production, operational and systems support for distributed 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.

End User Support

Facilities Facilities Analyst Coordinate overall planning, deployment and operations of facilities within computer centers.

Facilities

FGTI Intellectual Property attorney from Ford Global Technologies, Inc.

Review application and/or business processes and provide Customer with advice/guidance and support with respect to applying for patent.

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.


GAO GAO Prevention Control Specialist (GAO ACR reviewer)

Review ACR documents with the ICC and Application Owner to ensure that the application adheres to Ford security and maintenance standards.


ICC Internal Controls Coordinator

Provide support to project teams that are developing an ACR and/or ICR. This person will provide ongoing ACR coaching, 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.

End User Support

InfoArch Information Architect

Plan and design data and its relationship to business processes to ensure correct information boundaries, integrity, security, accuracy and the proper use of information.

Architecture

InfraArch Infrastructure Architect

Specifies the computing infrastructure and services needed to support the development and deployment of the solution, including the proper mix of commercial off-the-shelf products (COTS), hardware, and networking.

Architecture

IntTest Systems Integrator and Integration Tester

Lead integration and testing of application components into a completed application.

Solutions Development/QA

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 pre-defined set of questions.

Project/Program Management

ITET&D IT Learning – Education, Training and Development (ET&D)

Create application-specific training materials as well as provide the training on an as-needed basis.

End User Support


Process Guide




KE Knowledge Engineer

Develop strategy, provide expertise and long-range planning in the areas of it knowledge acquisition, capture, analysis, 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.

Knowledge Management

LDevl Lead Developer Guides and oversees development of application software components.


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 networks for a geographical area and the impacts to the rest of the global network. Assists with the design, evaluation, selection, and integration of networking technologies to meet the needs of the business.

Network Engineering

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, as well as advice and guidance with respect to legal issues, Office of General Counsel (OGC) Document and record Suspension Orders, etc.

N/A

Oper Data Center Operations

Perform daily data center operations support activities (backup, restore).

Operations

PGM Program Manager Direct all program -related activities. Initiates, plans executes, controls, and closes program, ensures requirements are 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, controls, and closes project, ensures requirements are 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 methodology selection, related processes and templates. 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 function, spanning the entire software development life cycle.


PSDevl Production Support Developer/Analyst

Support and maintain application – performs production 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

Works with project teams to acquire vendor-provided information, RFP/RFQ, and negotiate the acquisition of goods or services.

N/A

QCLead Quality Control Test A senior tester, with an understanding of test processes, templates and tools who may lead the development of the

Solutions


Process Guide




Lead Quality Control Test Plan and Strategy. Development/QA

QCTest Quality Control Test Specialist

Provide testing expertise and guidance, develop QC Test Strategy and Plan, develop and execute both functional and system tests.


RDM Resource Deployment Manager

The Resource Deployment Manager will manage a pool of ADS resources to ensure that they are being highly utilized as 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-capture, -retention and -reuse efforts on it projects.


SAE Specialized Application Engineering

Specialized Application Engineering

SCC Security Control Champion

The security control champion is organization-specific and will ensure that Ford's security needs are recognized and 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.


SCMTool SCM Tool Administrator

Install, configure and support software configuration management (SCM) tools, process, and procedures to ensure they are understood and followed .


SDevl Software Developer Participates in design activity and constructs, tests, and documents application system code under the guidance of the lead developer.


SecE Security Engineer 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.

Security Engineering

SIE Strategic Infrastructure Engineering Analyst (was called Ford Systems Integration Center / FSIC)

Work with one or more project team members to test an application to determine whether it is well behaved (e.g.; DLL's installed in correct location, DLL's are not over-written, etc.) and that it is compatible with the Ford Standard desktop.

Technology Analysis

SiteCRM Site Client Relationship Manager

Manage the application and technical environments at a site as well as act a liason between the Customer and application development/deployment and support teams.

End User Support

SME Subject Matter Expert

Person with sufficient knowledge of a business process as to be considered an expert on the subject who will provide guidance on an as -needed basis.

Business Analysis/ Reengineering

SolnArch Solution Architect Responsible for the assembly and integration of business processes, data, and application and infrastructure

Architecture


Process Guide




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.

N/A

Steering Steering Committee A group of individuals (e.g.; managers and subject matter 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 willreview project status on a periodic basis; provide guidance on an as -needed basis.

N/A

Supplier / Vendor

Any 3rd party or a representative of a 3rd party that is either supplying software or software services

Company outside of Ford that either directly or indirectly provides hardware, software, goods or services to or for Ford.

N/A

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 Technical Specialist, Technology Analyst

Individual with expertise in development Tools. Technology Analysis

UsabSpec Usability Specialist Evaluates an application's ease of use and suggests usability improvements. This individual can plan usability testing; 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.


Consult the One IT Competency Center Website at http://www.itonline.ford.com/home/it-prof/it-comp/ for additional information.


Process Guide



Process Guide


1.0 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

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).

Objective Process Steps PM Deliverable

1.1.1 Confirm Project Readiness to Start Readiness Confirmation 1.1.2 Identify and Engage Stakeholders Stakeholder Assessment 1.1.3 Engage Project Start-up Team Resource Request/Roster

1.1 Prepare for the Project

1.1.4 Develop Start-up Work Plan Work Plan for Initiation 1.2.1 Establish Project Control File Project Control File Setup 1.2 Establish PM

Infrastructure 1.2.2 Establish Project Procedures Procedures/Logs Started

1.3.1 Develop Initial Charter/Enhancement Request Commitment Level Charter

1.3.2 Develop Project Approach Methodology/Approach 1.3.3 Develop Quality Mgmt Plan Quality Mgmt Plan

1.3 Define the Project

1.3.4 Develop Communications Plans Communications Plan 1.4.1 Develop High-Level WBS Initial Work Breakdown 1.4.2 Develop Dependency Network Dependency Network 1.4.3 Estimate Effort High Level Estimates

1.4 Develop High Level Work Plan

1.4.4 Develop High-Level Schedule High Level Schedule 1.5.1 Complete Initial Risk Assessment Risk Assessment/Plan 1.5.2 Develop Initial SOW SOW

1.5 Complete Investment Analysis

1.5.3 Confirm/Refine the Business Case Financial Scope

1.6.1 Confirm Requirements/BOV Bus. Owner View Signoff 1.6 Confirm Readiness to Proceed 1.6.2 Obtain Initial Charter/Enhance. Req.

Sign-off Charter Approval Signoff

Project Proposal Executive Summary

Initial Business Case

Change Request Program

Charter

Inputs to Initiate Project

Solution Delivery

Methodology

Project Management Processes

Initiate

Plan

Execute

Control

Close


Process Guide


1.1 Prepare for the Project 1.1.1 Confirm Project Readiness to Start

Purpose 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:

• 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.

Diagram No diagram created for this process step.

Process Tasks

No Task Name Description Participants

1 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

PM, PracticeMgr, FinanceAnal


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:

• 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

PM, PracticeMgr, 6-Sigma

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 person 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


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 Outputs Recipients 241_Project_Proposal.doc 242_business_case.xls 231_Scalability_Classification_Questionnaire 243_program_charter.doc RMS – http://www.rms.ford.com

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

BusA, PQA, NLM


Process Guide


1.1.2 Identify and Engage Stakeholders

Purpose 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.


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 buy-in from them.

Diagram No diagram provided for this process.


Process Guide


Process Tasks


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:

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.

PM, BusA

3 Use Stakeholder Information to Plan Project

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 Outputs Recipients 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire Org Charts (if available)

201_stakeholder_assessment_template.doc ESpon, BusA


Process Guide


1.1.3 Engage Project Start-up Team

Purpose 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.


Key Considerations The key considerations when identifying team members are

• 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?


Process Tasks


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


Process Guide


Roster organization, their role, and the amount of time that they will be available.


Methods and Applications/Tools Skills needs assessment Microsoft Word Resource Request located at http://www.ads.ford.com/resman/

Inputs to Proce ss Outputs Recipients 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire 242_business_case.xls

Resource Request located at http://www.ads.ford.com/resman/ 203_team_directory_template.doc

Espon, BusA, Competency Center, Demand 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.


Key Considerations The key considerations for developing the Initiation work plan are

• Have timing constraints already been defined for Initiation?

• What is the availability of each resource assigned to participate in Project Initiation?


Process Tasks


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


Methods and Applications/Tools MS Project

Inputs to Process Outputs Recipients 241_Project_Proposal.doc 231_Scalability_Classification_Questionnaire 201_stakeholder_assessment_matrix.doc 203_team_directory_template.doc

229_Classic_SDM_Work_Plan.mpp Team


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.


Key Considerations

The key considerations in establishing a Project Control File are

• 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)?

Diagram No diagram provided for this process step.

Process Tasks


1 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:

• The Project Charter and Addendums • Project Plans • Issue, Risk and Change Logs • Change Requests • Communications Plans • Requirements Specifications • Assignments • Corrective Actions • Approvals • Procurement Documents

PM

2 Set Up Version Control Mgmt Tool(s)

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.

PM

3 Maintain Project Records

Ensure that project records are kept current while at the same time maintaining a complete project history.

PM



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 Outputs Recipients All Project Records Project Control File Control File,

Team


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.


Key Considerations No key considerations


Process Tasks


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


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 Outputs Recipients Project Control File 09_SCM_Plan.doc (for existing applications)

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/cgi-bin/dbchgreq.cgi

Control File


Process Guide


1.3 Define the Project

1.3.1 Develop Initial Charter/Enhancement Request

Purpose 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.


Key Considerations

Key considerations in developing the charter are

• 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?

Diagram No diagram created for this process.

Process Tasks


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,


Process Guide


multiple objectives that support that goal. Objectives must be measurable.

Stakeholders

3 Define Project Scope

Describe the scope as follows:

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.

PM, Sponsor, BusA, Team, Stakeholders

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


Process Guide



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.


Process Guide


1.3.2 Develop Project Approach

Purpose 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

• 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.


Process Tasks


1 Review Requirements

Review requirements, initial scope definition, and any technology decisions made to date.

PM, BusA, Cust, SysDesAn, SolnArch, PQA

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

PM, BusA, Cust, SysDesAn,


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.


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).


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


Process Guide



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 Recipients

241_Project_Proposal.doc

242_business_case.xls

231_Scalability_Classification_Questionnaire

200_project_charter_template.doc

02_Requirements_Specification.doc or 230_SDM_Enhancement_and_Small_Project_Request.doc

214_project_pqa_plan_template.doc


204_Accelerator_Use_Plan.doc

---

02_Requirements_Specification.doc or 230_SDM_Enhancement_and_Small_Project_Request.doc

Control File, Espon, Team


Process Guide


1.3.3 Develop Quality Management Plan

Purpose 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.


Process Tasks


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,


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


Methods and Applications/Tools Review of initial project charter and the guide for the selected solution delivery methodology. Microsoft Word

Inputs to Process Outputs Recipients 200_project_charter_template.doc Solution Delivery Methodology Process Guide 57_PQA_Review_Checklists.xls

200_project_charter_template.doc 214_project_pqa_plan_template.doc

Control File


Process Guide


1.3.4 Develop Communications Plans

Purpose 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.


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.

Corporate Executives

IT Customer Relationship Managers

IT Project Managers

Solution Architects

Developers

Business Managers

Users

Support Groups

Sponsor/Customer


Process Guide



Process Tasks


1 Identify Information to be Shared

Determine what should be shared/made available to stakeholders. For example:

• 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.

PM, BusA

2 Complete a Communications Plan Template

Using the Project Communications Plan Template record the following information for each communication planned:

• 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

PM

3 Review and File Plan

Review the Communication Plan with the Business Analyst and Project Team to assess completeness and file the Plan in the Project Control File.

PM, BusA, Team

4 Refine Plan as Needed

Refine the communication plan as project plans are finalized and changes occur.

PM


Methods and Applications/Tools Microsoft Word

Inputs to Process Outputs Recipients 200_project_charter_template.doc 201_stakeholder_assessment_template.doc

215_communication_plan_template.doc Control File, BusA, Cust


Process Guide


1.4 Develop High-Level Work Plan

1.4.1 Develop High-Level WBS Purpose 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:

• 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

Trigger Development of an initial charter.

Key Considerations The key considerations in developing the WBS are:

• 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?

Diagram The diagram below depicts the high-level process flow for this activity.

Process Tasks

Review Methodology for Existing

WBS

Project Charter

Requirements Specification

Solution Delivery

Methodology

WBS Pre-Defined?

Identify Work Activities to

Produce Deliverables

Decompose & Sequence

Work Activities

Ensure Completeness

No

Yes

Record WBS WBS Worksheet and/or MS Project

Plan

Project

Stage

Activity

Task

Note: The High-Level WBS generally stops at the Activity Level.


Process Guide



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.

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.

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


Methods and Applications/Tools Microsoft Word MS Project

Inputs to Process Outputs Recipients 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request

205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *

Control File BusA Team


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:

• 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.


Process Tasks


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


Process Guide



Methods and Applications/Tools Microsoft Word MS Project

Inputs to Process Outputs Recipients 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *

205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *

Control File BusA Team


Process Guide


1.4.3 Estimate Effort

Purpose 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.


Process Tasks


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.

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.

PM, BusA, Espon, Team, ImpA


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


Methods and Applications/Tools Microsoft Word MS Project Microsoft Excel

Inputs to Process Outputs Recipients 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp *

205_wbs_worksheet_template.doc 228_Classic_SDM_Estimating_Model.xls 229_Classic_SDM_Work_Plan.mpp

Control File, BusA, Team


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.


Process Tasks


1 Develop High-level 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


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 Outputs Recipients 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp

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/

Control File, BusA, Team


Process Guide


1.5 Complete Investment Analysis

1.5.1 Complete Initial Risk Assessment

Purpose 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.


Process Tasks


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.

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

PM, BusA, Team


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


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:

• Avoid (Eliminate the cause of negative events)

• Moderate impact (Define mitigation strategies and create contingency plans to follow if a negative events occurs)

• 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 fixed-price contract to transfer the risk of cost overrun)

• Accept the risk The E&Y Risk Management Strategies job aid contains specific recommendations for mitigating strategies for commonly encountered risks.

PM, BusA, Team

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.

PM


Process Guide



Methods and Applications/Tools Microsoft Word MS Project 207_risk_strategies_jobaid.pdf

Inputs to Process Outputs Recipients 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp

206_risk_assessment_template.xls 212_risk_management_log.doc

Control File, BusA, Team, Sponsor


Process Guide


1.5.2 Develop Initial SOW

Purpose 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:

• 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.


Process Tasks


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.

Submit the SOW for review and approval using the SOW Workflow Process (ADS Funding Authorization Workflow Process) and tool documented at that site.

PM


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


Methods and Applications/Tools Microsoft Word Microsoft Excel

Inputs to Process Outputs Recipients 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

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

Control File, BusA, Team, Sponsor


Process Guide


1.5.3 Confirm/Refine the Business Case

Purpose 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 High-Level 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.




Process Guide


Process Tasks


1 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:

• 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.

PM, BusA, Espon, FinanceAnal

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


Process Guide


Authorization Request /PAR in MEARS is updated.


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



230_Enhancement_and_Small_Project_Request

206_risk_assessment_template.xls

229_Classic_SDM_Work_Plan.mpp

SOW located at http://www.ads.ford.com

56_Process_Capability_Scorecard

PAR at the MEARS website http://www.finance.ford.com/mears/index2.html



56_Process_Capability_Scorecard.xls


230_SDM_Enhancement_and_Small_Project_Request.doc

241_Project_Proposal.doc

PAR at the MEARS website http://www.finance.ford.com/mears/index2.html

Control File, BusA, Team, ESpon, Finance Office, Stakeholders


Process Guide


1.6 Confirm Readiness to Proceed

1.6.1 Confirm Requirements/Business Owner View

Purpose 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.


Process Tasks


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



Process Guide


Methods and Applications/Tools Review of SDM deliverables

Inputs to Process Outputs Recipients 02_Requirements_Specification.doc 61_Business_Owner_View.doc

Confirmation of signed Business Owner View and Requirements Specification

Control File


Process Guide


1.6.2 Obtain Initial Charter/Enhance. Req. Signoff

Purpose 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?

• Are there significant risks attached to the project and do they outweigh potential benefits?

• How important is the project to the business?

• Is the project required to meet regulatory requirements?

• Will the resources and skills required to do the project be available when needed?

• Can timing constraints be met?

• Does the charter accurately capture the goal and objectives defined by the Sponsor and key stakeholders?

• Will the deliverables identified meet the Sponsor’s criteria for success?

• If the project is part of a program, is the charter completely aligned with the program charter?

• 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?


Process Tasks


Process Guide



1 Schedule & Conduct a Pre-Charter 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


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


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 Outputs Recipients 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

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/

Control File, Program Mgr, ESpon, Cust, Team Support Activities Competency Center Metrics


Process Guide



Process Guide


2.0 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



2.1.1 Develop Org Change Mgmt Plan Org Change Mgmt Plans

2.1.2 Develop Procurement Plans Procurement Plans

2.1.3 Develop Transition Plans Support and Launch Plan

2.1 Develop Project Management 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 Baseline Project Schedule

2.2.3 Refine Risk Management Plans Risk Management Plans

2.2.4 Refine Resource Requirements Resource Requests

2.2 Refine Work Plans and Budget

2.2.5 Refine The SOW Refined 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 Kick-off Metting

Project Charter

Business Case

High Level Plan

Business Owner View

Inputs to Plan Project

Requirements

Solution Delivery

Methodology


Initiate

Plan

Execute

Control

Close


Process Guide


2.1 Develop Project Management Plans

2.1.1 Develop Organizational Chg Mgt (OCM) Plan

Purpose 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 • 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/.


Process Tasks


1 Coordinate OCM activities

Ensure that OCM activities occur. See the Classic SDM Guide for details. Update the work estimates and workplans as appropriate.

PM


Methods and Applications/Tools MS Project Organizational Change Management techniques – see http://www.change-management.com/ for articles and books

Inputs to Process Outputs Recipients 200_project_charter_template.doc


215_communication_plan_template.doc






Control File, Program Mgr, BusA, Sponsor


Process Guide


2.1.2 Develop Procurement Plan

Purpose 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:

• 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.



Process Guide


Process Tasks


1 Complete Make/Buy Decision

Use cost/benefit analysis to determine if purchasing goods or services is the right approach.

PM, BusA, ESpon, SMEs

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:

• 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.

PM, BusA, SMEs

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.


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



Process Guide


decision.)

7 Make Decision

Make the final decision to purchase the goods or services and notify stakeholders as appropriate.


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


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 Outputs Recipients 200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request

Organization-specific procurement plan Control File, BusA, Purchasing, OGC


Process Guide


2.1.3 Develop Transition Plans

Purpose 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.


Key Considerations Key considerations for this process are:

• Will the application be implemented immediately or shelved pending completion of a related project or projects?

• 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?

• What additional coordination activities will be required because an outside vendor is involved?


Process Tasks


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:

• 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

PM, AppSupr, ImpA



Process Guide


Methods and Applications/Tools Microsoft Word and MS Project


217_transition_support_plan.doc 229_Classic_SDM_Work_Plan.mpp

Control File, BusA, Cust


Process Guide


2.1.4 Develop Resource Management Plans

Purpose 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.


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


Process Guide


§ 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.


Process Tasks


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


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.

PM


Process Guide




Skills assessment Resource Request located at http://www.ads.ford.com/resman/


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

Control File, BusA, Competency Center, Demand Management


Process Guide


2.2 Refine Work Plans and Budget

2.2.1 Refine Project Approach

Purpose 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 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.

Key Considerations

• 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.


Process Tasks


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,


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



Inputs to Process Outputs Recipients 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

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

Control File, BusA, Cust, Team


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.


Process Tasks


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


Update the project record in ITMS, RMS and MRS to reflect the updated schedule and file documents in project Control File.

PM





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

Control File BusA Cust Team


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.


Key Considerations

• Ensure that ability to achieve requirements, including CTQ's, are incorporated into risk management process.


Process Tasks


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



Process Guide


Methods and Applications/Tools Microsoft Word and MS Project eTracker at www.etracker.ford.com

Inputs to Process Outputs Recipients 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

206_risk_assessment_template.xls 212_risk_management_log.doc 200_project_charter_template.doc

Control File BusA Cust Team


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.


Key Considerations No key considerations provided for this process step.


Process Tasks


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


Process Guide



Methods and Applications/Tools Microsoft Word and Excel and MS Project Resource Request located at http://www.ads.ford.com/resman/

Inputs to Process Outputs Recipients 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

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

Control File, BusA, Cust, Team, Competency Center, Demand 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.


Key Considerations

• Only Ford employees are authorized to access the SOW. Non-Ford employees should work with their Practice Manager to modify it.


Process Tasks


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


Methods and Applications/Tools Microsoft Word and Excel MS Project



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



Process Guide



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 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.


Process Tasks


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


Process Guide


Requirements Specification

Control File folder.



Inputs to Process Outputs Recipients 200_project_charter_template.doc 02_Requirements_Specification.doc

200_project_charter_template.doc 02_Requirements_Specification.doc 230_Enhancement_and_Small_Project_Request

Control File


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.


Process Tasks


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



Inputs to Process Outputs Recipients 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

200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request 206_risk_assessment_template.xls



Process Guide


2.3.3 Conduct Formal Kick-off

Purpose 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

• Key considerations when planning and conducting the meeting include

o What decisions must be made before the meeting?

o What information will be distributed to attendees in advance? o What will be presented in the meeting? o 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.

Diagram The following diagram shows inputs and outputs for this activity.

Process Tasks


1 Identify Participants

Work with the Sponsor, the Practice Manager, and Business Analyst to determine who needs to be at the kick-off.

PM, PracticeMgr, Sponsor, BusA


Process Guide


2 Schedule Kickoff

Identify the date, time and place. Reserve the meeting room and any presentation equipment required.

PM

3 Develop Agenda

Introduction: Sponsor or Rep – Welcome address.

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.

PM, BusA, Sponsor

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


Process Guide



Process Guide




Inputs to Process Outputs Recipients 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

218_kickoff_meeting_checklist.doc 219_kickoff_meeting_agenda_template.doc

Control File, BusA, ESpon, Team, Stakeholders


Process Guide


3.0 Execute Project

Overview 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)

Process Contents

Objectives 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 Manage Project Execution

3.1.3 Direct & Coordinate Plan Execution Work Products

3.2.1 Maintain Project Records Documentation 3.2 Manage Project Information 3.2.2 Distribute Project Information Meeting Minutes,

Reports and Notices

Resource Plan

Procurement Plan

Inputs to Execute Project

Communication Plan

Budget Plan Transition

Plans Project Charter

Work Plan

Solution Delivery

Methodology


Initiate

Plan

Execute

Control

Close


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 co-located 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:

• 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?



Process Tasks


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,


Process Guide


Workstation and Development Environment

work begins. Team


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 Outputs Recipients 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

Move Request (see Tools Above) GIRS Tickets

Ford Land, Help Desk


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?

• 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. 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.

• 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.


Process Tasks


1 Identify Skills Create a two dimensional matrix. List the skills/knowledge needed on PM,


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).

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.

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


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/



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)

Control File, Competency Center, Resource Mgmt, Demand 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.


Process Tasks


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


Methods and Applications/Tools Microsoft Word and Excel, MS Project RMS-- http://www.rms.ford.com

Inputs to Process Outputs Recipients 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


Control File, ESpon, BusA, Cust, Team, Other Stakeholders


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.


Process Tasks


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.

Note: Keep project plans current by applying actuals hours and actual start and end dates on each task.

PM

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




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 Outputs Recipients 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

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

Control File, Stakeholders


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


Process Guide



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


Methods and Applications/Tools Microsoft Word Email Meetings eRoom Web Sites

Inputs to Process Outputs Recipients 201_stakeholder_assessment_template.doc 203_team_directory_template.doc 215_communication_plan_template.doc See also the SDM Process Guide

221_weekly_status_report_template.doc Results of reviews Approval to Proceed

Control File, Stakeholders


Process Guide



Process Guide


4.0 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 Processes Key Deliverables

4.1.1 Monitor and Control Scope Change Requests/Log

4.1.2 Monitor and Control Schedule/Costs Updated Plans

4.1.3 Monitor and Control Risks Risk Management Log

4.1.4 Monitor and Control Issues Issues Resolution/Log

4.1

Monitor and Control the Project

4.1.5 Monitor and Control Quality Checklists and Metrics

4.2.1 Conduct Status Reviews Status Reviews

4.2.2 Coordinate Architecture Reviews Architecture Rev. Results

4.2.3 Coordinate Metrics Workshops Function Point Counts

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 Go/No-Go Decisions

4.2 Conduct Project Reviews

4.2.7 Support Operations Reviews Input to Ops Reviews

Inputs to Control Project

Resource Plan

Procurement Plan Communication

Plan Budget Plan

Work Plans

Project Charter

Work Products

Solution Delivery

Methodology


Initiate

Plan

Execute

Control

Close


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

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? Diagram The diagram below depicts the high-level process flow for this activity.

Recommend a Course of

Action

Includes:

Project Charter

ITMS Record

Risk Assessment Budget Plan

Obtain Resources if

Required

Complete the Request

No

Yes

Log New Change Request

Updated Work Plan

Update Project Plans & Records

Change Approved

?

Obtain Approval

Close Request & Communicate

Status

Group Requests if Appropriate

Assign & Schedule

Investigation

Investigate Change Request

Updated Records/ Plans

Updated Change Log

Resource Request

Change Requested


Process Guide


Process Tasks


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.

• 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)

PM

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


Process Guide



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 Outputs Recipients 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

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

ESpon, Program Mgr, BusA, Stakeholders, Competency Center, Resource Mgmt, Demand Mgmt


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

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?


Process Tasks


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.

Note: A SPI or CPI lower than 1 indicates a problem

PM

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.

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

PM, Team, Program Mgr


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.

Note: Using reserves, overtime, or additional resources, or rescheduling the project, as a solution, will require approval.

PM, Sponsor

7 Update & Close Issue

Update project plans, as appropriate, and update and close the issue. PM


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 Outputs Recipients 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

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

ESpon, Program Mgr, BusA, Stakeholders, Competency Center, Resource Mgmt, Demand Mgmt


Process Guide


4.1.3 Monitor and Control Risks

Purpose 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:

• 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.


Process Tasks

Develop Plans to Manage

Track & Control

Risk

Assess the Risk

Updated Risk Log & Plans

Risk Under

Control?

Yes

Close Risk & Update Plans

No Log Risk

Risk Resolved

?

No

Yes

Raise Issue

New Risk Identified

Weekly Status Review


Process Guide



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


Methods and Applications/Tools MS Project

Inputs to Process Outputs Recipients 206_risk_assessment_template.xls 206_risk_assessment_template.xls Sponsor 212_risk_management_log.doc 212_risk_management_log.doc Program Mgr 207_risk_strategies_jobaid.pdf 213_issue_log.doc or eTracker located at

http://www.etracker.ford.com/ BusA

229_Classic_SDM_Work_Plan.mpp Sponsor


Process Guide


4.1.4 Monitor and Control Issues

Purpose 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?


Monitor Issue Status

Issue Resolv

ed?

Develop Resolution Strategy

Yes

Updated Issue Log

No

Log Issue

Close Issue

Scope Change

Required?

Submit Change Request

Resolve or Escalate

Issue

No

Yes

Assign To Resource for Resolution

Updated Work Plan

Issue Identified

Weekly Status Review


Process Guide


Process Tasks


1 Identify & Log Issue

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.

Stakeholders

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


Methods and Applications/Tools http://www.etracker.ford.com/ MS Project

Inputs to Process Outputs Recipients 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

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


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.


Monitor Process &

Deliverables

Results Acceptable

?

Rework or Improvement Required?

No

Yes

No

Yes

Project Plans & Deliverables

Methodology/ Quality

Standards

Determine Course of

Action

Implement Rework or

Improvement

Record Results

Analysis Design Build 0

20

40

60

80

100

120

Source: International Institute of Learning

Implement


Process Guide


Process Tasks


1 Monitor Process & Deliverables

Inspect deliverables and monitor the performance of required processes.

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.

PM, Team

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.


Process Guide


Adds a defect, status=“New”

Is it a defect?

Will it be addressed in the current release?

Assign the defect to a developerstatus = “open”

Developer fixes the defect, status=“fixed”

Rebuild the deliverable and roll to the test environment where the

developer verifies the fix, status=rolled

Update test cases as needed, test the fix in test environment

Status=“Closed”

The defect is rejected, status=Rejected

Convinced with this resolution?

Status=“Rejected”

Status=“Reopen”

B

Defect Management Process Flow

The defect is deferred,

Status=“Deferred”

YesNo

Defect Still Exists

B

Was the defect associated with a

change?

Root Cause ChangeFollow the Change Management

Process

No

Yes

Yes

No

A Current/New/Old found?

NewDefect

Defect Closed

A

Yes

Done

No


1 Log Defect 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

Person who found the defect

2 Analyze Defect Analyze the defects reported and change their status to either - 'Open', 'Deferred' or 'Reject'.

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

PM, LDevl, QCTest

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


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

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'

SDevl

6 Test Application 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'.

If the defect is addressed (not seen) – change the status to 'Closed'. If a new defect is discovered, then log as "New".

QC Team, BusA, Sdevl, Cust (e.g.; who ever raised the defect)

7 Update Defect Status

If a defect is 'Re-Opened' – all steps from step 2 are repeated. QC Team, BusA, Sdevl, Cust (e.g.; who ever raised the defect)


Process Guide




eTracker at http://www.etracker.ford.com/

MS Project


212_risk_management_log.doc

213_issue_log.doc


233_Gate_Review_Checklists.xls

239_PQA_Review_Report.doc

32_Defect_Log or Test Director

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


213_issue_log.doc or eTracker

Acceptance Decisions

Defects in 32_Defect_Log or Test Director

Process Adjustments

Control File, Program Mgr, BusA, ESpon, Team, Metrics


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:

• 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?

Diagram 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.


Process Guide


Process Tasks


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.

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

PM, Cust

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews

Director Ops Reviews

Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage

From Project Manager to IT Manager andBusiness Partner

Architecture•ARB Health•Occurs for ID & Assess, Analysis, & Design Stages•Once per Stage

During SDM 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

WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN


Process Guide



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.

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


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


Green Red Yellow

Target dates & deliverables are on track

Recovery Plan is in Place

YES

Recovery Plan is Resourced

Recovery Plan Approved by Stakeholders

Recovery on Track Since Last Review

YES YES YES NO

NO NO NO NO YES


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

Control File, Program Mgr, BusA, ESpon, Cust


Process Guide


4.2.2 Coordinate Architecture Reviews Purpose 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.

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN


Process Guide


Process Tasks


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


Ensure that review documentation is stored in the project Control File as appropriate.

PM


Methods and Applications/Tools 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 Recipients ARB review meeting minutes in 220_meeting_minutes_template.doc

73_ARB_Workbook.xls completed to appropriate level in system development lifecycle.

ARB review meeting minutes in 220_meeting_minutes_template.doc

Update 73_ARB_Workbook.xls

See SDM Guide


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.


Process Tasks


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


Ensure that workshop documentation is stored in the project Control File as appropriate.

PM


Methods and Applications/Tools Classic_SDM_Process_Guide

Inputs to Process Outputs Recipients Metrics meeting minutes in 220_meeting_minutes_template.doc

Metrics meeting minutes in 220_meeting_minutes_template.doc

See SDM Guide


Process Guide


4.2.4 Coordinate Security Reviews & Certification

Purpose 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

• 3rd party products need to go through the SIE certification test if there is no prior SIE certification

See the Solution Delivery Methodology Guide for details of these reviews.


Process Tasks


1 Verify Submissions/ Registrations

Verify that the appropriate submissions and registrations have been completed.

PM

2 Coordinate Scheduling

Coordinate scheduling of review sessions. PM

3 Participate in Make self and team members available for participation in the review SCC,


Process Guide



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.

PM, Team, Reviewers as appropriate

4 Monitor Resolution of Issues

Monitor completion of the changes identified in the session or issues that need to be resolved.

PM

5 Verify final approval

Verify that final approval is obtained prior to launch and archive records.

PM



Inputs to Process Outputs Recipients Security review meeting minutes in 220_meeting_minutes_template.doc

Security review meeting minutes in 220_meeting_minutes_template.doc

See SDM Guide


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.

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN


Process Guide


Process Tasks


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


Ensure that review documentation is stored in the project Control File as appropriate.

PM



Inputs to Process Outputs Recipients PQA review meeting minutes 239_PQA_Review_Report.doc See SDM Guide


Process Guide


4.2.6 Lead Gate/Tollgate Reviews

Purpose 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:


Process Guide


• Have all deliverables of the stage been completed?

• 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?

• Must any outstanding issues be resolved, before the project can proceed?

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.

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN


Process Guide


Process Tasks


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.

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.

PM

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

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.

PM, BusA Cust Program Mgr

5 Conduct Review

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.

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)

• 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.

PM, BusA, Cust

As necessary: ESpon, AppOwn, Program Mgr, PQA, AMCoord, PM for related projects, APM/LOB, Practice Mgr, 6-Sigma, Stakeholders, Vendor/Supplier


Process Guide



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.

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.

PM


Store minutes and other documentation of the review in the project Control File. Update the project record in ITMS, RMS and MRS.

PM


Process Guide




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




Results of ARB Reviews

Results of PQA Reviews


206_risk_assessment_template.xls

211_change_request_template.doc


213_issue_log.doc


221_weekly_status_report_template.doc


Current Earned Value Report


211_change_request_template.doc

220_meeting_minutes_template.doc

221_weekly_status_report_template.doc

233_Gate_Review_Checklist

Go/No-Go Decision / Recommendation to Terminate (if appropriate)

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

BusA, Control File, Cust, IT Management, Stakeholders, Team, ITMS, ESpon


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 Considerations

No key considerations specified for this process.

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).

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN

To CBG/GEC Exec

From IT Manager

To Business Manager

CIO Ops Reviews


Manager Ops Reviews

Project Reviews

To PSC

Gate Reviews

Quarterly

Quarterly

Monthly

CIOFrom

Director

IT MANAGER

IT DIRECTOR

At End of SDM Stage







WHATWHEN


Process Guide


Process Tasks


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


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 Outputs Recipients 221_weekly_status_report_template.doc Project Control File Results of Gate Reviews Results of ARB Reviews Results of PQA Reviews

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/

Control File, Sponsor, IT Management, Cust


Process Guide



Process Guide


5.0 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



5.1.1 Finalize Implementation Implementation as Planned 5.1 Finalize Delivery

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 Lessons Learned/Metrics

5.2

Conduct Final Project Review

5.2.3 Prepare Closure Report Completion Documents

5.3.1 Release Resources Released Resources

5.3.2 Complete Financial Closure Budget/Contract Closure

5.3 Perform Administrative and Financial Closure

5.3.3 Close & Archive Records Closed/Archived Records

Inputs to Close Project


Initiate

Plan

Execute

Control

Close

Resource Plan

Procurement Plan Communication

Plan Budget Plan

Work Plans

Project Charter

Work Products

Solution Delivery

Methodology


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:

• 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?

Diagram No diagram provided for this process

Process Tasks


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


Update project records to reflect that implementation plans have been executed as appropriate.

PM


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 Outputs Recipients Implementation Plans Project Record in RMS http://www.rms.ford.com

Project Record in MRS http://www.ads.ford.com/mrs Control File, AppSupr


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.


Key Considerations

Key considerations for this process step include:

• 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?


Process Tasks


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


Update project records to reflect that transition plans have been executed as appropriate.

PM


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 Outputs Recipients 217_transition_support_plan.doc 217_transition_support_plan.doc Control File,

AppSupr


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:

• Which Customers will be asked to complete a Satisfaction Survey?

• How much time will Customers be given to complete the survey?

• If the project in question a pilot project?


Process Tasks


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


Process Guide




Microsoft Word / Project Record in MRS http://www.ads.ford.com/mrs




201_stakeholder_assessment_template.doc

203_team_directory_template.doc

Major Release Survey

85_QC_Final_Report_Metrics_Spreadsheet located at QC web site http://www.sdg.ford.com/qc/

84_QC_Final_Report_Management_Summary located at QC web site http://www.sdg.ford.com/qc/

ESpon (s), Cust(s), Team, Metrics


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.


Key Considerations

The key questions to be addressed in the final assessment are:

• What went right and why?

• What went wrong and why?

• How well did the methodology work to guide the project?


Process Tasks


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:

• What was really created versus what was planned?

• Did the deliverables comply with the Customers’ and sponsors’ acceptance criteria?

• Were there deviations from the project plan?

• Why did the deviations occur?

• Could they have been avoided?

PM, Team, Metrics

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.

• Were the right people/skill-sets on the team?

PM, Team


Process Guide



• 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


Methods and Applications/Tools Microsoft Word Brainstorming Facilitated Session

Inputs to Process Outputs Recipients 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

211_change_request_log.doc 212_risk_management_log.doc 213_issue_log.doc 222_lessons_learned.doc 220_meeting_minutes_template.doc

Team, Metrics


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


Process Tasks


1 Create Project Closure Report

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).

Acknowledgements:

Acknowledge individuals who have made special contributions to the project.

PM

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



Process Guide



Inputs to Process Outputs Recipients 200_project_charter_template.doc 229_Classic_SDM_Work_Plan.mpp 222_lessons_learned.doc

223_closure_report_template.doc 224_completion_notification_template.doc

Control File, ESpon, Cust, Local Mgmt


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:

• 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?

Diagram No diagram provided for this report.

Process Tasks


1 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).

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.

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



Process Guide


Methods and Applications/Tools Microsoft Word Interim Resource Management Process http://www.ads.ford.com/resman/

Inputs to Process Outputs Recipients 203_team_directory_template.doc 223_closure_report_template.doc

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

• 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?


Process Tasks


1 Confirm the Closure or Completion Date

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

PM

Project Schedule

Project Contracts

Budget Plan

Project Closure Report

Communicate Project Closure

Close Charge Codes

Confirm Contract Fulfillment

Contract Fulfilled?

Close Contract Resolve Contract Issues

Yes

No

Confirm Project Completion

Date


Process Guide



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.

• 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.

PM

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


Process Guide



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 Outputs Recipients 229_Classic_SDM_Work_Plan.mpp 223_closure_report_template.doc

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/

Control File, Purchasing, OGC, Demand Management, MRS Plans Database


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

• 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?

Diagram No Diagram provided for this process

Process Tasks


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


Process Guide



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 Outputs Recipients Records Retention Policies Project Deliverables Project Control File Records Retention Policies 225_archive_documents_checklist.doc

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

Control File, Metrics

PM Process Guide

Documents

Transcript of PM Process Guide