April 2, 2007 Page 1

Project ManagementProject Management

Rita M Anderson, PMP

Directory of Project Management & Engineering

University Technology Services

April 2, 2007 Page 2

What Is Project Management?What Is Project Management?

• Project– Temporary endeavor undertaken to create a unique

product or service, or result. (PMBOK)

• Project Management– Application of knowledge, skills, tools, and

techniques to project activities to meet project requirements. (PMBOK)

April 2, 2007 Page 3

Why Project Management?Why Project Management?

• Today’s Small Business– Single product or service focused– Sales– Marketing– Engineering– Manufacturing– Delivery– Support

April 2, 2007 Page 4

Why Project ManagementWhy Project Management

• PM Began with NASA• Today’s Corporations

– Multiple lines of Business– Vertical Specialties– Projects Cut Across

All Departments

En

gin

eer

ing

Ma

nu

fact

uri

ng

Ma

rke

tin

g

Sa

les

Su

pp

ort

Ac

co

un

tin

g

IT, H

R, L

earn

ing

Project Management

April 2, 2007 Page 5

CHAOS Report – Standish GroupCHAOS Report – Standish Group

CHAOS Report - 1994

• Study of IT Projects• 16.2% of Projects

Classified as Successful

• 31% of IT Projects Fail

• $140B of $250B in total US Projects $’s Wasted

CHAOS Report 2004

• 34% Classified as Successful (Up to 35% in Latest Report)

• 15% Failure Rate

• Only $55B of $255B Wasted

April 2, 2007 Page 6

Why the Improvement?Why the Improvement?

• Jim Johnson, Chairman– Improved Project Management

– Iterative Development

– Emergence of Web Technologies

Source: SD Times, 3/2007

April 2, 2007 Page 7

Software Development ModelsSoftware Development Models

• “Just Do It” Model – Code and Fix and Fix and Fix…..

• Waterfall• Modified Waterfall• Iterative or Agile• Extreme Programming (Rapid Prototyping)

April 2, 2007 Page 8

Traditional WaterfallTraditional Waterfall

Concept

Requirements

Architect

Design

Code &Debug

SystemTesting

AcceptanceTesting

Deploy

April 2, 2007 Page 9

Modified WaterfallModified Waterfall

Concept

Requirements

Architect

Design

Code & Debug

System Testing

Acceptance Testing

Deploy

April 2, 2007 Page 10

Iterative or Agile MethodsIterative or Agile Methods

• More Flexibility than Traditional Waterfall Methods• Break the Project Down into Small Phases• Execute the Waterfall Process on an Iterative Basis

– Less Documentation, More Communication– More User Involvement, Especially in Testing– Ideal for Smaller Development Teams

• Extreme Programming Forces Much More Overlap

April 2, 2007 Page 11

The Project LifecycleThe Project Lifecycle

• Project Management Process Groups– Initiation

• Defines and authorizes the project or phase of the project– Planning

• Refines the objectives and plans the course of action– Executing

• Integrates people and other resources to carry out project– Monitoring & Controlling

• Regularly measures progress; takes corrective action when needed

– Closure• Formalizes acceptance of the final product, service, or result

(Reference: PMBOK)

April 2, 2007 Page 12

How UTS Runs ProjectsHow UTS Runs Projects

PROJECT INITIATION

INITIATION STAGE REVIEW

PROJECT SCOPING

DESIGN PLANNING

SCOPING STAGE

REVIEW

DEVELOPMENT AND TESTING

DESIGN PLANNING

STAGE REVIEW

DESIGN IMPLEMENTATION CLOSURE

DESIGN STAGE REVIEW

DEV & TEST STAGE REVIEW

IMPL. & CLOSURE STAGE

REVIEW

Stage Checklist

Project Charter

Stage Checklist

Project Scope

Requirements Spreadsheet

Project Plan

Project Plan

Validation Results

Post-production problem log

Procedures in Doc. Repository

Transition to Operations and

Support checklist and minutes

Stage Checklist (Implementation

and Closure)

Project Lessons Learned

Project Report

Stage Checklist

Project Plan

Design Plan

Requirements Spreadsheet

Stage Checklist

Project Plan

Design Specification

Design Review Checklist and

Minutes

Requirements Spreadsheet

Stage Checklist

Project Plan

Controlled Components

Project Documentation

Test Plan

Pre-Production Problem Log

Implementation Plan

Quality Review/Production Readiness

Review Minutes

Requirements Spreadsheet

IT Project Management Methodology

http://uts.sc.edu/csprojects

Initiation Planning Execution & Control Closure

April 2, 2007 Page 13

Project Initiation - ConceptProject Initiation - Concept

• Sponsor– The person or group that provides the resources for the project.– The high level executive who is “championing” the project.– Projects that are not well sponsored typically fare poorly.

• Charter– Formally authorizes the existence of a project and provides the

project manager with the authority to apply organizational resources to project activities.

– Defines objectives for the project and a high level view of customer expectations.

• Establish the Project Team– The group of subject matter experts that will be working together on

the project.(Reference: PMBOK)

April 2, 2007 Page 14

Know Your StakeholdersKnow Your Stakeholders

• Stakeholders– Persons or organizations, such as customers,

sponsors, performing organizations, and the public, that are actively involved in the project, orwhose interests may be positively or negatively impacted by execution or completion of the project.

(Reference: PMBOK)

April 2, 2007 Page 15

RequirementsRequirements

• Understand What Your Customer Expects the Project to Produce.– Avoid the trap of “Vague Requirements”– Avoid the Rock

Hunt Exercise

April 2, 2007 Page 16

Requirements ExerciseRequirements Exercise

• Develop a Website for Outlook Training• Allow Faculty & Staff to

– Review the Available Classes– Sign Up for the Class of Their Choice

• Link to the University E-mail Information Center

April 2, 2007 Page 17

Examples of Bad RequirementsExamples of Bad Requirements

• The application must be user friendly.• The application must perform well.• The application must be highly available.• The application must integrate with the new

Payroll system.

• Requirements Planning Takes Time– Specific, Measurable, Testable– Investing Time Up Front Saves Time Later

April 2, 2007 Page 18

Generating Good RequirementsGenerating Good Requirements

• Brainstorming, Delphi Method• Use Cases• Prototypes• Review with a group of Stakeholders

• What Happens when Stakeholders Don’t Agree?– Project Manager must facilitate the discussion and compromise.– Project Manager should use the Project Sponsor to

“break the tie.”

• IT Managers cited poor requirements as one of the main reasons projects fail [Standish Group, 2000 ]

April 2, 2007 Page 19

Managing the Triple ConstraintManaging the Triple Constraint

• 3 Key Factors– Scope– Time– Cost

• Determine Whichis the Highest Priority and Can Not Change

TIME

COSTSCOPE

QUALITY

April 2, 2007 Page 20

Project PlanningProject Planning

• Scope Management

• Cost Management

• Procurement Management

• Time Management (Schedule)

• Quality Management

• Communications Management

• Integration Management

• Human Resource Management

• Risk Management

Project Management Knowledge Areas:

(Reference: PMBOK)

April 2, 2007 Page 21

Sample ProjectSample Project

• Objective: Develop a solution to generate network user accounts for USC students and faculty/staff.

• Key Requirements– Source of record for student info is the Student Database– Source of record for employee is in the HR Database– Create account when student is admitted– Eliminate student account 1 Yr after

last class taken– Comply with FERPA regulations– Provide employee account from hire through

termination

April 2, 2007 Page 22

Scope ManagementScope Management

• Refine the Objectives– Specify what will be included– Specify what will not be included

• List Assumptions• List Constraints• Review with Project Team & Stakeholders

• Communicate, Communicate, Communicate

April 2, 2007 Page 23

Avoid Scope CreepAvoid Scope Creep

• What’s Scope Creep?– Unauthorized Changes in Requirements– Additional Features that Just Appear

• Example:– Provide accounts to retirees– Provide accounts to alumni– Provide accounts to faculty members from other

schools who are collaborating with USC faculty on research

April 2, 2007 Page 24

Cost ManagementCost Management

• Keep Costs Within Budget– Know Your Budget

– Track Costs Regularly

• Factors to Consider– Cost of Labor – Time is Money!

– Cost of Contractors Vs. Employees– Time Value of $’s for Multi-Year Projects

April 2, 2007 Page 25

Other Knowledge AreasOther Knowledge Areas

• Procurement Management– Decide How to Proceed– Make Vs. Buy Decision

• Human Resource Management– Invest Time in Making the

Team a Team.

• Integration Management– Know the Environment.– Understand the Constraints and Assumptions.

April 2, 2007 Page 26

Communications ManagementCommunications Management

• 90% of Project Management is Communications!• Determine Up Front

– Who to Include– What to Communicate– When (How Often to Provide Updates)– How: Meetings, E-mail, Web Posts, etc.

• Include Some Form of Regular Communication to All Stakeholders!

April 2, 2007 Page 27

Time ManagementTime Management

• Scheduling– Determine the Work Breakdown Structure

– Work Units – Typically No More than 80 Hrs of Work Each

– Determine the Optimal Sequencing – Determine the Dependencies

– Manage the Critical Path!

April 2, 2007 Page 28

Quality ManagementQuality Management

• Quality Planning– Identifying which quality standards are relevant and how to

satisfy them.

• Quality Assurance– Evaluating overall performance to ensure that standards are

met.

• Quality Control– Monitoring specific results to determine if they comply with

standards and addressing how to resolve issues if needed.

(Reference: PMBOK)

April 2, 2007 Page 29

Defect RemovalDefect Removal

“The longer a defect remains undetected, the more expensive it becomes to correct.”

Source:Steve McConnell, http://stevemcconnell.com

April 2, 2007 Page 30

Defect PreventionDefect Prevention

“An unstable organization can not consistently produce high quality products.”

• Focus on Defect Prevention– Clearly Defined Roles, Responsibilities – Up to 15%

Reduction– Formalized Procedures – Up to 25%

Reduction– Repeatable Processes – Up to 35%

Reduction– Controls and Measures in Place – Up to 30% Reduction

Source: David Longstreeet, www.SoftwareMetrics.com

April 2, 2007 Page 31

Capability Maturity Model IntegrationCapability Maturity Model Integration

*SEI

Initial

Initial

Repeatable [Managed]

Defined

Quantitatively ManagedOptimizing

CMMI was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University

April 2, 2007 Page 32

Architect & Design Architect & Design

• Different Solutions Require Different Approaches– Use Cases– Rapid Prototype– Pseudo Code– Flowcharts

• Design Verification– Design and Code Reviews– Validate that Each Requirement Can be Tested– Define the Test Plan During Design

April 2, 2007 Page 33

Development & TestDevelopment & Test

• Detailed, Labor Intensive Tasks• Best Practice: Implement Peer Review of Code• Avoid “Gold Plating”

– Code to the Requirements

• Stages of Testing– Unit Test– Systems Testing– Acceptance Testing

April 2, 2007 Page 34

User Account ExampleUser Account Example

April 2, 2007 Page 35

Risk ManagementRisk Management

• Key Area for Project Manager• Risk Identification

– Lessons Learned from Previous Projects– Brainstorming with the Team– Ask Subject Matter Experts

• Risk Quantification• Risk Response Development• Risk Response Control• Risk Should Reduce as Project Progresses

(Reference: PMBOK)

April 2, 2007 Page 36

Some Classic MistakesSome Classic Mistakes

• People-Related– Adding people late to a project– Unrealistic Expectations

• Process-Related Mistakes– Insufficient Planning– Overly Optimistic Schedules

• Product-Related Mistakes– Feature Creep

Source: S. McConnell, Software Project Survival Guide

April 2, 2007 Page 37

Managing IssuesManaging Issues

• Managing the Plan is an on-going task• Track All Issues

– Assign some form of numbering scheme– Description of Issue– Priority– Owner– Date Identified– Date to be Resolved– Status

April 2, 2007 Page 38

Typical Risk MatrixTypical Risk Matrix

Risk Likelihood Impact Response

Provisioning SW May Run Slow

High High Avoid – Extensive performance testing during systems test

Supporting FERPA May Limit IT Staff Access to Data

High Med Mitigate – Develop Process for Appropriate IT Staff to Access Data

Inability to Distinguish Faculty and Staff

Low Low Mitigate – Utilize additional data sources

April 2, 2007 Page 39

Project Execution & ControlProject Execution & Control

• Status Updates Frequently• Establish Metrics Upfront and Track Metrics• Adjust When Issues Occur

– Deal with Problems BEFORE They Occur– Project Schedule Slips BEFORE They are realized– Exercise Contingency Planning

April 2, 2007 Page 40

Project ClosureProject Closure

• Ensure that Stakeholders “Accept” the Product, Service, or Result

• Archive All Project Documentation• Transition the On-going Product Support to

Operations• Hold Lessons Learned• Celebrate the Team’s Success

April 2, 2007 Page 41

Portfolio ManagementPortfolio Management

• Most Companies Have Multiple High Priority Projects In Progress Concurrently

• Portfolio Management -> Balancing Priorities• PMO Can Assist

– Ensure that Projects Move through the Pipeline Efficiently

– Assist in Managing Resources– Ensure Consistency in Practice & Delivery

April 2, 2007 Page 42

Project Management SquaresProject Management Squares

• Object of the Game: Obtain Funding for your Project• Process: Project Managers take turns claiming squares, similar to

tic-tac-toe• Funding is secured as follows:

– Each square that is in a row or column of 3 or more counts as $10,000 per square

– A square’s value can only be counted once.

• Minimal Funding = $30,000• Expected Funding = $40,000 - $70,000• Well Funded = $80,000+

April 2, 2007 Page 43

ScoringScoring

1 2 3 4 5 6 1 2 3 4 5 6

7 8 9 10 11 12 7 8 9 10 11 12

13 14 15 16 17 18 13 14 15 16 17 18

19 20 21 22 23 24 19 20 21 22 23 24

25 26 27 28 29 30 25 26 27 28 29 30

31 32 33 34 35 36 31 32 33 34 35 36

Total Funds = $50,000 Total Funds = $70,000

April 2, 2007 Page 44

More InformationMore Information

• UTS Projects– http://uts.sc.edu/csprojects

• E-Mail Project or the UTS Project Office– Contact Rita Anderson

• ritaa@sc.edu• 803-777-7507