Scribd
Upload
104 views36 pages

Information Technology Project Management: by Jack T. Marchewka

ITPM

Uploaded by

deeps0705
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
104 views36 pages

Information Technology Project Management: by Jack T. Marchewka

ITPM

Uploaded by

deeps0705
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 36

Information

Technology Project
Management
by Jack T. Marchewka

Power Point Slides by Jack T. Marchewka, Northern Illinois University

Copyright 2006 John Wiley & Sons, Inc. all rights reserved. Reproduction or translation of this work beyond that permitted
in Section 117 of the 1976 United States Copyright Act without the express permission of the copyright owner is unlawful.
Request for further information information should be addressed to the Permissions Department, John Wiley & Sons, Inc.
The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher
assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the
information contained herein.

Chapter 6
The Work Breakdown
Structure & Estimation

Learning Objectives
Develop a work breakdown structure (WBS).
Describe the difference between a deliverable and a
milestone.
Describe and apply several project estimation methods.
These include the Delphi technique, time boxing, topdown estimation, and bottom-up estimation.
Describe and apply several software engineering
estimation approaches. These include lines of code
(LOC), function point analysis, COCOMO, and
heuristics.

Project Time Management as


defined in PMBOK

Activity definition
Activity sequencing
Activity duration estimation
Schedule development
Schedule control

The Work Breakdown


Structure (WBS)
The WBS represents a logical decomposition
of the work to be performed and focuses on
how the product, service, or result is naturally
subdivided. It is an outline of what work is to
be performed.
Gregory T. Haugan (2002)

Work Package

Deliverables and Milestones


Deliverables
Tangible, verifiable work products
Reports, presentations, prototypes, etc.

Milestones
Significant events or achievements
Acceptance of deliverables or phase completion
Cruxes (proof of concepts)
Quality control
Keeps team focused

Developing the WBS

Develop work packages for each of the phases and deliverables


defined in the Deliverable Structure Chart (DSC)

Example Work Breakdown Schedule

The WBS Should Follow the Work


Package Concept

Developing the WBS


The WBS Should Be Deliverable-Oriented
The WBS Should Support the Project's MOV
Ensure WBS allows for the delivery of all the projects
deliverables as defined in project scope
100 percent rule

The Level of Detail Should Support Planning and


Control
Developing the WBS Should Involve the People
Who Will Be Doing the Work
Learning Cycles and Lessons Learned Can
Support the Development of a WBS

Estimation Techniques
- The Project Management Approach

Guesstimating
Delphi Technique
Time Boxing
Top-Down
Bottom Up
Analogous Estimates (Past experiences)
Parametric Modeling (Statistical)

Project Estimation
Guesstimating
Based on feeling and not facts
Not a good method for estimating but often used
by inexperienced project managers

Delphi Technique
Involves multiple, anonymous experts
Each expert makes an estimate
Estimates compared
If close, can be averaged
Another iteration until consensus is reached

Project Estimation
Time Boxing
A box of time is allocated for a specific
activity, task, or deliverable
Can focus a team if used effectively
Can demoralize a team if used too often or
ineffectively because of the increased stress
or pressure on the project team to get things
done

Project Estimation
Top-Down Estimating
Top and middle managers determine overall project
schedule and/or cost.
Lower level managers are expected to breakdown
schedule/budget estimates into specific activities
(WBS).
Often couched in terms of what a project should cost
and how long it should take as decreed by a member
of top management who thinks those parameters are
appropriate.
May be a response to the business environment.
May lead to a death march project.

Project Estimation
Bottom-Up Estimating
Most common form of project estimation
Schedules & budgets are constructed from
the WBS
Starts with people who will be doing the work
Schedules & budgets are the aggregate of
detailed activities & costs

Project Estimation
Analogous estimating
based on similarity between current projects
and others
Use information from previous, similar
projects as a basis for estimation

Project Estimation
Parametric Modeling
Use project characteristics (parameters) in a
mathematical model to estimate
Example: $50/ LOC based on:
Programming language
Level of expertise
Size & complexity

Example WBS with Estimated Task


Durations

6.2 Test Results Report


6.2.1 Review test plan with client
6.2.2 Carry out test plan
6.2.3 Analyze results
6.2.4 Prepare test results report and presentation
6.2.5 Present test results to client
6.2.6 Address any software issues or problems

1 day
5 days
2 days
3 days
1 day
5 days

Project Estimation Software Engineering Approaches

Lines of Code (LOC)


Function Points
COCOMO
Heuristics

Determinants of Estimating the Largest Deliverable


of the Project The Application System

Software Engineering Metrics


and Approaches
Lines of Code (LOC)
An metric that is often used for determining
the size of the project
Most controversial

Count comments?
Declaring variables?
Efficient code vs. code bloat
Language differences
Easier to count afterwards than to estimate before
programming begins

Function Point Analysis

Allan Albrecht, IBM 1979


Synthetic metric
Independent of the Technology
IFPUG standards (www.ifpug.org)
5 Primary Elements

Inputs
Outputs
Inquiries
Logical Files
Interfaces

The Application Boundary for


Function Point Analysis

Complexity

Low

Average

High

Total

_3x 7=21

_2x 10=20

_1x 15=15

56

__x 5=__

_2x 7=14

__x 10=__

14

ExternalInput
(EI)

_3x 3=9

_5x 4=20

_4x 6=24

53

External
Output(EO)

_4x 4=16

_2x 5=10

_1x 7=7

33

External
Inquiry(EQ)

_2x 3=6

_5x 4=20

_3x 6=18

44

Internal
LogicalFiles
(ILF)

External
InterfaceFiles
(EIF)

Total Unadjusted Function Points (UAF)

200

General System Characteristic

Degree of Influence

DataCommunications

DistributedDataProcessing

Performance

HeavilyUsedConfiguration

TransactionRate

On-lineDataEntry

EndUserEfficiency

OnlineUpdate

ComplexProcessing

Reusability

InstallationEase

OperationalEase

MultipleSites

FacilitateChange

2
Total Degrees of Influence

ValueAdjustmentFactorVAF=(TDI*0.01)+.65

Total Adjusted Function Points = FP = UAF * VAF

40
VAF=(40*.01)+.65=1.05

FP=200*1.05=210

Language

Average Source LOC


per Function Pont

Average Source LOC


for a 210 FP
Application

Access

38

7,980

Basic

107

22,470

128

26,880

C++

53

11,130

COBOL

107

22,470

Delphi

29

6,090

Java

53

11,130

MachineLanguage

640

134,440

VisualBasic5

29

6,090

Source:http://www.theadvisors.com/langcomparison.htm

COCOMO
COnstructive COst MOdel
Parametric Model developed by Barry Boehm in
1981
Project types
Organic
Routine projects where the work is expected to go smoothly
with few problems

Embedded
Challenging projects that may be new ground for the
organization or project team

Semi-detached
In between organic and embedded. Projects that may not be
simple and straightforward, but there is a high degree of
confidence that the project team can meet the challenge

COCOMO Models (Effort)


Organic Routine
Person Months = 2.4 * KDSI1.05

Embedded Challenging
Person Months = 3.6 * KDSI1.20

Semi-Detached Middle
Person Months = 3.0 * KDSI1.12

COCOMO Effort Example


Semi-Detached
10,600 Java LOC = 200 FP * 53
Person Months = 3.0 * KDSI1.12
= 3.0 * (10.6) 1.12
= 42.21

COCOMO Models (Duration)


Organic
Duration = 2.5 * Effort0.38

Semi-Detached
Duration = 2.5 * Effort0.35

Embedded
Duration = 2.5 * Effort0.32

COCOMO Duration Example


Duration = 2.5 * Effort0.35
= 2.5 *(42.21)0.35
= 9.26 months
People Required = Effort / Duration
= 42.21 / 9.26
= 4.55

COCOMO
COnstructive COst MOdel
COCOMO Model Types
Basic
Intermediate
Advanced
COCOMO II

Heuristics
(Rules of Thumb)
Whenforschedulingasoftwaretask:
1/3Planning
1/6Coding
1/4Componenttestandearlysystemtest
1/4Systemtest,allcomponentsinhand

Some Examples of Heuristics from Estimating


Software Costs by Capers Jones (1988)
Each formal design inspection will find and
remove 65 percent of the bugs present.
Each formal code inspection will find and
remove 60 percent of the bugs present.
Function points raised to the 0.4 power predict
the approximate development schedule in
calendar months.
Function points divided by 150 predict the
approximate number of personnel required for
the application.

What Is the Best Way to


Estimate IT Projects?
Use more than one technique for
estimating
If estimates from different techniques
close, average them
Adjust estimate based on experience
Negotiation may lead to unrealistic
estimations

You might also like