Software Project Management

WBS, Estimation & Scheduling

1

Today & Next Week

Work Breakdown Structures (WBS) Estimation Network Fundamentals PERT & CPM Techniques Gantt Charts

Homework
Distribution of project by type
In-house, contract/for-hire, startup

Distribution of project by technology

Web, Windows, No platform

Distribution by industry
Fin. Svcs., Law, Retail

A reminder why no two projects are same

3

Homework
Most important elements
Why, who, what, what not A little bit of when

Make sure its clear Some more re-purposed than others

Occasionally read more like biz plans

Make the stakeholder relationships clear

You, sponsor, user, etc.
4

Homework
If for real youd want additional assumptions and scope constraint The justification or cost-benefit analysis materializes in some of the cases Dont shortchange downstream activities
Integration, testing, rollout, etc.

Homework
Risks
Business risks vs. Project risks
Ex: lack of market adoption vs. inexperienced team

Formalities
Spell check. Make sure your name is on first page or footer.

Functionality
Forgotten items: user registration, help, security

Homework
Good out of scope items
Internationalization Search system

Project Considerations
Is infrastructure setup part of your project? Assumptions
What are you counting on? These can be critical to identify Resources expected: equip/people, approvals Availability of partners, connections Outline key limits:
System load: expect an maximum of 100 users
8

Estimation
Predictions are hard, especially about the future, Yogi Berra 2 Types: Lucky or Lousy?

Planning, Estimating, Scheduling

Whats the difference? Plan: Identify activities. No specific start and end dates. Estimating: Determining the size & duration of activities. Schedule: Adds specific start and end dates, relationships, and resources.

10

Project Planning: A 12 Step Program

1) 2) 3) 4) 5) 6) Set goal and scope Select lifecycle Set org./team form Start team selection Determine risks Create WBS 7) Identify tasks 8) Estimate size 9) Estimate effort 10) Identify task dependencies 11) Assign resources 12) Schedule work

11

How To Schedule
1. Identify what needs to be done
Work Breakdown Structure (WBS)

2. Identify how much (the size)

Size estimation techniques

3. Identify the dependency between tasks

Dependency graph, network diagram

4. Estimate total duration of the work to be done

The actual schedule

12

WBS & Estimation

How did you feel when I asked
How long will your project take?

Not an easy answer to give right? At least not if I were are real customer on a real project How can you manage that issue?

13

Partitioning Your Project

You need to decompose your project into manageable chunks ALL projects need this step Divide & Conquer Two main causes of project failure
Forgetting something critical Ballpark estimates become targets

How does partitioning help this?

14

Project Elements
A Project: functions, activities, tasks

15

Work Breakdown Structure: WBS

Hierarchical list of projects work activities 2 Formats
Outline (indented format) Graphical Tree (Organizational Chart)

Uses a decimal numbering system

Ex: 3.1.5 0 is typically top level

Includes
Development, Mgmt., and project support tasks

Shows is contained in relationships Does not show dependencies or durations

16

WBS
Contract WBS (CWBS)
First 2 or 3 levels High-level tracking

Project WBS (PWBS)

Defined by PM and team members Tasks tied to deliverables Lowest level tracking

17

A Full WBS Structure

Up to six levels (3-6 usually) such as

Upper 3 can be used by customer for reporting (if part of RFP/RFQ) Different level can be applied to different uses
Ex: Level 1: authorizations; 2: budgets; 3: schedules
18

WBS Chart Example

19

WBS Outline Example

0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production
20

WBS Types
Process WBS
a.k.a Activity-oriented Ex: Requirements, Analysis, Design, Testing Typically used by PM

Product WBS
a.k.a. Entity-oriented Ex: Financial engine, Interface system, DB Typically used by engineering manager

Hybrid WBS: both above

This is not unusual Ex: Lifecycle phases at high level with component or featurespecifics within phases Rationale: processes produce products
21

Product WBS

22

Process WBS

23

Outline WBS w/Gantt

24

WBS by PMI Process Groups

25

WBS Types
Less frequently used alternatives
Organizational WBS
Research, Product Design, Engineering, Operations Can be useful for highly cross-functional projects

Geographical WBS
Can be useful with distributed teams NYC team, San Jose team, Off-shore team

26

27

Work Packages
Generic term for discrete tasks with definable end results Typically the leaves on the tree The one-to-two rule
Often at: 1 or 2 persons for 1 or 2 weeks

Basis for monitoring and reporting progress

Can be tied to budget items (charge numbers) Resources (personnel) assigned

Ideally shorter rather than longer

Longer makes in-progress estimates needed These are more subjective than done 2-3 weeks maximum for software projects 1 day minimum (occasionally a half day) Not so small as to micro-manage
28

WBS
List of Activities, not Things List of items can come from many sources
SOW, Proposal, brainstorming, stakeholders, team

Describe activities using bullet language

Meaningful but terse labels

All WBS paths do not have to go to the same level Do not plan more detail than you can manage

29

WBS & Methodology

PM must map activities to chosen lifecycle Each lifecycle has different sets of activities Integral process activities occur for all
Planning, configuration, testing

Operations and maintenance phases are not normally in plan (considered post-project) Some models are straightened for WBS
Spiral and other iterative models Linear sequence several times

Deliverables of tasks vary by methodology

30

WBS Techniques
Top-Down Bottom-Up Analogy Rolling Wave
1st pass: go 1-3 levels deep Gather more requirements or data Add more detail later

Post-its on a wall
31

WBS Techniques
Top-down
Start at highest level Systematically develop increasing level of detail Best if
The problem is well understood Technology and methodology are not new This is similar to an earlier project or problem

But is also applied in majority of situations

32

WBS Techniques
Bottom-up
Start at lowest level tasks Aggregate into summaries and higher levels Cons
Time consuming Needs more requirements complete

Pros
Detailed
33

WBS Techniques
Analogy
Base WBS upon that of a similar project Use a template Analogy also can be estimation basis Pros
Based on past actual experience

Cons
Needs comparable project
34

WBS Techniques
Brainstorming
Generate all activities you can think of that need to be done Group them into categories

Both Top-down and Brainstorming can be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!)
35

WBS Basis of Many Things

Network scheduling Costing Risk analysis Organizational structure Control Measurement

36

WBS Guidelines Part 1

Should be easy to understand Some companies have corporate standards for these schemes Some top-level items, like Project Mgmt. are in WBS for each project
Others vary by project

What often hurts most is whats missing Break down until you can generate accurate time & cost estimates Ensure each element corresponds to a deliverable
37

WBS Guidelines Part 2

How detailed should it be?
Not as detailed as the final MS-Project plan Each level should have no more than 7 items It can evolve over time

What tool should you use?

Excel, Word, Project Org chart diagramming tool (Visio, etc) Specialized commercial apps

Re-use a template if you have one

38

Estimations
Very difficult to do, but needed often Created, used or refined during
Strategic planning Feasibility study and/or SOW Proposals Vendor and sub-contractor evaluation Project planning (iteratively) Estimate the size of the product Estimate the effort (man-months) Estimate the schedule NOTE: Not all of these steps are always explicitly performed
39

Basic process
1) 2) 3)

Estimations
Remember, an exact estimate is an oxymoron Estimate how long will it take you to get home from class tonight
On what basis did you do that? Experience right? Likely as an average probability For most software projects there is no such average

Most software estimations are off by 25-100%

40

Estimation
Target vs. Committed Dates
Target: Proposed by business or marketing Do not commit to this too soon! Committed: Team agrees to this After youve developed a schedule

41

Cone of Uncertainty

42

Estimation
Size:
Small projects (10-99 FPs), variance of 7% from post-requirements estimates Medium (100-999 FPs), 22% variance Large (1000-9999 FPs) 38% variance Very large (> 10K FPs) 51% variance

43

Estimation Methodologies
Top-down Bottom-up Analogy Expert Judgment Priced to Win Parametric or Algorithmic Method
Using formulas and equations

44

Top-down Estimation
Based on overall characteristics of project
Some of the others can be types of top-down (Analogy, Expert Judgment, and Algorithmic methods)

Advantages
Easy to calculate Effective early on (like initial cost estimates)

Disadvantages
Some models are questionable or may not fit Less accurate because it doesnt look at details
45

Bottom-up Estimation
Create WBS Add from the bottom-up Advantages
Works well if activities well understood

Disadvantages
Specific activities not always known More time consuming

46

Expert Judgment
Use somebody who has recent experience on a similar project You get a guesstimate Accuracy depends on their real expertise Comparable application(s) must be accurately chosen
Systematic

Can use a weighted-average of opinions

47

Estimation by Analogy
Use past project
Must be sufficiently similar (technology, type, organization) Find comparable attributes (ex: # of inputs/outputs) Can create a function

Advantages
Based on actual historical data

Disadvantages
Difficulty matching project types Prior data may have been mis-measured How to measure differences no two exactly same
48

Priced to Win
Just follow other estimates Save on doing full estimate Needs information on other estimates (or prices) Purchaser must closely watch trade-offs Priced to lose?

49

Algorithmic Measures
Lines of Code (LOC) Function points Feature points or object points Other possible
Number of bubbles on a DFD Number of of ERD entities Number of processes on a structure chart

LOC and function points most common

(of the algorithmic approaches)

Majority of projects use none of the above

50

Code-based Estimates
LOC Advantages
Commonly understood metric Permits specific comparison Actuals easily measured

LOC Disadvantages
Difficult to estimate early in cycle Counts vary by language Many costs not considered (ex: requirements) Programmers may be rewarded based on this
Can use: # defects/# LOC

Code generators produce excess code

51

LOC Estimate Issues

How do you know how many in advance? What about different languages? What about programmer style? Stat: avg. programmer productivity: 3,000 LOC/yr Most algorithmic approaches are more effective after requirements (or have to be after)

52

Function Points
Software size s/b measured by number & complexity of functions it performs More methodical than LOC counts House analogy
Houses Square Feet ~= Software LOC # Bedrooms & Baths ~= Function points Former is size only, latter is size & function

Six basic steps

53

Function Point Process

1. Count # of biz functions per category
Categories: outputs, inputs, db inquiries, files or data structures, and interfaces

2. Establish Complexity Factor for each and apply

Simple, Average, Complex Set a weighting multiplier for each (0->15) This results in the unadjusted function-point total

3. Compute an influence multiplier and apply

It ranges from 0.65 to 1.35; is based on 14 factors

4. Results in function point total

This can be used in comparative estimates
54

Wideband Delphi
Group consensus approach Rand corp. used orig. Delphi approach to predict future technologies Present experts with a problem and response form Conduct group discussion, collect anonymous opinions, then feedback Conduct another discussion & iterate until consensus Advantages Easy, inexpensive, utilizes expertise of several people Does not require historical data Disadvantages Difficult to repeat May fail to reach consensus, reach wrong one, or all may have same bias

55

Parametric Method Issues

Remember: most projects youll run into dont use these Which is normal, so dont be surprised
Or come-in to new job and say Hey, lets use COCOMO

These are more effective on large projects

Where a past historical base exists

Primary issue for most projects are

Lack of similar projects
Thus lack of comparable data

Catch-22: how to get started

56

Code Reuse & Estimation

Does not come for free Code types: New, Modified, Reused If code is more than 50% modified, its new Reuse factors have wide range
Reused code takes 30% effort of new Modified is 60% of new

Integration effort with reused code almost as expensive as with new code
57

Effort Estimation
Now that you know the size, determine the effort needed to build it Various models: empirical, mathematical, subjective Expressed in units of duration
Man-months (or staff-months now)

58

Effort Estimation
McConnell shows schedule tables for conversion of size to effort As with parametric size estimation, these techniques perform better with historical data Again, not seen in average projects Often the size and effort estimation steps are combined (not that this is recommended, but is what often is done) Commitment-Based Scheduling is what is often done
Ask developer to commit to an estimate (his or her own)

59

COCOMO
COnstructive COst MOdel Allows for the type of application, size, and Cost Drivers Outputs in Person Months Cost drivers using High/Med/Low & include
Motivation Ability of team Application experience

Biggest weakness?
Requires input of a product size estimate in LOC
60

Estimation Issues
Quality estimations needed early but information is limited Precise estimation data available at end but not needed
Or is it? What about the next project?

Best estimates are based on past experience Politics of estimation:

You may anticipate a cut by upper management

For many software projects there is little or none

Technologies change Historical data unavailable Wide variance in project experiences/types Subjective nature of software estimation
61

Over and Under Estimation

Over estimation issues
The project will not be funded
Conservative estimates guaranteeing 100% success may mean funding probability of zero.

Parkinsons Law: Work expands to take the time allowed Danger of feature and scope creep Be aware of double-padding: team member + manager

Under estimation issues

Quality issues (short changing key phases like testing) Inability to meet deadlines Morale and other team motivation issues
62

Estimation Guidelines
Estimate iteratively!
Process of gradual refinement Make your best estimates at each planning stage Refine estimates and adjust plans iteratively Plans and decisions can be refined in response Balance: too many revisions vs. too few

63

Know Your Deadlines

Are they Real Deadlines?
Tied to an external event Have to be met for project to be a success Ex: end of financial year, contractual deadline, Y2K

Or Artificial Deadlines?
Set by arbitrary authority May have some flexibility (if pushed)

64

Estimation Presentation
How you present the estimation can have huge impact Techniques
Plus-or-minus qualifiers
6 months +/-1 month

Ranges
6-8 months

Risk Quantification
+/- with added information +1 month of new tools not working as expected -2 weeks for less delay in hiring new developers

Cases
Best / Planned / Current / Worst cases

Coarse Dates
Q3 02

Confidence Factors
April 1 10% probability, July 1 50%, etc.
65

Other Estimation Factors

Account for resource experience or skill
Up to a point Often needed more on the low end, such as for a new or junior person

Allow for non-project time & common tasks

Meetings, phone calls, web surfing, sick days

There are commercial estimation tools available

They typically require configuration based on past data

66

Other Estimation Notes

Remember: manage expectations Parkinsons Law
Work expands to fill the time available

The Student Syndrome

Procrastination until the last minute (cram)

67

Mythical Man-Month Revisited

Back to notes from class 2

68

Financial Analysis of Projects

Financial considerations are often an important consideration in selecting projects Three primary methods for determining the projected financial value of projects:
Net present value (NPV) analysis Return on investment (ROI) Payback analysis

69

Net Present Value Analysis: NPV

NPV: a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time Projects with a positive NPV should be considered if financial value is a key criterion The higher the NPV, the better
70

NPV Example

71

Return on Investment (ROI)

ROI: income divided by investment
ROI = (total discounted benefits - total discounted costs) / discounted costs

The higher the ROI, the better Many organizations have a required rate of return or minimum acceptable rate of return on investment for projects
72

Payback Analysis
Another important financial consideration is payback analysis The payback period is the amount of time it will take to recoup, in the form of net cash inflows, the net dollars invested in a project Payback occurs when the cumulative discounted benefits and costs are greater than zero Many organizations want IT projects to have a fairly short payback period
73

NPV, ROI, Payback Period: Ex 1

74

NPV, ROI, Payback Period: Ex 2

75

Weighted Scoring Model

A weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria
First identify criteria important to the project selection process Then assign weights (percentages) to each criterion so they add up to 100% Then assign scores to each criterion for each project Multiply scores * weights = total weighted scores

The higher the weighted score, the better

76

Sample Weighted Scoring Model

77

Homework
McConnell: 9, Scheduling Schwalbe: 5, Project Time Management URLs: See class web site for URLs on PERT/CPM Create a WBS for your project

78

WBS Homework
The fine print
You only need to do this down to level 2 (or 3 if your so inclined or that helps clarify some higher-level activities). Going to level 2 means means start with level 0 (a single node the name of your project), level 1, the highest level breakdown (4-7 nodes), and one level below that. You can go deeper at your discretion. As we covered in class, you can use either a process, product or hybrid approach. For most of your projects I suspect the process approach would work best at the highest level. You can use either Excel, Word, or Project. Follow the standard hierarchical numbering scheme for WBS structures. Please think this through. Youre the PM now.
79

Questions?

80