Project Management Process Guide for Information Resource ...

Project Management Process Guide

for Information Resource Projects

November 2009

V 2.01

TTUHSC IR Project Management Process Guide

Version 1.00 2 Last update: 12/15/2009 4:09 PM

1.0 Introduction.................................................................................................................................................... 4 1.1 Purpose ............................................................................................................................................................................ 4 1.2 Scope................................................................................................................................................................................ 4

1.2.1 Definitions .................................................................................................................................................................. 4 1.2.1.1 What is a Process? ............................................................................................................................................... 4 1.2.1.2 What is an IR Project? ......................................................................................................................................... 4 1.2.1.3 What is the Project Management Office? ............................................................................................................ 4 1.2.1.4 What is Project Management? ............................................................................................................................. 5

1.3 Benefits ............................................................................................................................................................................ 5 1.4 Triple Constraints and Quality ......................................................................................................................................... 6

2.0 The Project Management Process ................................................................................................................ 7 2.1 Applicability .................................................................................................................................................................... 7 2.2 Project Processes .............................................................................................................................................................. 7 2.3 Five Process Groups ........................................................................................................................................................ 9 2.4 Knowledge Areas ........................................................................................................................................................... 10 2.5 TTUHSC Project Management Activity Flow ............................................................................................................... 11 2.6 Project Management Process Flow ................................................................................................................................ 12 2.7 Project Classification ..................................................................................................................................................... 12 2.8 Project Management Approval Processes and Deliverables .......................................................................................... 14 2.9 Portfolio Management at TTUHSC ............................................................................................................................... 16

3.0 Document Management .............................................................................................................................. 17 3.1 Guidelines to Records Retention .................................................................................................................................... 17

4.0 Roles in the Process ..................................................................................................................................... 19 5.0 Project Initiation .......................................................................................................................................... 20

5.1 Initiation Activities ........................................................................................................................................................ 21 5.2 Initiation Roles ............................................................................................................................................................... 22 5.3 Initiation Deliverables .................................................................................................................................................... 22 5.4 Business Case ................................................................................................................................................................ 23 5.5 Statewide Impact Analysis ............................................................................................................................................. 24 5.6 Project Charter ............................................................................................................................................................... 24 5.7 Business Justification Stage Gate .................................................................................................................................. 26

6.0 Planning ........................................................................................................................................................ 27 6.1 Description of the Project Plan ...................................................................................................................................... 28 6.2 Scope of the Project ....................................................................................................................................................... 28 6.3 Planning Activities ......................................................................................................................................................... 28 6.4 Planning Roles ............................................................................................................................................................... 30 6.5 Planning Roles ............................................................................................................................................................... 30 6.6 Project Plan Deliverables ............................................................................................................................................... 30 6.7 Project Scope Statement ................................................................................................................................................ 32 6.8 Work Breakdown Structure ........................................................................................................................................... 33 6.9 Work Breakdown Structure (WBS) Dictionary ............................................................................................................. 34 6.10 Network Diagram .......................................................................................................................................................... 34 6.11 Project Schedule ............................................................................................................................................................ 35 6.12 Budget ............................................................................................................................................................................ 35 6.13 Measures ........................................................................................................................................................................ 38 6.14 Project Management Plan .............................................................................................................................................. 38 6.15 Communication Plan ...................................................................................................................................................... 39 6.16 Configuration Plan ......................................................................................................................................................... 40 6.17 Performance Management Plan ..................................................................................................................................... 41 6.18 Risk Management Plan .................................................................................................................................................. 42 6.19 System Development Plan ............................................................................................................................................. 42 6.20 Acquisition Plan ............................................................................................................................................................. 45

7.0 Executing ...................................................................................................................................................... 47 8.0 Monitoring and Controlling ........................................................................................................................ 50

8.1 Scope of the Process ...................................................................................................................................................... 51 8.2 Monitoring and Controlling Activities ........................................................................................................................... 51 8.3 Monitoring and Controlling Roles in the Process .......................................................................................................... 52 8.4 Monitoring and Controlling Roles ................................................................................................................................. 52



8.5 Monitoring and Controlling Deliverables ...................................................................................................................... 52 8.6 Continuously Monitor Progress ..................................................................................................................................... 53 8.7 Conduct Team Reviews ................................................................................................................................................. 54 8.8 Conduct Formal Progress Reviews ................................................................................................................................ 54 8.9 Manage Changes ............................................................................................................................................................ 55 8.10 Revise the Plan ............................................................................................................................................................... 55 8.11 Conduct Work Product Reviews .................................................................................................................................... 56 8.12 Verification Activities .................................................................................................................................................... 57

9.0 Project Closure ............................................................................................................................................. 58 9.1 Scope of the Lessons Learned Process .......................................................................................................................... 59 9.2 Closing Activities .......................................................................................................................................................... 59 9.3 Closing Roles ................................................................................................................................................................. 60 9.4 Closing Roles ................................................................................................................................................................. 60 9.5 Closing Deliverables ...................................................................................................................................................... 61 9.6 Overview of the Closing Process ................................................................................................................................... 61 9.7 Define the Process to Use .............................................................................................................................................. 62 9.8 Build Data Gathering Instruments ................................................................................................................................. 62 9.9 Gathering Information ................................................................................................................................................... 63 9.10 Conduct the Lessons Learned Review Session .............................................................................................................. 63 9.11 Documents Results From Session .................................................................................................................................. 64 9.12 Measures ........................................................................................................................................................................ 65 9.13 Verification Activities .................................................................................................................................................... 65 9.14 The Closing Process ....................................................................................................................................................... 65

10.0 Glossary ........................................................................................................................................................ 67 11.0 Document Revision History ........................................................................................................................ 75 12.0 References ..................................................................................................................................................... 76 13.0 Revision History ........................................................................................................................................... 77



1.0 INTRODUCTION

1.1 Purpose

The Process Guide provides Texas Tech University Health Sciences Center (TTUHSC) departments with

a consistent approach for the management of Information Resource (IR) projects. This process guide

complements the IR Project Management Policy and IR Project Management Standard.

1.2 Scope

The processes and procedures described in this guide are generally applicable to the management of all

TTUHSC IR projects. However, projects identified as major information resource projects are also subject

to the Major IR Project Deliverables and must meet the minimum requirements and guidelines for the

Department of Information Resources (DIR) Texas Project Delivery Framework located at

http://www.dir.state.tx.us/pubs/framework/.

Project management processes form an approach for the initiation and management of IR projects, as well

as the completion of project management documentation. As appropriate, tailor the processes to match the

size and complexity of the individual business area projects. A glossary is at the end of the document.

This document covers processes associated with the project management lifecycle only. Processes

associated with the system development lifecycle are outside the scope of this text.

1.2.1 Definitions

1.2.1.1 What is a Process?

The characteristic of an effective process is that the process reliably delivers specific outcomes.

That is, cost estimates and schedule commitments must be met with reasonable consistency, and

the resulting products should generally meet users‟ functional and quality expectations

(Humphrey, 1989). Meeting those goals requires a method for proceeding and a system for

documenting project activities. The process works roughly the same way and produces roughly

the same result each time (successful project). The project management process is a repeatable

set of tools, methods, and processes used to conduct a project.

1.2.1.2 What is an IR Project?

As defined in Information Resource (IR) Project Management Policy, the project is an IR project

if the planned work (project) has any of the following characteristics or purposes:

Builds or buys a new software application and/or interfaces;

Enhances or maintains an existing software application;

Conducts IR research, discovery, feasibility, or proof of concept as part of the project‟s

scope;

Provides technology solutions to support business innovation, optimization, or

consolidation;

Performs systems or data optimization; or

Buys new or enhances existing IT infrastructure.

1.2.1.3 What is the Project Management Office?

The Complete Project Management Office Handbook, Second Edition identifies the function of

the PMO as:

http://www.dir.state.tx.us/pubs/framework/



the essential business integrator of the people, processes, and tools that manage or

influence project performance

applying professional project management practices and successfully integrates business

interests with project goals

According to the Project Management Institute (PMI) Program Management Office

Significant Interest Working Group (PMOSIG), the PMO is:

a strategic driver for organizational excellence and seeks to enhance the practices of

execution management, organizational governance, and strategic change leadership.

1.2.1.4 What is Project Management?

Project Management is the application of knowledge, skills, tools, and techniques to project

activities in order to meet or exceed stakeholder needs and expectations (PMBOK, 2004). As

defined in Information Resource (IR) Project Management Policy, the project is an IR project if

the planned work (project) has any of the following characteristics or purposes:

1.3 Benefits

The benefits of using an effective project management process include:

Compliance with House Bill (HB) 1789, Texas Administrative Code (TAC) §216

Cost estimates and schedule commitments are met with reasonable consistency, and the resulting

products generally meet users‟ functional and quality expectations

As project requirements change, the process guides the clients and stakeholders toward a

satisfactory solution

The project management process is explainable and understandable

Informs stakeholders of the work, gives confidence in decisions, and gives stakeholders faith in

the results

Repeatable – repeating processes in the same way will produce the same result

Measurable - evaluate or estimate the processes to numerically represent the process being

controlled and to provide a basis for action

Reliable – the customer expectation that the probability of the product functioning without failure

is low

Predictable - cost estimates and schedule commitments can be met with reasonable consistency

while the end product should generally meet users‟ functional and quality expectations



1.4 Triple Constraints and Quality

Project managers often talk of a “triple constraint” – project scope, time, and cost – in managing

competing project requirements. The relationship among these factors is such that if any one of the three

factors changes, at least one other factor is likely to be affected. Project quality is affected by balancing

these three factors. High quality projects deliver the required product, service, or result within scope, on

time, and within budget. Product quality is a blend of functionality and how well the product works. Some

quality factors are (see glossary for definitions) availability, efficiency, flexibility, integrity,

interoperability, reliability, robustness, usability, maintainability, portability, reusability, and testability.

Project managers also manage projects in response to uncertainty. Project risk is an uncertain event or

condition that, if it occurs, has a positive or negative effect on at least one project objective (see Figure 1-

1).

Figure 1-1

Figure 1-1 Project Management Institute’s Triple Constraint



2.0 THE PROJECT MANAGEMENT PROCESS

2.1 Applicability

Scale the application of the processes, procedures, and concepts to the size and complexity of each

project.

Meeting stakeholder needs and expectations for projects requires a clear definition of the business

problem or opportunity with well-defined goals and success criteria. The basic questions for defining the

success criteria are “Why are we doing this project?” and “How will we know when the project is done?”

Criteria for project success must be expressed in terms of value and must be measurable. There are four

aspects to project success the process focuses on:

Does the project meet the documented requirement specifications (meet the defined business goals

and objectives)?

Was it completed on time?

Was the project completed within the approved budget?

Quality – the degree to which the product satisfies both stated and implied requirements.

The process is only as effective as the project team using the process. The skill with which the process is

used is at least as important as the process itself.

2.2 Project Processes

There are two kinds of lifecycles associated with a project:

Project management processes deal with describing and organizing the work of the project. The

processes in this document use five Project Management Process Groups (initiation, planning,

executing, monitoring & controlling, and closing).

The product development lifecycle (also known as systems development lifecycle (SDLC)) deals

with specifying, creating, delivering, and, after deployment, maintaining the final product.

Maintaining or evolving the product is not part of the project (see Figure 2-1). Details for system

development processes are beyond the scope of this document. However, typical TTUHSC system

development phases are described in the TTUHSC IT Policy 9.5 Information Services Coding

Standards, Security, and Audit Controls at http:www.ttuhsc.edu/it/policy/coding.aspx.

http://www.ttuhsc.edu/it/policy/coding.aspx



Figure 2-1 Project and Product Lifecycle Relationships



2.3 Five Process Groups

This document describes standardized project management processes and a generally accepted industry

standard approach. Project management processes are presented as discrete elements which define a

process group. The process groups and the constituent processes are used to apply appropriate project

management knowledge and skills during the project (PMBOK, 2004). The five process groups are in

Table 2-1:

Process Group Activity

Project Initiation Identifying the business need and proposed solution, as well as,

justifying and packaging a business case for approval. Authorizes

the project and the project manager.

Project Planning Defining and refining objectives and a course of action.

Project Execution Integrating people and resources to carry out the project work.

Project Monitoring and Control Measuring progress, identifying variances, taking corrective actions.

Project Closing Gaining acceptance of the project product, bringing the project to an

orderly end including delivering the product.

Table 2-1 Process Groups

For ease of understanding, the five process groups are described in sequence. In practice, multiple

processes from different process groups can be in progress simultaneously to manage and control various

planned work and unplanned events taking place during the project lifecycle. The Figure 2-2 illustrates

the Project Management Lifecycle (PMLC) using process groups.

Figure 2-2 The Five Project Lifecycle Process Groups (PMBOK, 2004)



Note the length of time for completing a process group varies from project-to-project. Project initiation

and closing processes are performed once per project or per phase. Planning and execution, as well as,

monitoring and controlling are processes performed throughout the life of the project (see Figure 2-3).

Closing

Level of

Activity

Time

InitiatingInitiating

Planning

Monitoring &

Control

Monitoring &

Control

Executing

Figure 2-3 Overlap of the Five Process Groups Over the Life of a Project (PMBOK,1996)

2.4 Knowledge Areas

In addition to the five process groups, Project Management Institute (PMI) suggests there are nine

knowledge areas that must be considered and applied by the project manager. They are:

1. Integration Management: areas required to ensure the various elements of the project are properly

coordinated. Includes overall plan development, execution, and control of the project.

2. Scope Management: areas required to ensure the project includes all the work required and only the

work required to complete the project successfully. Includes scope definition, verification or

elaboration, and change control.

3. Time Management: areas required to ensure timely completion of the project. Includes identifying

specific activities to be performed, sequencing, estimating duration, and developing and controlling

the schedule.

4. Cost Management: areas required to ensure the project is completed within the approved budget.

Includes resource planning, cost estimating, budgeting, and cost control.

5. Quality Management: areas required to ensure the project will satisfy the needs for which it was

undertaken. Includes quality planning, assurance, and control.

6. Human Resources Management: areas required to make the most effective use of the people involved

with the project. Includes organizational planning, staff acquisition, and team development or

training.

7. Communications Management: areas required to ensure timely and appropriate generation,

collection, dissemination, and storage of project information. Includes performance reporting and

administrative closure.

8. Risk management: the systematic process of identifying, analyzing, and responding to project risk.

Includes maximizing the probability and consequences of positive events and minimizing the

probability and consequences of adverse events to project objectives.

9. Procurement Management: areas required to acquire goods and services from outside your

organization to complete the project. Includes solicitation, source selection, contract administration,

performance monitoring, and contract closeout.



2.5 TTUHSC Project Management Activity Flow

All TTUHSC IR projects are responsible for complying with the standard and processes referenced in the

IR Project Management Policy. Figure 2-4 broadly depicts the project management activity flow:

Figure 2-4 TTUHSC Project Activity Flow

*See Glossary.



2.6 Project Management Process Flow

Among the Project Management Process Groups, individual processes are often repeated. The Planning

Process Group provides the Executing Process Group with a documented project management plan early

in the project and then facilitates updates to the project management plan if changes occur as the project

progresses (PMBOK, 2004). Experienced project managers know every project brings a different set of

challenges. The project manager applies project management knowledge, skills, processes, tools, and

techniques in different degrees of rigor to achieve the desired project performance. The project manager

and the project team must address every process, and the level of implementation for each process as it

applies to the project size and complexity at hand.

2.7 Project Classification

Information resource projects will be managed through standardized project management practices.

However, the specific processes engaged within each Project Management process group will be based

upon a project‟s classification level. As new project ideas and requests are brought for consideration, they

must first be classified through the Project Complexity and Risk Assessment model, which scores

factors that define a project‟s complexity and risk. The Classification Matrix (see Table 2-2) uses this

information to determine the Classification Level of a project. This classification process is used to

identify the project management methodologies required for each phase of the project life cycle of the

project. An online tool is provided at http://www.ttuhsc.edu/it/projectmanagement/ to compute a project’s

complexity and risk level.

Project management processes form an approach for the initiation and management of IR projects, as well

as the completion and collection of project management deliverables. In some cases, processes will be

used more informally (less rigor) than in others which will need more detail (more rigor). Risk

management is an integral part of IT project management, as reflected in the categorization matrix and

project scoring mechanisms. Risk has three fundamental elements: nature of the possible disruptive

event, the probability that an event will occur, and the impact should the event occur (Cooke, 2005). Risk

is assessed in terms of business continuity and institutional impact, as well as influence on the strategic

mission of the entities involved in the project. In rare cases, risk is too great to initiate a project, but

typically strategies of risk avoidance, acceptance, mitigation, and transfer are adopted.

http://www.ttuhsc.edu/it/projectmanagement



Table 2-2

To determine the appropriate process effort, projects can be divided into three levels of effort as shown in

Figure 2-5.



Figure 2-5 Levels of Effort

2.8 Project Management Approval Processes and Deliverables

Projects, no matter how complex, should follow a Project Management Methodology. Approval processes

and deliverables are determined by the level of effort of a project. Larger more complex projects require

more stringent procedures and documentation than smaller, less complex projects. Consequently, approval

processes and deliverables are determined by the level of effort of a project.

Review Gate Approval Requirements

Level 1

o Major IR project approvals are coordinated through the TTUHSC Information Technology

Division. The Texas Department of Information Resources (DIR) has identified a Project

Delivery Framework for Statewide Project Delivery of Major Information Resource

projects and can be found at www.dir.state.tx.us/pubs/framework/.

Non-major project approvals are obtained from the TTUHSC Information Technology

Division.

o Coordinate project approval through PMO.

Level 2: Approvals are obtained from the sponsoring department head.

o Coordinate project approval through PMO.

Level 3: Departmental project management practices apply.




Project Deliverables

TTUHSC template cores are the same as those required by the Texas Project Delivery Framework for

major information resource (IR) projects. Scaled down templates or an appropriate subset may be used

for projects not classified as major projects.

Level 1

o Major IR projects are required to follow the Project Delivery Framework. Document

templates and instructions can be found at www.dir.state.tx.us/pubs/framework/ and must

be coordinated through the TTUHSC Information Technology Division and then submitted

to DIR throughout each phase of the project.

o Non-major project templates as indicated in Table 2-3.

Level 2: Project templates as recommended in Table 2-3.

Level 3: Departmental project management practices apply.

PROJECT MANAGEMENT DELIVERABLES

INITIATE PLAN IMPLEMENT

Execute, Monitor & Control CLOSE

Classification Level 1 2 3 Classification Level 1 2 3 Classification Level 1 2 3 Classification Level 1 2 3

Project Complexity & Risk Assessment

R R R Project Plan R X 0 Project Status Report R 0 0 Project Closeout Report X 0 0

Business Case R 0 0 Project Schedule X 0 0 Monitoring Report R 0 0 Post Implementation Review of Business Outcome

R 0 0

Statewide Impact

Analysis R 0 0

Project Planning

Review Gate Approval

R X 0 Change Request X X 0 Benefits Realization Review

Gate Approval R X 0

Project Charter R X 0 Solicitation & Contracting

(if applicable)

Vendor Performance

Review X 0 0

Business Justification

Review Gate Approval R X 0 Acquisition Plan R 0 0 Acceptance to Deploy R X 0

Contract

Amendment &

Change Order

R 0 0 Project Implementation Review Gate Approval

R X 0

CATRAD, if

Major IR Project R 0 0

Technology

Addendum R 0 0

Solicitation &

Contracting Review Gate

Approval

R 0 0

An "R" in the column indicates that a completed template is required to be submitted for approval to the TTUHSC CIO. An "X" in the column indicates that a completed template is recommended but not required to be submitted for approval. A "0" in the column indicates that project managers may choose to use any template deemed necessary for the success of the project.

Table 2-3




2.9 Portfolio Management at TTUHSC

Through a collaborative process that involves the Deans, Vice Presidents and the IT Board of Directors of

the institution, Information Technology needs are considered and prioritized so that they align with the

mission and strategic goals of the institution. Projects at TTUHSC are prioritized and scheduled through

the Office of the CIO under the direction of the IT Board of Directors.



3.0 DOCUMENT MANAGEMENT

Project documentation must be maintained throughout the life of an active project and for a certain

amount of time after project closure, as determined by the IT Division and the Institution‟s Archivist.

Records flagged as having historical value should be transferred to the Institution‟s Archives, as cited by

section 441.186 of the State Records Management Laws. At the time of closure of an IR project, project

documents must be consolidated into a single repository for record-keeping purposes. Digital project

repositories must receive regular backups to ensure recoverable copies are available. Prior to the

destruction of project documents, review by IT Division and Institution‟s Archivist must occur to ensure

records of technical relevance and/or archival value are not destroyed.

3.1 Guidelines to Records Retention

The retention time applies to the master [original] copy of a document. Each document has only one

official master copy. Duplicate copies of a document are disposable at the discretion of the project

manager, project team, and project team members. However, the IT project manager is responsible for

complying with the following records retention schedule:

PM Level Record Type Retention Period Archival Value

Level One Initiation documents and correspondences Permanent Yes

Planning documents and correspondences Permanent Yes

Implementation documents and

correspondences

Permanent Yes

Process correspondence 3 Years No

Closure documents and correspondences Permanent Yes

Level Two Initiation documents and correspondences 3 Years Yes

Planning documents and correspondences 1 Year No


correspondences

1 Year No

Process correspondence 1 Year No

Closure documents and correspondences 3 Years Yes

Level Three Initiation documents and correspondences 1 Year Yes

Planning documents and correspondences Duration of

project

No


correspondences

Duration of

project

No

Process correspondence Duration of

project

No

Planning documents and correspondences 1 Year Yes

All Levels Transitory Information

(Internal meeting notes, design sketches and

preliminary diagrams, Internal

correspondences)

Duration of

project

No

Document retention requirements will be disseminated to all project participants at project inception

during the initiation phase. Note that documents containing confidential or sensitive data must be stored

on an institutional server and carefully managed.



According to Texas Administrative Code 202, information and data shall be classified by its level of

access control as one of the following:

Confidential - Confidential Information as defined by the Texas Administrative Code Information

Security Standards, which is information that is exempt from disclosure requirements under the

provisions of applicable state or federal law.

Sensitive - Information pertaining to Access Control data, Account Management Data, procedures,

security documentation of Information Resources, or any other information the institution so

designates.

Public - Information specifically designated by state or federal law as Public and/or in accordance

with the Texas Public Information Act.

Information and data shall be classified by its level of criticality as one of the following:

Mission Critical - Information considered essential to the function(s) of an institution, a business

unit within an institution, or a higher education research project.

Non-Mission Critical - Information considered nonessential to the function(s) of an institution, a

business unit within an institution, or a higher education research project.



4.0 ROLES IN THE PROCESS

The project manager drives the project activity through the five process groups. As the project progresses,

project activity happens at different levels within an organization. Advancing through each process group,

the project incorporates appropriate management perspectives and requires active participation by

different organizational levels of the project team as shown in Figure 4-1.

Planning

Executing

Initiating

Monitoring and

Controlling

ClosingStrategic

Tactical

Operational

Project Management

Figure 4-1 Process Group Activity by Organizational Level

Management Level Action

Strategic The strategic level (management and sponsorship) provides scope,

guidance, resources, and priority for the tactical processes based on the

organizations business needs and drivers. The strategic level addresses

results, or outcomes; answers questions, such as, "Why are we performing

these functions?” is externally focused on customers; includes a mission,

goals, strategic objectives, outcome measures, and effectiveness evaluations.

Tactical The tactical processes (project manager and support) develop and maintain

the project plan, as well as, managing and controlling the project. The

tactical level addresses products, or outputs; answers questions, such as:

"What products (or services) should we produce?"; "How will we achieve

the results described in the strategic objective?” includes strategies, tactical

objectives, output measures, budgeting, and efficiency evaluation.

Operational The operational level (technical lead, subject matter experts, and project

team) create the product by executing the processes as outlined in the

project plan. The operational level addresses processes, procedures or tasks;

answers questions, such as "Who will perform tasks or procedures that will

lead to production?” is internally focused; includes tasks, operational

objectives, workload measures, and performance appraisal.



5.0 PROJECT INITIATION

The key project management deliverables associated with the Project Initiation Process Group are

depicted in Figure 5-1.

Figure 5-1 Initiation Process Flow

The processes and activities starting from creating a business case for a project through authorizing the

project and the project manager follow.



5.1 Initiation Activities

The activities, roles, and deliverables may be performed slightly differently for different types of projects.

The following tables provide suggestions for adaptation of activities. The project manager should

complete any process/activity deemed necessary for the success of the project.

Activities Level 1 Projects Level 2 Projects Level 3 Projects

Create Business Case Takes 4 person weeks

for long range items; 2

person weeks for short

range items; usually built

by the project sponsor,

department head, IT

Division and in one or

more facilitated team

sessions.

For non-major projects,

use the TTUHSC

Business Case template

For Major IR projects,

refer to DIR Texas

Project Delivery

Framework

Submit documents to IT

Division

Recommended. Takes 2

person weeks; usually

built by a department

head and a small team.

Use a spreadsheet to

capture cost and time

data. Use individuals‟

previous experience and

review lessons learned

from other projects.

Retain document in

departmental files.

Takes 1 person week;

Usually built by the

department head. Gather

data from individuals

with previous experience

for estimating level of

effort, time needed, and

cost. Retain document in

departmental files.

Draft Statewide Impact

Analysis

Refer to DIR Texas

Project Delivery

Framework. Submit

documents to IT Division

Not required Not required

Create Project Charter Takes 4 person weeks



range items; built in one

or more facilitated team

sessions. Use TTUHSC

Project Charter template.

For Major IR projects,

refer to DIR Texas

Project Delivery

Framework. Submit

documents to IT Division.

Takes 2 person weeks;

built by a project manager

and small team. TTUHSC

Project Charter template

recommended. Retain

document in departmental

files.

Not required. May

complete sections of

TTUHSC Project Charter

which apply. Retain


files.

Conduct Business

Justification Stage Gate

Project manager compiles

the documentation.

Submit documents to IT

Division.

Project manager

develops the

documentation. Business

manager certifies

accuracy and

completeness. Retain


files.

Project manager develops

the documentation.

Business manager

certifies accuracy and

completeness. Retain


files.



5.2 Initiation Roles

Role Names Role Definitions

Project Manager Participate as early in project as possible

Communication

Leadership

Management

Administrative maintenance

Project Team Probable members of the team assist with project deliverables, as needed

Project Sponsor Authorize and funds the project. Keeps abreast of current status

Empower project manager

Review plans ensuring they meet organizational goals

Senior management liaison

Remove barriers beyond the control of the project manager or project team

Department head

IT Division

Ensure business goals are met

Provide business resources

Represent the customer interests concerning requirements and project results

Has signature authority for Level 2 & Level 3 Review Gate approvals and may

elect to delegate authority for Level 3 Review Gate approvals

Level 1 Major IR project approvals are coordinated through the TTUHSC IT

Division and follow requirements listed at


Non-major Level 1 project approvals are obtained from the TTUHSC

Information Technology Division

These roles in project initiation may be handled differently based on the classification level of a project.

Role Level 1 Projects (non-

major) Level 2 Projects Level 3 Projects

Project Manager Person in this role is

dedicated to managing the

project.

Person in this role may

also do some of the work

of the team

Person in this role is also

likely to be a member of

the team doing the work

Project Sponsor Role performed by the

person providing funding

and resource authorization.

Identifies the business

goals the project satisfies.

Role performed by the

person providing funding

and resource authorization.

Identifies the business

goals the project satisfies.

Department head and

project sponsor may be

one in the same for Level 3

Projects. Identifies the

business goals the project

satisfies.

Department head Identifies the need and

determines the business

processes the project

satisfies. Provides business

resources and direction.

Identifies the need and





Identifies the need and





5.3 Initiation Deliverables

Deliverables in project planning may be done differently based on the classification level of a project.

Deliverable Level 1 Projects (non-





Deliverable Level 1 Projects (non-


Business Case Use TTUHSC Business

Case template

Recommended use of

TTUHSC Business Case

template

Provide a descriptive

narrative and costs in a

table

Project Charter Use TTUHSC Project

Charter template

Recommended use of

TTUHSC Project Charter

template

Provide a descriptive

narrative

Business Justification Stage

Gate

Use TTUHSC Business

Justification Review Gate

template

Obtain documented

approval signed by

department head/project

sponsor

Departmental practices

apply for documentation

approval

5.4 Business Case

The Business Case provides comparative information between business solution costs and proposed

project benefits. As a detailed investment proposal, the Business Case considers quantitative and

qualitative evaluation factors and provides the baseline information to make an informed decision and

whether to recommend proceeding further. The Business Case also provides input into the Statewide

Impact Analysis that is required for Major IR projects.

Entry Criteria: Business change need or opportunity with a potential IR component. For

example:

o application need from within business unit

o new business unit productivity goal, business equipment or

infrastructure changes

o business technology changes, which may offer value

pending/enacted legislation or other legal requirements public and

private sector trends

Costs

Inputs: Description of business need

Role Procedure/Activity Project Sponsor

Business & Technology

Staff

Collect and analyze business information and need

Derive description of business need (A business need can be based on needed

training, customer demand, technological advance, legal requirement, or

governmental standard)

The Project Sponsor and appropriate staff draft the Business Case and

workbook

The business areas use the help of a business and technology staff and, ideally,

a project manager

The Business Case is a structured proposal for business change justified in terms of

costs and benefits. The Business Case addresses, at a high level, the business need

the project seeks to resolve. It includes the reasons for the project, the expected

business benefits, the options considered (with reasons for rejecting or carrying

forward each option), the expected costs of the project, and the expected risks. In

almost all cases the option of doing nothing should be included with the costs and

risks of inactivity along with the differences (costs, risks, outcomes etc) between

doing nothing and the proposed project.

Executive Summary – Provide a synopsis of the project and how the project

affects institution service or product delivery. At a high level, describe the

merits, impacts, and benefits of the proposed project.

Governance and Business Case Analysis Team – Describe the structure for



Role Procedure/Activity making project decisions. With the project meriting further business analysis,

identify the Executive Sponsor, Technical sponsor, and key staff.

Problem Definition – State the business problem, specifically identifying the

processes, services, and technology receiving benefit from the project. Do not

include solutions in this section.

Project Overview – Establish a basis for the qualitative and quantitative

analysis completed later by describing the project with the goals and objectives

of the project.

Project Evaluation – Provide a measure of how well the project satisfies the

business goals and objectives of the project. Six factors are considered:

o Statutory fulfillment

o Strategic alignment

o Institution impact analysis

o Financial analysis

o Initial risk consideration

o Alternatives analysis

Project Selection – using the six evaluation dimensions and a documented

selection process, the project is, or not, selected based on how well business

needs are met.

Exit Criteria: Completed Business Case

Output: Business Case

5.5 Statewide Impact Analysis

Applicable to Major IR Projects, the Texas Project Delivery Framework (Framework) includes a

Statewide Impact Analysis (SIA) to provide a consistent method for collecting and analyzing a project's

effect on common IR used throughout the state. The SIA is a self-report questionnaire that describes a

project's use of (or effect upon) interoperability, collaboration, and reuse of information resources

throughout the state.

The SIA accomplishes this through a series of questions related to the institution‟s approach to leveraging

the state‟s resources through collaboration with other state agencies. The assessment seeks information

regarding the extent to which business processes and technical components will be reused from prior

projects within the institution, or from other agencies, institutions of higher learning, or other

governments (federal, local, other states). The SIA also elicits specific information regarding shared

services related to project goals or requirements for interoperability. For more instructions and the

template, go to http://www.dir.state.tx.us/pubs/framework/.

5.6 Project Charter

The Project charter provides a consistent method to formally authorize work to begin on a project. The

intent is that an agreement among stakeholders is established before significant resources are committed

and expenses are incurred. The Project Charter is the tool that gives the named Project Manager authority

to carry out the project business. Approval of the Project Charter provides the go-ahead for an officially

recognized project to begin when business considerations, such as, resources, budget, and timing allow.

Entry Criteria: Completed Business Case

Inputs: Business Case

Statewide Impact Analysis (Major IR projects only)

Enterprise Environmental Factors




o Organization structure

o Organizational culture

o Infrastructure

Organizational Process Assets

o Standards, policies, software development lifecycles

o Established organization processes, e.g. procurement

Role Procedure/Activity

Initiating Sponsor


Staff

IT Security Staff

Complete the Project Charter:

o Develop a concise statement of the business reasons for starting the

project specifically stating problems the project is going to solve

o Describes the approach the project will use to address the business need

o Provide a narrative description of what will be included and excluded in

the Project Scope

Critical Success Factors

o List factors or characteristics deemed critical to the success of the

project

Project Oversight Authority

o Describe management control over the project

o Describe external oversight bodies and policies

Project Structure

o Describe the organizational structure of the project team and the

stakeholders

o Provide an organizational chart

Roles and Responsibilities

o Outline the overall structure of the project organization throughout the

project phases

o Identify customers, key stakeholders who have influence or may be

impacted

Responsibility Matrix

o Identify who is responsible for each activities and who needs to be

informed or consulted

Project Facilities and Resources

o Describe the project requirements for facilities and resources such as

office space, computer equipment, support tools

o Identify the Points-of-Contact

Executive Sponsor and/or

Steering Committee

Follow project selection process

Review Project Charter

Approve, rework, shelve, or kill proposal. If approved:

Get required authorization signatures, as applicable

Approver Signature authorities vary by project size and complexity. See Section 1.8

Project Approval Processes and Deliverables

Approve (sign) Project Charter

Executive Sponsor For Level 1 projects, submit document to IT Division. For Level 2 and 3 projects,

retain the approved Project Charter in file.

Exit Criteria: Completed Project Charter

For Level 1 projects, submit document to IT Division. For Level 2 & 3, Project

Charter retained in file

Output: Project Charter



5.7 Business Justification Stage Gate

The Business Justification Stage Gate is the initial check point during a project management lifecycle.

The stage gate is intended to synchronize the state‟s investment in a project based on approval of business

outcomes. The stage gate facilitates assessment and approval of whether the project goals have been

achieved and whether a project is ready to proceed. The process approval considers:

Verification of approved deliverables

Assessment of key questions

Assessment of open issues

Before any formal project planning activities can occur, the appropriate approver must approve the

completion of the necessary documentation at that specific point during project delivery (See Section 1.8

Project Approval Processes and Deliverables).

Entry Criteria: Approved Project Charter

Inputs: Completed Business Case and Project Charter


Initiating Sponsor


Staff

IT Security Staff

The project approver collaborates with the executive sponsor to obtain complete,

accurate, and comprehensive status information on the project. The status

information provides evidence to support the responses to key questions. Emphasis

is placed on whether the expected results and deliverables of the project, thus far,

align with business goals and objectives.

Member Institution IR

Steering Committee

and/or

Executive Sponsor

Follow project authorization process

Review Project Charter

Approve, rework, shelve, or kill proposal. If approved:

Get required authorization signatures, as applicable.

Approver Signature authorities vary by project size and complexity. See Section 1.8

Project Approval Processes and Deliverables

Approve (sign) Initiation Stage Gate Approval

Executive Sponsor and/or

Steering Committee

Store the approved Project Charter in file

Exit Criteria: Completed Initiation Stage Gate Document

Project Charter stored in PMRS

Output: Business Justification Review Gate Document



6.0 PLANNING

Project

Initiated

Develop the Project

Critical Success Factors

Refine the Project

Scope Statement

Create the WBS

(Includes Project

Planning Tasks)

Create the Network

Diagram

Create the WBS

Dictionary

Develop Initial Project

Schedule

Develop the Project

Budget

Sponsor

Approval?

Resolve Issues and

ResubmitNo

Yes

Stage Gate

Approved?

Develop the

Configuration Plan

Develop the Project

Plan

Develop the

Communication Plan

Develop the

Performance

Management Plan

Develop the Risk

Management Plan

Procurement

Involved?

Resolve Issues and

Resubmit

Perform

Procurement

Process

Perform

Executing

Activities

Yes

No

Yes

No

Figure 6-1 Planning Process



6.1 Description of the Project Plan

The Project Planning Process provides a framework for Project Plans. In the planning process, develop

estimates of effort, develop a schedule, plan the management and technical approaches, identify measures

to gather, develop a risk management approach, and, if procurement of external resources or services is

needed, use the procurement process (see Figure 6-1 and Figure 6-3, page 46). The key project

management deliverables associated with the Project Planning Process Group are:

Project Scope Statement

Work Breakdown Structure (WBS)

Network Diagram (e.g.: Microsoft Project)

Work Breakdown Structure Dictionary

Initial Project Schedule

Budget

Project Measures

Project Management Plan (PMP)

Communication Plan

Configuration Plan

Performance Management Plan

Risk Management Plan

Acquisition Plan (if services or materials needed)

6.2 Scope of the Project

The activities, roles, and deliverables in the project planning process may be performed slightly

differently for different types of projects.

6.3 Planning Activities

The activities, roles, and deliverables may be performed slightly differently for different types of projects.

The following tables provide suggestions for adaptation of activities. The project manager should

complete any process/activity deemed necessary for the success of the project.


Refine Project Scope

Statement Takes 4 person weeks





sessions

Takes 3 to 4 person

weeks by project manager

and team

Takes 1 to 2 person

weeks by project manager

and team

Establish Work

Breakdown Structure Takes 4 person weeks





sessions


built by project manager

and small team



and project team




Create Network Diagram Takes 4 person weeks





sessions



and small team



and project team

Complete Work

Breakdown Structure

Dictionary

Takes 4 person weeks





sessions



and small team



Develop Initial Project

Schedule

Attempt to get level of

confidence >70%. Use

scheduling software (e.g.

MS Project)


confidence >75%. Use

scheduling software (e.g.

MS Project)


confidence >80%. Use a

spreadsheet or word

processing table

Develop Budget +/- 3-5 person week

(project manager and

project team). Estimates

based on WBS dictionary

detail

+/- 2-3 person week

(project manager and

project team). Estimates

based on WBS dictionary

detail

+/- 1 person week (project

manager) Estimates based

on task length estimate,

skill level needs,

schedule, resource

availability, and cost of

resource plus materials

cost

Define Project Measures Collect fundamental

measures and those

needed to handle project

issues

Collect fundamental

measures and those

needed to handle project

issues

Collect fundamental

measures of size, defects,

milestone attainment,

effort

Draft Project Management

Plan (PMP)

Ensure plan is useful for

project members added

after project start

Use organization

templates. Takes 2

person weeks; built by

project manager and small

team

Use concise plan formats

Develop Communication

Plan



after project start

Use organization

templates. Takes the

Project Manager 1

person week.

Address in the PMP – a

paragraph or two

Create Configuration Plan Ensure plan is useful for


after project start

Use organization


small team 2 person

weeks

Address in the PMP – a

paragraph or two

Establish Performance

Management Plan



after project start

Use organization

templates for

Procurement Activity

Evaluation

Not Applicable

Create Risk Management

Plan

Use the appropriate risk

factor tables for

identification at the start

of the project, and the

beginning of each phase

Use the appropriate risk

factor table for

identification

Use a short list of key

risks for identification




Develop Acquisition Plan

(if services or materials

needed)



after project start

Use organization


small team 2 person

weeks

Not Applicable

6.4 Planning Roles


Project Manager Plan and track the project

Project Team Participate in building and reviewing the plan(s) and project work items; developers

or implementers of a system

Senior Management Authorizes the project and provides staff and other resources

Reviews the plans to ensure they meet organization goals

Business Area Subject

Matter Expert (SME)(s) Represents the customer and/or user of the project results

Provides input to the plan concerning requirements, may review the plan to

ensure it meets user needs

Project Sponsor Provides resources and funding for the project

6.5 Planning Roles

These roles in project planning may be handled differently for different types of projects.

Role Level 1 Projects Level 2 Projects Level 3 Projects

Project Manager Person in this role is

dedicated to project

management



of the team as well as

managing the project




Project Team Completing work and

report status

Provide input for plan

development as well as

doing the work

Does majority work

Senior Management Monitor work, provide

funding, manage

communication with

upper management

Monitor work, provide

funding, manage

communication with

upper management

Acknowledge work


Matter Expert (SME)

Play part in direction and

funding as well as active

role during delivery of

product

Plays part in direction and

funding as well as active

role during delivery of

product

Provide input and tests

Project Sponsor Provide funding and

authorization to do the

project

Provide funding and

authorization to do the

project

Provide support

6.6 Project Plan Deliverables

These deliverables in project planning may be done slightly differently for different types of projects.



Activity

Deliverable

Level 1 Projects Level 2 Projects Level 3 Projects

Scope Statement Fully documented outline

of the product, service, or

result desired while listing

constraints, assumptions,

limits, rough order of

magnitude proposed

budget, critical success

factors

Formal document

outlining the product,

service, or result desired

Brief statement in a word

processing software or e-

mail

WBS MS Project; may be

connected to process

library tools

MS Project file Table in project plan or

Excel spreadsheet

Network Diagram Use MS Project network

diagram view

Use MS Project network

diagram view

Put tasks in order in an

Excel spreadsheet

WBS Dictionary Likely to employ formal

estimating technique, e.g.

Wideband Delphi, with

associated deliverables

Documented assumptions

in project plan, plus

modest tool support, e.g.

MS Project

Table in project plan

Schedule MS Project MS Project Table in project plan

Budget Usually captured in

budgeting tool

May be Excel spreadsheet

or MS Project

Table in project plan

Project Management Plan Rigorous plan detailing

how the project will be

managed as well as

developing subsidiary

plans (i.e. risk,

communication, etc.)

Basic Plan detailing how

the project will be

managed as well as

developing subsidiary

plans (i.e. risk,

communication, etc.)

Brief outline in word

processing document

Communication Plan Rigorously developed

plan with Roles and

Responsibilities outlined.

Contains full outline of

communication needs

Plan with Roles and



communication needs

Few lines identifying

status and problem

reporting

Configuration Plan Rigorously developed

plan with Roles and



configuration needs

including versioning for

IR projects

Plan with Roles and



configuration

Few lines referring to

how revisions handled.

Performance Management

Plan

Rigorously developed

plan with roles and

responsibilities outlined.


contracted deliverables

needs

Plan with roles and



contracted deliverables

needs

Not applicable for

projects of this size



Activity

Deliverable


Risk Management Plan Rigorously developed

plan with roles and


Contains risk

prioritization charts and

actions

Plan with roles and


Contains risk

prioritization charts and

actions

List in word processing

with suggested actions

Project Planning Review

Gate

Use TTUHSC Business


template

Obtain documented

approval signed by


sponsor



approval

Acquisition Plan Rigorously developed

plan from procurement

documentation through

contract closure with roles

and responsibilities

outlined.

Plan with roles and


TTUHSC Purchasing


apply

Contract Amendment and

Change Order

TTUHSC Contracting


apply

TTUHSC Contracting


apply

TTUHSC Contracting


apply

Solicitation and

Contracting Review Gate

Use TTUHSC Business


template

Obtain documented

approval signed by


sponsor

TTUHSC Purchasing

Department and

Contracting Departmental

practices apply

6.7 Project Scope Statement

The project scope statement has evolved and will require more detail to manage the project. The project

scope statement describes, in detail, the project‟s deliverables and the work required to complete the

deliverable. The statement provides a common understanding for the stakeholders of the major

deliverables. The detail provides the basis for detailed planning while guiding the project team through

execution. The statement provides the baseline for the boundaries of the project. With well defined

boundaries, the scope of the project can be more easily managed which, in turn, determines how well the

project team can plan, manage, and control the execution of the project.

Purpose: Describe in detail the project deliverables and all of the work for the project.

Entry Criteria: Approved Project Charter

Preliminary Scope Statement

Organizational Process Assets, i.e. a template for developing the scope

statement, if available

Role Procedure/Activity Project Manager Delineate the work items, user requirements, boundaries, constraints, and

assumptions while referring to other documents describing the system to be

built

Include:

o Objectives

o Scope description

o Requirements Gathering

o Boundaries

o Deliverables



o Acceptance criteria

o Constraints

o Assumptions

o Initial organization

o Initial defined risks

o Schedule milestones

o Fund limitation

o Cost estimate

o Configuration management requirements

o Specifications

Approval requirements

Project Manager, Project

Team Review the work elements for completeness

Provide input on systems affected


Matter Expert (SME) Ensure business needs are documented

Review results with Senior Management to ensure all needed work is included

Exit Criteria: Project manager, business area SME, project team members, and other affected

groups are in agreement.

Output: Enhance Project Scope Statement

6.8 Work Breakdown Structure

The Work Breakdown Structure (WBS) is a deliverable-oriented decomposition of the work to be done by

the project team. The WBS organizes and defines the total scope of the project. The WBS subdivides the

project work into smaller, more manageable pieces of work, with each descending level of the WBS

representing an increasingly detailed definition of the project work (PMBOK, 2004). The lowest level of

work can be scheduled, cost estimated, monitored, and controlled. The WBS may be developed using a

hierarchical structure or using an outline structure. When using a project scheduling software (MS

Project) the default method is the outline structure.

Purpose: Identify and describe the work elements in the project plan, any dependencies

between them, and approximate level of effort of each.

Entry Criteria: Project requirements and goals are well-defined (Scope Statement)

Lifecycle, development approach, methods, and tools have been selected


Project Manager Draft an initial list of work items by using statement of work, user requirements,

and/or other documents describing the system to be built

Determine development lifecycle (waterfall, spiral, rolling wave, time phased)

Document the results as a Work Breakdown Structure (WBS) in the project plan

(or a living document attached as an appendix to the project plan)

Review results with Customer Subject Matter Expert (SME) and Senior

Management to ensure all needed work is included


Team Decompose the project to the lowest level where reliable estimates for

scheduling, costing, monitoring, and controlling can occur. Avoid breaking

down the task too far because this may cause non-productive management

effort, inefficient use of resources, and decreased efficiency in performing the

work.

Use an estimation process to create effort estimates for each work item.



Exit Criteria: Project team members and other affected groups are in agreement with the

estimates, the completeness of the list of work items, and the dependencies between

them.

Output: Work Breakdown Structure

6.9 Work Breakdown Structure (WBS) Dictionary

The WBS Dictionary supports the WBS. The contents of the WBS are defined in the dictionary down to

the lowest level of component of work. The component level can include a list of associated schedule

activities, resources, and estimates of cost. Also, the component can include contract information, quality

requirements, and technical references to help in the performance of the work.

Purpose: Identify and describe the detail elements of the work components and approximate

level of effort of each.

Entry Criteria: Work Breakdown Structure

Business and technical experts are available


Project Manager Lead the elaboration effort of the WBS

Lead meetings for deriving information

Document the results as a Work Breakdown Structure (WBS) Dictionary in the

project plan (or a living document attached as an appendix to the project plan)




Team Review the work components

Provide expert judgment for identifying tasks, skills, estimates-to-complete

Exit Criteria: Project team members and other affected groups are in agreement with the

estimates and the completeness of the list of the information in the dictionary.

Output: Work Breakdown Structure Dictionary

6.10 Network Diagram

The network diagram supports the later development of a realistic and achievable project schedule. The

network diagram is the product of identifying and documenting of the logical relationships among the

work components. The sequence is developed by considering precedence relationships, leads, and lags.

The sequencing can be accomplished with manual methods or by using project management software.

Purpose: Identify and document the logical relationships between work components

including any dependencies between them.

Entry Criteria: Work Breakdown Structure and the Work Breakdown Structure Dictionary



Project Manager Provide a Work Breakdown Structure (WBS) and dictionary




Team Review the work elements to identify dependencies and ordering of work

Provide expert judgment in identifying:

o Mandatory dependencies

o Discretionary dependencies

o External dependencies



Exit Criteria: Project team members and other affected groups are in agreement with the results of

the network diagram.

Output: Network Diagram

6.11 Project Schedule

This activity is generally done in iteration with the allocation of staff, since initial schedules often reveal

conflicts in resource needs or dependencies between tasks. The result of this activity is the first project

schedule, likely to be adjusted as the project proceeds and conditions change.

Purpose: Create an initial schedule of the work of the project.

Entry Criteria: Work Breakdown Structure

Network Diagram

Resource Calendars


Project Manager Use the task list from the WBS, the effort estimates, and the staff assignments

as input to a project scheduling tool

Generate initial schedule with the scheduling tool and review results to see if it

meets project goals

Use the above as a project management tool, in consultation with the team, to

make any adjustments needed in the order of the work, in staff assignments, or

in the specific WBS items included to meet the project goals

Negotiate changes, as needed, to modify project requirements to meet the

project goals, given any resource constraints

Negotiate changes, as needed, to modify staff commitments to meet project

goals, given requirements constraints

Review complete initial schedule with Senior Management and all affected

parties

Document the schedule in the project plan as an appendix

Exit Criteria: The project schedule is signed off by key stakeholder, business area, and

sponsor

The schedule is acceptable to the staff involved with the project

Work identified can be completed within the current schedule

Output: Approved project schedule

6.12 Budget

The budget is an aggregation of the estimated costs of individual activities or work components used for

creating a cost baseline and for measuring the project performance and health. The costs include all

internal and external resources planned for the project including, but not limited to, labor, materials,

equipment, services, and facilities. Also taken into account are inflation and contingency costs. Inputs for

creating the budget include the project scope statement, work breakdown structure (WBS), WBS

dictionary, project schedule, resource calendars, and, if applicable, a contract with a contract management

plan (see Figure 6-2). Budgets are typically represented in a time phased fashion (e.g. fiscal quarters).

This provides the project sponsor, and other financial parties of interest, an estimate of expected cash

consumption or “burn rate” during the project‟s life.



Work Breakdown Structure

Network Diagram

Skills by Task

Resources by Task

Time Per Task

Task Relationships

WBS Dictionary:

Schedule and Timeline

Budget

$ $ $

Project Management Plan:

Communications Plan

Configuration Plan

Performance Mgt Plan

Risk Mgt Plan

System Development Plan

Acquisition Plan

The project planning documents are interrelated. Make a change to one and you need to adapt the

rest. If you don’t keep the plan up-to-date, it doesn’t matter how good the initial plan was. An out-of-

date plan is a statement of what didn’t happen – not a guide to the future. Volatile documents

associated with the Project Management Plan, such as, the schedule or risk management plan, should

be referenced externally. Keeping actively managed plans separate minimizes the number of times the

core project plan requires updating.

Deliverables Detail

Work Required

Stakeholder Understanding

Major Objectives

Scope Statement

Figure 6 – 2 Estimate Planning



Establish a Project Budget

Entry Criteria: Project scope statement

Work breakdown structure (WBS)

WBS dictionary

Project schedule

Resource calendars

Contract, as applicable



Team, Purchasing Team,

Contracting Team,

Subject Matter Experts

(SME)

While developing the cost estimates for the budget, identify and consider:

o Possible causes of variation of the cost estimates, including risk

o Various costing alternatives

o Inflation allowances

o Contingency costs

Inputs for creating the budget include, but not limited to:

o Project scope statement – constraints, assumptions, and requirements

o Work breakdown structure (WBS) – relationships between tasks and the

deliverables

o WBS dictionary – identifies the deliverables and a description of the

work required to create the deliverables

o Schedule management plan – the work components and the amount of

time to complete the work, by resource, establish a fundamental part of

the cost estimate

o Resource calendars – availability of certain skills may cause the need to

go outside the organization of those skill sets

o Contract – the cost of using external resources to complete resource

shortfalls add to the basic cost

o Methods for creating the estimates for a budget include, but not limited to

• Analogous estimating (top down) uses the actual cost of

previous, similar projects as the basis for estimating the current

project. Use where there is a limited amount of detailed

information about the project. This method relies on expert

judgment. Less costly to do, but the method is less accurate.

• Analogous estimating (top down) uses the actual cost of

previous, similar projects as the basis for estimating the current

project. Use where there is a limited amount of detailed

information about the project. This method relies on expert

judgment. Less costly to do, but the method is less accurate.

• Bottom-up estimating estimates task costs at the lowest

level of detail, then, rolls up the cost for the total estimate.

Bottom up estimating is more costly and time consuming, but

usually more accurate. This type of estimating is motivated by

the size and complexity of the work. The more the work is

broken down and estimated, the better the overall estimate.

• Parametric estimating uses a statistical relationship

(mathematical model) between historical data and other

variables (i.e. lines of code, labor hours, square footage of a

facility) to calculate costs.

• Project management software may be used to assist with

cost estimating.

Senior Management, Review budget




Project Sponsor Authorize funding

Exit Criteria: Cost Baseline

Project Funding Requirements

Sponsor sign-off

Output: Approved budget

6.13 Measures

Measures of the project progress, product quality, and process performance include the following:

Milestone Attainment – Monitor achievement of milestones to the initial milestones set in the

project plan, reporting variance on each; maintain the initial baseline as well as the most recent

update; report achievement and variance to both

Effort Spent – Track the initial effort estimates for each major element of the work breakdown

structure, compared to the actual effort spent performing that element (may be a work product or

an activity)

Budget/Cost Performance – Track the rate of spending on the project by period (week or month)

compared to the planned spending

Requirements Change – Track requirements change by period (generally month), showing total

number of requirements, number added in this period, number deleted in this period, and number

changed in this period; also track these dimensions by the amount of effort reflected in each, to

understand the impact on the project‟s time and cost

Measures for monitoring and controlling activities include the following:

o Schedule attainment – compare progress review dates to the dates planned

o Effort required – compare the amount of effort used for monitoring and controlling the

plan

6.14 Project Management Plan

The Project Management Plan is a formal, approved document that defines how the project is executed,

monitored, and controlled. It may be summary or detailed and may be composed of one or more

subsidiary management plans and other planning documents. The project management plan will vary

depending upon the application area and complexity of the project (PMBOK, 2004). The project

management plan is also referred to as the Project Plan. Some examples of subsidiary plans are:

Project Scope Management Plan

Schedule Management Plan

Cost Management Plan

Quality Management Plan

Communication Plan

Risk Management Plan

Procurement Management Plan

Purpose: Gather all subsidiary plan(s) into a fundamental plan used as a basis for managing

the project and ensure commitment by all affected groups.

Entry Criteria: Tailored project lifecycle

WBS, resources, schedule, and budget have been developed.


Project Ensure a Configuration Management Plan is written for the project.




Manager Ensure a Communications Plan is written for the project.

Ensure a Performance Management Plan is written for the project.

Ensure the Risk Management Plan is written for the project.

Complete the Project Plan.

Prepare the Project Management Plan for the project.

Update the plan as needed, based on review.

Conduct a technical review of the plans.

Senior Management,

Customer, Project Team

Review completed Project Plan.

Exit Criteria: All members of the team have read and agree with the project plans (Quality,

CM, and Project Plan).

Senior Management and the leaders of the support groups have approved the

above plans.

Output: Approved Project Plan

6.15 Communication Plan

The Communication Plan is a document that describes:

The communications needs and expectations for the project

How and in what format information will be communicated

When and where each communication will be made, and

Who is responsible for providing each type of communication

The plan can be formal or informal as well as highly detailed or broadly framed based on the requirements

of the project stakeholders. The communication plan is a subsidiary of the project plan.

Purpose: Establish a consistent method for communication planning and management.

Entry Criteria: Project Scope Statement

Project Management Plan



Project Manager

Project Team

Key Stakeholders

Determine project stakeholder needs

o Mandatory generally includes Project Status Reports, legal

requirements, financial reporting, etc. This information is pushed out to

the recipients.

o Informational material is usually made available for people to read, but

requires them to take the initiative

o Marketing information is designed to establish ownership and

acceptance as well as enthusiasm for the project and its deliverables.

This type of information is pushed out to the appropriate people.

Determine:

o What information each stakeholder needs to know

o How often they need an update

o What the best manner is to deliver the information

o Determine the effort required to create and distribute each identified

communication option

o Determine the potential benefit of the communication



Prioritize the communication options established above.

o Discard those requiring high effort for marginal benefit

o Discard those that provide marginal benefit, even though they may take

little effort from the project team

o Implement the communication options providing high value and require

low effort from the project team

o Evaluate options that have high value and require a high level of effort

from the project team

Regardless of the prioritization, implement any communication options that are

mandatory for the project or for the environment – may include Project Status

Reports, governance required reports, legal reports, etc.

Add the resulting communication activities to the work plan. This will include

assigning:

o Frequencies

o Due dates

o Effort hours

Responsible person(s) for each communication option implemented.

Project Manager Prepare the Communication Management Plan for the project, incorporating it

into the overall project plan.


Exit Criteria: Reviewed by project team, stakeholders, and sponsor.

Output: Approved Communication Management Plan

6.16 Configuration Plan

The Configuration Management Plan (CMP) describes the overall planning efforts for implementing and

executing configuration management throughout a project‟s life cycle. The plan accomplishes:

Establishes an evolutionary method to consistently identify and request changes to

established baselines, and to assess the value and effectiveness of those changes

Provides opportunities to continuously validate and improve the project by considering

the impact of each change

Provides the mechanism for the project management team to consistently communicate

all changes to stakeholders (PMBOK, 2004).

The plan also identifies the documentation and defined approval levels needed for authorizing and

controlling changes. The change control system is a subset of the configuration management plan.

Purpose: Provide procedures for the status of the deliverables while assuring requested

changes to the project scope and product scope are thoroughly considered and

documented before being processed through the Change Control process.




Project Manager

Project Team Identify and document the functional and physical characteristics of a product,

service, result, or component known as a configuration item (CI)

List each CI, when it will be put under control and the person responsible for

each item

Identify the CI baselines. Describe when and how baselines are produced

Create a Configuration Library - Describe any tasks associated with using the

Configuration Library (submitting CIs, deleting CIs, and retrieving CIs)




Create a Change Control Process - Describe the mechanism for controlling

changes to the items under configuration management. Include details of

initiation, recording, review, approval, tracking, and closure.

Create a Release Procedure - Describe plans for releasing deliverables to the

customer. Reference can be made to the Release Procedure, if applicable.

Support the audit of the products, result or components to verify conformance to

requirements

Project Manager Prepare the Configuration Management Plan for the project, incorporating it

into the overall project plan

Update the plan as needed, based on review

Exit Criteria: Reviewed by project team, stakeholders, and sponsor

Output: Approved Configuration Management Plan

6.17 Performance Management Plan

The Performance Management Plan establishes a consistent method for formally assessing, measuring,

monitoring, and reporting the expected product, service, or result performance outcomes established for

the project. The Performance Management Plan is a sub-plan to the overall Project Plan. The plan serves

to control the quality of the project product deliverables.

Purpose: Using business goals and objectives developed in the Business Case and refined in

the Project Charter, measure the product, service, or result based on performance

reviews and evaluations.

Entry Criteria: Business Case



Enterprise Environmental Factors



Project Manager

Project Team Describe how the Performance Management Plan relates to the project while

defining the limits for the measurement of the product, services, or results.

Identify the roles and responsibilities of project team members within the

context of the plan

Relate each of the project business objectives to the product, service, or result

being delivered.

Provide the performance standards and measures for each objective.

Show how each measure will be collected, reviewed, and reported.

Demonstrate how the project team ensures plan activities are being completed

and evaluated.

List any tools that may be used to implement the plan.

Project Manager Prepare the Performance Management Plan for the project, incorporating it into

the overall project plan.



Output: Approved Performance Management Plan



6.18 Risk Management Plan

At this point in the planning, and again at significant points of change in the project, the project team

performs a risk identification process.

Purpose: Identify risk elements for this project, analyze them, and develop a risk management

approach.

Entry Criteria: First version of Work Breakdown Structure is complete.


Project Manager Identify risk identification team and approach for identifying the risks

Prepare the Risk Management Plan for the project, incorporating it into the

overall project plan


Document risk management approach in the Project Plan

Track risk progress of the project using risks list

Project Team, others

working with the team Use risk factor tables (or other means) to identify risks

State the key risks to the project

Establish estimates of probability, impact, and exposure (product of probability

and impact) for each risk

Rank risks using exposure estimates

Develop management approach for top risks on the list

Identify risks requiring contingency plans and develop contingency plans

Senior Management Review risk list, risk exposures, mitigation approaches, and contingency plans

Decide whether or not to proceed with project

Exit Criteria: Team has considered all risks in the risk register

Risk management approach is documented, and risk chart has been published

for team use

Management has agreed project should proceed, given the risk estimate

information and contingencies

Output: Approved Risk Management Plan

6.19 System Development Plan

The System Development Plan (SDP) describes plans for delivering a product, service, or result which

may be hardware, software, or other project purpose. The SDP provides the project team insight into, and

a tool for monitoring, the processes to be followed for delivery, the methods to be used, and, the approach

to be followed for each activity.

Purpose: Identify requirements, constraints, and assumptions for this project, analyze them,

and develop a system development approach.

Entry Criteria: First version of the Project Management Work Breakdown Structure is complete.


Project Manager Identify the development team and approach for the plan

In the System Development Plan:

o Briefly state the purpose and general nature of the product, service, or

result.

o Summarize the purpose and contents of the plan and describe any

security or privacy considerations.

o Describe the relationship, if any, of the SDP to other project

management plans.




Project Team, others

working with the team

In an overview of required work, provide:

o Requirements and constraints on the product, service, or result

o Requirements and constraints on project documentation

o Position of the project in the system life cycle

o Requirements and constraints on project schedules and resources

o Other requirements and constraints, such as on project security, privacy,

methods, standards, interdependencies in hardware and software

development, etc.

In plans for performing general delivery activities, identify:

o Delivery process

o Handling of critical requirements

o Safety assurance

o Security assurance

o Privacy assurance

o Assurance of other critical requirements

o Computer hardware resource utilization.

For project planning and oversight related to the delivery of the product,

service, or result:

o Delivery planning

o System test planning

o Installation planning

o Transition planning

o Maintenance Agreement

o System requirements analysis

• Analysis of user input

• Operational concept

• System requirements

o System design

o System-wide design decisions

o System architectural design requirements analysis

o product evaluation

Senior Management Review SDP

Decides whether or not to proceed with project

Project Manager Prepare the SDP for the project, incorporating it into the overall project plan


Exit Criteria: Team has considered all aspects of the delivery of the product, result, or service

System delivery approach is documented, and has been published for team use

Management agreement project should proceed.

Output: Approved System Development Plan



Develop the Acquisition

Plan

Process Contract

Amendment or Change

Orders

Modify Change Request

and Resubmit

>10% Budget

Increase OR Sizable

Timeline Change?

Sponsor Approval?

Contract Amendment

or Change Order

Approved?

Perform

Executing

Processes

Procurement

Process

Acquisition Plan

Approved?

Prepare Acquisition

Instrument

Solicitation and

Contracting Stage

Gate Approved?

Acquisition Instrument

Approved?

Procurement

Changes

Yes

No

Yes

No

Yes

No

Effect Procurement

Changes

Resolve Issues and

Resubmit

Resolve Issues and

Resubmit

Resolve Issues and

Resubmit

Yes

Yes

No

No

Yes

No

Figure 6-3 Procurement Process



6.20 Acquisition Plan

The Acquisition Management Plan describes how the procurement processes (see Figure 6-2) will be

managed from developing procurement documentation through contract closure. The plan may be formal

or informal and detailed or broadly framed. The plan is based upon the needs of the project. The plan may

contain, but is not limited to:

Types of contract to be used

Handling the make-or-buy decisions

Standardized procurement documents, if needed

Constraints and assumptions that could affect the purchase

Establishing the style and format of the contract

Identifying pre-qualified selected sellers, if any

Procurement metrics used to manage contracts and evaluate sellers

Purpose: Identify the key processes for managing the complete lifecycle of a contract.

Entry Criteria: Business Case, if available





Risk Register

Project Schedule

Resource Calendar

Cost Baseline



Team (or a subset)

NOTE

Before submitting the Acquisition Plan to a reviewing and

approval authority, ensure no further material changes may

be instituted. The plan must describe accurately and

completely the procurement approach to be taken for the

project.

Describe how this procurement will solve a business problem. Provide a

concise, specific description of the items and services to be procured. Do not

describe what needs to be done.

Declare the assumptions which are factors considered to be true, real, or

certain for planning purposes.

Name the constraints which are internal or external factors limiting the project.

Explain the research approach, especially which data sources were chosen and

why others were not chosen. Explain how the data was analyzed. Explain the

conclusions drawn from the analysis of the data including the impact of those

conclusions on the procurement.

Delineate the procurement project‟s major milestones. Identify which goods

and/or services are associated with each milestone and justify decisions where

phases or additional steps are planned.

Consult and coordinate with the contract manager to plan and execute the

procurement process

Explain the business justification for procurement method, how the

procurement method was chosen, and list any statutes or rules requiring a




particular method for this procurement.

Provide the evaluation and award approach, including evaluation factors and

overall use for vendor selection. Identify and describe any tools that will be

used for evaluation.

Detail how the performance standards and measurements will be used

specifically in terms of the procurement scope, assumptions, constraints, risks,

and strategy.

Describe the approach for tracking and managing all planned and actual

contractor deliverables, services, and maintenance agreements.

Describe the approach for managing invoices, including coordination between

program and fiscal staff.

Articulate the approach for escalation and resolution of contract disputes.

Describe the approach for contract closeout including products and services

verification, administrative closeout.

Project Manager Prepare the Acquisition Plan for the project, incorporating it into the overall

project plan.



Output: Approved Acquisition Management Plan



7.0 EXECUTING

Execute the

Configuration Plan

Execute the Project

Plan

Information Distribution

Execute the

Performance

Management Plan

Execute the Risk

Management Plan

Perform Quality

Assurance

Maintain the Schedule

Instances of Execution

Activities Completed

Time to Perform

Executing

Processes

Perform Closing

Processes

Figure 7-1 Executing Processes



The executing process is necessary for directing the various technical and organizational interfaces that

exist in the project to execute the work defined in the project management plan. The deliverables are

produced as outputs from the processes performed as defined in the project management plan.

Information on the completion status of the deliverables and what work has been accomplished are

collected as part of project execution and input to the performance reporting process (PMBOK, 2004).

During the Execution Phase, implementation of the project's plans happen resulting in the building or

delivery of the product, service, or result. In Execution, the project team transforms the concepts of

planning into action and this is when most of the project time is spent. Execution is also where the project

is at its greatest risk for failure. In this phase, discipline in following developed plans and using the

Change Management process when the plans need modification is pivotal. Recognize the practical truth

that plans will not survive the execution process intact, but dedicated use of the plans will allow the

project's challenges to be overcome. This is where the project manager's skills come into play. The project

manager‟s attention shifts for the Execution Phase. While the prior efforts focused on what to do, and why

to do it, this effort concentrates on the best way to do it. The approach is more practical, hands-on with

each effort aimed at successful completion of the project.

Purpose: Implementing the plans for managing the project.





Risk Register

Project Schedule

Resource Calendar

Cost Baseline



Team (or a subset)

The project manager and the project team perform multiple actions to execute the

project plan to accomplish the work defined in the project scope statement. Some of

those actions are:

Perform activities to accomplish project objectives

Expend effort and spend funds to accomplish the project objectives

Staff, train, and manage the project team members assigned to the project

Obtain quotations, bids, offers, or proposals, as appropriate

Select sellers by choosing from potential sellers

Obtain, manage, and use resources including materials, tools, equipment, and

facilities

Implement the planned methods and standards

Create, control, verify, and validate project deliverables

Manage risks and implement risk response activities

Manage sellers

Adapt approved changes into the project‟s scope and plans

Establish and manage project communication channels, both external and

internal to the project team

Collect project data and report cost, schedule, technical and quality progress,

and status information to facilitate forecasting

Collect and document lessons learned, and implement approved process

improvement activities



Project Manager Conduct the execution of the project, using the overall project plan and its

subsidiary plans.


Exit Criteria: Monitored by project team, stakeholders, and sponsor.

Project activity is moving ahead within scope, time, and cost

Output: On-going implementation of plans



8.0 MONITORING AND CONTROLLING

Vendor

Performance

Reporting

Change Requests

PMRS Status

Reporting

QAT Monitoring

Report

Acceptance to

Deploy

Monitoring and

Controlling

Processes

Perform Closing

Processes

Contract

Administration

Risk Monitoring

Performance

Reporting

Manage Project

Team

Perform Quality

Control

Cost Control

Schedule

Scope Control

Scope Verification

Deployment Stage

Gate Approved?

Resolve Issues

Yes

No

Figure 8-1 Monitoring and Controlling Process



Project managers use the Project Monitoring and Controlling Process for ensuring the team is making

satisfactory progress towards meeting the project goals. The purpose is tracking all major project

variables – cost, time, and scope. The overall objectives of the process are to:

Track and review actual project accomplishments and results to project plans

Revise the project plan to reflect accomplishments thus far, and to revise the plan for remaining work,

if needed

Provide visibility into progress as the project proceeds, so the team and management can take

corrective action early when project performance varies from original plans

8.1 Scope of the Process

The monitoring and controlling processes are based on the Project Management Plan and the subsidiary

plans. For many Level 1 and Level 2 Projects, the plan is likely to undergo change to reflect the resolution

of unknown items or changed items since the start of the project.

8.2 Monitoring and Controlling Activities

Monitoring and controlling activities vary for different types of projects, in the same way planning the

project varies by type of project. The activities, roles, and deliverables may be performed slightly

differently for different types of projects. The project manager should complete any process/activity

deemed necessary for the success of the project.


Continuously Monitor

Progress

Project manager uses

project plan as basis for

monitoring; each team

member provides weekly

status report to the project

manager or a team leader

Project manager uses

project plan as basis for

monitoring; each team

member provides weekly

status report to the project

manager or a team leader

Use the project summary

as the basis for

monitoring and control

Conduct Team

Reviews

May be several sub-teams

which regularly review

progress as well as an

overall regular team

meeting and regular

reports

Conduct a weekly

coordination meeting to

review status of the work,

risks, measures, and

action items being

handled

May be done with e-mail

or informal sessions

Conduct Formal Progress

Reviews

Complete on a monthly

basis with senior

management and key

stakeholders

Do on a monthly basis

with senior management

and key stakeholders

May be done with e-mail

or informal sessions

Manage Changes Include Subject Matter

Experts (SME) from

project, customer,

management, CM areas

Include Subject Matter

Experts (SME) from

project, customer,

management, CM areas

May involve only one or

two people

Revise the Plan Significant changes are

reviewed and agreed to by

the change control board

Significant changes are

reviewed and agreed to by

the change control board

May be informal

agreement with

management

Conduct Work Product

Reviews

Have technical reviews

and inspections based on

quality goals

Walkthroughs, some

technical reviews and

inspections

Informal walkthroughs

with two or three people



8.3 Monitoring and Controlling Roles in the Process


Project Manager Plan and track the project, including approved revisions to project plans, estimates,

schedules, and budgets

Project Team Participate in building and reviewing the plan and project work items; develops or

implements the deliverables

Senior Management

(including Steering

Committee)

Authorize the project and provides staff and other resources

Review progress and approves any changes to plans ensuring the project meets

organization goals

Configuration

Management

Identify (or review work done by the team to identify) the configuration items

handled with configuration management, place the items under control, create

baselines, make authorized changes to the configurations, provide status reports,

and build releases of the product

Change Control Board Review requests for changes to project baselines (requirements, deliverables

completed, work underway), approve or reject change requests, ensure approved

changes are completed as authorized

8.4 Monitoring and Controlling Roles


Project Manager Dedicated to project

management



of the team




Configuration

Management

Performed by someone on

the project team or

someone from an

independent group

Performed by someone on

the project team or

someone from an

independent group

Performed by project

manager or a member of

the team

Change Control Board Formally chartered group

composed of project

manager, department

head, key stakeholder,

Subject Matter Experts

Project manager, senior

manager, Subject Matter

Experts

Done by the project

manager and one or two

others

8.5 Monitoring and Controlling Deliverables

Activity

Deliverable


Project status reports Meetings, e-mail, regular

hard copy, filed in project

notebook

Meetings, e-mail, possibly

hardcopy at major

milestones

E-mail or verbal reports

Configuration

Management

activity/status reports

Formal reports to standard

distribution

Activity logs kept in

project notebook

Notes from CM

Change Requests File requests at end of

each phase

File requests at end of

project

May be filed by Process

Improvement Team.

Vendor Performance

Review

Performance tracked by

vendor

1 or 2 paragraphs

overview of vendor

performance

Not applicable for

projects of this size

Acceptance to Deploy Acceptance to Deploy by

stakeholders required

Acceptance to Deploy by

stakeholders

recommended

Acceptance to Deploy by

stakeholders

recommended



Activity

Deliverable


Project Implementation

Review Gate

Use TTUHSC Business


template

Obtain documented

approval signed by


sponsor



approval

8.6 Continuously Monitor Progress

Ensuring the project stays on track, the project manager and project team continuously monitor their

progress to the Project Plan.

Purpose: Examine progress on all key dimensions of the project, to determine whether or not

project goals are likely to be met, as documented in the Project Plan. When a

variance is detected, take appropriate corrective action.

Entry Criteria: Approved Project Management Plan

Work is underway

Explicit assignments of responsibility for work products and activities have

been made

Project is staffed and other resources are available

The project manager has been trained to perform the appropriate technical and

management responsibilities of the project


Project Manager Monitor, at least weekly, progress to plan on the key elements

o Tasks starting and ending when expected

o Deliverables with content and quality level required

o Level of effort as planned

o Size of work products as planned

o Milestones being met when planned

o Costs as budgeted

o Risk management progress

o Issues and action item resolution

o Measures to handle key project issues

Review and process requests for changes to the plan

Initiate and monitor corrective actions when necessary

Project Team Members Review progress on the tasks assigned and level of effort spent compared to

effort planned

Report progress weekly to the remainder of the team and the Project Manager

Monitor for and report potential risks to the project

Enter data for measures associated with project issues

Configuration

Management Accept items for configuration management as planned, if they meet the

conditions set by the project and by organization processes for configuration

management

Report on status and content of baselines

Exit Criteria: Project activity has reached a logical conclusion

Output: Project work is complete or the project is terminated (this activity continues

throughout the project)



8.7 Conduct Team Reviews

Holding regular reviews of progress and status is useful for most projects involving a team. Teams might

regularly meet or the team might exchange information electronically.

Purpose: Communicate status and plan for next activities of the project.

Entry Criteria: Project is staffed and underway.


Project Manager Determine what kinds of information need to be exchanged

Decide what medium of communication is best – meeting, electronic exchange,

or other

Determine frequency of communication


Team Exchange status information (in e-mail, team meeting, or other)

o Current action items, issues, and risks

o Status of technical activities

o Plans for next activities

o Establish action items


Team Follow up on action items, as appropriate

Work on next task assignments

Exit Criteria: Status reporting for the different needs of stakeholders and the project team

Output This activity continues throughout the project.

8.8 Conduct Formal Progress Reviews

Conduct formal progress reviews for Level 1 Projects and for Level 2 Projects ensuring all stakeholders

are kept informed of project status and progress. The reviews may be at key milestones for a project or

they may be event-driven or date-driven. Projects often hold monthly or quarterly reviews in addition to

project phase-based milestone reviews.

Purpose: Communicate status of the project to stakeholders and ask for assistance in areas

needing management or stakeholder attention.

Entry Criteria: Project has reached milestone, event, or date for review


Project Manager Identify information that needs to be prepared and/or presented

Identify participants for the review

Establish tasks and assignments for the review

Establish review logistics


Team Prepare information for the review, including items such as

o List of accomplishments in last period

o List of plans for next period

o Milestone progress reports (planned to actual)

o Staffing profile (planned to actual)

o Cost Profile (planned to actual)

o Size and Critical Computer Resources (if appropriate)

o Risk Management Status

o Action Item Status

o Quality Assurance Status

o Configuration Management Status

o Requirements Management Status



o Updated Cost-Benefit Analysis

Project Manager, Senior

Management, Other

Stakeholders

Conduct the review

Present the status information

Identify action items that require attention of management and/or stakeholders

Gain agreement on next steps and action items

Project Manager Provide information requested and establish action items

Exit Criteria: Reviews conducted and information disseminated

Output: Completed review and any follow-up information communicated

Action item list is updated with items from the review

8.9 Manage Changes

For most projects, changes occur. Changes may include requirements, issues, or changes to resource

commitments. Changes can be handled by the Change Control Board process.

Purpose: Identify, evaluate, prioritize, and control changes to the project.

Entry Criteria: Project is underway

Change request submitted by a project member or a stakeholder


Change Control Board

Member

Document the change requested, along with priority of the change, approaches to

handle the change, work around if the change is not implemented

Project Manager Acknowledge the change applies to this project

Enter change request into tracking system log

Change Control Board Review the change request and determine whether or not it is worth evaluating for

action

Project Team Member Estimate the impact of the change on the project effort, cost, schedule, resources

Change Control Board Using the estimate, decide whether or not to authorize the change

If the change is denied, communicate that decision to the requestor and

terminate this process

Project Manager Incorporate the change into the project work plan and adjust resources and schedule

as needed, to accommodate the change

Project Team Member Perform the work needed to address the change, and conduct the associated

verification activities to ensure correctness

Update change request records to document the changes made, and

communicate completion status to the Change Control Board

Change Control Board Update the change request records to reflect the completion status and inform the

requestor of the final status

Exit Criteria: Change control process complete

Output: Change has been addressed and requestor has been informed

Change request records have complete information about the request and the

work done to address it

8.10 Revise the Plan

The project plan is revised if there are significant changes in project deliverables, schedule, budget, or

approach. The plan is usually adjusted at the end of each major lifecycle phase. Any signoffs needed for

the initial project plan are required for a significant change.



Purpose: Revise the project plan (including estimates and schedule) to accommodate

significant changes, so the documented plan reflects the plan in use by the project

team.

Entry Criteria: Project team and Change Control Board agree to a significant change in the project.


Project Manager Determining a significant change in the plan is needed. Examples of such changes

include:

Lifecycle approach has changed from one release cycle to a series of iterations,

or the number of releases has changed

Time spent in a given project phase or the overall schedule has been changed by

more than n% (determined by state or institution guidance)

Requirements have changed in a way that requires additional staffing, more

time, or an alternate approach to the work

Tools and methods to be used are different from what was initially planned


Team Develop updates to project plan, review with all affected parties

Establish commitments to changes in plan

Change Control Board,

Stakeholders Review changes to project plan

Approve changes (or negotiate for other changes)

Sign off updated plan

Project Manager Place updated plan under configuration management

Exit Criteria: Project manager works with the project team and key stakeholders, producing

updates.

Output: Project plan is updated, approved, and under configuration management

Changes to commitments have been communicated to all affected parties

8.11 Conduct Work Product Reviews

The project team conducts team reviews of the work products being built throughout the project lifecycle.

The types of reviews may vary to ensure best use of time spent on the review according to the plan set.

Purpose: Ensure all involved understand the content of a given work product and identify any

changes needed in the work product before starting work on other work products

that depend on it.

Entry Criteria: Author agrees work product is ready for review

Team is available to review the item

Review process is defined and understood by the review team


Project Team Member

(author) Identify what portions of the work product are to be reviewed

Work with Project Manager to set goals for the review and select type of

review. Alternatives include:

o Informal Walkthrough by several team members

o Technical Review by project team members and stakeholders

o Inspection by project team members (and perhaps others)

Select a moderator for Technical Review or Inspection

Moderator Establish logistics for Technical Review or Inspection

Hold a kick-off meeting if needed, to distribute materials

Review Team Examine work product before attending the review meeting

Document questions and defects in the work product




Review Team, Moderator

(if relevant) Participate in the review meeting

o Informal Walkthrough – team examines the work product at its own

pace, giving feedback to the author

o Technical Review – moderator leads the review team through the key

issues of interest identified for the review

o Inspection – moderator leads review team through logging meeting,

gathering defects and questions for the author

Author Incorporate feedback from the review

Quality Assurance,

Project Manager

Review results of the work product review to ensure goals have been met and

organization processes were used (and useful)

Exit Criteria: Work reviews conducted and documented

Output: Feedback is incorporated into work product

8.12 Verification Activities

During project monitoring and control, the following verification activities are appropriate for

management:

Review periodic reports of the project team and/or project manager, to ensure the project continues to

meet business needs.

Provide information, as needed by the project, and authorize the work to proceed if the project is

meeting plans and commitments.

Participate in formal project and vendor performance (if applicable) reviews, reviewing status and

handling action items.

Review the Business Case (or cost/benefit analysis, as appropriate) on a regular basis ensuring the

project should continue.

The following verification activities are appropriate for Quality Assurance:

Review activities of the project team on an ongoing basis verifying they are following the plan and the

relevant processes of the organization.

Review the results of work product reviews and testing ensuring the project deliverables meet

customer requirements and project quality plans.

Review change management and configuration management activities ensuring they follow the

organization processes and baselines are under control.



9.0 PROJECT CLOSURE

Closing

Processes

Project Complete

Project Closeout

Report

Perform Post-Project

Processes

Project Closing Stage

Gate Approved?

Yes

No

Resolve Issues

Figure 9-1 Closing Process



Post-implementation

Review of Business

Outcomes

Benefits Realization

Stage Gate

Approved?

Resolve Issues

Business Area Need

Satisfied

Post-Project

Processes

Yes

No

Figure 9-2 Post-closing Process

9.1 Scope of the Lessons Learned Process

Project Closeout Reviews are generally done at the end of any significant project or portion of a project.

A project running longer than a year may conduct Post Phase Reviews at the end of each significant

phase, capturing lessons learned while they are still easily recalled.

9.2 Closing Activities

Monitoring and controlling activities vary for different types of projects, in the same way planning the

project varies by type of project. The activities, roles, and deliverables may be performed slightly

differently for different types of projects. The project manager should complete any process/activity

deemed necessary for the success of the project.



Activity Level 1 Projects Level 2 Projects Level 3 Projects

Define the Process to Use

Follow the process

described here at the end

of each phase of the

project

Follow the process


of the project

Use small team discussion

of those involved

Build Data Gathering

Instruments

Use the long form for data

gathering, tailored to the

phase

Use the short form for

data gathering

Use a simple project

summary form

Gather Information

Include all project

participants and

stakeholders

Include all project

participants

Include just the team

Conduct Project Closeout

Review Session

Conduct a facilitated

review session at each

phase

Conduct a facilitated

review session

Hold an informal

discussion

Distribute Lessons

Learned

Follow the process


of each phase of the

project

Follow the process


of the project

Update the minimal set of

factors, based on this

project‟s experience

9.3 Closing Roles

Members of the project team, key stakeholders, and users of the project deliverables, services, or results

generally participate in the Project Closeout Review process. An objective facilitator runs the process.

The facilitator might be an external facilitator. The project leader can run the session if no independent

participant is available. The roles in the Project Closeout Review are described in the following table.


Moderator Organizes the sessions and facilitates any meetings

Project Lead Represents the project overall; generally, a member of the development organization

which performed the project

Participant Provides input to the Project Closeout Review, based on experience with the project

or its results

Scribe Gathers information from participants and documents the final report of the Project

Closeout Review for this project

Process Improvement

Team

Handles suggestions for changes in Lessons Learned structures and requests for

process changes

9.4 Closing Roles


Moderator May be Process

Improvement Team

Subject Matter Expert

(SME), QA engineer, or

other non-project person

Process Improvement

Team Subject Matter

Expert (SME)

Likely to be Project

Manager

Meeting

Participants

Project team, Subject

Matter Expert (SME)s

from all stakeholders

Project team, selected

stakeholders

Project team




Scribe May be Process

Improvement Team


(SME), QA engineer, or

project team member

Project team member Project Manager

9.5 Closing Deliverables

Activity

Deliverable

Level 1 Projects

Level 2 Projects

Level 3 Projects

Project Closeout Report Describe in project plan,

with WBS and schedule.

Project results are

reviewed and final

acceptance by stakeholder

is required.

One or two paragraph

overview of project

completion. Project

results are reviewed and

final acceptance by

stakeholders is

recommended.

One sentence description

in project plan. Project

results are reviewed and

final acceptance by

stakeholders is

recommended.

Surveys Long form questionnaire Short form questionnaire Informal questions in a

meeting

Review Summary Detailed analysis of

findings with

recommendations

One or two paragraph

overview with specific

recommendations

Notes from meeting

Lessons Learned Long form for data

gathering, end of each

phase and end of project

Short form for data

gathering, end of project

Notes from informal

discussions

Change requests File requests at end of

each phase

File requests at end of

project

May be filed by Process

Improvement Team

Post Implementation

Review of Business

Outcomes

Begin within six months

after Project Closeout

Report complete. Project

information should be

reviewed and analyzed

throughout the project

lifecycle.

An analysis of project

information

recommended

An analysis of project

information

recommended


Review Gate

Use TTUHSC Business


template

Obtain documented

approval signed by


sponsor



approval

9.6 Overview of the Closing Process

The project estimates of effort, original and final schedules, project budget, actual costs, and staffing

profiles are gathered from the project tracking tools. Any data existing in a reusable form should be

collected. Items benefiting from discussion and consensus forming should be the subject of the Project

Closeout Review Session – what went well, when it needs to be changed, what risks occurred as

problems, what risks to watch for in the future. Archive Lessons Learned from the Project Closeout

Review so project team members, process improvement teams, and managers easily find useful

information.



9.7 Define the Process to Use

Purpose: Select and communicate to those involved the approach to be used for this Project

Closeout Review.

Entry Criteria: Project work is complete

A Moderator has been selected

A review schedule has been prepared


Moderator and Project

Lead

Discuss the alternatives for performing the Project Closeout Review, and select

appropriate elements. Potential components include:

Kickoff meeting to describe the process

Survey for each person to complete; might be tailored from a standard

organization format

Project Closeout Review session to discuss results

Report circulated for comment/correction

Report archived in process assets library

Distribute information about the approach to all involved

Exit Criteria: There is agreement on approach.

All involved have been notified of the next steps

Output: Process identified and documented

9.8 Build Data Gathering Instruments

Purpose: Identify information to be gathered and structure the instruments

Entry Criteria: Project records are complete and accessible

Participants can be reached through a common medium


Moderator and Project

Lead

Review the kinds of information generally gathered for projects of this type in

this organization in Project Closeout Reviews

Identify existing sources and data. Items to consider include:

o Initial budget, final cost

o Initial staffing estimates, profiles; actual staffing profiles

o Initial effort estimates, final effort values

o Initial work product size estimates; final values

o Initial milestone and schedule; final values

o Number of requirements changes

o Rework statistics

o Product quality targets, actual values

o Initial risk list, final results of risk management

o Any other relevant measures of process or product

Review local templates for gathering information from participants

Identify information to be gathered from project participants and stakeholders.

Candidate items include:

o Success rating by team, management, customers

o Key things done right on the project

o Key things done wrong and should be changed

o Risks not detected and became problems

o Risks for which mitigation actions were ineffective

Develop a survey; distribute to participants (with notice of when to complete) to

include information in Project Closeout Review Session.




Develop a summary form for analyzing the data

Exit Criteria: Sources of project history data identified

Survey prepared and distributed for participant feedback

Output: Data gathering instruments assembled

9.9 Gathering Information

Purpose: Collect data for Project Closeout Review Session and project history database

Entry Criteria: Summaries are complete and agenda is ready for Project Closeout Review Session


Moderator Gather all of the project history data and ensure data is complete and ready for the

organization project history database

Participants Complete the survey or use the risk management tools to enter personal responses to

lessons learned items

Moderator Review the results of all individual responses

Generate a summary report in areas that can be summarized; build lists of those

items requiring discussion and consensus (things done right, things done wrong,

risks missed, etc.)

For any data that appears to be suspect, review with the provider and reach

agreement on a resolution (or remove suspect data)

Set agenda for the Project Closeout Review Session and distribute an

announcement of the meeting to all participants. A possible agenda includes:

o Review of summary information gathered thus far

o Using results of surveys, facilitated discussion of things done right;

group ranking of most important, suggestions for how to ensure they

continue to be done in future projects

o Facilitated discussion of things done wrong; group ranking of most

important

o Brainstorm causes of these problems and how to ensure they don‟t

happen again

o Review of risk management effectiveness, what was missed; brainstorm

factors to include, ways to adapt mitigation

o Structured discussion of lessons learned, using an organization

structure, such as a risk factor table or another lessons learned

taxonomy, to identify lessons to add

o Collect any other comments participants want recorded

Exit Criteria: All participants have provided individual input

Agenda for Project Closeout Review Session has been published

Output: Lessons Learned data gathering session complete

9.10 Conduct the Lessons Learned Review Session

Purpose: Review project results with participants and gather consensus information

Entry Criteria: Most participants are able to attend the session

Summaries of surveys are ready for the session


Moderator Calls session to order and conducts it according to the agenda.




Methods used to facilitate the consensus-building portion of the session include:

o Nominal group technique, starting with the lists gathered from

individual participant surveys before the session

• Ask team about what went right; record the information; ask how

to preserve information (if not already in processes) and document the

information

• Ask team what went wrong

• Use voting technique to get team to select top „N‟ ideas to

improve

• For each, ask how to avoid next time; if not already in processes,

document the advice

o Facilitated completion of tables using risk management information

gathering tools or other Lessons Learned taxonomy

• Review final project risk list and gather the end of project details

for each risk (level of satisfaction, cost of the action, etc.)

• Elicit from project team any major problems that arose and how

they might have been detected as risks early in the cycle; mark those as

risks that emerged; if this is a complex project, go through each

category to prompt people for ideas

Participants Describe experiences and provide suggestions for how to improve the work of the

project

Scribe Record all meeting proceedings and capture ranked lists from the discussions

Exit Criteria: Participants agree all key input has been provided

Output: Draft document of lessons learned

9.11 Documents Results From Session

Purpose: Build the permanent record of lessons learned from this project

Entry Criteria: Team input is complete


Scribe Work with organization process improvement team to consolidate items from

the Project Closeout Review session into a form that fits the organization

Lessons Learned collection (may be risk factors or other taxonomy)

Write change requests to handle changes suggested by the project team

Write report on the results of the team Project Closeout Review session.

Distribute all results to participants for review.

Participants Review draft results and provide feedback to scribe.

Scribe Make suggested modifications as appropriate.

Archive results in organization process assets library.

Project Lead Ensure useful records from project are placed in project history database

Determine how best to distribute key results of the Project Closeout Review and

use those channels (example: brown bag seminars, presentations to quality

councils, presentations at technical seminars)

Exit Criteria: Participants have reviewed draft results and provided feedback.

Project history data is archived in an approved location

Organization structures for handling Lessons Learned have been updated, or

updates have been provided to the maintainer



Output: Completed Lessons Learned document or file

9.12 Measures

Measures used to determine the effectiveness of Project Closeout Reviews may include the following.

Change requests – The measure should include the number of suggested changes, as well as an

indication of the level of importance to the project team, any indication of when each change is

needed, and suggestions for the content of the change.

Lessons Learned Updates – The measure should include a count of the number of lessons (e.g. risk

factors) being added or changed in the organization‟s collection.

Level of Participation – Measure the participation of the project members and stakeholders in the

Project Closeout Review process, to understand the percent coverage of those who could have

constructive input to improving the processes.

9.13 Verification Activities

The following management verification activities are appropriate for Project Closeout Reviews:

Ensure the project manager and project team are performing Project Closeout Reviews for all medium

and Level 1 Projects.

Review the results of the Project Closeout Reviews, to identify actions needed by management, so

processes and project conditions are continuously improving.

9.14 The Closing Process

The Closing Process includes the processes used to formally terminate all activities of a project or a

project phase, hand-off the completed product to others, or close a cancelled project. This group, when

completed, verifies the defined processes are completed to close the project or a project phase and

formally establishes the project or project phase is finished. Some projects are easy to close, especially

once the budget is exhausted. But other projects can drag on, particularly if there are still pending issues,

change requests or outstanding bugs, and ending these projects can be difficult.


Project Manager Gather all project information

Ensure any contracts are closed

Verify and document the project deliverables

Confirm the project has met all sponsor, customer, and other stakeholders‟

requirements

Verify all deliverables have been provided and accepted

Validate project completion and exit criteria have been met

Coordinate and interact to formalize acceptance of those deliverables by the

customer or sponsor

Investigate and document the reasons for actions taken if the project is

terminated early

Archive information in project repository

Release project resources no longer required

Purpose: Close the project

Entry Criteria: Project deliverables complete

Contracts closed

Business outcomes met



Exit Criteria: All project processes complete with no exceptions to product.

Output: Archived Documents



10.0 GLOSSARY

The terms and descriptions below are explained as used / intended in the context of this document. Other,

or more elaborate, descriptions may exist for the terms listed.

Term Acronym Description

Acceptance to Deploy Provides a consistent method for formal product and/or service acceptance

before a product and/or service becomes operational. Various stakeholders are

responsible for deployment acceptance and must agree the product and/or

service can transition to operational status.

Acquisition Plan Describes how the procurement processes will be managed from developing

procurement documentation through contract closure. The plan may be formal

or informal and detailed or broadly framed. The plan is based upon the needs

of the project.

Approximately Symbol used as shorthand for the term „approximately.‟

Audit Review of project to assess compliance with requirements, specifications,

baselines, standards, procedures, instructions, codes, contract requirements,

and/or license requirements.

Availability Availability is a measure of the planned up-time during which the system is

actually available for use and fully operational. Availability is equal to the

Mean Time Between Failure (MTBF) divided by the sum of the MTBF plus

the Mean Time To Repair (MTTR) or MTBF / (MTTR + MTBF).

Baseline

An original plan with any approved changes applied.

A product release, including all related components used to create the product.

Business Area

The business unit conducting information resources activities.

Business Case Provides comparative information between business solution costs and

proposed project benefits. As a detailed investment proposal, the Business

Case considers quantitative and qualitative evaluation factors and provides the

baseline information to make an informed decision and whether to

recommend proceeding further.

Business Process

A set of activities performed continuously and produce one or more major

outputs.

Business Technology

Change

The evolutionary/revolutionary/regulatory increment in how an application,

system, equipment, tool, process, or knowledge use functions.

Change (As In Change

Control, Below)

Any alteration of the functional or physical characteristics of a project work

product. This includes both defect repairs and enhancements.

Change Control Process by which a change is proposed, evaluated, approved or rejected,

scheduled, and tracked to completion.

Change Control Board

CCB The governance body that reviews submitted Change Assessments, then

makes approve/reject/defer decisions for each underlying Change Request.

Change Control

Management

The process of handling change requests including: documenting the request;

evaluating the request; and disposing of the request.

Change Management

Process

A formal means to handle deviations/additions to a controlled work product

resulting from change requests, defect reports, maintenance requests, or

enhancements. For each potential change, the change management process

must handle how changes are requested, assessed, approved/rejected/deferred

and implemented if approved.

Change Request

A written request to modify an existing project‟s planned product,

documentation, or processes.

Commitment Pact between two or more people who trust each other to perform;

commitments are freely assumed, explicitly defined, and visible.




Configuration Functional and physical characteristics of hardware or software as set forth in

technical documentation or archived in a product; requirements, design, and

implementation that define a particular version of a system or system

component.

Configuration Management

CM The process of applying technical and administrative direction and

surveillance over the lifecycle of configuration items to:

Identify and document the functional and physical characteristics of

configuration items (Configuration Identification)

Control changes to configuration items and related documentation

(Configuration Control Processes)

Record and report status of proposed and approved changes (Status

Accounting)

Audit configuration items to verify conformance to documented

requirements (Configuration Auditing)

Configuration Management CM Configuration Management (also known as SCM, Software Configuration

Management)

Contract Amendment and

Change Order

Ensures project changes that impact a technology contract are analyzed and

justified before funds can be expended for those changes. The impact to the

project, whether to the contract completion date, contract scope, or some other

change, is identified as part of the Contract Amendment and Change Order

process.

Defect Report

A documented problem instance with an existing project‟s product,

documentation, or processes as discovered during a controlled test.

Deliverables

Tangible and meaningful, intermediate internal or final external work outputs

from a project planned, developed, and inspected.

Development

A generic term for the sum of activities performed by IT staff to create a

product based on a given set of requirements.

Discovery

The first phase of an IR Asset‟s (application‟s) lifecycle where the need for a

product or business change is evidenced.

Documentation

The internal working or deliverable collection of written/printed/drawn

documents including requirements, plans, reports, data, source codes, et cetera

distributed and/or archived on an application.

Efficiency Efficiency is a measure of how well the system uses processor capacity, disk

space, memory, or communication bandwidth.

Enhancement

A written request to change, modify, improve, or create an application,

system, or operation beyond an existing project‟s scope, production

application, system, or operation‟s current capability.

Enterprise

Reference to IR Assets with characteristics including: large scope, schedule,

resources, or cost; high risk for the sponsoring organization, complex or new

technology, significant procurement, notable linkage to public or private

entities, or executive directive to handle as such.

The largest relative business unit level.

Evolution

The remaining portion of an IR Asset‟s (application‟s) lifecycle, once fully

delivered from development, which covers maintenance, support, operational,

and strategic needs.

Flexibility Measures how easy it is to add new capabilities to the product. Also known as

extensibility, augmentability, extendibility, and expandability.

Impact The relative harm or damage to a project if a risk becomes a problem, usually

expressed either as a dollar amount or on a scale from 1 to 10.

Information Resources IR The development, installation, and implementation of computer systems and

applications (See IT).

Information Technology

IT The development, installation, and implementation of computer systems and

applications (See IT).

Information Resources Asset

An IR application, system, equipment, tools, process, or knowledge that

supports a business need. Usually refers to assets enabling or supporting a

substantial business operation.




Information Safety Officer ISO ISO is principal information security advisor to executive management and is

required to analyze and assess risks to their institution‟s technology

infrastructure and make informed decisions and recommendations on how to

spend resources to address security issues.

Infrastructure

The baseline integrated technical elements of the enterprise upon which higher

level business application systems are built. e.g.: local area network, wide area

network, client/server operating environment, electronic mail, office worker

productivity application suite.

Initiation

The second phase of an IR Asset‟s (application‟s) lifecycle, where the need

for a product or business change is documented in a project charter and

presented for approval.

Installation

The activities involved with the physical putting in place of a product.

Activities may include: planning, training, erecting and connecting equipment,

loading software, loading data, initializing/setting system parameters, tuning,

and operational readiness verification via test procedure.

Integrity Encompasses security and deals with blocking unauthorized access to system

functions, preventing information loss, ensuring the software is protected from

virus infection, and protecting the privacy and safety of data entered into the

system.

Interface

The point where two disparate systems, applications, tools, architectural

components, or user/machine meet and need to exchange underlying elements

of information.

Interoperability Interoperability indicates how easily the system can exchange data or services

with other systems.

Issue Any area of concern presenting an obstacle to achieving project objectives.

Issues Management

The process of identification, categorization, and resolution of project

problems known or certain to exist.

Lessons Learned

A joint activity by parties who participated in a recently completed major

involvement, such as a project lifecycle, whereby the key positive and

negative experiences are documented for the purposes of organizational

process improvement and future project planning purposes.

Lessons Learned Session Same as Project Closeout Review

Lifecycle

The lifetime phases from the beginning to the end of a defined set of

processes.

Maintainability Maintainability indicates how easy it is to correct a defect or modify the

software.

Maintenance

The actions to modify or upgrade a production application, system, dataset, or

operation from its current state to enable continued successful operation.

Maintenance Agreement

The joint pact describing what responsibilities, and to what extent, the

maintaining organization/staff and the sponsoring (D/D/O) organization are

committing for an application once it is placed into production use (Project

Closeout).

Maintenance Request

A written request to modify or update a production application, system,

dataset, or operation from its current state to enable continued successful

operation. Also a request for a controlled data change.

Major Information

Resources Project

Defined by §2054.003 (10), Texas Government Code, as any information

resources project identified in a state agency's biennial operating plan whose

development costs exceed $1 million and that

requires one year or longer to reach operations status;

involves more than one state agency; or

substantially alters work methods of state agency personnel or the

delivery of services to clients; and,

Any information resources technology project designated by the legislature in

the General Appropriations Act as a major information resources project.

Mean Time Between Fail MTBF The expected time between two successive failures of a system.

Mean Time To Repair MTTR The amount of time when something breaks and when it has been repaired and

is fully functional again.




Milestone Scheduled event used to measure progress in a project.

Milestone Review Formal review of management and technical progress of a project

Monitoring Report Provides a consistent method for presenting project status information to the

Quality Assurance Team. The purpose of the state-level monitoring process is

to help ensure projects have the means to achieve stated objectives.

Not Invented Here NIH The attitude of resisting anything not invented or derived by the using

organization or person

Performance Measurements Data used to assess, calculate, and determine the operational excellence of an

application.

Performance Tuning

Activities intended to maximize the overall efficiency of an application(s),

especially throughout response time.

Policy

A rule or direction established for an organization that is expected to be

followed.

Portability The measure of the effort to migrate a piece of software from one operating

environment to another.

Portfolio Management Through a collaborative process that involves the Deans, Vice Presidents and

the IT Board of Directors of the institution, Information Technology needs are

considered and prioritized so that they align with the mission and strategic

goals of the institution. Projects at TTUHSC are prioritized and scheduled

through the Office of the CIO under the direction of the IT Board of Directors.

Post Implementation Review

of Business Outcomes

Establishes a consistent method for evaluation of business outcomes. The

post-implementation review process establishes conclusions about whether the

project solved the business problem by achieving the stated business goals and

objectives.

Problem Report

A documented problem instance with a production application, system, or

operation behaving differently from previous results.

Process

A prescribed series of what actions to take in order to reach a particular

outcome.

Product

The primary tangible delivered to the requestor or intended consumer/user.

Product Development

A generic term for the sum of activities performed by IT staff to create a

product based on a given set of requirements.

Production

Generic term referring to the business use capability of a finished application,

system, process, or tool (as opposed to being in planning or development).

Program

An overarching strategy or group of projects managed in a coordinated way to

get benefits not available from managing the related projects individually.

Project

A temporary endeavor undertaken to create a unique product. A project has

the following characteristics:

Temporary-has a definite beginning and a definite end

Unique-the product is distinct from existing products

Done for a purpose by project staff building on successive deliverables

Interrelated activities

Performed by people and the project team is disbanded at completion

Constrained by limited resources

Planned, executed, controlled

Project Charter Provides a consistent method to formally authorize work to begin on a project.

The intent is that an agreement among stakeholders is established before

significant resources are committed and expenses are incurred. The Project

Charter is the tool that gives the named Project Manager authority to carry out

the project business. Approval of the Project Charter provides the go-ahead

for an officially recognized project to begin when business considerations,

such as, resources, budge, and timing allow.

Project Closeout Report A project management best practice. This deliverable summarizes the

efficiencies associated with key deliverables (planned vs. actual). It also

includes any outstanding issues and project lessons learned. This report is

filed within thirty (30) days of product or system deployment.




Project Plan Document describing the approach that will be taken for a project; typically

describes the work to be done, resources required, methods to be used,

configuration management and quality assurance procedures to be followed,

schedules to be met, and the project organization. The plan is required for all

projects, but is only submitted to the Quality Assurance Team when

requested. The plan will be used by the Team to analyze the status of the

project. Amendments to the plan may trigger a reassessment of risk and

monitoring levels

Project Issue

An event that has occurred, is now occurring, or is certain to occur and will

adversely affect the success of the project, and must be resolved.

Project Management

The third phase of an IR Asset‟s (application‟s) lifecycle, where the need for a

product or business change is formally managed to create a product.

System of procedures, process, technologies, and know-how that provides the

planning, organizing, staffing, directing, and controlling necessary to

successfully manage a project.

Project Management

Lifecycle Processes

PMLC Reference to the five process groups including: Initiating, Planning,

Executing, Monitoring and Controlling, and Closing performed by a project

manager.

Project Management Process

The set of policy, process, procedure, tools and techniques, standards,

knowledge and skill a Project Manager applies in the conduct of their job.

Project Monitoring And

Control

The process of analyzing project parameters‟ progress against plan,

commitments, risks, data management, and stakeholders to resolve issues and

take corrective action. Project parameters include: scope, schedule, resources,

quality, and budget.

Project Planning

The process of defining the approach, environment, work, schedule, resources,

and expected results for a project or specific portion thereof.

Project Lessons Learned The learning gained from the process of performing the project.

Project Schedule The planned dates for performing schedule activities and the planned dates for

meeting schedule milestones.

Project Sponsor

The person who ensures funds and resources are made available and allocated

to enable the project environment, assists in resolving project related hurdles

beyond the Project Manager‟s realm, and is the approving authority for key

project documents and deliverables.

Project Status Report Status reporting for the different needs of stakeholders and the project team as

well as overall status on the project.

Quality Assurance

The process of analyzing and managing project parameter performance

against the established standard/goal for the project environment.

Quality Assurance Team QAT The QAT is composed of Subject Matter Experts (SME) from the Department

of Information Resources and the State Auditor‟s Office. The Team is

responsible for reviewing, approving, and overseeing major information

resources projects.

Reliability The probability of the software executing without failure for a specific period

of time.

Repository

A single location or source reference point where subject matter and related

information is kept for multiple user access.

Requirements

A written description about a (future) product including: functional - what the

system must accomplish; interfaces, performance, non functional - security,

reliability, maintainability, et cetera. A well documented requirement has the

characteristics of being clearly defined, achievable, measurable, and agreed-to

by the (customer) business area.

Requirements Gathering

Activities of extracting, clarifying, and prioritizing information about a

(future) product. Sources of information may include: business area

customers, users, regulations, IR subject matter expertise, trade studies, policy

and standards, and records of enterprise processes and operations.




Requirements Management

RM The process of information capture, information storage and management, and

information dissemination. Information management includes organization,

traceability, analysis, and visualization.

Reusability Reusability indicates the relative effort involved to convert a software

component for use in other applications.

Review Gate A distinct division of project effort that involves successful completion of

specific deliverables in order to obtain agency head approval before

proceeding with project activities. Each review gate is intended to synchronize

the state‟s investment in a project based on approval of business outcomes at a

specific point during project delivery. DIR has identified the following review

gates that are required for Major IR projects:

Business Justification

Project Planning

Solicitation and Contracting

Project Implementation


Risk The possibility of an act or event occurring that would have an adverse effect

on the state, an organization, or an information system. Risk involves both the

probability of failure and the possible consequences of a failure.

Risk Exposure The level of loss presented to an organization by a risk; the product of the

likelihood the risk will occur and the magnitude of the consequences of its

occurrence.

Risk Factor An element of project development and management used to evaluate a

project. It is an element with the potential to affect the success or failure of the

project. Risk factors can be both internal and external to the institution. Each

risk factor should be addressed and controlled as much as feasible by the

project management team.

Risk Management The process of planning, identifying, qualitatively analyzing, quantitatively

analyzing, responding, and monitoring events which may have a negative or

positive impact on the projects; and process used to identify potential

problems before they occur.

Risk Mitigation Actions taken to reduce the likelihood of a risk occurring as a problem, or to

reduce the impact if it does occur.

Robustness The degree which a system continues to function properly when confronted

with invalid inputs, defects in connected software or hardware components, or

unexpected operation conditions.

Scaling

The activity to adopt, adapt, match, and size the enterprise processes and

deliverables to the work at hand in order to ensure the optimum quality

environment/deliverables with the least time and cost investment.

Scheduling Determining the start and stop time of each activity and task in the project,

taking into account the precedence relations among tasks, the dependencies of

tasks on external events, the required milestone dates, and the resources

available.

Scope

The (estimated) sum/range/extent of the referenced

work/effort/items/operation/etc. that is within boundary.

SDLC Template

An existing model (one of a number available) prescribing a set of processes

to approach development of an IR product in a particular way.

Software Acquisition

Management

SAM The actions taken by management with a supplier or subcontractor in the

process of acquiring software.

Software Configuration

Management

SCM A discipline applying technical and administrative direction and surveillance

to

• identify and document the functional and physical characteristics of a

configuration item,

• control changes to those characteristics,

• record and report change processing and implementation status, and

• verify compliance with specified requirements




Software Quality Assurance SQA A process by which an organization determines the software it produces

and/or acquires the organization‟s technical and administrative performance

requirements, relatively free from discrepancies, and meeting user needs. SQA

must be part of an organization‟s culture to ensure all of its products and

services are of the highest quality.

Stage

One major subset of related activities/tasks that produce a key (intermediate)

deliverable(s) in a sequence of multiple major subsets within a given process

lifecycle.

Stage Gate Decision

A Go/No-go point of determination based on an assessment of the

current/previous stage work and the desired/planned forthcoming stage(s)

proposed.

Stakeholder

An internal or external person, or their collective Subject Matter Expert

(SME), who has a direct interest in the business input, definition, direction,

results, and future impact of business change.

Standard Approved, documented, and available set of criteria used to determine the

adequacy of an action or object.

Steering Committee Provides strategic direction to the overall project

Strategy

An overall plan, method, or series of maneuvers devised to move the business

toward an intended goal.


SME One or more Department (or potentially contracted) staff drawn upon by the

project for their specialized technical/process knowledge. Tasking requests are

typically done, as needed, for the project and therefore the SME is involved

with, rather than committed to, the project outcome.

System Development

Lifecycle

SDLC A generic term for (one of a selected) structured set of processes used to

develop an IR product.

System Requirements

Requirements that have been analyzed and transformed from the functional

business terminology into more technical language needed to proceed with

product design and construction.

Tailor

The art and skill of modifying an existing/generic/robust process, template, or

object to best suit the needs of the business activity it will be used in.

Team Members

A group of Department (and potentially contracted) staff composed of

business and technical team workers, who generally have a full commitment

to a project for its lifecycle and are impacted by its successes or failures.

Technology Architecture

The enterprise‟s interrelated technical infrastructure elements. e.g.: operating

systems, computing platforms, network systems, databases, et cetera.

Testability Refers to the ease with which software components or the integrated product

can be tested to look for defects. Also known as verifiability.

Usability Usability addresses the myriad factors that constitute what users often

describe as user-friendliness or designed for effective and unobtrusive usage.

Validate

Evaluate a product or deliverable against a specific set of requirements.

“Building the right product.”

Validation Determining the correctness of a work product, with respect to the user‟s

needs and requirements (Is this the right product?)

Variance

The amount of difference measured from the original plan or baseline value(s)

and the actual(s).

Vendor

A contracted organization performing an agreed-to service, often with explicit

deliverables, either in whole or as an adjunct to the contracting organization‟s

needs.

Vendor Performance

Review

Defines the procurement in terms of what goods or services were acquired,

what performance measures were applied to the acceptance goods and

services, when the goods or services were required by the project, and who

was responsible for each task.

Vendor Project Manager

The person contracted to: manage specified business and/or technical aspects

of a project, manage vendor and sub-contracted resources, and support overall

project goals through execution of contracted deliverables and services.




Verification Determining whether the products of a given phase of the lifecycle meet the

requirements established during the previous phase (Are we building the

product right?).

Verify

Evaluate the correctness of a product against the processes used to build it.

“Building the right product, right.”


WBS A hierarchical list of tasks, usually sequenced, that represents all of the project

work to be done and issued for estimation and scheduling the work.

Work Product Any tangible item resulting from working on a project function, activity, or

task



11.0 DOCUMENT REVISION HISTORY

The following table shows the history of revisions made to this document since inception.

DATE VER. DESCRIPTION Originator

11/2008 1.00 Version 1.00 Vickie Gustafson

09/2009 2.00 Version 2.00 Amy Santana

11/2009 2.01 Version 2.01 – PMO Initiated Shane McNeil



12.0 REFERENCES

A Guide to the Project Management Body of Knowledge (PMBOK Guide). Third Edition.

Newton Square, PA: Project Management Institute, Inc., 2004.

TTUHSC Information Resources Project Management Policy.

http://www.ttuhsc.edu/it/policy/projectmanagement.aspx

Project Delivery Framework. Ver1.4. Department of Information Resources.


Standard for TTUHSC IR Projects.

http://www.ttuhsc.edu/it/projectmanagement/

Process Guide for TTUHSC IR Projects.


TTUHSC IT Security Policies, 9.5 Information Services Coding Standards, Security, and Audit Controls


Quality Assurance Review Guide for Major Information Resources Projects. Director of Information

Resources.

http://www.dir.state.tx.us/eod/qa/qat/index.htm

http://www.ttuhsc.edu/it/policy/projectmanagement.aspx





http://www.dir.state.tx.us/eod/qa/qat/index.htm



13.0 REVISION HISTORY Identify changes to the Process Guide

Version Date Name Description

2.01 11/2009 Shane McNeil Updated Figure 2.4 to include PMO

2.01 11/2009 Shane McNeil Updated Table 2-2

2.01 11/2009 Shane McNeil Updated Review Gate Approval

Requirements to include PMO

2.01 11/2009 Shane McNeil Updated Figure 5-1 to include PMO