April 2, 2007

Project Management

Rita M Anderson, PMP Directory of Project Management & Engineering University Technology Services

Page 1

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 2

Why Project Management?

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

April 2, 2007 Page 3

Why Project Management

• PM Began with NASA • Today’s Corporations – Multiple lines of Business – Vertical Specialties – Projects Cut Across All Departments

Project Management April 2, 2007 Page 4

CHAOS 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 5

Why the Improvement?

• Jim Johnson, Chairman

– Improved Project Management – Iterative Development – Emergence of Web Technologies

Source: SD Times, 3/2007

April 2, 2007 Page 6

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

Traditional Waterfall

Concept Requirements Architect

April 2, 2007

Design Code & Debug System Testing Acceptance Testing Deploy

Page 8

Modified Waterfall

Concept Requirements Architect Design Code & Debug System Testing Acceptance Testing Deploy April 2, 2007 Page 9

Iterative 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 10

The 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 11

How UTS Runs Projects

Initiation

IT Project Management Methodology

Planning Execution & Control Closure PROJECT INITIATION PROJECT SCOPING DESIGN PLANNING DESIGN DEVELOPMENT AND TESTING IMPLEMENTATION CLOSURE INITIATION STAGE REVIEW Stage Checklist Project Charter Stage Checklist Project Scope Requirements Spreadsheet Project Plan SCOPING STAGE REVIEW

http://uts.sc.edu/csprojects

Stage Checklist Project Plan Design Plan Requirements Spreadsheet DESIGN PLANNING STAGE REVIEW DESIGN STAGE REVIEW DEV & TEST STAGE REVIEW IMPL. & CLOSURE STAGE REVIEW 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 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

April 2, 2007 Page 12

Project 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 13

Know Your Stakeholders

• Stakeholders

– Persons or organizations, such as customers, sponsors, performing organizations, and the public, that are actively involved in the project, or whose interests may be positively or negatively impacted by execution or completion of the project.

(Reference: PMBOK)

April 2, 2007 Page 14

Requirements

• Understand What Your Customer Expects the Project to Produce.

– Avoid the trap of “Vague Requirements” – Avoid the Rock Hunt Exercise

April 2, 2007 Page 15

Requirements 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 16

Examples 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 17

Generating 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 18

Managing the Triple Constraint

• 3 Key Factors – Scope – Time – Cost

TIME QUALITY

• Determine Which is the Highest Priority and Can Not Change

SCOPE COST April 2, 2007 Page 19

Project Planning

Project Management Knowledge Areas:

• Scope Management • Communications Management • Cost Management • Integration Management • Procurement Management • Time Management (Schedule) • Human Resource Management • Risk Management • Quality Management

(Reference: PMBOK)

April 2, 2007 Page 20

Sample 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 21

Scope 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 22

Avoid 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 23

April 2, 2007

Cost 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

Page 24

Other 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 25

Communications 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 26

April 2, 2007

Time 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!

Page 27

Quality 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 28

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

Defect Removal

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

April 2, 2007 Page 29

Defect 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 – – Repeatable Processes – – Controls and Measures in Place – Up to 25% Reduction Up to 35% Reduction Up to 30% Reduction

Source: David Longstreeet, www.SoftwareMetrics.com

April 2, 2007 Page 30

5,00 4,00 3,00 2,00 1,00

Capability Maturity Model Integration

Capability Maturity Model Integration Optimizing Quantitatively Managed Defined Repeatable [Managed] Initial Initial

*

SEI

April 2, 2007 Page 31

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 32

Development & 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 33

April 2, 2007 User Account Example Page 34

Risk 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 35

Some 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 36

Managing 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 37

Typical Risk Matrix

Risk

Provisioning SW May Run Slow

Likelihood

High

Impact

High Supporting FERPA May Limit IT Staff Access to Data High Inability to Distinguish Faculty and Staff Low Med Low

Response

Avoid – Extensive performance testing during systems test Mitigate – Develop Process for Appropriate IT Staff to Access Data Mitigate – Utilize additional data sources

April 2, 2007 Page 38

Project 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 39

Project 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 40

Portfolio 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 41

Project 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 42

1 7 13 19 25 31 2 8 14 20 26 32 3 9 15 21 27 33 4 10 16 22 28 34 5 11 17 23 29 35 6 12 18 24 30 36 Total Funds = $50,000

April 2, 2007

Scoring

1 7 13 19 25 31 2 8 14 20 26 32 3 9 15 21 27 33 4 10 16 22 28 34 5 11 17 23 29 35 6 12 18 24 30 36 Total Funds = $70,000

Page 43

More Information

• UTS Projects – http://uts.sc.edu/csprojects • E-Mail Project or the UTS Project Office – Contact Rita Anderson • [email protected]

• 803-777-7507

April 2, 2007 Page 44