Slide 1
Chapter 3: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 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• Approximate lines of code per function point in the
chosen language• If you chose C, then 243 function Points times 130 lines
of code = 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
Person Months
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 WORKPLAN
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
Gantt Chart
Slide 38
Gantt Chart
Slide 39
Another Style of Gant Chart
Slide 40
Slide 41
Slide 42
Slide 43
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 44
PERT Estimation
• PERT uses three time stimates: • Optimistic, O• Most likely, M• Pessimistic, P
• Time Estimate = O + 4 * M + P
Slide 45
Pert Chart
• Used to communicate task dependencies• Allows easier visualization of tasks on a critical path
Slide 46
Another kind of PERT Chart
Slide 47
Another Variation
Slide 48
And another
Slide 49
Slide 50
And another variant
Slide 51
PERT vs. Gantt
Slide 52
CONTROLLING AND DIRECTING THE PROJECT
Slide 53
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 54
The Hurricane Model
Project StageTime
Slide 55fig_03_09
Slide 56
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 57
Managing Scope
• Scope creep -- a major cause of development problems• JAD and prototyping• Formal change approval• Charging for changes
Slide 58
Scope Management
• Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.”
Slide 59
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 60
Project Risk
• 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 61
Managing Risk
Slide 62
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 63
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 64
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 65
Risk Assessment - Overview
• Do risk assessment• Take/plan actions to reduce risk• Revise assessment
Slide 66
Classic Mistakes
• Overly optimistic schedule• Failing to monitor schedule• Failing to update schedule• Adding people to a late project• Allowing requirements creep
Slide 67
STAFFING THE PROJECT
Slide 68
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 69
Increasing Complexity with Larger Teams
Slide 70
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 71
Example Reporting Structures
Slide 72
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 73
Motivation
• Use monetary rewards cautiously• Use intrinsic rewards
• Recognition• Achievement• The work itself• Responsibility• Advancement• Chance to learn new skills
Slide 74
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 75
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 76
COORDINATING PROJECT ACTIVITIES
Slide 77
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 78
Standards
• Examples• Formal rules for naming files• Forms indicating goals reached• Programming guidelines
• Can you think of more examples?
Slide 79
Standards
Slide 80
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 81
Summary
• Project Management• Identifying Project Size• Creating And Managing the Workplan• Staffing the Project• Coordinating Project Activities