PM Process Guide

Project Management
Process Guide
Production Version 2.3
Originator: One IT PPM Team Page 1 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
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 Draft 1.04 Release
Team § 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 Production Release
Team • 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 • Noted possibility that the project may have been the result of a number of
Team change requests being bundled together to produce a new application
release. May note of this in Section 1.1.1 Confirm Project Readiness
(CR#782)
• Added task in Section 1.1.1 Confirm Project Readiness for completion of the
PQA Metrics Sizing Profile Template (CR#782)
Production 1.1 05/08/2002 OneIT SDM Project • Completed changes identified in pilot training and earmarked for version 1.1
Team
Production 1.2 05/21/2002 OneIT SDM Project • Completed changes identified in detailed training and earmarked for version
Team 1.2
Production 1.2.1 06/05/2002 SDM Manager, • Completed changes identified in detailed training and earmarked for version
TPMO 1.2.1
Production 1.3 06/26/2002 SDM Manager, • Completed changes to match new RMS process as well as changes identified
TPMO during Classic SDM detailed training.
Production 1.3.1 07/18/2002 SDM Project Team, • Completed changes related to new RMS process. Change project/program
TPMO data entry from ProSight to ITMS.
• Updated Review Pyramid Diagram.
Production 2.0 08/05/2002 SDM Project Team, • CR #1456: incorporate that Project Appropriation Request / PAR process in
TPMO 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 • CR #1576. Per Mark Bradford, beginning Sunday, November 3rd, 2002 the
Team 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 • CR #272077: synchronized role descriptions in SDM Guide and PM Guide
Team • 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, EPMO – Program • Gate Review ICRP Control Concern – obtain signatures of decision-makers to
2003 Governance Team confirm accountability (Section 4.2.6)
• PQA Strategy update – direct PM to PQA web site (Section 1.1.1)
Prod 2.3 30Apr2004 Program • Portfolio Management – updated overview section with new Portfolio
Governance Office Management Process.

Process Guide
Table of Contents
PURPOSE ......................................................................................................................................................................................... 6
PORTFOLIO MANAGEMENT .............................................................................................................................................................. 6
PORTFOLI O MANAGEMENT PROCESS FLOW ................................................................................................................................... 6
DEFINITION OF PROJECT MANAGEMENT ......................................................................................................................................... 7
PROJECT MANAGEMENT CORE PROCESSES .................................................................................................................................. 8
PROJECT MANAGEMENT KNOWLEDGE AREAS ................................................................................................................................ 9
THE PROJECT LIFE CYCLE .............................................................................................................................................................. 9
PM ALIGNMENT TO TYPICAL PROJECT LIFE CYCLE ....................................................................................................................... 9
KEY PRINCIPLES OF PROJECT MANAGEMENT............................................................................................................................... 11
Project objectives must be SMART ................................................................................................................... 11
Understanding and managing requirements is crucial ............................................................................ 11
Planning is everything and ongoing ................................................................................................................... 11
Control is a necessity, not a luxury .................................................................................................................... 11
Customers must be part of the process .......................................................................................................... 11
Providing an honest assessment of project health is critical................................................................ 11
We know what works, just do it............................................................................................................................ 11
Metrics should be collected throughout the project life cycle............................................................... 11
PURCHASED PACKAGE SELECTION AND IMPLEMENTATION (PPSI) .............................................................................................. 14
IT MANAGEMENT TOOLS ............................................................................................................................................................... 14
GAO AUDIT GUIDELINES .............................................................................................................................................................. 17
PROJECT AUTHORIZATION REQUESTS AND PURCHASE ORDERS................................................................................................. 17
PROCESS PARTICIPANT ROLES ..................................................................................................................................................... 18
1.0 INITIATE PROJECT ......................................................................................................................................................... 25
1.1 PREPARE FOR THE PROJECT............................................................................................................................................ 26
1.1.1 Confirm Project Readiness to Start.................................................................................................................... 26
1.1.2 Identify and Engage Stakeholders..................................................................................................................... 29
1.1.3 Engage Project Start-up Team............................................................................................................................ 31
1.1.4 Develop Start-up Work Plan................................................................................................................................ 33
1.2 ESTABLISH PM INFRASTRUCTURE ................................................................................................................................... 34
1.2.1 Establish Project Control File .............................................................................................................................. 34
1.2.2 Establish Project Procedures.............................................................................................................................. 36
1.3 DEFINE THE PROJECT....................................................................................................................................................... 38
1.3.1 Develop Initial Charter/Enhancement Request................................................................................................ 38
1.3.2 Develop Project Approach................................................................................................................................... 41
1.3.3 Develop Quality Management Plan.................................................................................................................... 44
1.3.4 Develop Communications Plans......................................................................................................................... 46
1.4 DEVELOP HIGH -LEVEL WORK PLAN ................................................................................................................................. 48
1.4.1 Develop High-Level WBS .................................................................................................................................... 48
1.4.2 Develop Dependency Network ........................................................................................................................... 50
1.4.3 Estimate Effort ....................................................................................................................................................... 52
1.4.4 Develop High-Level Schedule............................................................................................................................. 54
1.5 COMPLETE INVESTMENT ANALYSIS .................................................................................................................................. 55
1.5.1 Complete Initial Risk Assessment...................................................................................................................... 55
1.5.2 Develop Initial SOW.............................................................................................................................................. 59
1.5.3 Confirm/Refine the Business Case.................................................................................................................... 61
1.6 CONFIRM READINESS TO PROCEED ................................................................................................................................. 64
1.6.1 Confirm Requirements/Business Owner View................................................................................................... 64
1.6.2 Obtain Initial Charter/Enhance. Req. Signoff.................................................................................................... 66
2.0 PLAN PROJECT............................................................................................................................................................... 69
2.1 DEVELOP PROJECT MANAGEMENT PLANS ........................................................................................................................ 70
2.1.1 Develop Organizational Chg Mgt (OCM) Plan ................................................................................................. 70
2.1.2 Develop Procurement Plan.................................................................................................................................. 71
2.1.3 Develop Transition Plans..................................................................................................................................... 74
2.1.4 Develop Resource Management Plans............................................................................................................. 76
2.2 REFINE WORK PLANS AND BUDGET ................................................................................................................................. 80

Process Guide
2.2.1 Refine Project Approach ...................................................................................................................................... 80
2.2.2 Refine Work Plans................................................................................................................................................ 82
2.2.3 Refine Risk Management Plans.......................................................................................................................... 84
2.2.4 Refine Resource Requirements.......................................................................................................................... 86
2.2.5 Refine the SOW..................................................................................................................................................... 88
2.3 CONFIRM READINESS TO PROCEED ................................................................................................................................. 90
2.3.1 Confirm Requirements Specification Signoff.................................................................................................... 90
2.3.2 Obtain Final Charter Approval............................................................................................................................. 92
2.3.3 Conduct Formal Kick -off....................................................................................................................................... 93
3.0 EXECUTE PROJECT....................................................................................................................................................... 97
3.1 MANAGE PROJECT E XECUTION ........................................................................................................................................ 98
3.1.1 Acquire/Release Facilities & Equipment........................................................................................................... 98
3.1.2 Acquire/Release Team Members..................................................................................................................... 100
3.1.3 Direct & Coordinate Plan Execution................................................................................................................. 103
3.2 MANAGE PROJECT INFORMATION ................................................................................................................................... 104
3.2.1 Maintain Project Records................................................................................................................................... 104
3.2.2 Distribute Project Information............................................................................................................................ 106
4.0 CONTROL PROJECT.................................................................................................................................................... 109
4.1 MONITOR AND CONTROL THE PROJECT ......................................................................................................................... 110
4.1.1 Monitor and Control Scope................................................................................................................................ 110
4.1.2 Monitor and Control Schedule/Costs............................................................................................................... 113
4.1.3 Monitor and Control Risks.................................................................................................................................. 115
4.1.4 Monitor and Control Issues................................................................................................................................ 117
4.1.5 Monitor and Control Quality............................................................................................................................... 119
4.2 CONDUCT PROJECT REVIEWS........................................................................................................................................ 124
4.2.1 Conduct Status Reviews .................................................................................................................................... 124
4.2.2 Coordinate Architecture Reviews ..................................................................................................................... 128
4.2.3 Coordinate Metrics Workshops......................................................................................................................... 130
4.2.4 Coordinate Security Reviews & Certification.................................................................................................. 131
4.2.5 Coordinate PQA Reviews .................................................................................................................................. 133
4.2.6 Lead Gate/Tollgate Reviews ............................................................................................................................. 135
4.2.7 Support Operations Reviews............................................................................................................................. 140
5.0 CLOSE PROJECT.......................................................................................................................................................... 143
5.1 FINALIZE DELIVERY......................................................................................................................................................... 144
5.1.1 Finalize Implementation..................................................................................................................................... 144
5.1.2 Finalize Transition............................................................................................................................................... 145
5.2 CONDUCT FINAL PROJECT REVIEW................................................................................................................................ 146
5.2.1 Administer Major Release Survey.................................................................................................................... 146
5.2.2 Conduct Wrap-up Session................................................................................................................................. 148
5.2.3 Prepare Closure Report..................................................................................................................................... 150
5.3 PERFORM ADMINISTRATIVE AND FINANCIAL CLOSURE................................................................................................... 152
5.3.1 Release Resources.............................................................................................................................................. 152
5.3.2 Complete Financial Closure................................................................................................................................ 153
5.3.3 Close & Archive Records................................................................................................................................... 156

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 Programs and projects originate within the Portfolio Management

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 is defined as directing the activities

Project associated with executing a project, while controlling limited
resources efficiently and effectively, and ensuring the project’s end
Management goal is achieved successfully.
As shown in figure 1.1 below, projects can be viewed in three dimensions. The
Project Life Cycle axis describes the work to be done to deliver the product. The
Project Management Core Processes axis delineates the five processes that must
be performed to plan, manage and conclude projects. The Project Management
Knowledge Areas axis lists ten areas of responsibility that must be addressed by
the project manager while managing the project. Each of the three dimensions is
discussed in more detail below.
Typical Project
Life Cycle
Project Management
Support Knowledge Areas
Resources
Implement
Procurement
Cost
Build Organizational Impact

Time
Design Scope Communications
Integration Quality
Analysis
Risk
ID & Assess
Initiate Plan Execute Control Close
Project Management
Core Processes
Figure 1.1 – The Three Dimensions of Project Management

Process Guide
Project Project management processes as defined by the Project Management Institute

Management (PMI) are shown in figure 1.2 below.
Core
Processes Initiate
Project
Plan
Project
Control Execute
Project Project
Close
Project
Figure 1.2 - Core Project Management Processes

Process Guide
Project The ten project management knowledge areas, shown in figure 1.1
Management and described below, represent what the project manager manages
while executing the project management processes.
Knowledge Areas
Integration Ensure that all elements of the project are coordinated

Management: properly and included in project plans. This includes
hardware, software, networks, training, etc.
Scope Ensure that the project includes all of the work
Management: required and only the work required to complete the
project successfully, including scope planning, scope
definition, scope verification and change management.
Quality Ensure that the project will satisfy the requirements
Management: that have been agreed and that quality assurance and
quality control processes are completed.
Time Ensure timely completion of the project by defining and
Management: managing tasks to be completed, the sequencing of
work, the resources assigned, task durations, and the
project schedule.
Cost Ensure that the project is completed within the
Management: approved budget by estimating, monitoring and
controlling project costs.
Risk Identify, assess and mitigate project risks associated
Management: with factors such as new technology, very tight
schedule constraints, lack skilled resources, and
readiness of the user organization to accept the
change.
Communication Provide timely and appropriate generation and
Management: dissemination of project information to management
and all other stakeholders to ensure that their
expectations are consistent with the realities of the
project.
Organizational Identify organizational changes that must occur and
Impact develop appropriate communication and training
Management: programs for impacted departments and staff to
support the new system or change.
Resource Provide effective leadership and management of the
Management: project team, including project organizational planning,
Staff Requisition, and team development.
Procurement Acquire goods and services from outside vendors as
Management: needed by planning procurement, preparing requests
for quotes, making source selections, and negotiating
and administering contract negotiation.
The Project IT projects are divided into stages that make up the project life cycle. Each
Life Cycle 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
Project Life
Cycle
Initiate
Plan
Core
Project
Execute
Mgmt
Processes
Control
Close
Figure 1.3 – Project Management alignment to Project Life
As this diagram shows, elements of Execute and Control occur at each stage of the
project. It is, therefore, recommended that the reader refer to the Execute and Control
sections throughout the project life cycle and take action, as needed, to acquire
resources, monitor and control project performance, and review and approve project
deliverables.

Process Guide
Key Key Principles will be placed in this section

Principles of Project objectives must be SMART
Project
Project objectives must be
Management Specific -- clear and precise
Measurable -- quantifiable
Achievable – realistic
Relevant – linked to business needs
Time-based – defined by clear deadlines
Understanding and managing requirements is crucial

Each requirement should be traceable to a specific project objective described in
the Project Charter. The ability to trace planned and completed requirements
assures that the delivered product will satisfy Customer needs and will not include
inappropriate or extraneous functionality.
Planning is everything and ongoing

The single most important activity that project managers engage in is planning --
detailed, ongoing, systematic, team-involved plans are the true foundation for
project success.
Control is a necessity, not a luxury

Schedule and cost overruns, issues that go unresolved, risks that are not mitigated,
and changes that are made to plans and deliverables without adequate review and
approval will inevitably lead to project failure. This is why rigorous monitoring and
control is an absolute necessity and a key role of the Project Manager.
Customers must be part of the process

Customers demand the right to approve deliverables. Along with that authority
comes the responsibility to be active participants in the project. It’s the Project
manager’s job to ensure that Customers understand what is expected of them and
that they are kept informed and active through out the project life cycle.
Providing an honest assessment of project health is critical
Assessing project health opening and honestly on a regular basis is critical to the
successful management of the Ford IT portfolio. For sponsors and management
to make the right decision about a project's future, it must have accurate
information about the state of that project.
We know what works, just do it
We know what works. Methodologies like those described here today
ensure that standards and best practices are built into project plans and
deliverables. Not only do these methodologies support quality, they help
minimize rework.
Metrics should be collected throughout the project life cycle

Metrics should be collected throughout the project life cycle and used to help
manage and evaluate productivity, timing, cost, and quality. A good metrics program
will enable better trend analysis and more effective process improvement.
The following are the OneIT recommended metrics to be captured and reported
Function Function Points are a measure of the functionality delivered by
Points (FP) 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 Function Points per unit of work is a measure of productivity.
Points per Function Points are estimated during the Analysis and Design
Staff Month stages, and a final count is done at the end of the Build stage.
Time to Time to Market is a measure of speed of delivery. TTM per
Market, TTM 1000 Function Points provides a way to evaluate speed of
per 1000FP delivery for projects of differing sizes.
Schedule Start and End Dates for each stage are documented in the
Variance 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 The maintainability of an application is measured by dividing
per FP support costs by the number of function points calculated for
the supported application.
Assignment Assignment scope is defined as the number of function points
Scope supported divided by the number of full-time equivalents
supporting the application.
Defects per Defects are non-conformance to requirements. They are
1000FP 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 Non-compliance issues are identified in the Process Quality
Review 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 Project team members, sponsors, and end users are surveyed
Surveys

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 A number of variables need to be considered when evaluating
Variables project metrics. Some important variables include:
• Technology Platform
• Development Type (New Development, Enhancement,
Purchased Package, etc)
• Complexity
The following diagram illustrates the metrics collected during a typical project's life cycle:
ID & Support &

Analysis Design Build Implement
Assess Maintenance
Function Points per Staff Month Support Cost per

Function Point
Time to Market (TTM) and TTM per 1000 FP
Assignment
Schedule Variance Scope (FP/FTE)
Cost Variance (Budgeted less Actual Cost of Work)

Post Launch
Incidents
Cost per Function Point
Defects per 1000 FP (Defects identified during inspections and testing)
NCI per Review (Non-compliance issues identified in a Process Quality Assurance Review)
Customer Satisfaction Scores
Figure 1.4 Metrics captured over the project life cycle

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 Process changes and special considerations have been incorporated to address the
Package selection and implementation of purchased products, including:
Selection and • Procurement-related processes include considerations for working with 3 rd party
vendors.
Implementation
(PPSI) • 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 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
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 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
Guidelines 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 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
Authorization part has been approved. For most operations, funding for the specific action is authorized by
Requests and an approved "Project Appropriation Request / PAR", including a standard set of project detail
Purchase Orders 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 / Competency/Role Responsibilities Job Family
Role Acronym
6-Sigma 6-Sigma Blackbelt This is a person trained in 6-Sigma DMAIC and DFSS General IT
processes. The 6-Sigma Blackbelt will work with the project Management
team in the design of business processes and ensure that
those processes will achieve Customer CTQ's. It is expected
that all Business Analysts will eventually have Greenbelt or
Blackbelt certification. Until a critical mass of 6-Sigma
certified Business Analysts has been achieved, the Classic
SDM Guide will treat the 6-Sigma role as an additional
consultant on the project team.
ADSBusiness ADS Business Coordinates service rates, approval of project costs against General IT
Manager account codes prior to project execution and billing of incurred Management
project costs to account codes.

Process Guide
Role Acronym
ADSMgt ADS Management ADS Manager with profit and loss responsibility for a project General IT
Management
AMCoord Architecture Review architecture selection for compliance with Ford Architecture
Management architecture principles and standards.
Coordinator.
Ensure that the
project team
adheres to Ford
corporate
architecture
principles.
APM/LOB Application Portfolio Coordinate application and support activities for a portfolio of General IT
Manager/ LOB applications, typically for one line of business. Management
Manager
AppDataAdmin Application Data This is the person who has oversight responsibility for N/A
Administrator application data, including data integrity, adherence to the
retention period as defined by GIS1 standards.
AppOwn Application Owner Customer with ultimate responsibility for application and N/A
related business processes. This person is registered on the
ACR as the application owner.
AppSecAdmin Application Security This is the person who administers security for an application N/A
Administrator and defines the type of access allowed.
AppSupr Application Provide oversight for maintenance of one or more General IT
Supervisor applications. Management
AppTechArch Application Plan and design of application platform technology patterns, Architecture
Technology usage standards, and guidelines used to implement IT
Architect solutions. Extend existing architectures to satisfy changing
application needs.
BusA Business Analyst Work with Customer to identify and documenting Business
requirements, perform business process design, measure Analysis/
process capability, and perform Acceptance Test with Reengineering
Customer.
CDBA Corporate / Data Install and configure database products. Database
Center Database Administration
Administrator
CDM Capacity Demand Works as a liason between with project teams and the Data Operations
Management (CDM) Center to select and allocate hardware and software for all
Analyst technical environments (e.g.; development, QC, Education,
Production, Support) in a timely manner.
Cust Business Person(s) knowledgeable of all requirements and business N/A
Customer(s) processes in a subject area, and empowered to define and
accept solution. It is expected that the Customer will actively
participate throughout the project and will sign-off on
designated SDM deliverables.
See the section titled " Customer Involvement In Projects" for
further information.
DBA Data Base Provides expertise, and performs physical database design, Database
Administrator administration and related planning. Administration
DMT Data Model Team A peer review team made up of analysts and the lead Architecture
Information Architect from a Practice that reviews proposed

Process Guide
Role Acronym
data model changes for compliance with Ford data standards.

These individuals also coordinate cross-application database
changes.
Espon Executive IT and Business Sponsors who fund the project and actively N/A
Sponsor(s) participate throughout the life cycle.
EUSupport End User Support Provide consulting services, implementation services, End User
Analyst production, operational and systems support for distributed Support
computing at all locations; serves as a liaison between clients
and vendors or other technical groups to resolve client
problems. Also provide feedback to corporate application
owners on user-base issues and establishing effective
support processes Across it support organizations to ensure
timely resolution to end user technology issues.
Facilities Facilities Analyst Coordinate overall planning, deployment and operations of Facilities
facilities within computer centers.
FGTI Intellectual Property Review application and/or business processes and provide N/A
attorney from Ford Customer with advice/guidance and support with respect to
Global applying for patent.
Technologies, Inc.
FinanceAnal Financial Analyst Allocate and release funding for projects (e.g.; hardware, General IT
software and services) on behalf of a business area. This Management
person may also assist with development of project cost
estimates.
GAO GAO Prevention Review ACR documents with the ICC and Application Owner General IT
Control Specialist to ensure that the application adheres to Ford security and Management
(GAO ACR maintenance standards.
reviewer)
ICC Internal Controls Provide support to project teams that are developing an ACR General IT
Coordinator and/or ICR. This person will provide ongoing ACR coaching, Management
review the ACR drafts, and present them to the GAO along
with the Project Manager and Application Owner.
ImpA Implementation Develop deployment-related materials, implementing the End User

Analyst solution and providing training. Support
InfoArch Information Plan and design data and its relationship to business Architecture
Architect processes to ensure correct information boundaries, integrity,
security, accuracy and the proper use of information.
InfraArch Infrastructure Specifies the computing infrastructure and services needed to Architecture
Architect support the development and deployment of the solution,
including the proper mix of commercial off-the-shelf products
(COTS), hardware, and networking.
IntTest Systems Integrator Lead integration and testing of application components into a Solutions
and Integration completed application. Development/QA
Tester
Inventor Inventor The originator of concepts, processes or products/software. N/A
IRR Independent Risk Evaluate project risk (prior to project start) based on a pre- Project/Program
Reviewer defined set of questions. Management
ITET&D IT Learning – Create application-specific training materials as well as End User

Education, Training provide the training on an as-needed basis. Support
and Development
(ET&D)

Process Guide
Role Acronym
KE Knowledge Develop strategy, provide expertise and long-range planning Knowledge

Engineer in the areas of it knowledge acquisition, capture, analysis, Management
dissemination, retention and reuse efforts. Determines
relevant sources of it information/knowledge in support of
project requirements and provides guidance to implement
global information standards as required within project
specifications.
LDevl Lead Developer Guides and oversees development of application software Solutions
components. Development/QA
Metrics Metrics Specialist Ensure consistent metrics gathering. The specialist will Process and
collect, review, analyze, and report program/project metrics. Methodology
NetE Network Engineer Individual/group with responsibility for all aspects of the Network
networks for a geographical area and the impacts to the rest Engineering
of the global network. Assists with the design, evaluation,
selection, and integration of networking technologies to meet
the needs of the business.
NLM Next Level Manager The manager directly over the Project Manager from a General IT
reporting perspective. Management
OGC Office of General Provide legal counsel for legal transactions such as contracts, N/A
Counsel Attorney as well as advice and guidance with respect to legal issues,
Office of General Counsel (OGC) Document and record
Suspension Orders, etc.
Oper Data Center Perform daily data center operations support activities Operations
Operations (backup, restore).
PGM Program Manager Direct all program -related activities. Initiates, plans executes, Project/Program
controls, and closes program, ensures requirements are Management
understood across all project teams, prioritized and that what
is delivered meets the agreed requirements. Provide
oversight in the management and execution of multiple
projects or projects that are viewed as large and/or complex.
PM Project Manager Direct all project-related activities – initiates, plans executes, Project/Program
controls, and closes project, ensures requirements are Management
understood, prioritized and that what is delivered meets the
agreed requirements.
PQA Independent Process coach who will provide coaching with respect to Process and
Process Quality methodology selection, related processes and templates. Methodology
Assurance Coach They will also participate in project/program reviews to ensure
adherence to process quality assurance guidelines.
PracticeMgr Practice Manager Provide application management for a particular business General IT
function, spanning the entire software development life cycle. Management
PSDevl Production Support Support and maintain application – performs production Solutions
Developer/Analyst support, participates in incident/enhancement design, Development/QA
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 Works with project teams to acquire vendor-provided N/A
Purchasing information, RFP/RFQ, and negotiate the acquisition of goods
or services.
QCLead Quality Control Test A senior tester, with an understanding of test processes, Solutions
templates and tools who may lead the development of the

Process Guide
Role Acronym
Lead Quality Control Test Plan and Strategy. Development/QA

QCTest Quality Control Test Provide testing expertise and guidance, develop QC Test Solutions
Specialist Strategy and Plan, develop and execute both functional and Development/QA
system tests.
RDM Resource The Resource Deployment Manager will manage a pool of General IT
Deployment ADS resources to ensure that they are being highly utilized as Management
Manager well as deployed in a fashion that accounts for Ford's overall
resource requirements
Responsibility: assign resources; report resource utilization
information to management
RS Reuse Specialist Develops strategies and leads implementation of knowledge- Process and
capture, -retention and -reuse efforts on it projects. Methodology
SAE Specialized Specialized
Application Application
Engineering Engineering
SCC Security Control The security control champion is organization-specific and will General IT
Champion ensure that Ford's security needs are recognized and Management
addressed in the implementation of policies, business
processes and computer applications.
SCCB Software Group responsible for evaluating and approving/rejecting N/A

Configuration proposed changes to configuration items and for ensuring
Control Board implementation of approved changes.
SCM Project Software Person responsible for coordinating and implementing Solutions
Configuration software configuration management (SCM) for the project. Development/QA
Management
Specialist
SCMTool SCM Tool Install, configure and support software configuration Solutions
Administrator management (SCM) tools, process, and procedures to ensure Development/QA
they are understood and followed .
SDevl Software Developer Participates in design activity and constructs, tests, and Solutions
documents application system code under the guidance of the Development/QA
lead developer.
SecE Security Engineer Provide consultation on enterprise security both within the Security
organization and external business units. Provides Engineering
assessment, vision, expertise, direction and guidance in the
implementation of secure solutions.
SIE Strategic Work with one or more project team members to test an Technology
Infrastructure application to determine whether it is well behaved (e.g.; Analysis
Engineering Analyst DLL's installed in correct location, DLL's are not over-written,
(was called Ford etc.) and that it is compatible with the Ford Standard desktop.
Systems Integration
Center / FSIC)
SiteCRM Site Client Manage the application and technical environments at a site End User
Relationship as well as act a liason between the Customer and application Support
Manager development/deployment and support teams.
SME Subject Matter Person with sufficient knowledge of a business process as to Business
Expert be considered an expert on the subject who will provide Analysis/
guidance on an as -needed basis. Reengineering
SolnArch Solution Architect Responsible for the assembly and integration of business Architecture
processes, data, and application and infrastructure

Process Guide
Role Acronym
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 N/A
person who has a vested interest in the development and
deployment of business processes and computer
applications. These people will provide guidance to project
team on an ongoing basis.
Steering Steering Committee A group of individuals (e.g.; managers and subject matter N/A
experts) who can provide oversight and guidance to a
project/program. From a reporting perspective, the Steering
Committee reports to the Executive Sponsor and has the
project team report to it on a periodic basis. These people will
review project status on a periodic basis; provide guidance on
an as -needed basis.
Supplier / Any 3 rd party or a Company outside of Ford that either directly or indirectly N/A
Vendor representative of a provides hardware, software, goods or services to or for Ford.
3rd party that is
either supplying
software or software
services
SysDesAn Systems Individual who oversees design of business processes, Systems
Designer/Analyst application architecture, user interface and system design. Design/Analysis
SysE Systems Engineer Individual who participates in hardware/software Systems

insfrastructure design and installs/configures the related Engineering
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.
Team Project Team In general, these are all members of a project team. N/A
Tech Development Tools Individual with expertise in development Tools. Technology

Technical Analysis
Specialist,
Technology Analyst
UsabSpec Usability Specialist Evaluates an application's ease of use and suggests usability Solutions
improvements. This individual can plan usability testing; Development/QA
execute usability testing; provide usability feedback after
testing; provide coaching on an ongoing basis.
WebDesigner Web Designer A member of the "Web Creative Services Group" who will Solutions
assist in the design and development of web-based user Development/QA
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
Project Proposal Project Management Processes

Executive
Summary Initiate
Initial Business
Case Plan
Change
Request Program
Charter Execute
Solution
Delivery Control
Methodology
Close
Inputs to Initiate Project
Overview At the start of any project, there will be a variety of ideas and opinions about its
purpose and scope, what the final product will be, and how the project will be
carried out. Project Initiation is concerned with taking these ideas and
intentions and developing them into a formal, planned, resourced and funded
project.
The purpose of Project Initiation is to define the overall parameters of the
project, develop initial project plans, and define the appropriate project
management and quality environment required to complete the project. Upon
completion of Initiation, the sponsor(s), business analyst, and project manager
should have enough information to make a go/no-go decision.
Process Contents
Objective Process Steps PM Deliverable
1.1 Prepare for 1.1.1 Confirm Project Readiness to Start Readiness Confirmation
Note the Project 1.1.2 Identify and Engage Stakeholders Stakeholder Assessment
Refer to PM Processes 1.1.3 Engage Project Start-up Team Resource Request/Roster
"3.0 Execute Project" 1.1.4 Develop Start-up Work Plan Work Plan for Initiation
and "4.0 Control
1.2 Establish PM 1.2.1 Establish Project Control File Project Control File Setup
Project" for processes
Infrastructure 1.2.2 Establish Project Procedures Procedures/Logs Started
such as "Maintain
Project Records" or 1.3 Define the Develop Initial Charter/Enhancement
1.3.1 Commitment Level Charter
"Conduct Status Project Request
Reviews" for process 1.3.2 Develop Project Approach Methodology/Approach
steps that must be
carried out across all 1.3.3 Develop Quality Mgmt Plan Quality Mgmt Plan
five PM Processes 1.3.4 Develop Communications Plans Communications Plan
(Initiate, Plan, Control, 1.4 Develop High 1.4.1 Develop High-Level WBS Initial Work Breakdown
Execute, Close). Level Work 1.4.2 Develop Dependency Network Dependency Network
Plan
1.4.3 Estimate Effort High Level Estimates
1.4.4 Develop High-Level Schedule High Level Schedule
1.5 Complete 1.5.1 Complete Initial Risk Assessment Risk Assessment/Plan
Investment 1.5.2 Develop Initial SOW SOW
Analysis
1.5.3 Confirm/Refine the Business Case Financial Scope
1.6 Confirm 1.6.1 Confirm Requirements/BOV Bus. Owner View Signoff
Readiness to
Proceed Obtain Initial Charter/Enhance. Req.
1.6.2 Charter Approval Signoff
Sign-off

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 Confirm that the Project Appropriation Request / PAR has been PM,
of Project created and approved. PracticeMgr,
Appropriation FinanceAnal
The primary purpose of the appropriation system is to control the
Request 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

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 Confirm that the initial SOW has been created and forwarded to the PM,
of initial SOW ADS Business Office and that the project is funded. PracticeMgr
and project If funding has not been resolved or the SOW has not been created
funding. 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.
3 Confirm Six Confirm that the Six Sigma Tollgate 0 (Recognize) process has PM,
Sigma Tollgate 0 occurred. The Recognize tollgate ensures that: PracticeMgr,
(Recognize) 6-Sigma
• An opportunity has been identified and has been identified
as "green field" or "redesign"
• Primary goals have been identified
• Customer segmentation has been addressed
• Linkages have been established to Business Objectives and
Customer Satisfaction
• Sign-off has been obtained from Executive, IT and Financial
leadership
• A general budget has been established
4 Review the Review the high-level business case used to justify and secure that PM,
Business Case funding or the change requests that have been bundled to make a BusA
new application release project.
Note: A Business Case may not be required for enhancement
requests to existing applications.
5 Review Project Review the project proposal or change request(s) that precipitated the PM,
Proposal or project to better understand the business need. Ask questions of the BusA
Change Request pers on who submitted the proposal or request as appropriate.
6 Confirm Project Confirm that a record has been created for the project in ITMS, RMS PM,
Records Exist and MRS. If not, ask the Business Analyst assigned to the project to BusA
create the appropriate records.
7 Confirm that a Confirm that a Scalability Questionnaire has been completed for the PM,
Scalability project. If it has not, work with the Business Analyst to Complete one. BusA
Questionnaire is
Completed
8 Complete a Complete a PQA Metrics sizing profile to identify the sizing category PM,
Sizing Profile of your project as shown below. Note that this sizing profile is used BusA
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.
9 Engage Process Review the PQA web site: PM
Quality
http://www.itonline.ford.com/sdm/classic/pqa/
Assurance
to determine level of involvement required. If PQA involvement is
required or desired, continue with steps 10-11.

Process Guide
10 Schedule Initial The Project Manager schedules a meeting with the assigned PQA. PM
Meeting with
PQA Consultant
11 Prepare PQA If the PM and NLM feel that the project should be exempt from PQA PM,
Waiver form reviews and involvement, a PQA Wavier form must be completed. 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 Project Appropriation Request / PAR at the BusA,
242_business_case.xls MEARS website PQA,
231_Scalability_Classification_Questionnaire http://www.finance.ford.com/mears/index2.html. NLM
243_program_charter.doc 231_Scalability_Classification_Questionnaire
RMS – http://www.rms.ford.com 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

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 Work with the Business Analyst to identify and classify key PM,
Stakeholders stakeholders . Use the project proposal and concept documents as BusA
input to the process.
2 Record Use the Stakeholder Assessment Matrix template to record the PM,
Information following: BusA
About Key
Stakeholders 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 Assess the stakeholders importance to the
Project: project as H- High, M- Medium, or L- Low
Engagement Briefly describe the strategy for engaging
Strategy: and communicating with the stakeholder.
3 Use Use the stakeholder information to assess risk, develop the charter, PM
Stakeholder plan meetings, and develop communications plans.
Information to
Plan Project
Interview with Sponsor/Business Analyst
Microsoft Word
241_Project_Proposal.doc 201_stakeholder_assessment_template.doc ESpon,
231_Scalability_Classification_Questionnaire BusA
Org Charts (if available)

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 Create a two dimensional matrix. List the skills/knowledge needed on PM,
Needed the project – particularly in early stages – down one side. BusA
2 Identify List the potential team members across the top of the matrix. PM,
Candidates BusA
3 Map Skills to Mark the intersection between skills/knowledge and each candidate. PM,
Candidates Identify and close gaps. BusA
4 Obtain Request and engage resources required. PM,
Required Sponsor
Resources
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.
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 Resource Request located at Espon,
231_Scalability_Classification_Questionnaire http://www.ads.ford.com/resman/ BusA,
242_business_case.xls 203_team_directory_template.doc 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 Identify the activities in project initiation, including those outlined in this PM
Activities in process guide and any activities identified for the solution delivery
Initiation methodology (if known).
2 Identify Use the stakeholder Matrix and Team Roster to identify participants. PM
Participants
3 Estimate Determine the availability of participants and estimate the duration of PM
Duration activities.
4 Develop Develop and publish a schedule detailing the timing of activities and PM
Schedule assignments.
MS Project

241_Project_Proposal.doc 229_Classic_SDM_Work_Plan.mpp Team
231_Scalability_Classification_Questionnaire
201_stakeholder_assessment_matrix.doc
203_team_directory_template.doc

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 The key considerations in establishing a Project Control File are

Considerations
• 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 Decide how project records will be kept and where. The types of PM
Control File 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
2 Set Up Version Set up electronic control tool for the management of document and PM
Control Mgmt software versions. See Create Software Configuration Management
Tool(s) section of the Solution Delivery Methodology Guide for suggested
tools.
3 Maintain Project Ensure that project records are kept current while at the same time PM
Records maintaining a complete project history.

Process Guide

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.
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 Using eTracker or MS Office files set up control logs for Issues, Risk PM
Project Logs and Change Management.
2 Identify SCM On software projects, identify and document any pre-existing PM,
Constraints constraints (e.g.; global requirements) with respect to software SCM
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.
3 Communicate Communicate procedures for submitting change requests and PM,
Change identifying new issues and risks to project team members and BusA,
Procedures stakeholders Espon,
Cust
4 Communicate Communicate how status reports will be collected from project team PM,
Status members and the frequency of meetings conducted to review that Team
Reporting status. Ensure that team members understand what information they
Procedures must provide and when
5 Establish Team Establish team meetings to review issues, risks, change requests, and PM,
Meetings progress. Weekly meetings are recommended. Establish a regular Team
time and place, agenda and procedure for capturing meeting minutes
6 Establish Establish regular meetings with the Project Sponsor to review issues, PM,
Sponsor risks, change requests that require Sponsor signoff and project BusA,
Meetings progress. Monthly meetings are recommended. Establish a regular Espon,
time and place, agenda and procedures for capturing meeting minutes Cust
7 Communicate Communicate procedures for submitting normal and emergency logical PM,
Database data model, physical data model and database change requests. Team,
Change DBA,
Request DArch
Procedure
8 Establish If performing Package Product Selection and Implementation / PPSI, PM,
approach for the team will have to establish approach for logging defects and Team
logging defects

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
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.
Project Control File http://www.etracker.ford.com Control File
09_SCM_Plan.doc (for existing applications) 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

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 Key considerations in developing the charter are

Considerations
• 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 Review the project proposal, business case, and concept profile PM,
Existing delivered with the project assignment and any existing documentation BusA,
Information to understand the project’s purpose. Team
2 Identify Project Identify the goals and objectives of the project. Project goals and PM,
Goal & objectives should align with the goals and objectives of the Sponsor,
Objectives organization and that of the program to which the project belongs (if BusA,
applicable). By definition, a project should have only one goal and Team,

Process Guide
multiple objectives that support that goal. Objectives must be Stakeholders
measurable.
3 Define Project Describe the scope as follows: PM,
Scope Sponsor,
Deliverable Deliverable scope refers to the deliverables BusA,
that the project will produce. Team,
Logical Logical scope delineates the boundaries of the Stakeholders
information systems to be included in the
project.
Organizational Organizational scope s pecifies which
organizations will participate in or be impacted
by the project.
Temporal Temporal scope defines the start date and end
of the project, milestones, and any external
dates that constrain it.
Financial Financial scope summarized the project
budget plan.
4 Identify Describe the key aspects of the project that are believed to be true, but PM,
Assumptions should be expressly stated to ensure validity and concurrence, BusA,
including items that should already in place. Team
5 Define Risks Identify the high probability/high impact risks factors that may PM,
jeopardize a successful project outcome and their mitigation strategies BusA,
and contingency plans (to be completed after the Investment Analysis Team
is completed below).
6 ID Related Identify other projects that will impact your project. Include projects PM,
Projects that are in progress and those that are planned. BusA
7 Describe The Describe the project organization, including key roles and PM
Project responsibilities and the identities of individuals assigned to those roles,
Organization if known.
8 Describe Describe, at a high-level, the solution delivery methodology chosen PM
Approach and the project management approach (to be completed after the
"Define Project Approach" process is completed (below).

Process Guide
Facilitated Sessions and Interviews
Microsoft Word
242_business_case.xls 200_project_charter_template.doc Control File,
231_Scalablity_Classification_Questionaire.doc 230_enhancement_and_small_project_request_template Project Sponsor,
243_program_charter.doc ∗ 231_Scalablity_Classification_Questionaire.doc BusA,
241_Project_Proposal.doc Team,
Stakeholders
Existing documentation, if any
∗
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 • When selecting the methodology, processes and templates, the project team
Considerations 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 Review requirements, initial scope definition, and any technology PM,
Requirements decisions made to date. BusA,
Cust,
SysDesAn,
SolnArch,
PQA
2 Review method Review the methodologies available to the team. Note that the PM,
options and 246_Classic_SDM_and_Unified_SDM_Comparative_Overview.ppt BusA,
determine presentation provides a comparison between Classic SDM and Unified Cust,
methodology SDM methodologies. Additionally, the PQA coaches can aid in SysDesAn,

Process Guide
understanding the methodologies and aid in the making of method SolnArch,
tailoring decisions. PQA
Determine what methodology or methodologies will be used to meet
project objectives.
3 Select Determine the processes and deliverables appropriate for the size and PM,
processes and characteristics of the project. BusA,
deliverables Document variances from the "standard methodology" in the Project Cust,
SysDesAn,
PQA Plan. The plan should note any deviations from the standard
SolnArch,
methodology and justification for those decisions.
PQA
4 Select Project Review the list of potential project accelerators identified in the PM,
Accelerators Accelerator Use Plan template and determine which ones will be applied. BusA,
Note that, at this stage of the project, you may not know enough to make Cust,
a final commitment on priorities and the accelerators that will be used, SysDesAn,
but it is a good idea to begin thinking about them now as some may SolnArch,
require up front work to organize (e.g., co-location of the project team PQA
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 Work with the customer to begin prioritizing functionality to be delivered PM,
functionality as part of solution. Force rank the list of functions outlined in the Initial BusA,
and determine Charter and record that information on the Accelerator Use Plan. This Cust,
timing information will be used to negotiate content of iterations/releases, SysDesAn,
scope, project timing and cost. These priorities will have to be taken into SolnArch,
consideration if new functionality is requested or a corrective action is PQA,
needed to recover a slippage in the project plan. ESpon
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.
6 Review and Review the proposed Project Approach, PQA Plan and Accelerator Use PM,
Communicate Plan the Customer, project team, and stakeholders. BusA,
Project Note: if significant variances from the identified methodology exist, Cust,
Approach consider gaining written authorization from the Practice Manager, PTG SysDesAn,
Customer Relationship Manager and Customer. SolnArch,
PQA,
ESpon
7 Adjust Initial Ensure that decisions made here are appropriately reflected in the PM,
Charter Project Management Approach section of the Initial Charter 6-Sigma
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".

Process Guide
Facilitated Sessions
PQA presentation titled 246_Classic_SDM_and_Unified_SDM_Comparative_Overview.ppt
247_Project_Approach_Questionaire.xls (job aid)

241_Project_Proposal.doc 214_project_pqa_plan_template.doc Control File,
Espon,
242_business_case.xls 200_project_charter_template.doc Team
231_Scalability_Classification_Questionnaire 204_Accelerator_Use_Plan.doc
200_project_charter_template.doc ---
02_Requirements_Specification.doc or 02_Requirements_Specification.doc or
230_SDM_Enhancement_and_Small_Project_Re 230_SDM_Enhancement_and_Small_Project_Re
quest.doc quest.doc

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 For purposes of this methodology, quality is:

Considerations 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 Review the deliverables outlined in the Scope section of the Project PM
Completeness Charter. Establish completeness and correctness criteria for
& Correctness determining when each deliverable meets specifications. Use these
Criteria criteria as standards when conducting deliverable reviews.
2 Ensure Quality Ensure the consistency of the work within each deliverable and across PM,
through

Process Guide
Reviews deliverables through the appropriate reviews. Examples include peer Team,
reviews of deliverables, independent quality reviews with the Process PQA
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.
3 Document The project work plan must include tasks that allow the project manager PM
Requirements to gather and analyze metric data. Use metrics to measure and monitor
for Metrics the quality of the work process. Much of this data will come in the form
Gathering of status reports, issues logs and change request logs.
4 Document Document any planned deviations from the standards defined by the PM
Planned solution delivery methodology. Record those deviations and their
Deviations justification in the Quality Management Plan section of the project
charter.
5 Review Quality Review the quality management plan with the Business Analyst and PM,
Mgmt Plan project team. Make adjustments as necessary. BusA,
Team
Review of initial project charter and the guide for the selected solution delivery methodology.
Microsoft Word
200_project_charter_template.doc 200_project_charter_template.doc Control File
Solution Delivery Methodology Process Guide 214_project_pqa_plan_template.doc
57_PQA_Review_Checklists.xls

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.
Corporate
Executives
IT Customer
Relationship
Managers
Sponsor/Customer
Solution
IT Project Architects Business
Managers Managers
Users
Developers Support
Groups
Key The communication plan should

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

Process Guide
Process Tasks
1 Identify Determine what should be shared/made available to stakeholders. PM,

Information to be For example: BusA
Shared
• Project Charter and Plans
• Project Standards and Procedures
• Change Requests, Logs and Resolutions
• Status Reports and Plan Changes
• Key Issues and Decisions with Backup
• Specification and Design Documentation
• Roles and Responsibilities
• Approvals and Contracts
Ensure that plans cover all of the items identified.
2 Complete a Using the Project Communications Plan Template record the PM
Communications following information for each communication planned:
Plan Template
• 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
3 Review and File Review the Communication Plan with the Business Analyst and PM,
Plan Project Team to assess completeness and file the Plan in the BusA,
Project Control File. Team
4 Refine Plan as Refine the communication plan as project plans are finalized and PM
Needed changes occur.
Microsoft Word

200_project_charter_template.doc 215_communication_plan_template.doc Control File,
201_stakeholder_assessment_template.doc 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.
Project Charter Review Identify Work

Methodology WBS Pre- No Activities to
Requirements for Existing Defined? Produce
Specification WBS Deliverables
Decompose &
Sequence
Solution
Delivery Work Activities
Methodology
Note:
The High-Level WBS Ensure
Project generally stops at Yes Completeness
the Activity Level.
Stage
WBS Worksheet Record WBS

Activity and/or MS Project
Plan
Task
Process Tasks

Process Guide
1 Review Determine if the methodology being used pre-defines the work PM

Standards 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.
2 Identify Work Using the project charter, work with team members to review the PM,
Activities project deliverables and identify the work activities required to Team
produce them.
3 Decompose & Decompose the work to the point where a high-level plan can be PM,
Sequence created. Team
Work Activities
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.
4 Ensure Review the breakdown to ensure that all of the work on the project is PM,
Completeness accounted for including Project Management and support activities. Team
5 Record the Use a WBS Worksheet to record the breakdown. If preferred, the PM
WBS 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.
Microsoft Word
MS Project
200_project_charter_template.doc 205_wbs_worksheet_template.doc Control File
230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp * 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 Several items may affect activity sequencing and interdependence:

Considerations • 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 Enter the high-level work breakdown structure into MS Project. PM
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.
2 Identify Links Establish the finish to start, start-to-start, start to finish, and PM
finish-to-finish relationships between dependent activities.
3 Incorporate Develop the appropriate iteration cycles for the development PM
Iterations of deliverables and work products.
4 Partition & Split Partition the work and split activities to make the work more PM
Activities manageable.

Process Guide
Microsoft Word
MS Project
200_project_charter_template.doc 205_wbs_worksheet_template.doc Control File
230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp * BusA
205_wbs_worksheet_template.doc Team
229_Classic_SDM_Work_Plan.mpp *

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 Determine what method/model will be used to produce initial PM,
Estimating estimates. Team
Tool/Technique
2 Determine How Decide how far out you should try to estimate in detail. PM,
Far Out Estimates can be produced in detail for the first few stages of Team
Estimates Will the project and at a higher level further out.
Go
3 Determine Determine how much contingency to include in early estimate PM,
Amount of to offset uncertainty. Team
Contingency
4 Estimate Project Use estimates to determine expected duration of the project or PM,
Duration the number of Full Time Equivalent (FTE’s) resources needed BusA,
Espon,
to meet a finish date that was identified at the beginning of the
Team,
project as a constraint.
ImpA
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.

Process Guide
5 Define Complete the temporal scope section of the charter by filling in PM

Temporal the high-level time line. Document your estimating
Scope assumptions as well.
6 Refine the WBS Incorporate estimate data into the Work Breakdown Structure PM
and Initial Work Worksheet (if in use) and the MS Project Plan.
Plan
Microsoft Word
MS Project
Microsoft Excel
200_project_charter_template.doc 205_wbs_worksheet_template.doc Control File,
230_Enhancement_and_Small_Project_Request 228_Classic_SDM_Estimating_Model.xls BusA,
205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp Team
229_Classic_SDM_Work_Plan.mpp *

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 No key considerations provided for this process step.

Considerations
Process Tasks

1 Develop High- Develop a high-level schedule. Where possible assign PM
level individuals to activities and roles to others.
Schedule
2 Identify Identify interim milestones – major checkpoints or deliverables. PM
Interim
Milestones
3 Update Initial Update the initial charter to reflect the schedule and milestones. PM
Charter
4 Update Update the project record in ITMS, RMS and MRS to reflect the PM
Project updated schedule and file documents in project Control File.
Records
Microsoft Word
MS Project
http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Reference_For_Project_Managers_and_Application_Managers.doc
200_project_charter_template.doc 200_project_charter_template.doc Control File,
230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp BusA,
205_wbs_worksheet_template.doc 230_Enhancement_and_Small_Project_Request Team
229_Classic_SDM_Work_Plan.mpp 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/

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 • Risk response development may result in any combination of contingency

Considerations 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 Complete the risk assessment checklist for the first time to PM,
Assessment obtain an initial numerical risk assessment score and risk BusA,
rating. Use the calculated risk score to determine the amount Team
of contingency to be included in the project plan.
2 Identify Risks Define the potential areas of risk that may affect the project PM,
Factors and record them on the Risk Management Log. The following BusA,
risk factors are common in projects. Team
Threat
• Threat due to changes in nature and/or strategy of
competitors
Capability of Developer or Organization
• Capability of developing organization to perform the task
at hand, including technical or management (project
and/or program management processes, tools and
techniques, and how they fit together).
• Incorporates experience, tools, skills, documented
processes and capacity, influence of external factors such

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 Classify the potential risks into risk categories (e.g., scope, PM,
Factors technology, etc., see Risk Management Log Template). BusA,
Team
4 Assess Impact Evaluate the potential impact of each risk on the project’s PM,
and Likelihood success (High, Medium or Low) and the likelihood that the risk BusA,
will occur (High, Medium, or Low). Team
5 Develop Risk Risk response development is the process of determining PM,

Response Plans what to do (or not to do) about the risk. Some choices are: BusA,
Team
• 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.
6 Record HH Enter the risks that are determined to be high risk and high PM
Risks in Charter probability in the Risk section of the Project Charter.

Process Guide
Microsoft Word
MS Project
207_risk_strategies_jobaid.pdf
200_project_charter_template.doc 206_risk_assessment_template.xls Control File,
230_Enhancement_and_Small_Project_Request 212_risk_management_log.doc BusA,
229_Classic_SDM_Work_Plan.mpp 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 Some key considerations for this process are:

Considerations • 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 Review the initial estimates of the project to determine the PM,
Labor Budget total hours of effort required. Apply the appropriate resource BusA,
cost rates to derive a total budget amount. Team,
ImpA
2 Estimate Estimate any significant non-labor costs. Consider training, PM,
Remaining facilities, computing, implementation, and project support BusA,
Budget costs. Use 209_budget_considerations_checklist.doc to help Team,
ImpA
Categories identify costs that should be considered.
3 Author SOW Author the SOW using the template located at PM

and submit for http://www.ads.ford.com.
approval Submit the SOW for review and approval using the SOW
Workflow Process (ADS Funding Authorization Workflow
Process) and tool documented at that site.

Process Guide
4 Enter Summary Record the budget summary data in the Financial Scope PM
Data into the section of the Initial Charter document and the Business
Initial Charter Case.
and Business
Case
Microsoft Word
Microsoft Excel

241_Project_Proposal.doc SOW located at http://www.ads.ford.com Control File,
242_business_case.xls 209_budget_considerations_checklist BusA,
200_project_charter_template.doc 200_project_charter_template.doc Team,
230_Enhancement_and_Small_Project_Request 230_Enhancement_and_Small_Project_Request Sponsor
206_risk_assessment_template.xls 242_business_case.xls
228_Classic_SDM_Esimating_Model.xls
229_Classic_SDM_Work_Plan.mpp

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 • Participation in this process by a Financial Analyst who is familiar with the
Considerations business processes in the value chain is essential to creating a
reasonable and accurate business case.
• Organizational benefits and risks may be included in the discussion in
order to show productivity improvement expectations by implementing the
system, but be careful not to overestimate savings by reducing or
redistributing headcount. If associates have multiple responsibilities,
reductions often aren’t possible.
• During the business case development, the benefits should be identified
as being either "qualified" or "perceived" based on the degree of certainty
achieved during the analysis process.
• Six Sigma projects may additionally require the use of a Six Sigma
template for stating the summary business case and a detailed business
case. See the DFSS template titled "DCOV overview with forms.XLS" for
details.
• Numerous references and links on the Ford intranet provide insight on the
business case development process. Enter the string "Business Case" as
the search criteria.
• Reference the introductory section in this guide titled "Project
Authorization Requests and Purchase Orders" for further information on
Project Appropriation Requests / PARs and Purchase Orders POs.

Process Guide
Process Tasks

1 Confirm Business Review the business opportunities and benefits outlined in PM,
Benefits the business case provided at project start-up. BusA,
Espon,
The Business Case will be stated in terms of costs as well as FinanceAnal
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.
2 Confirm or Refine Review the cost estimates provided in the original business PM,
Cost Estimates case. Determine what changes are necessary and note them BusA
accordingly.
3 Consider Timing Consider external factors that the project is dependent on PM,
and such as the timing for completion of other projects. BusA
Dependencies
4 Assess and Assess proposed costs against the estimated benefits of the PM,
Make proposed solution. Consider timing and dependencies. BusA,
Recommendation Based on this, formulate a recommendation as to the viability ESpon
of the project.
5 Communicate Communicate any changes in the cost, benefit or PM,
Changes recommendation to the Executive Sponsor, Stakeholders and ESpon,
IT management as appropriate. Stakeholders,
IT
Provide any changes in project costs or benefits to the Management,
Controller/Financial Manager and request that the Project FinanceAnal

Process Guide
Authorization Request /PAR in MEARS is updated.
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.
241_Project_Proposal.doc 242_business_case.xls Control File,
BusA,
242_business_case.xls 200_project_charter_template.doc
Team,
200_project_charter_template.doc 56_Process_Capability_Scorecard.xls ESpon,
Finance
230_Enhancement_and_Small_Project_Request SOW located at http://www.ads.ford.com Office,
Stakeholders
206_risk_assessment_template.xls 230_SDM_Enhancement_and_Small_Project_Request.doc
229_Classic_SDM_Work_Plan.mpp 241_Project_Proposal.doc
SOW located at http://www.ads.ford.com PAR at the MEARS website
http://www.finance.ford.com/mears/index2.html
56_Process_Capability_Scorecard
PAR at the MEARS website
http://www.finance.ford.com/mears/index2.html

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 No key considerations specified for this process.

Considerations
Process Tasks

1 Confirm Initial Confirm that an initial Requirements Specification has been PM,
Business completed as per the appropriate Solution Delivery BusA
Requirements Methodology (SDM) Guide and that the lead Customer has
Specification reviewed and approved that specification.
2 Confirm Confirm that the required process and data models (future PM,
Customer state) have been constructed as part of the Business Owner BusA,
Signoff of View described in the Solution Delivery Methodology. Ensure Cust
Business Owner that the Business Owner View has been reviewed and
View approved by the Customer (i.e., that the Customer has signed
off on the Business Owner View).
3 Ensure Ensure that the scope section of the charter is appropriately PM
Alignment with aligned with the initial Requirements Specification and
Initial Charter Business Owner View
4 File Documents File the completed documents in the project Control File. PM
in Control File

Process Guide

Review of SDM deliverables
02_Requirements_Specification.doc Confirmation of signed Business Owner View and Control File
61_Business_Owner_View.doc Requirements Specification

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 The decision to sign the charter is generally made on the basis of the
Considerations 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 & Before reviewing the charter with the Sponsor ensure that the PM,
Conduct a Pre- IT Business Analyst and Program Manager (if appropriate) BusA,
Charter Signing have a chance to review the charter, high-level plan, and Program Mgr,
Review Team,
investment analysis documents. Obtain their agreement on
ImpA,
the charter content and backup data to be presented to the Cust
Sponsor before proceeding.
2 Schedule Schedule a charter review and signoff session with the PM
Charter Review Sponsor.
with Sponsor
3 Prepare Prepare an approval package for review with the Sponsor. PM
Approval The package should include the Initial Charter Document and
Package as backup, the High-Level Project Plan, Risk Assessment,
Budget Plan, and refined Business Case.
4 Review Charter Review the charter and supporting material, as needed, with PM,
and Detail the Sponsor. Identify and document any issues that must be BusA,
resolved before the charter can be approved (e.g., any Sponsor,
Team,
refinements or additions that must be made before the
Stakeholders,
Sponsor will approve the charter). If possible make the
ImpA
changes needed in the session itself.
5 Obtain Signoff Obtain the Sponsors signoff. If the Sponsor decides that, PM,
based on the charter, the project should not proceed, BusA,
document that decision. ESpon
6 Update Project Update the project record in ITMS, RMS and MRS to reflect PM
Records the status and file documents in project Control File.
7 Notify Notify support activities, the project managers of PM
Stakeholders related/dependent projects, the Practice Manager, the
Portfolio Manager, and the Competency Center Manager of
the results of the charter review.
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
02_Requirements_Specification.doc 02_Requirements_Specification.doc Control File,
200_project_charter_template.doc 200_project_charter_template.doc Program Mgr,
204_accelerator_use_plan 230_Enhancement_and_Small_Project_Request ESpon,
206_risk_assessment_template.xls Go/No-Decision Cust,
228_Classic_SDM_Estimating_Model.xls Project Record in RMS Team
229_Classic_SDM_Work_Plan.mpp http://www.rms.ford.com
Support Activities
230_Enhancement_and_Small_Project_Request Project Record in MRS http://www.ads.ford.com/mrs
241_Project_Proposal.doc Updated ITMS Record at Competency
Center
242_business_case.xls http://www.itms.ford.com/
Metrics
56_Process_Capability_Scorecard
SOW located at http://www.ads.ford.com

Process Guide

Process Guide
2.0 Plan Project
Project Charter Project Management Processes

Business Case Initiate
High Level Plan
Business Plan
Owner View Requirements
Execute
Solution
Delivery Control
Methodology
Close
Inputs to Plan Project
Overview Project Planning is an iterative process that occurs throughout the project life cycle.
It begins in Initiate Project with the development of the charter and high level plans
and continues in subsequent stages with more detailed planning and adjustments
made to reflect changes and corrective actions.
The process described below picks up where the high level plan that was created in
Initiate Project leaves off. Here, however, the results of analysis and design
activities are used to identify additional planning requirements and create detailed
work plans.
Process Contents
2.1 Develop 2.1.1 Develop Org Change Mgmt Plan Org Change Mgmt Plans
Project
Management 2.1.2 Develop Procurement Plans Procurement Plans
Note
Plans
Refer to PM 2.1.3 Develop Transition Plans Support and Launch Plan
Processes "3.0
2.1.4 Develop Resource Mgmt Plans Resource Mgmt Plan
Execute Project" and
"4.0 Control Project" 2.2 Refine Work 2.2.1 Refine Project Approach Accelerator Use Plan
for processes such Plans and
as "Maintain Project Budget 2.2.2 Refine Work Plans Baseline Project Schedule
Records" or
"Conduct Status 2.2.3 Refine Risk Management Plans Risk Management Plans
Reviews" for process 2.2.4 Refine Resource Requirements Resource Requests
steps that must be
carried out across all 2.2.5 Refine The SOW Refined SOW
five PM Processes
(Initiate, Plan, 2.3 Confirm 2.3.1 Confirm Requirements Spec Signoff Requirements Signoff
Control, Execute, Readiness to
Proceed Final Charter Approval
Close). 2.3.2 Obtain Final Charter Approval
Signoff
2.3.3 Conduct Formal Kick-off Kick-off Metting

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 Ensure that OCM activities occur. See the Classic SDM Guide for PM
OCM activities details.
Update the work estimates and workplans as appropriate.
MS Project
Organizational Change Management techniques – see http://www.change-management.com/ for articles and books
Program Mgr,
230_Enhancement_and_Small_Project_Request 230_Enhancement_and_Small_Project_Request BusA,
215_communication_plan_template.doc 215_communication_plan_template.doc Sponsor
229_Classic_SDM_Work_Plan.mpp 229_Classic_SDM_Work_Plan.mpp

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 Key considerations for this process are:

Considerations
• 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 Use cost/benefit analysis to determine if purchasing goods or PM,
Make/Buy services is the right approach. BusA,
Decision ESpon,
SMEs
2 Determine The question of how much to purchase can only be answered by PM,
How Much To the individual project. However, consideration should be given BusA,
Buy to the following questions before making that decision: SMEs
• Will there be need beyond the immediate project for this

product?
• How much of the budget has been or will be allocated for
this product?
• Is the need for the product or service clearly defined enough
for the organization to know how much is needed?
Underestimating or overestimating the cost or quantity of an item
can have a big impact on the financial success or failure of the
project. Caution should be used when entering into any contract
without clearly defined needs and objectives.
3 Determine If a decision is made to purchase an item or service, the next PM,
How to Buy step is to explore the various types of contracts that can be BusA,
arranged. Work with Purchasing and the Office of The General Purchasing,
OGC
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.
4 Contact Ford Contact Ford Purchasing to discuss project requirements as well PM,
Purchasing as agree to approach/plan for performing vendor contact and BusA,
product analysis. Purchasing
5 Develop Determine if an existing contract with a pre-approved vendor can PM,

Procurement be used to satisfy the need for services. If not, determine what BusA,
Plan vendors will be asked to solicit the business. Purchasing
6 Develop Work with Purchasing to put a procurement plan together that PM,
Sollicitation determines how bids in the form of Contract will be solicited from BusA,
Plan potential vendors. Agree on how the final decision will be made Purchasing
(i.e., agree on the criteria that will be used to make the buy

Process Guide
decision.)
7 Make Make the final decision to purchase the goods or services and PM,
Decision BusA,
notify stakeholders as appropriate. Purchasing
8 Establish Work with Purchasing and the Office of the General Council PM,
Contractual BusA,
(OGC) to finalize the contractual arrangements with the vendor. Purchasing,
Agreement OGC
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
200_project_charter_template.doc Organization-specific procurement plan Control File,
230_Enhancement_and_Small_Project_Request 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 Identify the Practice Application Supervisor that will be responsible PM,
Transition for supporting the deliverables produced by the project. Notify that AppSupr,
Process supervisor of the project and schedule an initial meeting to review ImpA
project plans and anticipated transition events.
2 Identify the Identify the transition team members, including their names, roles, PM,
Transition Team cds ids, and phone numbers. AppSupr,
ImpA
3 Schedule Key Identify when key transition events will occur, who will be involved, PM,
Transition Events and what actions will be taken. Transition events include, but are not AppSupr,
limited to the following: ImpA
• Knowledge Transfer Meetings

• Service Level Agreement Reviews
• Acceptance Testing Reviews
• Performance Monitoring and Control Reviews
• Outstanding Change Request Handover
• Outstanding Issues Handover
• Outstanding Defects Handover
• Documentation Handover

Process Guide

200_project_charter_template.doc 217_transition_support_plan.doc Control File,
230_Enhancement_and_Small_Project_Request 229_Classic_SDM_Work_Plan.mpp BusA,
229_Classic_SDM_Work_Plan.mpp 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 Team members have a stake in the success of the project. Consider the
Considerations 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

Process Tasks

1 Identify skills Refine the list of skills required on the project that was PM,
and Resource developed at the beginning of the project. Include skills Team,
Levels Required needed as a result of requirements gathered and any other BusA
analyses of project deliverables.
2 Identify Identify the available resources. PM
Resources
3 Assess Assess the skills of the people available. It is the project PM
Resource Skill manager’s job is to determine the risks associated with the
Levels 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.
4 Determine Identify and price any training that will be required to PM
Training supplement team knowledge and skills. Refine the proposed
Requirements budget to include any training costs.
5 Determine Identify the facilities and equipment (e.g., computers, PM
Facilities/ cubicles/desks etc.) that will be needed for the people
Equipment identified. See 3.1.1 Acquire/Release Facilities & Equipment
6 Develop a For small projects, the staffing plan may be as simply stated PM
Staffing Plan 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.
7 Review Review the resource plans with the Business Analyst and PM,
Resource Plans technical subject matter experts on the team. Team,
BusA

Process Guide
8 Refine the Refine the Financial Scope and Project Organization sections PM
Project Charter of the Project Charter to reflect the resource management
decisions made.

Process Guide
Skills assessment

200_project_charter_template.doc Resource Request located at Control File,
230_Enhancement_and_Small_Project_Request http://www.ads.ford.com/resman/ BusA,
229_Classic_SDM_Work_Plan.mpp 227_project_organization_chart_jobaid.ppt Competency Center,
200_project_charter_template.doc Demand Management
230_Enhancement_and_Small_Project_Request
216_project_organization_chart.doc

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 • When selecting the methodology, processes and templates, the project team
Considerations 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 Review the current Accelerator Use Plan (AUP) and determine if PM,
Accelerator elements need to be updated or added based on information gathered BusA
Use Plan since the initial plan was created.
2 Update User At this stage, you will know about the users and functionality required. PM,
Types Describe/update and prioritize all user types and enter this information BusA,
into the AUP template. Cust
3 Describe Work with the Customer to identify and describe the primary areas of PM,

Process Guide
Business functionality to be developed within the project. BusA,
Functionality Cust,
6-Sigma
4 Decompose Work with the business analyst and Customer to decompose the PM,
Business business functionality into logical sub-areas. BusA,
Functionality Cust
5 Prioritize Work with the Customer to prioritize the business functionality based PM,
Functionality upon perceived benefit, value to the highest priority user types and the BusA,
minimization of project risk. Enter this information into the AUP Cust
template.
6 Select Update the list of accelerators to be employed (e.g.; time-boxing, PM,
Accelerators prototyping, reusable software, co-location, etc.) and update that BusA,
information in the AUP template. Cust
7 Update Update the Charter, Work Breakdown Structure, and Project Plan to PM
Plans to reflect any decisions made about the sequence of activities, timing, or
Reflect AUP dependencies, as appropriate.
204_accelerator_use_plan.doc 200_project_charter_template.doc Control File,
200_project_charter_template.doc 230_Enhancement_and_Small_Project_Request BusA,
230_Enhancement_and_Small_Project_Request 204_accelerator_use_plan.doc Cust,
229_Classic_SDM_Work_Plan.mpp 205_wbs_worksheet_template.doc Team
205_wbs_worksheet_template.doc 229_Classic_SDM_Work_Plan.mpp

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 Refine the work breakdown structure to reflect information gathered since PM,
Work project initiation. Add or remove activities and take the breakdown to its Team
Breakdown lowest level.
2 Refine Refine the dependency network to reflect task level dependencies. PM,
Dependencies Team
3 Update Update the project schedule to reflect the task-level work breakdown and PM,
Project assign specific resources. Make a note of any tasks for which a specific Team
Schedule individual cannot be identified. You will need to use this information to
refine resource plans and request additional resources.
4 Refine Project Refine project estimates taking new work breakdown and resource PM,
Estimates assignments into consideration. Ensure that adequate contingency is BusA,
baked into task estimates where resources are less skilled or liable to be Cust
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.
5 Generate Update the MS Project Plan to reflect all of the changes identified. If the PM,
Baseline end-date has moved out, use the accelerator use plan and other factors BusA,
Work Plan to determine if the date can be bought back in line by deferring low Cust
priority functionality, adding resources, or other means. Baseline the
schedule when timing and resource issues have been resolved.
6 Update Update the project record in ITMS, RMS and MRS to reflect the updated PM
Project schedule and file documents in project Control File.
Records

Process Guide
230_Enhancement_and_Small_Project_Request 230_Enhancement_and_Small_Project_Request BusA
229_Classic_SDM_Work_Plan.mpp 204_accelerator_use_plan.doc Cust
205_wbs_worksheet_template.doc 205_wbs_worksheet_template.doc Team
204_accelerator_use_plan.doc 229_Classic_SDM_Work_Plan.mpp
228_Classic_SDM_Estimating_Model.xls 228_Classic_SDM_Esitmating_Model.xls

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 • Ensure that ability to achieve requirements, including CTQ's, are

Considerations incorporated into risk management process.
Process Tasks

1 Identified Risk Review the risk assessment conducted during project initiation to PM,
Factors determine if additional risk factors apply. If not, skip the Team
remainder of this process step. If new risks identified, add them to
the Risk Management Log (eTracker if in use).
2 Assess Risk Assess the level of impact, likelihood of occurrence, and potential PM,
Factors impact on cost, time, and benefits and record in the Risk Team,
Management Log. Cust
3 Define Define strategies for mitigating each additional risk. Refer to the PM,
Mitigation Ernst & Young Risk Factor Strategies job aid for ideas on Team
Strategies mitigating common risk factors.
4 Define Define contingency plans for each risk factor added and record PM,
Contingency that information in the log. Team
Plans
5 Confirm Risk Confirm the risk assessment score on the Risk Assessment PM
Rating Checklist and file the refined copy in the Project Control File.
6 Record HH Enter any additional high impact, high probability risks into the PM
Risks in Project Charter.
Charter
7 Address Work Ensure that mitigation strategies and contingency plans are PM
Plan Impacts accurately reflected in the work plan

Process Guide

eTracker at www.etracker.ford.com

200_project_charter_template.doc 206_risk_assessment_template.xls Control File
230_Enhancement_and_Small_Project_Request 212_risk_management_log.doc BusA
229_Classic_SDM_Work_Plan.mpp 200_project_charter_template.doc Cust
207_risk_strategies_jobaid.pdf
204_accelerator_use_plan.doc
228_Classic_SDM_Estimating_Model.xls

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 Refine the list of skills required on the project as needed PM,
and Resource Team
Levels
Required
2 Identify Identify the available resources and assess their skill levels. PM
Resources
4 Refine Identify and price any training that will be required to supplement PM
Training Plans team knowledge and skills. Determine the impact on the budget.
5 Refine For small projects, the staffing plan may be as simply stated as PM
Staffing Plans 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.
6 Review Review the resource plans with the Business Analyst and PM
Resource technical subject matter experts on the team.
Plans
7 Refine the Refine the Financial Scope and Project Organization sections of PM
Project the Project Charter to reflect the resource management
Charter decisions made.

Process Guide
Microsoft Word and Excel and MS Project

200_project_charter_template.doc Online resource request at Control File,
230_Enhancement_and_Small_Project_Request http://www.ads.ford.com/resman/ BusA,
229_Classic_SDM_Work_Plan.mpp 227_project_organization_chart_jobaid Cust,
205_wbs_worksheet_template.doc 216_project_organization_chart.doc Team,
200_project_charter_template.doc Competency Center,
230_Enhancement_and_Small_Project_Request Demand Management
206_risk_assessment_template.xls

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 • Only Ford employees are authorized to access the SOW. Non-Ford
Considerations employees should work with their Practice Manager to modify it.
Process Tasks

1 Refine the Refine initial resource requirements estimates. Use specific labor PM,
Labor rates as appropriate. BusA,
Budget ImpA
2 Refine Refine estimates and any non-labor costs. Consider additional PM,
Remaining facilities, equipment, training or travel identified since the initial BusA,
Budget SOW was created during project initiation. ImpA
Elements
4 Summarize Confirm or refine the SOW as appropriate. If changes are required, PM,
Costs submit a new SOW to the ADS Business Office via the SOW BusA,
Workflow process and tool documented at http://www.ads.ford.com. ImpA
The Business Office review the SOW for completeness and
accuracy, then circulate it for signature via the Work Flow Tool.
5 Update the Update the financial scope section of the charter or enhancement PM
Charter request, as appropriate.
MS Project

Process Guide
229_Classic_SDM_Work_Plan.mpp SOW located at http://www.ads.ford.com Cust,
http://www.ads.ford.com/resman/

Process Guide
2.3 Confirm Readiness to Proceed

2.3.1 Confirm Requirements Specification Signoff
Purpose The purpose of this process is to ensure that the Requirements Specification
has been reviewed and approved by the Customer and that the final charter
accurately reflects the information contained in that specification.
Trigger Development of detailed Requirements Specifications and a baseline work plan

and completion of all sections of the project charter as appropriate.
Key For enhancement

Considerations
• 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
Process Tasks

1 Confirm Confirm that the final Requirements Specification has been PM,
Customer reviewed and approved by the appropriate parties per the BusA,
Signoff of Solution Delivery Methodology. Ensure that the lead Cust,
Requirements SolnArch,
Customer(s) on the project has signed the specification
Specification Vendor/Supplier
document indicating concurrence with its contents.
2 Ensure Ensure that the scope section of the final project charter is PM,
Alignment of aligned to the Requirements Specification. BusA,
Charter Cust
3 File Signed File the signed Requirements Specification in the appropriate PM

Process Guide
Requirements Control File folder.

Specification
Microsoft Word

02_Requirements_Specification.doc 02_Requirements_Specification.doc
230_Enhancement_and_Small_Project_Request

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 The same key considerations that applied at the initial charter signoff, apply
Considerations here.

Process Tasks

1 Finalize Ensure that project objectives are measurable and still PM
Objectives accurately reflect the requirements and business success
criteria.
2 Finalize Ensure that all sections of project scope are defined and PM
Scope accurately reflect the understanding reached with the Customer.
4 Finalize Ensure that all sections of the project approach are completed PM
Project Mgt and accurately reflect decisions made concerning the methods
Approach that will be employed to manage quality, issues, risk,
communications, procurement, support, implementation, and
resource management.
5 Finalize Risk Ensure that the high impact and high probability risks are PM
Section recorded in the risk section of the charter.
6 Finalize Ensure that the project organization accurately reflects the team PM
Project structure. Include an organization chart as appropriate.
Organization
7 Review Review changes with the Business Analyst and Customer and PM,
Changes BusA,
decide if they require Sponsor review. Obtain Sponsor signoff. Cust,
ESpon
MS Project
229_Classic_SDM_Work_Plan.mpp 206_risk_assessment_template.xls Cust,
204_accelerator_use_plan.doc Team

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 • Key considerations when planning and conducting the meeting include
Considerations
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 PM,
Work with the Sponsor, the Practice Manager, and Business
Participants PracticeMgr,
Analyst to determine who needs to be at the kick-off. Sponsor,
BusA

Process Guide
2 Schedule Identify the date, time and place. Reserve the meeting room PM
Kickoff and any presentation equipment required.
3 Develop Introduction: Sponsor or Rep – Welcome address. PM,

Agenda BusA,
Project Manager – Describes the agenda.
Sponsor
Introduction of Participants introduce themselves, describe
Attendees: their concerns and expectations.
Project Sponsor – Background to the project, the
Overview: Customer, why it is important to be successful,
future opportunities, Customer needs and
expectations, and high -level project scope.
Project Goals Project Manager – Presents what’s known of
and Objectives: project goals and objectives, key milestones,
and critical success factors. The Concept
Profile, Executive Summary, and interview with
the Sponsor to prepare.
Project Project Manager – Presents the organization
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 Project Manager – Describes the project
Tools: management model, the documentation, the
processes, and highlights the way progress will
be monitored.
Question and Project Manager – Leads brief question and
Answer: answer period.
Summing Up: Project Manager – Summarizes the meeting
and reminds everyone of action points with
target completion dates.
4 Distribute Distribute the agenda, Project Charter, Project Plan, and any PM,
Materials other relevant material ahead of the meeting. Admin Support
5 Conduct the Conduct the meeting, taking notes on any issues raised and/or PM,
Meeting action points BusA,
ESpon
6 Distribute Distribute minutes of the kickoff to attendees and appropriate PM,
Minutes stakeholders who were not in attendance. Admin Support

Process Guide

Process Guide
MS Project
200_project_charter_template.doc 218_kickoff_meeting_checklist.doc Control File,
230_Enhancement_and_Small_Project_Request 219_kickoff_meeting_agenda_template.doc BusA,
229_Classic_SDM_Work_Plan.mpp ESpon,
204_accelerator_use_plan.doc Team,
Stakeholders
201_stakeholder_assessment.doc
215_communication_plan_template.doc

Process Guide
3.0 Execute Project
Resource Plan Project Management Processes

Procurement
Communication Initiate
Plan
Plan
Budget Plan
Transition Plan
Project Charter Plans
Work Plan Execute
Solution Control
Delivery
Methodology
Close
Inputs to 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 Manage 3.1.1 Acquire/Release Facilities and Equipment Move Request/GIRS

Project
Execution 3.1.2 Acquire/Release Team Members Resource Requests
3.1.3 Direct & Coordinate Plan Execution Work Products
3.2 Manage 3.2.1 Maintain Project Records Documentation

Project
Information Meeting Minutes,
3.2.2 Distribute Project Information
Reports and Notices

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 Key Considerations for this process are:

Considerations
• What hardware and software will be required for team members?
• Will software licenses be required?
• Are new security badges and network access required?
• Do team members need to be moved from one building or room location to

another?
• Will team members be co-located and is a team room required?

• Is the cost of training and software included in the SOW?
• Reference the introductory section in this guide titled "Project Authorization

Requests and Purchase Orders" for further information on Project
Appropriation Requests / PARs and Purchase Orders POs.
Process Tasks
1 Obtain Team Request team room(s) or cubicles as appropriate to the location and PM
Facilities resource requirements.
2 Obtain Determine what workstations, network access, shared drives, phones, PM
Workstations eRooms, and other facilities or equipment will be needed and submit
and Other the appropriate requests through the help desk.
Equipment
3 Request Determine if specific software licenses will be required (e.g., licenses PM
Software for MS Project) and submit the appropriate support requests through
the help desk (GIRS). The cost of software should be included in the
SOW.
4 Schedule Ensure that the setup of cubicles, team rooms, equipment and software PM
Facilities, are scheduled and completed on time.
Hardware, and
Software
5 Verify Supplies Verify that adequate office supplies are available and accessible to the PM
team.
6 Verify Verify that team hardware and software are functioning properly before PM,

Process Guide
Workstation work begins. Team
and
Development
Environment
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

200_project_charter_template.doc Move Request (see Tools Above) Ford Land,
230_Enhancement_and_Small_Project_Request GIRS Tickets Help Desk
02_Requirements_Specification.doc

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
• 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 List the potential team members across the top of the matrix. PM,
Candidates BusA
3 Map Skills to Mark the intersection between skills/knowledge and each candidate. PM,
Candidates Identify and close gaps. BusA
4 Interview Interview candidates. PM
Candidates
5 Obtain Request and engage resources required. Engaging resources PM,
Required includes providing them with background on the project. It may also Sponsor
Resources entail follow through on training plans for resources.
6 Request Direct new employees to the web sites or local support functions that PM,
Badge, Phone they will need to contact to get phones installed and access to the Team
or Move building, printers, and shared drives.
7 Update the Create a team roster identifying team members, their home PM
Team Roster organization, their role, and the amount of time that they will be
available.
8 Orient Team Provide new team members with background on the project and PM,
Members access to any existing documentation. Team
9 Notify Send an MS-Outlook note to the appropriate Competency Center AppSupr,

Competency Manager 30 days prior to the release and notify him/her that the Competency
Center of resource will be released and the date of the release. If the resource Center
Upcoming doesn't know whom their manager is, the note should be sent to Don Manager
Release of a Bartkowiak (DBARTKOW).
Ford ADS
Note: As per the new Competency Center Guide, Ford ADS resources
Resource
will have been assigned a Competency Center Manager. The
AppSupr should obtain the Competency Center Manager's name from
the resource.
10 Notify Agency Send an MS-Outlook note to the appropriate agency representative 2 AppSupr,
of Upcoming weeks prior to the release and notify him/her that the resource will be Agency
Release of released and the date of the release. Representative
Agency
Resource
11 Notify RMS of Send an MS-Outlook note to cdsid RMSHELP to inform them that the AppSupr
Resource resource will no longer be working on the application and should not
Release bill against it any longer.
12 Perform Exit Follow the instructions at the exit procedure link located at AppSupr
Procedure http://www.ads.ford.com/facilities/. This procedure covers the removal
of application access, building access and other tasks.
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
Process Guide
200_project_charter_template.doc Resource Request located at Control File,
230_Enhancement_and_Small_Project_Request http://www.ads.ford.com/resman/ Competency Center,
229_Classic_SDM_Work_Plan.mpp 203_team_directory_template.doc Resource Mgmt,
http://www.ads.ford.com/resman/ Move Requests (see Tools Above) 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 No key considerations defined for this process step.
Considerations
Process Tasks
1 Assign Tasks to Ensure that team mem bers are aware of assignments including PM,
Team Members those added after the plan is baselined to deal with issues, risks, and Team
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.)
2 Ensure Provide stakeholders who are outside the core team with a copy of PM,
Stakeholders the plan so they understand what is expected of them over the life of Stakeholders
Understand their the project. Stakeholders include, but are not limited to the Sponsor,
Role lead Customer, Business Analyst, and other subject matter experts
whose input will be required at various points over the project life
cycle.
3 Execute Project Ensure that tasks that rightfully belong to the Project Manager are PM
Manager Tasks carried out per the project plan.
Microsoft Word and Excel, MS Project
RMS-- http://www.rms.ford.com
229_Classic_SDM_Work_Plan.mpp 229_Classic_SDM_Work_Plan.mpp Control File,
201_stakeholder_assessment_matrix.doc ESpon,
203_team_directory_template.doc BusA,
Timesheets http://www.rms.ford.com Cust,
210_change_request_template.doc Team,
Other Stakeholders
211_change_request_log.doc
212_risk_management_log.doc
213_issue_log.doc
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 No key considerations provided for this process step.

Considerations
Process Tasks

1 Keep Record in Ensure that the records in the project Control File are kept PM
Control File Up current and available to stakeholders who need access.
to Date
2 Post Actuals to Ensure that the project plan is kept current by posting actuals PM
Plan 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.
3 Maintain Project Ensure that issue, risk, and change logs are kept current. PM
Control Logs Provide access to key stakeholders so new issues and risks
can be documented in the appropriate logs.
4 Maintain Project Ensure that the project record in ITMS is kept current per PM
Record in ITMS ITMS procedures.
5 Maintain Project Ensure that the project record in RMS is kept current per RMS PM
Record in RMS procedures.
6 Maintain Project Ensure that project records are kept current in MRS. PM
Record/Metrics
in MRS
Process Guide
MRS
RMS – http://www.rms.ford.com
Timesheets http://www.rms.ford.com Updated project records Control File,
221_weekly_status_report_template.doc 221_weekly_status_report_template.doc Stakeholders
210_change_request_template.doc 210_change_request_template.doc
211_change_request_log.doc 211_change_request_log.doc
212_risk_management_log.doc 212_risk_management_log.doc
213_issue_log.doc 213_issue_log.doc
212_risk_management_log.doc Project Hours http://www.rms.ford.com
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 No key considerations provided for this process.

Considerations
Diagram The following diagram shows where Information Distribution fits into the overall
communication management process.
Process Tasks
Process Guide
1 Execute On a weekly basis, review the project communication plan to PM,

Communication determine what information must be distributed and to whom and act Stakeholders
Plan accordingly.
2 Communicate the Notify stakeholders at key decisions points including, but not limited PM,
Results of Key to, charter signing, stage completion, the results of status reports, the Stakeholders
Decision Points results of sponsor reviews, the results of technical reviews (see
section 4.2.4 Coordinate Security Reviews & Certification), scope
changes, etc.
3 Respond to Provide access to information as appropriate, including project logs PM,
Requests for and other records, and respond to specific questions asked Stakeholders
Information concerning the purpose of the project and the status of the project.
Microsoft Word
Email
Meetings
eRoom
Web Sites
201_stakeholder_assessment_template.doc 221_weekly_status_report_template.doc Control File,
203_team_directory_template.doc Results of reviews Stakeholders
215_communication_plan_template.doc Approval to Proceed
See also the SDM Process Guide
Process Guide
Process Guide
4.0 Control Project
Project Management Processes

Resource Plan
Procurement Initiate
Plan Communication
Plan
Budget Plan Plan
Work Plans
Project Charter
Execute
Work Products
Solution
Delivery Control
Methodology
Close
Inputs to Control Project
Overview The Project Management Institute (PMI) defines Project Control as follows:
A project management function that involves comparing actual performance

with planned performance and taking corrective action (or directing or
motivating others to do so) to yield the desired outcome when significant
differences exist.
Monitoring and controlling the project also involves proactive management of scope,
risks, quality, and issues and project reviews to ensure that stakeholders are satisfied
that the project will succeed and should continue as planned.
Process Contents
Objectives Processes Key Deliverables
4.1 Monitor and 4.1.1 Monitor and Control Scope Change Requests/Log
Control the
4.1.2 Monitor and Control Schedule/Costs Updated Plans
Project
4.1.3 Monitor and Control Risks Risk Management Log
4.1.4 Monitor and Control Issues Issues Resolution/Log
4.1.5 Monitor and Control Quality Checklists and Metrics
4.2 Conduct 4.2.1 Conduct Status Reviews Status Reviews
Project 4.2.2 Coordinate Architecture Reviews Architecture Rev. Results
Reviews
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.7 Support Operations Reviews Input to Ops Reviews
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 Key considerations in controlling project scope are

Considerations • 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?
Updated Investigate Includes:

Work Plan Change Project Charter Updated
Request Records/ Plans
ITMS Record Resource
Request
Risk Assessment
Recommend
Budget Plan
a Course of
Assign & Action
Schedule
Investigation
Change
Requested Obtain Change Yes Update Project
Approval Approved Plans &
? Records
Log New Group

Change Requests if
Request Appropriate No Obtain
Resources if
Required
Updated Close Request & Complete the

Change Log Communicate Request
Status
Process Guide
Process Tasks
1 Log New Change Ensure that the change request has been submitted on the Stakeholders
Request appropriate form and that sufficient details have been provided to
allow for assessment.
Note: All changes are to be logged, even small ones.
2 Group Requests Review change log to determine if other similar or related requests PM,
are outstanding. Group requests, if appropriate. Team
3 Schedule Assign a resource to investigate the request and add that effort to PM
Investigation the project schedule, as appropriate.
4 Investigate the Investigate the change and its potential impact on project Team
Change Request 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.
5 Recommend a Based on the investigation recommend a course of action. PM
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)
6 Obtain Approvals Any request that requires a change in the approved deliverables, PM,
resources, budget or end-date, a new project, or the use of project ESpon,
reserves must be approved. Recommendations to defer or reject Program Mgr
changes that have been submitted by the intended recipients of BusA,
deliverables should also be reviewed and signed off by the Cust
Customer and Sponsor.
7 Update Project Update project records and work, resource, budget plans, and PM
Records and SOW as appropriate. This includes updating the project record in
Plans ITMS, RMS and MRS.
8 Request Submit a resource request if additional resources are required and PM
Resources approved to complete the change.
9 Close the Notify the stakeholder who submitted the request of the decision to PM
Request & complete or reject the change request. Notify other stakeholders as
Communicate appropriate (e.g., the Project Mangers of related projects)
Status
Process Guide
eTracker – see http://www.etracker.ford.com/
229_Classic_SDM_Work_Plan.mpp 210_change_request_template.doc ESpon,
210_change_request_template.doc 211_change_request_log.doc Program Mgr,
211_change_request_log.doc Resource Request located at BusA,
02_Requirements_Specification.doc http://www.ads.ford.com/resman/ Stakeholders,
213_issue_log.doc Project Record in MRS http://www.ads.ford.com/mrs Competency Center,
229_Classic_SDM_Work_Plan.mpp Resource Mgmt,
212_risk_management_log.doc Demand Mgmt
SOW located at http://www.ads.ford.com 213_issue_log.doc
Logs listed or logs in eTracker
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 The questions/issues that need to addressed during this process are:
Considerations • 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 Determine project status and spending in relation to the approved plans. PM,
Schedule & Assemble pertinent materials, including the most recent weekly Team
Cost timesheets, expense reports, the current approved Project Plan and
Performance 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.
2 Analyze Analyze variances to determine their root causes and assess their impact PM
Variances 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

3 Log & Track Log any variance that requires corrective action as an issue and track PM
as an Issue accordingly.
4 Identify Identify the actions that must be taken to get the project back on PM,
Alternative track or keep it progressing on schedule. Distinguish between Team,
Solutions minor corrective actions (those that can be managed within the Program Mgr
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
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 Identify what action will be taken to correct the schedule or cost issue. PM,
Corrective Team
Action
6 Obtain Get signoff on actions that will alter the current approved schedule, budget PM,
Approvals or resource plan. If the schedule is changed, the Project Manager needs Sponsor
(as to notify the Competency Center. The resource's agency must approve the
Required) 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.
7 Update & Update project plans, as appropriate, and update and close the issue. PM
Close Issue
http://www.etracker.ford.com/
Earned Value Analysis see http://www.ads.ford.com/eva/
MS Project

229_Classic_SDM_Work_Plan.mpp Resource Request located at ESpon,
204_accelerator_use_plan http://www.ads.ford.com/resman/ Program Mgr,
210_change_request_template.doc 204_accelerator_use_plan BusA,
213_issue_log 210_change_request_template.doc Stakeholders,
213_issue_log Competency Center,
02_Requirements_Specification.doc Resource Mgmt,
Timesheets http://www.rms.ford.com 229_Classic_SDM_Work_Plan.mpp Demand Mgmt
SOW located at http://www.ads.ford.com Earned Value Analysis located at
http://www.ads.ford.com/eva/
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.
New Risk Weekly

Identified Status
Review
Log Risk Assess Develop Track & Risk No Raise Issue

the Risk Plans to Control Under
Manage Risk Control?
Yes
No Risk
Resolved
?
Yes
Updated Risk Close Risk &

Log & Plans Update Plans
Process Tasks
Process Guide
1 Identify and Log Identify a new Risk and log it into the Risk Management Log. Stakeholders
Risk 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.
2 Analyze Risk Work with project team mem bers to transform risk data into PM,
decision-making information. Categorize the risk in terms of how Team
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.
3 Develop Plans to Identify mitigation strategies (strategies to help minimize or avoid PM,
Manage the risk) and develop contingency plans (plans to go into effect if Team
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.
4 Track & Control Risk Review actions against plan to determine if mitigation strategies PM,
are working. Institute contingency plans if necessary or develop Team
new strategies to manage the risk.
5 Raise Issue Where risk management strategies are not working, raise an issue PM,
for immediate action. Team
6 Close Risk & Close risks that are no longer a potential threat to the timing, cost PM
Update Plans or quality of project deliverables or risks that have been converted
to an issue.
MS Project
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 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 The key considerations in monitoring and controlling issues are

Considerations
• 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?
Issue Weekly
Identified Status
Review
Resolve or
Log Issue Assign To Updated
Escalate
Resource for Work Plan Issue
Resolution
Develop Scope No Monitor Issue No

Resolution Change Issue Resolv
Strategy Required? Status ed?
Yes
Yes
Submit Change Request
Updated Close Issue

Issue Log
Process Guide
Process Tasks
1 Identify & Log Identify the issue and supply the following information to assess it Stakeholders
Issue 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 A proposed resolution or plan of action if
Solution known.
Comments Any other comments that will help the
Project Manager assign or escalate the issue
Note: Anyone involved in or impacted by the project can submit an
issue, including team members, users, support functions, etc.
2 Assign for Assign the issue for further investigation and resolution. Identify a PM,
Resolution due date and enter the information into the Issue Log (eTracker, if Team
in use). Update the work plan to reflect the new assignment.
3 Develop Develop a resolution strategy and review it with the project team. PM,
Resolution Determine if the strategy will require a change in the project scope. Team,
Strategy If it does, close the issue, submit a Change Request and manage BusA,
accordingly. Cust
4 Monitor Issue Review the status of the issue in weekly project status review PM
Status meetings.
5 Resolve or Resolve the issue within the project team or escalate it to the PM,
Escalate the Sponsor, Program Manager, or Business Analyst. Team,
Issue BusA,
ESpon
6 Close Issue Close Issues that are resolved and update the log entries PM,
accordingly. Team
MS Project
229_Classic_SDM_Work_Plan.mpp Issues in 213_issue_log.doc or Control File,
213_issue_log.doc eTracker Program Mgr,
02_Requirements_Specification.doc 229_Classic_SDM_Work_Plan.mpp BusA,
35_Quality_Control_Plan_and_Test_Strategy.doc or 210_change_request_template.doc ESpon,
89_QC_Plan_and_Test_Strategy_for_Enhancement_and_Support 211_change_request_log.doc 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 As shown on the diagram below, which depicts the relative cost of addressing
Considerations defects over the life of the project, the earlier in the life cycle a defect is found,
the less costly it is to correct.
120
100
80
60
40
20
0
Analysis Design Build
Implement
Source: International Institute of
Learning
Methodology/ Yes
Quality
Standards
Monitor Record Results
Process & Results Acceptable
Deliverables ?
Project Plans
& Deliverables
No
No
Implement Yes Rework or Determine

Rework or Improvement Course of
Improvement Required? Action
Process Guide
Process Tasks
1 Monitor Process Inspect deliverables and monitor the performance of required PM,
& Deliverables processes. Team
Inspections include activities such as measuring, examining, and
testing undertaken to determine whether deliverables conform to
requirements.
Monitoring of the process involves the use of checklists and
reviews to confirm that the process is being followed. It also
involves the use of control mechanisms to monitor cost and
schedule variances (earned value reports), the volume and
frequency of changes (change logs), the timely resolution of issues
(issues management logs), and other management results that
help determine that the process is in control and, thereby, that
quality is control.
2 Record Results Capture results on acceptance documents, control charts, trend PM,
analyses, checklists, and defect or incident reports, as appropriate. Team
Maintain records for use in project reviews.
3 Identify Issues Where defects or unacceptable results have been identified, PM,
and Determine determine what course of action is required. Defects in Team
Course of Action 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.
4 Complete Schedule and complete any rework or improvement required. PM,
Rework or Team
Improvement
Defect A defect is defined as a non-conformance to requirements. The purpose of

Management Defect Management is to ensure that defects are documented and resolved
Within Quality with a minimum impact on the project. Defects that are found during
Management inspections and testing are documented using the defect log and tracked to
Process 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
Defect Management Process Flow
A Adds a defect, status=“New”
No The defect is rejected,

Is it a defect?
status=Rejected
Yes
No Will it be addressed in
the current release? No Convinced with Yes
this resolution?
Yes
Assign the defect to a developer

B
status = “open”
Status=“Rejected”
Developer fixes the defect,

status=“fixed”
Rebuild the deliverable and roll to

the test environment where the
developer verifies the fix,
status=rolled Was the defect
associated with a
Update test cases as needed,
No change?
test the fix in test environment
Yes
New
Defect Current/New/ Defect Still Exists
A
Old found?
Defect Closed
The defect is Root Cause Change
deferred, Status=“Closed” Status=“Reopen” Done Follow the Change Management
Status=“Deferred” Process
1 Log Defect Enter the defect in TestDirector as 'New' and categorize the Person who found
defect (e.g.; Critical, Serious, Moderate, Cosmetic). the defect
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
2 Analyze Defect Analyze the defects reported and change their status to either - PM,
'Open', 'Deferred' or 'Reject'. LDevl,
QCTest
If 'Reject' or 'Deferred', specify in the 'R&D Column' on why it is
being rejected or deferred. If defects are 'Opened', assign them
for correction/fixing
3 Correct Defect Correct the defect. Using the configuration management system SDevl
(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.
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 Confirm that the application is functioning properly in the QC SDevl
Application environment prior to testing. Make sure that the correct
Readiness deliverable has been rolled to QC environment, and change the
status to 'Rolled'
6 Test Application Update Test Case(s) if necessary. QC Team,
BusA,
Re-run the tests as documented in the TestDirector. Sdevl,
Cust
If the defect is seen again – change the status to 'Re-Open'. (e.g.; who ever
raised the defect)
If the defect is addressed (not seen) – change the status to
'Closed'.
If a new defect is discovered, then log as "New".

7 Update Defect If a defect is 'Re-Opened' – all steps from step 2 are repeated. QC Team,
Status 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 212_risk_management_log.doc Control File,
Program Mgr,
213_issue_log.doc 213_issue_log.doc or eTracker BusA,
229_Classic_SDM_Work_Plan.mpp Acceptance Decisions ESpon,
Team,
233_Gate_Review_Checklists.xls Defects in 32_Defect_Log or Test Metrics
Director
239_PQA_Review_Report.doc
Process Adjustments
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
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 Key considerations in conducting status reviews are:

Considerations
• 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
CIO CIO Ops Reviews

Quarterly
WHEN From
To PSC WHAT
Director
IT DIRECTOR
Quarterly From IT Director Ops Reviews
To CBG/GEC
Manager
Exec
Monthly IT MANAGER Manager Ops

Reviews
To Business Manager
At End From Project Manager to IT Manager and
of SDM Business Partner
Stage Gate Reviews
During
SDM Project
Stage Architecture Project Status Reviews Reviews
Process Reviews
•ARB Health •Project Cost, Benefit, Timing Health
•Occurs for ID & Assess, •PQA Health
•Occurs for all Stages
Analysis, & Design Stages •Occurs for all Stages
•Many Times per Stage
•Once per Stage •Once per Stage
Process Tasks
1 Schedule Schedule a standing weekly status review meeting with core project PM
Weekly Status participants (the Customer, Business Analys t, and Project Team). If
Reviews appropriate, include the Sponsor and Program Manager in one or more
of those meetings each month. Create a standing agenda.
2 Prepare Prepare the standard weekly status report. Ensure that both the Project PM,
Materials Manager assessment and the Customer assessment are completed. Cust
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
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.
Green Red Yellow
NO NO NO NO
YES YES
Target dates & NO Recovery YES Recovery YES Recovery Plan YES Recovery on
deliverables are Plan is in Plan is Approved by Track Since
on track Place Resourced Stakeholders Last Review
3 Provide Access Be sure that participants have access to issue, change, and risk logs, PM
to Materials 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.
4 Review Status Review and agree on the project GYR status with the team. Analyze PM,
with Participants any Yellow or Red items to determine root causes and agree on an Cust,
action plan to address, accordingly. Team
5 Review Open Review the open items in the Issues, Risk and Change Request Logs. PM,
Issues, Risks Identify work completed and any items that can be closed. Agree on a Cust,
and Change course of action and team assignments for addressing for any new Team
Requests items.
6 Assess Results Review the results of inspections, testing, technical reviews (see PM,
of Quality section 4.2.4) and the most recent gate review to determine if the Cust,
Controls project is adhering to quality standards. Make assignments, as Team
necessary, to deal with any issues identified.
7 Review Team Allow each participant to provide a brief report out on work in progress. Team
Assignments Work with the team to determine if additional help is needed or other
corrective measures are warranted.
8 Assess Viability Look at the actual work completed in comparison to the project plan to PM,
of the Project determine if the business case is still valid. Determine if anything has ESpon,
changed since the project started that would invalidate the assumptions Program Mgr,
made in the goals and objectives. Review forecasts of project Cust,
completion and costs to determine if the project will deliver to promise. Team
Earned Value Analysis template at http://www.ads.ford.com/eva/
MS Project
RMS -- http://www.rms.ford.com
Process Guide
229_Classic_SDM_Work_Plan.mpp 221_weekly_status_report_template.doc Control File,
211_change_request_template.doc Earned Value Analysis Template at Program Mgr,
212_risk_management_log.doc http://www.its.ford.com/eva/ BusA,
213_issue_log.doc 211_change_request_template.doc ESpon,
221_weekly_status_report_template.doc 212_risk_management_log.doc Cust
Timesheets http://www.rms.ford.com Issues in 213_issue_log.doc or eTracker at
220_meeting_minutes_template.doc http://www.etracker.ford.com
32_Defect_Log.doc 220_meeting_minutes_template.doc
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 No key considerations provided for this process.

Considerations
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.
CIO CIO Ops Reviews

Quarterly
WHEN From
To PSC WHAT
Director
IT DIRECTOR
To CBG/GEC
Manager
Exec

Reviews
To Business Manager
Stage Gate Reviews
During
SDM Project
Process Reviews
Process Guide
Process Tasks

1 Coordinate Ensure that a required Architecture Review occurs. Refer to PM
Architecture the appropriate SDM Process Guide for details.
Review
2 Ensure Review Review results and ensure that any action items are reflected PM
Results are in project plans and completed.
Documented
3 Update Project Ensure that review documentation is stored in the project PM
Records Control File as appropriate.
Methods and Applications/Tool s
Classic_SDM_Process_Guide
Architecture Management Guidebook located at http://www.fsic.ford.com/architecturemanagement/
OneIT Architecture Review Board Workbook located at http://www.fsic.ford.com/architecturemanagement/
ARB review meeting minutes in ARB review meeting minutes in See SDM Guide
220_meeting_minutes_template.doc 220_meeting_minutes_template.doc
73_ARB_Workbook.xls completed to appropriate Update 73_ARB_Workbook.xls
level in system development lifecycle.
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 Instructions for preparing for metrics workshops (Initial, Interim, and Final)
Considerations 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 Ensure that a required Interim and Final Metrics Workshop PM,
Interim and occur. Refer to the appropriate SDM Process Guide for Team,
Final Metrics Metrics
details.
Workshops
2 Ensure Review results and ensure that any action items are reflected PM,
Workshop in project plans and completed, as appropriate. Team,
Results are BusA,
Documented Cust
3 Update Project Ensure that workshop documentation is stored in the project PM

Records Control File as appropriate.
Metrics meeting minutes in Metrics meeting minutes in 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 The main consideration here is

Considerations
• what type of project is being conducted
• what reviews are stipulated for that type of project
rd
• 3 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 Verify that the appropriate submissions and registrations have been PM
Submissions/ completed.
Registrations
2 Coordinate Coordinate scheduling of review sessions. PM
Scheduling
3 Participate in Make self and team members available for participation in the review SCC,
Process Guide

Review sessions as appropriate. Identify a team member to record the session PM,
Sessions and make note of any changes required to satisfy requirements or issues Team,
that need to be resolved. Reviewers as
appropriate
4 Monitor Monitor completion of the changes identified in the session or PM
Resolution of issues that need to be resolved.
Issues
5 Verify final Verify that final approval is obtained prior to launch and archive PM
approval records.
Security review meeting minutes in Security review meeting minutes in 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 See the appropriate SDM Process Guide.

Considerations
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
CIO CIO Ops Reviews

Quarterly
WHEN From
To PSC WHAT
Director
IT DIRECTOR
To CBG/GEC
Manager
Exec

Reviews
To Business Manager
Stage Gate Reviews
During
SDM Project
Process Reviews
Process Guide
Process Tasks
1 Coordinate PQA Ensure that a required PQA Review occurs. Refer to the appropriate PM,
Review SDM Process Guide for details. Team,
PQA
2 Ensure Review Review results and ensure that any action items are reflected in project PM,
Results are plans and completed. Team
Documented
3 Update Project Ensure that review documentation is stored in the project Control File PM
Records as appropriate.
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 At this point in the process, there are two key decisions that must be made: 1)
Considerations 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?
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
CIO CIO Ops Reviews

Quarterly
WHEN To PSC From
Director WHAT
IT DIRECTOR
To CBG/GEC
Manager
Exec

Reviews
To Business Manager
Stage Gate Reviews
During
SDM Project
Process Reviews
Analysis, & Design Stages •Occurs for all Stages •Many Times per Stage
Process Guide
Process Tasks
1 Schedule The end date of each stage should be clearly identified in the project plan. PM
Review 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).
2 Collect Pull together all of the materials that may be required to explain the PM
Backup current state of the project, including the PQA R/Y/G rating, ARB R/Y/G
Materials for rating, the status of issues, risks, and change requests, and recent status
Meeting 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.
3 Complete the Obtain the appropriate Gate Review Checklist and complete the Yes/No PM,
Review checkboxes. Cust
Checklists Note that 6-Sigma Tollgate questions have been included in the Gate
Review Checklist.
4 Assess Review the completed Gate Review checklist, current status, risk rating, PM,
Project change logs, issue log, risk management log, with the Customer and BusA Cust
Viability Business Analyst to jointly arrive at a recommendation as to the viability of Program Mgr
the project prior to the actual gate review. Typically this is performed at a
regular project status meeting.
5 Conduct During the gate review, present and review the completed Gate Review PM,
Review checklist and, if necessary, any backup/supporting materials needed to BusA,
explain the current state of the project. Cust
Review recommendations made by the Project Manager, Business As necessary:
Analyst and Customer on the continued viability of the project. ESpon,
AppOwn,
Make Overall Project R/Y/G Rating, Go/No-Go Decision, and if Program Mgr,
appropriate, a recommendation to terminate the project. These decisions PQA,
may take the following forms: AMCoord,
• Overall R/Y/G rating becomes the lowest of the ARB, PQA and PM for related
Project Status R/Y/G ratings projects,
APM/LOB,
• Continue as planned Practice Mgr,
• Continue in a watch state for a specified short-interval and review the 6-Sigma,
status again at the end of that period Stakeholders,
Vendor/Suppli
• Continue the project under the condition of specified changes in the er
current plan (create Change Requests, as appropriate)
• Terminate the project
Guidelines on When to Consider Terminating a Project
When it no longer When the project is no longer contributing to the

has business/ organization’s long- or short-term business
strategic value strategies.
Process Guide
When it is no When the project cannot be done properly with

longer feasible the available resources or under the current
circumstances.
When When even the best efforts of the project team

deliverables and aggressive corrective action (changes to the
continually fail to plan, scope, or resources) fail to produce desired
appear results.
When there are When issues outnumber the successfully
more issues than completed milestones and deliverables.
successes
When the budget When budget or resource allocations are
stops continually exceeded or substantial unreported
representing overtime is required to meet milestones.
reality
6 Obtain Obtain signatures on the Gate Review Checklist Forms from the PM
Signatures appropriate decision makers including the customer responsible.
Cust
Others, as
necessary
7 Communicate Communicate the overall project R/Y/G rating and the go/no-go decision PM
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.
8 Update Store minutes and other documentation of the review in the project PM
Project Control File. Update the project record in ITMS, RMS and MRS.
Records
Process Guide
MS Project

Results of ARB Reviews 211_change_request_template.doc BusA,
Control File,
Results of PQA Reviews 220_meeting_minutes_template.doc Cust,
200_project_charter_template.doc 221_weekly_status_report_template.doc IT Management,
Stakeholders,
206_risk_assessment_template.xls 233_Gate_Review_Checklist Team,
ITMS,
211_change_request_template.doc Go/No-Go Decision / Recommendation to Terminate (if ESpon
appropriate)
212_risk_management_log.doc
Issues in 213_issue_log.doc or eTracker
213_issue_log.doc
Overall Project R/Y/G Rating
215_communication_plan_template.doc
Project Record in RMS http://www.rms.ford.com
Risks in 206_risk_assessment_template.xls and
Current Earned Value Report 212_risk_management_log.doc
Process Guide
4.2.7 Support Operations Reviews
Purpose Operations reviews provide the means to assess programs and projects within the context of an
organization’s entire portfolio of work.
Trigger Monthly or quarterly review or a project portfolio.
Key No key considerations specified for this process.

Considerations
Diagram The following diagram shows the periodic reviews that must be supported, including gate reviews
at the end of each stage, weekly status reviews and various levels of operations reviews that are
conducted on a monthly and quarterly basis (see items identified by red arrows).
CIO CIO Ops Reviews

Quarterly
WHEN From
To PSC WHAT
Director
IT DIRECTOR
To CBG/GEC
Manager
Exec

Reviews
To Business Manager
Stage Gate Reviews
During
SDM Project
Process Reviews
Process Guide
Process Tasks
1 Ensure Ensure that project records in ITMS, RMS and MRS are kept current and PM
Project accurately reflect the true status of the project.
Records are
Kept Current
2 Provide Be prepared to provide a current status report if requested. PM,
Current Cust
Status
Report
3 Prepare Ensure that project records (documentation) are ready for review if PM
Backup requested – particularly if the current status of the project is yellow or red.
Material as
Required
221_weekly_status_report_template.doc Project Record in MRS Control File,
Project Control File http://www.ads.ford.com/mrs Sponsor,
Results of Gate Reviews Project Record in RMS http://www.rms.ford.com IT Management,
Results of ARB Reviews Project Record in ITMS http://www.itms.ford.com/ Cust
Results of PQA Reviews
Process Guide
Process Guide
5.0 Close Project
Project Management Processes

Resource Plan
Procurement Initiate
Plan Communication
Plan
Budget Plan Plan
Work Plans
Project Charter
Execute
Work Products
Solution
Delivery Control
Methodology
Close
Inputs to Close Project
Overview Closure is the formal end-point of a project, either because it is completed or

because it has been terminated. Termination may occur because the project is
no longer viable or because the risks associated with it have become
unacceptably high.
Formal closure finalizes the project in the eyes of the stakeholders and provides
a learning opportunity. It is also the point at which issue and change logs are
closed, project accounts are reconciled, resources are released, feedback is
solicited from stakeholders, and work products are archived for future reference.
Process Contents
5.1 Finalize 5.1.1 Finalize Implementation Implementation as Planned
Note Delivery
Refer to PM Processes 5.1.2 Finalize Transition Handover to Support
"3.0 Execute Project" 5.2 Conduct Final
and "4.0 Control 5.2.1 Administer Major Release Survey Feedback on Project
Project
Project" for processes Review 5.2.2 Conduct Wrap-up Session Lessons Learned/Metrics
such as "Maintain
Project Records" or 5.2.3 Prepare Closure Report Completion Documents
"Conduct Status
Reviews" for process 5.3 Perform 5.3.1 Release Resources Released Resources
steps that must be Administrative
carried out across all and Financial 5.3.2 Complete Financial Closure Budget/Contract Closure
five PM Processes Closure
(Initiate, Plan, Control, 5.3.3 Close & Archive Records Closed/Archived Records
Execute, Close).
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 Key considerations for this process step include:

Considerations
• 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 Ensure that final implementation tasks are executed as PM,

Implementation planned. If the project is closing because it has been Cust,
Plans terminated, finish any implementation steps that are Support Activities
appropriate.
2 Update Project Update project records to reflect that implementation plans have PM
Records been executed as appropriate.
Implementation Plans Project Record in RMS http://www.rms.ford.com Control File,
Project Record in MRS http://www.ads.ford.com/mrs 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 Key considerations for this process step include:

Considerations
• 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 Ensure that final transition tasks are executed as planned. If the PM,
Transition project is closing because it has been terminated, finish any Cust,
Plans transition steps that are appropriate. Support Activities
2 Update Update project records to reflect that transition plans have been PM
Project executed as appropriate.
Records
Microsoft Word
http://www.itonline.ford.com/sdm/docs/Templates/245_IT_Systems_Quick_Referenc e_For_Project_Managers_and_Application_Managers.doc
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 The key considerations in soliciting and obtaining Customer feedback are:
Considerations • 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 Project Manager will add/update user list in MRS with names of PM Cust(s)
Feedback individuals who should receive a support survey from MRS,
being sure to include the Business Analyst, Program Manager,
Customer, and Sponsor.
2 Solicit QC Ask the Quality Control Test Specialist (QCTest) to provide the PM,
Feedback QC final reports for filing in the Project Control File. QCTest
3 Assess Review and summarize completed results. PM
Feedback
Results
4 Share results Share summarized results with participants. Add completed PM,
ESpon(s),
and thank surveys and summary report to Project Control File. Thank
Cust(s),
participants participants.
Team
Process Guide
Microsoft Word / Project Record in MRS http://www.ads.ford.com/mrs

201_stakeholder_assessment_template.doc Major Release Survey ESpon (s),
Cust(s),
203_team_directory_template.doc 85_QC_Final_Report_Metrics_Spreadsheet located at QC Team,
web site http://www.sdg.ford.com/qc/ Metrics
84_QC_Final_Report_Management_Summary located at
QC web site http://www.sdg.ford.com/qc/
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 The key questions to be addressed in the final assessment are:

Considerations
• 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 Schedule a wrap-up session with members of the project team. PM,
Hold the Arrange for a facilitator if possible. Ask participants to review Team,
Meeting documents in the Project Control File ahead of time to refresh Metrics
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.
2 Compare Compare the final project schedule, resource utilization, budget, PM,
Actuals to and deliverables to the original plan: Team,
Project Plans Metrics
• 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?

3 Evaluate Evaluate the project management and solution delivery PM,
Methodology methodologies used on the project. Determine what worked Team
well and what could have been improved.
4 Review Team Assess the make up of the team to determine if it was effective. PM,
Make-up Team
• Were the right people/skill-sets on the team?
Process Guide
• Were ad hoc members useful?

5 Review the Review the results of gate reviews conducted during the life of PM,
Results of the project. Determine if lessons can be learned from those Team
Gate Reviews results.
6 Review Review feedback obtained as part of the Solicit Feedback PM,
Feedback process. Identify lessons learned from that feedback. Team
7 Document & Document all lessons learned and any recommendations made PM,
File Lessons by the group and add to Project Control File. Share lessons Team
Learned learned with local management as required.
Microsoft Word
Brainstorming
Facilitated Session
Results of Customer and team satisfaction 211_change_request_log.doc Team,
surveys 212_risk_management_log.doc Metrics
211_change_request_log.doc 213_issue_log.doc
212_risk_management_log.doc 222_lessons_learned.doc
213_issue_log.doc 220_meeting_minutes_template.doc
220_meeting_minutes_template.doc
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 No key considerations provided for this process

Considerations
Process Tasks
1 Create Project Create a report with the following sections: PM

Closure Report
Reason for State the circumstances under which the project
Closure: is being closed.
Objectives Import the Deliverables section from the Project
Achieved: Charter and identify which ones are completed.
Project Describe metrics that demonstrate how effective
Proficiency: the project was in resolving issues, managing
risks and scope, and producing deliverables.
Lessons Summarize highlights of the lessons learned as
Learned: determined in the Team Wrap-up Session.
Results of Summarize feedback obtained from the project
Feedback: team, Customer(s) and sponsor(s).
Acknowledge Acknowledge individuals who have made special
ments: contributions to the project.
2 Issue Notification Complete and distribute a Completion Notification Letter. PM,
Letter Cust
3 Review & Finalize Review the Closure Report with the Customer and obtain sign-off. PM,
Closure Report Cust
4 Archive Signed Add the signed Closure Report to the Project Control File. PM
Closure Report
5 Change Project Send a note to RMSHELP to change the project status to "Closed". PM
Status in RMS
Process Guide

Microsoft Word
200_project_charter_template.doc 223_closure_report_template.doc Control File,
229_Classic_SDM_Work_Plan.mpp 224_completion_notification_template.doc ESpon,
222_lessons_learned.doc 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 The key considerations in releasing resources are:

Considerations
• 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 Send an MS-Outlook note to the appropriate Competency Center AppSupr,
Competency Manager 30 days prior to the release and notify him/her that the Competency
Center of resource will be released and the date of the release. If the Center Manager
Upcoming resource doesn't know whom their manager is, the note should be
Releas e of a sent to Don Bartkowiak (DBARTKOW).
Ford ADS
Note: As per the new Competency Center Guide, Ford ADS
Resource
resources will have been assigned a Competency Center Manager.
The Application Supervisor should obtain the Competency Center
Manager's name from the resource.
2 Notify Agency of Send an MS-Outlook note to the appropriate agency representative AppSupr, Agency
Upcoming 2 weeks prior to the release and notify him/her that the resource Representative
Release of will be released and the date of the release.
Agency
Resource
3 Notify RMS of Send an MS-Outlook note to cdsid RMSHELP to inform them that AppSupr
Resource the resource will no longer be working on the application and
Release should not bill against it any longer.
4 Perform Exit Follow the instructions at the exit procedure link located at AppSupr
Procedure http://www.ads.ford.com/facilities/. This procedure covers the
removal of application access, building access and other tasks.
Process Guide

Microsoft Word
Interim Resource Management Process http://www.ads.ford.com/resman/
203_team_directory_template.doc Team Evaluations Team
223_closure_report_template.doc Notification of release of resources
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 The key considerations in completing financial closure are

Considerations
• 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?
Communicate Close Charge

Project Closure Codes
Project
Schedule
Project
Contracts Confirm Project Confirm Contract Yes
Completion Contract Fulfilled?
Budget Plan Date Fulfillment
Project Closure
Report
Resolve No Close Contract
Contract Issues
Process Tasks
1 Confirm the Once a project is closed, there should be no need to apply labor or PM
Closure or resources against the project because it will be delivered or turned
Completion Date over to operations. Any further work done on the product beyond this
Process Guide

date should be considered operations and maintenance costs.
2 Communicate Project staff, management, and RMSHELP need to be told as far PM
Closure Date 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.
3 Close Charge Most projects have account numbers associated with them that allow PM,
Codes financial departments to track labor hours and resource procurement. FinanceAnal
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.
4 Confirm Contract In order to close a contract, it is important to collect all pertinent PM,
Fulfillment documentation for review. This includes all of the original contracts Purchasing,
and supporting documentation such as schedules, contract changes, OGC
and performance reports. This documentation needs thorough
review to ensure that there are no unrealized contract issues that
could result in legal liability.
5 Resolve Contract Reconcile the actual utilization of contract resources against the PM,
Issues planned utilization. Reconcile actual costs against planned costs. Purchasing,
Terminate all arrangements for the use of resources, including leases OGC
and contractual agreements.
6 Close Contract Produce any written contract closure documentation required by the PM
vendor.
Process Guide
Microsoft Word
WebTracs
MRS User and Quick Referenc e Guides are located at http://www.ads.ford.com/mrs/documentation.htm.
229_Classic_SDM_Work_Plan.mpp Charge Code Closure Control File,
223_closure_report_template.doc Closed Contracts Purchasing,
Project Record in RMS http://www.rms.ford.com OGC,
Project Record in MRS http://www.ads.ford.com/mrs Demand Management,
229_Classic_SDM_Work_Plan.mpp MRS Plans Database
Project Record in ITMS http://www.itms.ford.com/
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 The key considerations in closing and archiving project records are
Considerations
• 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 Prepare project deliverables and records for handover. Ensure that PM
Deliverables the correct versions are passed to other teams and that the recipients
know how to access and update them, as appropriate.
2 Close Project in Update the Project State in ITMS so that it shows a status of BusA
ITMS "Complete".
3 Close Project Close records that describe the project. Ensure that the project is PM
Logs and Records accurately reflected in ITMS, RMS, MRS and any local systems used
to track IT projects.
4 Review Work Review work products in the Project Control File to determine if it PM
Retention should be maintained for reuse or legal purposes.
5 Archive Work The first rule of archiving project products is -- if it was important to PM
Product or Discard 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.
Process Guide
GIRS
Records Retention Policies 225_archive_documents_checklist.doc Control File,
Project Deliverables Updated ITMS Record at Metrics
Project Control File http://www.itms.ford.com/
Records Retention Policies Archived Work Products
225_archive_documents_checklist.doc Project Record in RMS http://www.rms.ford.com

PM Process Guide

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PM Process Guide

Caricato da

Copyright:

Formati disponibili

Project Management

Originator: One IT PPM Team Page 1 of 157 Date Issued: 2002-Apr-12

Version Date Author(s) Revision Notes

Originator: One IT PPM Team Page 2 of 157 Date Issued: 2002-Apr-12

Originator: One IT PPM Team Page 3 of 157 Date Issued: 2002-Apr-12

Originator: One IT PPM Team Page 4 of 157 Date Issued: 2002-Apr-12

Originator: One IT PPM Team Page 5 of 157 Date Issued: 2002-Apr-12

Portfolio Programs and projects originate within the Portfolio Management

Portfolio Management Process Flow

Originator: One IT PPM Team Page 6 of 157 Date Issued: 2002-Apr-12

Definition of Project management is defined as directing the activities

Build Organizational Impact

Design Scope Communications

Originator: One IT PPM Team Page 7 of 157 Date Issued: 2002-Apr-12

Project Project management processes as defined by the Project Management Institute

Figure 1.2 - Core Project Management Processes

Originator: One IT PPM Team Page 8 of 157 Date Issued: 2002-Apr-12

Integration Ensure that all elements of the project are coordinated

Originator: One IT PPM Team Page 9 of 157 Date Issued: 2002-Apr-12

Figure 1.3 – Project Management alignment to Project Life

Originator: One IT PPM Team Page 10 of 157 Date Issued: 2002-Apr-12

Key Key Principles will be placed in this section

Understanding and managing requirements is crucial

Planning is everything and ongoing

Control is a necessity, not a luxury

Customers must be part of the process

Metrics should be collected throughout the project life cycle

Originator: One IT PPM Team Page 12 of 157 Date Issued: 2002-Apr-12

ID & Support &

Function Points per Staff Month Support Cost per

Cost Variance (Budgeted less Actual Cost of Work)

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

Customer Satisfaction Scores

Figure 1.4 Metrics captured over the project life cycle

Originator: One IT PPM Team Page 13 of 157 Date Issued: 2002-Apr-12

§ WebTracs: WebTracs is a web-enhanced budget and cost tracking application intended to

Originator: One IT PPM Team Page 14 of 157 Date Issued: 2002-Apr-12

o Provide consistent information between financial reports produced by Strategic Planners

o Manage resource acquisition placement, and release process.

o Provide a time keeping, and financial reporting solution.

Originator: One IT PPM Team Page 15 of 157 Date Issued: 2002-Apr-12

Originator: One IT PPM Team Page 16 of 157 Date Issued: 2002-Apr-12

• Purchase, from outside sources, of "off-the-shelf" computer software programs.

• Development of "Internal-Use" custom Ford computer software programs developed

• Acquisition or modifications of fixed assets (land, building, equipment, vehicles,

• Major repair, maintenance, and overhauling of equipment, including all nonrecurring

• Supplier agreements involving contingent liabilities (as defined by FM 55-10-70). If a

• Acquisition or granting of easements, right of way, or licenses.

• Acquisition or granting of options to purchase or lease (including leases of office

• Disposal of capitalized assets.

• Items normally included in overhead expense accounts and budgets, such as

Originator: One IT PPM Team Page 17 of 157 Date Issued: 2002-Apr-12

• Items less than $25,000 at the discretion of the Controller/Finance Manager,

• Cost information must be entered by an authorized MEARS user in the PAR.

• An Authorized MEARS user (Controller/Finance Manager) reviews and

• Cost information from the approved PAR is automatically transferred from

• The PO is created by the Purchasing Buyer in the purchase order application

Process Participant Roles

Originator: One IT PPM Team Page 18 of 157 Date Issued: 2002-Apr-12

Originator: One IT PPM Team Page 19 of 157 Date Issued: 2002-Apr-12

data model changes for compliance with Ford data standards.

ImpA Implementation Develop deployment-related materials, implementing the End User

ITET&D IT Learning – Create application-specific training materials as well as End User