Slide 1 Project Management
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