Slide 1

Project Management

Slide 2

Objectives

• Become familiar with estimation.• Be able to create a project work plan.• Understand why project teams use

timeboxing.• Become familiar with how to staff a project.• Understand how computer-aided software

engineering (CASE), standards, and documentation improve the efficiency of a project.• Understand how to reduce risk on a project.

Slide 3

Project Management Concerns

Slide 4

Project Management

• The discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives

•Cost•Schedule•Performance

Slide 5

PM Activities evolve over Phases

• Inception• Elaboration• Construction• Transition

Slide 6

PM Artifacts in UP

• Software development plan• Business case• Detailed plan for each iteration• Assessment of each iteration• Periodic status assessment• Work schedule• Project measurement database

Slide 7

PM in Inception Phase

1. Conceive new project• Preliminary business case• Identify some risk, begin assessment

2. Evaluate project scope and risk• More detailed development of business case

and risk assessment

Slide 8

IDENTIFYING PROJECT SIZE

Slide 9

Cost Schedule Performance Trade-offs

Cost

Schedule Quality/Performance

Project management involves balancing trade-offs among the three key project parameters

Project management involves balancing trade-offs among the three key project parametersProject cheaper

bettersooner

Slide 10

Estimating Project Timeframes

Slide 11

Function Point Approach

Estimate System Size(function points and lines of code)Estimate System Size

(function points and lines of code)

Estimate Effort Required

(person-months)

Estimate Effort Required

(person-months)

Estimate Time Required(months)

Estimate Time Required(months)

Slide 12

Getting the Right Numbers for Estimation

• Prior projects• Past experience• Industry standards

• Detailed analysis

Slide 13

Estimation Guidelines

• Estimate using at least two techniques• Get estimates from independent sources• Avoid over-optimism; assume difficulties• When you have arrived at an estimate, sleep

on it• Adjust for the people who'll be doing the job

-- they have the highest impact

Slide 14

Estimation Trade-offs

• Size• Function (or use-case) points• Lines of code

• Effort• Person-months• People available

• Time• Months

Slide 15

Calculate Function Points

• List major elements of system• Determine total number of each element• Specify complexity index of each component

(low, med., high)• Total index multiplied by number of

components (TUFP)

Slide 16

Function Point Estimation : Step One

Complexity

Description Low Medium High Total

Inputs __x 3 __x 4 __x 6 ____

Outputs __x 4 __x 5 __x 7 ____

Queries __x 3 __x 4 __x 6 ____

Files __x 7 __x 10 __x 15 ____

Program __x 5 __x 7 __x 10 ____Interfaces

TOTAL UNADJUSTED FUNCTION POINTS

Slide 17

TUPF Example

Slide 18

Adjusted Processing Complexity -- Step 2

Slide 19

Function Points Estimation : Step Four

Adjusted Project Complexity

= .065 + (0.01 * Project Complexity)

Total Adjusted Function Points

=

Adjusted Project Complexity * TUFP

Slide 20

Function Point Estimation

Processing Complexity (PC): __7______ (From Step 2)

Adjusted Processing Complexity (PCA) = 0.65 + (0.001 * __7_ )

Total Adjusted Function Points: _0.72 * _338_ = 243 (TUFP -- From Step 1)

Slide 21

Converting Function Points to Lines of Code

Source: Capers Jones, Software Productivity Research

Language LOC/Function Code Point

CCOBOLJAVAC++Turbo PascalVisual BasicPowerBuilderHTMLPackages (e.g., Access, Excel)

130110 55 50 50 30 15 1510-40

Slide 22

Final Step

• Multiply function points by LOC/FP• Approximate lines of code per function point

in the chosen language• If you chose C, then

243 function points x 130 lines of code/FP = 31,590 total lines of code

Slide 23

Estimating Effort

• Function of size and production rate• COCOMO model

• Converts a lines-of-code estimate into a person-month estimate

• For moderate-size projects multiply thousands of lines of code by 1.4 to get the number of people to assign to the project

Slide 24

COCOMO Estimation Calculation

Effort = 1.4 * thousands-of-(in Person- lines-of-codeMonths)

Example:

If LOC = 2000 Then...Effort = (1.4 * 2000) = 28

PersonMonths

Slide 25

Estimating Schedule Time

• Rule of thumb for estimation

Schedule Time (months)

=

3.0 * person-months1/3

Slide 26

Estimation Guidelines

• Estimate using at least two techniques• Get estimates from independent sources• Avoid over-optimism; assume difficulties• When you have arrived at an estimate, sleep

on it• Adjust for the people who will be doing the

job; they have the highest impact

Slide 27

Reconsider Buy/Build Decision

Slide 28

CREATING AND MANAGING THE WORK PLAN

Slide 29

Developing Work Plans

• A work plan, is a dynamic schedule that records and keeps track of all tasks to be accomplished over the course of the project• Created after a project manager has a

general idea of the project’s size and rough schedule• The work plan is usually the main item in a

project management software application

Slide 30

Developing a WorkPlan

• Identify tasks in the project• Estimate task length• Determine task dependencies• Specify to whom task will be assigned• List deliverables

Slide 31

A Workplan Example

Work Plan Information Example

Name of task Perform economic feasibilityStart date ` Jan 05, 2001Completion date Jan 19, 2001Person assigned Mary Smith, sponsorDeliverable(s) Cost-benefit analysisCompletion status OpenPriority HighResources needed SpreadsheetEstimated time 16 hoursActual time 14.5 hours

Slide 32

Identifying Tasks

• Top-down approach• Identify highest level tasks• Break them into increasingly smaller units

• Methodology• Using standard list of tasks

Slide 33

Work Breakdown Structure

• Specify high level tasks• Break down each step into smaller tasks and

number them in a hierarchical fashion• WBS can be done in two ways

•SDLC phase•Product

Slide 34

Work Plan Deliverables Estimated Assigned

hours To

****

Top Down Task Identification

PhasesPhases with

high level steps

Slide 35

Work Breakdown Structure

Slide 36

WBS Problems

• They tend to be specific to the design of the information system being developed• Too many levels of detail too early on in the

SDLC for large projects or too few for small projects.• Since they are project specific, they are very

difficult to compare across projects.

Slide 37

Applying Iteration to Planning

• Develop a high level long range plan, with allocation of time and resources to phases• Develop a more detailed plan for the earliest

phase(s), including allocation of work, time and resources to interations• Develop a still more detailed plan for the

current iteration, including work breakdown into tasks• Revise the plan iteratively, at least weekly

Slide 38

Gantt Charts

• Good for identifying time and order dependencies• Show slack (ahead) and over-runs (past)• Good for identifying critical paths• Good for small projects, and overview of

large ones• Attempt to combine work breakdown with

activities, deliverables not shown• Do not show task difficulty or cost• Do not scale well for details of large projects

Slide 39

Gantt Chart

Slide 40

Gantt Chart

Slide 41

Another Style of Gant Chart

Slide 42

Slide 43

Slide 44

Slide 45

PERT

• Project Evaluation and Review Technique (PERT)• US Navy, 1957• Systematic method of estimating project length,

and monitoring progress• Uses systematic serialization algorithm based on

• Dependences• Resource availability

• Adds administrative oversight to critical paths• Critical path = sequence of tasks such that if any

case on the CP is delayed so is the whole project

Slide 46

PERT Estimation

• PERT uses three time estimates: •Optimistic, O•Most likely, M•Pessimistic, P

• Time Estimate = (O + 4 * M + P) / 6

Slide 47

Pert Chart

• Used to communicate task dependencies• Allows easier visualization of tasks on a

critical path

Slide 48

Slide 49

Slide 50

Slide 51

Slide 52

Slide 53

PERT vs. Gantt

Slide 54

CONTROLLING AND DIRECTING THE PROJECT

Slide 55

Typical Margins of Error for Well-done Estimates

Phase Deliverable Cost (%) time (%)

Planning System Request 400 60

Project Plan 100 25

Analysis System Proposal 50 15

Design System Specification 25 10

Source: Boehm et al. (1995)

Slide 56

The Hurricane Model

Project StageTime

Slide 57fig_03_09

Slide 58

Evolutionary WBS

• Organize in a standard manner across all projects• Create in an incremental and iterative

manner•First evolutionary WBS done with initial aspects

of the project •Later on more details are added to the WBS.

• Comparable to earlier projects based on cost and schedule estimation

Slide 59

Managing Scope

•Scope creep -- a major cause of development problems

•JAD and prototyping•Formal change approval•Charging for changes

Slide 60

Scope Management

• Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.”

Slide 61

Timeboxing Steps

1. Set the date for system delivery2. Prioritize the functionality that needs to be

included in the system3. Build the core of the system (the

functionality ranked as most important)4. Postpone functionality that cannot be

provided within the time frame5. Deliver the system with core functionality6. Repeat steps 3 through 5 to add

refinements and enhancements

Slide 62

Project Risk Analysis

• A risk comprises three elements:•an undesirable event,•an estimate of the severity of the consequences of the event

•a likelihood that the event will occur

• The amount of risk a project is exposed to is a good measure of the viability of the project

Slide 63

Managing Risk

Slide 64

Classes of Risk

• Direct risk that the manager can control to some extent• Indirect risk that the manager cannot

influence

In managing a project the aim is to control risk so we try to avoid indirect risk where possible.

Slide 65

Risk Control

Three strategies:• Risk avoidance - reorganize the project so

you are not exposed to the risk• Risk transfer -find other stakeholders to

share the risk• Risk acceptance - decide to live with the risk

and to take the occurrence of the risk as a possible contingency to be taken account of in the planning process

Slide 66

Risk Acceptance

Risk mitigation• Try to reduce the likelihood or the impact of

a risk.• e.g. if we decide to choose a particular supplier

for a component we can identify an alternative supplier with a similar product that could be used if the original supplier fails to deliver.

Contingency planning• Construct “what if” plans on the basis of the

risk occurring

Slide 67

Risk Assessment - Overview

• Do risk assessment• Take/plan actions to reduce risk• Revise assessment

Slide 68

Classic Mistakes

• Overly optimistic schedule• Failing to monitor schedule• Failing to update schedule• Adding people to a late project• Allowing requirements creep

Slide 69

STAFFING THE PROJECT

Slide 70

Staffing Attributes

• Staffing levels will change over a project’s lifetime• Adding staff may add more overhead than

additional labor• Using teams of 8-10 reporting in a

hierarchical structure can reduce complexity

Slide 71

Increasing Complexity with Larger Teams

Slide 72

Staffing the Project

• Determine average number of people needed• Divide total person-months of effort by the

optimal schedule• Adding more people will not reduce schedule

• Create a staffing plan• Roles required for the project• Reporting structure

Slide 73

Example Reporting Structures

Slide 74

Key Definitions

• The staffing plan describes the kinds of people working on the project• The project charter describes the project’s objectives and rules• A functional lead manages a group of analysts• A technical lead oversees progress of programmers and technical staff members

Slide 75

Motivation

•Use monetary rewards cautiously•Use intrinsic rewards

•Recognition•Achievement•The work itself•Responsibility•Advancement•Chance to learn new skills

Slide 76

Motivational Don’ts

• Assign unrealistic deadlines• Ignore good efforts• Create a low-quality product• Give everyone on the project a raise• Make an important decision without the

team’s input• Maintain poor working conditions

Slide 77

Conflict Avoidance Strategies

• Clearly define roles and project plans• Make sure the team understands how the

project is important to the organization• Develop detailed operating procedures and

communicate these to the team members• Develop a project charter• Develop schedule commitments ahead of time• Forecast other priorities and their possible

impact on project

Slide 78

COORDINATING PROJECT ACTIVITIES

Slide 79

CASE Tools

• Computer-Aided Software Engineering (CASE) tools automate some or all of the development process• Not a silver bullet, but advantages include:

– Reduced maintenance costs– Improve software quality– Enforce discipline– Some project teams even use CASE to assess the

magnitude of changes to the project

Slide 80

Standards

• Examples• Formal rules for naming files• Forms indicating goals reached• Programming guidelines

• Can you think of more examples?

Slide 81

Standards

Slide 82

Documentation

• Good documentation happens up front–Documentation that occurs only at the tail end of

a project/phase is not very useful

• Project binder(s) are best practices containing– All internal communications (e.g. minutes from

status meetings)–Written standards– Letters to and from the business users–Deliverables from each task

Slide 83

Summary

• Project Management• Identifying Project Size• Creating And Managing the Workplan• Staffing the Project• Coordinating Project Activities