Information Technology Project Management – Fourth Edition

By Jack T. MarchewkaNorthern Illinois University

Power Point Slides by Gerald DeHondtGrand Valley State University

The Work Breakdown Structure and Project Estimation

Chapter 6

Project Time ManagementPMBOK®

Define Activities Identifying what activities must be completed to produce the project

scope deliverables Sequence Activities

Determining whether activities can be completed sequentially or in parallel and any dependencies that may exist among them

Estimate Activity Resources Identifying the type of resources (people, technology, facilities, etc.)

and the quantity of resources needed to carry out project activities Estimate Activity Durations

Estimating the time to complete each activity Develop Schedule

Based on the availability of resources, the activities, their sequence, and time estimates, a schedule for the entire budget can be developed

Control Schedule Ensuring that proper processes and procedures are in place in order to

control changes to the project schedule

6-3

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 Provides a link between the project’s scope

and detailed project plan Once the activities are defined, the next step

is to estimate the duration of each activity Estimation is not an exact science but the

estimates improve as more details about the project are uncovered

6-4

Work Package

The WBS subdivides the project into smaller components and more manageable units of work called work packages

Enables the development of a project plan schedule, budget and subsequent monitoring of the project’s progress

Each phase should provide at least one specific deliverable (a tangible and verifiable piece of work)

Activities or tasks are identified in order to produce the project’s deliverable

5

Work Package

6-6

Deliverables versus Milestones Deliverables

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

Milestones Significant events or achievements that provides

evidence that the deliverable has been completed or that a phase is formally over

Focuses on the achievement, not the deliverable Deliverable – prototype Milestone – stakeholder’s formal acceptance of the user

interface Smaller, shorter term deliverables keep the team

focused Cruxes (proof of concepts)

Successfully use a piece of software for the first time on small set of data, validates proof of concept for expanding to full blown database

Quality control No user acceptance, no moving forward. The deliverable must

be done right.

6-7

Developing the WBS A work package is developed for each of the phases and

deliverables defined in the Deliverable Structure Chart (DSC)

Focus on Testing box with deliverable of Test Plan and Test Results

6-8

Deliverable: Test Results Report Logical Activities to produce the test results

document:1. Review the test plan with the client so that key

stakeholders are clear as to what will be tested, how the tests will be conducted, and when the tests will be carried out.

2. Carry out the tests as outlined in the plan.3. Once the test results are collected, we need to

analyze them.4. The results should be summarized in the form of

a report and presentation to the client.5. If all goes well, the client will sign-off or approve

the test results and then we can move on to the implementation phase of the project. If not, then we need to address and fix any problems.

What are the deliverables? Milestones?

6-9

Example Work Breakdown Schedule

6-10

The WBS Should Follow the Work Package Concept

6-11

The WBS… Should be deliverable oriented Should support the project’s MOV The level of detail should support planning and

control WBS is bridge between scope and schedule/budget

Should involve those who will be doing the work The experience and expertise of those involved will

ensure that the level of detail will be appropriate Learning cycles and lessons learned can support

the development of a WBS Focus on what they know (facts), what they think they

know (assumptions) and what they need to find out (research) in order to develop a more useful WBS.

Lessons learned help keep the project plan realistic and complete.

6-12

6-13

6-14

Estimation Questions

How do you estimate?

What are you going to estimate?

Where do you start?

6-15

Estimation Techniques - TraditionalProject Management Approaches Most difficult and critical activity in project

management Time to complete an activity impacts cost due to

resource(s) needed – the project budget is thus impacted

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

6-16

Guestimating

Estimation by guessing or just picking numbers out of the air is not the best way to derive a project’s schedule and budget.

Unfortunately, many inexperienced project managers tend to guesstimate, or guess at the estimates, because it is quick and easy.

When put on the spot to give an estimate, give a range of time and cost and say that more research will enable a more confident estimate

6-17

18

Delphi Technique Involves multiple, anonymous experts Each expert makes an estimate Estimates compared

If close, can be averaged If not, do another iteration until consensus is

reached Can take longer than most other estimation

methods, but can be very effective and provide reasonable assurance

6-19

Time Boxing

A “box” of time is allocated for a specific activity, task, or deliverable May be based on a

requirement that can’t be changed

Can focus a team if used effectively

Can demoralize a team if not used effectively May result in long hours

and pressure May not succeed

6-20

Top-Down Mandate from above

has predetermined the time and cost of the project (competitor, satisfy client)

Top & middle managers determine overall project schedule &/or cost

Lower level managers are expected to breakdown schedule/budget estimates into specific activities (WBS) Previous project

experience can help in allocating time to activities

6-21

Top-Down When top-down estimation is done by

people independent of the project it may be overly optimistic or overly aggressive Death March project

Project schedule has been compressed 50% or more

Staff has been reduced by 50% or more Budget and resources have been reduced by

50% or more Functionality, features or other requirements

are twice what they should be under typical circumstances

Can force the PM to examine the project's risks more closely so that a specific budget or schedule target can be achieved

22

Bottom-Up

Schedules & budgets are constructed from WBS

Starts with people who will be doing the work

Schedules & budgets are the aggregate of detailed activities & costs

Analogous estimation - use information from previous, similar projects as a basis for estimation BUT – is everything else

the same?

6-23

Parametric Modeling Use project characteristics (parameters) in a

mathematical model to estimate Example: $50/ LOC based on:

Programming language Level of expertise Size & complexity

6-24

6.2 Test Results Report6.2.1 Review test plan with client 1

day6.2.2 Carry out test plan 5

days6.2.3 Analyze results 2

days6.2.4 Prepare test results report and presentation 3

days6.2.5 Present test results to client 1

day6.2.6 Address any software issues or problems 5

days

Estimates are made for each activity in the WBS

How did we come up with these estimates? Using a technique,or combination of techniques, with the exception of guestimating!

6-25

Estimating Techniques - Software Engineering Approaches

Lines of Code (LOC) Function Points COCOMO Heuristics

Software engineering techniques focus on estimating the size ofthe system to be developed

6-26

Software Engineering Metrics Software engineering focuses on processes,

tools and methods for developing a quality approach to developing software

Metrics provide the basis for SE and refers to a broad range of measurements for objectively evaluating computer software The greatest challenge for estimating an IT project is

estimating the time and effort for the largest deliverable of the project – the application system True for maintenance projects and installation of packaged

software as well Trying to estimate something that is not well defined until

the later stages of the project life cycle The complexity and technical challenges are unknown or

optimistically glossed over in the early stages of the project

27

Software Engineering Metrics

Size

Application Estimate

ComplexityConstraints &

Influences

28

Determinants of Estimating the Largest Deliverable of the Project – The Application System

Function Point Analysis Developed to address the inadequacies of LOC

Proposed by Allan Albrecht of IBM in 1979 It is a synthetic metric much as hours, kilos and

Celsius are Focuses on the functionality and complexity of the

application Independent of the Technology

Avoids the program of different programming languages or technology platforms

FP analysis is reliable in the sense that two analysts trained in FP analysis will obtain the same results within a margin of error

Two main organizations oversee the rules, guidelines, standards and certification for FP analysis IFPUG (www.ifpug.org) and UFPUG

29

Function Point Analysis

A FAP is done early on based on the project’s scope followed by a more detailed analysis during the analysis and design stage

FAP is based on an evaluation of five data and transactional types that define the application boundary

5 Primary Elements Inputs Outputs Inquiries Logical Files Interfaces

30

The Application Boundary for Function Point Analysis

6-31

Function Point Analysis Internal Logical File (ILF) – AN ILF is a logical file that stores data within the

application boundary. For example, each entity in an E-R diagram would be considered an ILF. The

complexity of an ILF can be classified as low, average, or high based on the number of data elements and subgroups of data elements maintained by the ILF. An example of a sub-group would be new customers for an entity called customer. Examples of data elements would be customer number, name, address, phone number,

and so forth. In short, ILFs with fewer data elements and subgroups will be less complex than lLFs with more data elements and subgroups.

External interface file (EIF)——An EIF is similar to an ILF; however, an EIF is a file maintained by another application system. The complexity of an EIF is determined using the same criteria used for an ILF.

External input (El)—An El refers to processes or transactional data that originate outside the application and cross the application boundary from outside to inside. The data generally are added, deleted, or updated in one or more files internal to the application (i.e., internal logical files). A common example of an EI would be a screen that allows the user to input

information using a keyboard and a mouse. Data can, however, pass through the application boundary from other

applications. For example, a sales system may need a customer’s current balance from an accounts

receivable system. Based on its complexity, in terms of the number of internal files referenced, number of data elements (i.e., fields) included, and any other human factors, each EI is classified as low, average, or high.

32

Function Point Analysis External output (EO)—Similarly, an EO is a process or transaction

that allows data to exit the application boundary. Examples of EOs include reports, confirmation messages, derived or

calculated totals, and graphs or charts. This data could go to screens, printers, or other applications. After the number of EOs are counted, they are rated based on their complexity, like the external inputs (El).

External inquiry (EQ)——An EQ is a process or transaction that includes a combination of inputs and outputs for retrieving data from either the internal files or from files external to the application. EQs do not update or change any data stored in a file. They only read this

information. Queries with different processing logic or a different input or output format

are counted as a single EQ. Once the EQs are identified, they are classified based on their complexity as low, average or high, according to the number of files referenced and number of data elements included in the query

33

Function Point Analysis Once all of data and transactional types are counted and their

relative complexities rated, an unadjusted function point (UAF) count is determined

The following has been determined after reviewing the application system ILF: 3 low, 2 average and 1 complex EIF: 2 average EI: 3 low, 5 average and 4 complex EO: 4 low, 2 average and 1 complex EQ: 2 low, 5 average and 3 complex

The next step is to compute a Value Adjustment Factor (VAF) It is based on the Degrees of Influence (DI), often called Processing

Complexity Adjustment (PCA) Derived from the 14 General Systems Characteristics (GSC) To determine the total DI, each GSC is rated based on the following

0 = not present or no influence 1 = incidental influence 2 = moderate influence 3 = average influence 4 = significant influence 5 = strong influence

34

Function Point Analysis After reviewing the application, the Total Adjusted Function Points

(TAFP) is computed to be 210 That number can be transformed into development estimates

Productivity – how many function points can a programmer produce in a given period of time Can be based on lessons learned from prior project experience

LOC – convert function points into lines of code based on the programming language Backfiring – technique which allows for direct conversion from source code to a

function point count Accuracy not high due to individual programming styles but can be use to create a FP

inventory of an organization’s project portfolio

35

  Complexity  

Low Average High Total

Internal Logical Files

(ILF)_3 x 7 = 21 _2 x 10 = 20 _1 x 15 = 15 56

External Interface

Files (EIF)__ x 5 = __ _2 x 7 = 14 __ x 10 = __ 14

External Input (EI) _3 x 3 = 9 _5 x 4 = 20 _4 x 6 = 24 53

External Output (EO) _4 x 4 = 16 _2 x 5 = 10 _1 x 7 = 7 33

External Inquiry (EQ) _2 x 3 = 6 _5 x 4 = 20 _3 x 6 = 18 44

  Total Unadjusted Function Points (UAF) 200

General System Characteristic Degree of Influence

Data Communications 3

Distributed Data Processing 2

Performance 4

Heavily Used Configuration 3

Transaction Rate 3

On-line Data Entry 4

End User Efficiency 4

Online Update 3

Complex Processing 3

Reusability 2

Installation Ease 3

Operational Ease 3

Multiple Sites 1

Facilitate Change 2

Total Degrees of Influence 40

Value Adjustment Factor VAF = (TDI * 0.01) + .65

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

Total Adjusted Function Points = FP = UAF * VAF

FP = 200 * 1.05 = 210

36

COCOMO (COnstructive COst MOdel) Developed by Barry Boehm in 1981in his book

Software Engineering Economics Based on LOC estimates, used to estimate cost,

effort and schedule Open model (all equations, assumptions, definitions,

etc. are freely available) It is a parametric model because it uses dependent

variables such as cost or duration, based upon one or more independent variables that are quantitative indices of performance and/or physical attributes of the system

Has been extended to COCOMO II http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

6-37

COCOMO Models (Effort) First determine the type of the project

Organic – Routine Technology, processes and people are expected to all work

together smoothly Person Months = 2.4 * KDSI1.05

Embedded – Challenging System to support a new business process or new ground

for the organization People may be less experienced and the processes and

technology less mature Person Months = 3.6 * KDSI1.20

Semi-Detached – Middle Not simple or straightforward but the organization feels

confident that the processes, people and technology are adequate to meet the challenge

Person Months = 3.0 * KDSI1.12

Person month = 152 hours KDSI = Thousands of delivered source instructions i.e., LOC

38

COCOMO – Effort Example Semi-Detached

200 total adjusted function points Using Table 6.3 we know Java averages 53 SLOC

per FP 200 FP * 53 10,600 Java LOC Assuming the project is of medium difficulty, we

use the semi-detached equation to compute the effortPerson Months = 3.0 * KDSI1.12

= 3.0 * (10.6) 1.12

= 42.21 Having computed effort, we can now determine

duration using the following formulas Organic Duration = 2.5 * Effort0.38

Semi-Detached Duration = 2.5 * Effort0.35

Embedded Duration = 2.5 * Effort0.32

39

COCOMO Duration ExampleDuration = 2.5 * Effort0.35

= 2.5 *(42.21)0.35

= 9.26 months

People Required = Effort / Duration= 42.21 / 9.26= 4.55

40

COCOMO Intermediate COCOMO

Estimates the software development as a function of the size and a set of 15 subjective cost drives that include attributes of the end product, the computer used, the personnel staffing and the project environment

Advanced COCOMO Includes all the characteristics of intermediate

COCOMO but with an assessment of the cost driver’s impact over four phases of development: product design, detailed design, coding/testing and integration/testing

COCOMO II More suited for projects developed using 4GLs (VB,

Delphi, Power Builder) SLIM

Uses LOC to estimate the project’s size and 22 questions to calibrate the model

41

Heuristics (Rules of Thumb)The same base activities will be required for a typical s/w development project and these activities will require a predictable percentage of the overall effort

Use knowledge gained from previous project experience when scheduling a software task:

1/3 Planning 1/6 Coding 1/4 Component test and early system test 1/4 System test, all components in hand

6-42

Heuristics (Rules of Thumb)T. Capers Jones provides these heuristics

Creeping user requirements will grow at an average rate of 2% per month from design through coding phases

FPs raised to the 1.25 power predict the approximate defect potential for new s/w projects

Each formal design inspection will find and remove 65% of the bugs present

Maintenance programmers can repair 8 bugs per staff month

FPs raised to the 0.4 power predict the approximate development schedule in calendar months

FPs divided by 150 predict the approximate number of personnel required for the application

FPs divided by 750 predict the approximate number of maintenance personnel required to keep the application updated

Rules of thumb are easy, but they are not always accurate

43

The seeds of major software disasters are usually sown in the first three months of commencing the software project.

Hasty scheduling, irrational commitments, unprofessional estimating techniques, and carelessness of the project management function are the factors that tend to introduce terminal problems.

Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably.

T. Capers Jones, 1988 Page 120

6-44

Brooks’ Law

Adding manpower to a late softwareproject makes it later.

6-45

The Man MonthM

onth

s

People

Mon

ths

PeopleTime versus number of workersperfectly partitionable task – i.e.,No communication among theme.g., reaping wheat.

When a task that cannot be partitionedbecause of sequential constraints, theapplication of more effort has noeffect on the schedule.

6-46

Adding People

Increases the total effort necessary The work & disruption

of repartitioning Training new people Added

intercommunication

6-47

6-48

What can cause inaccurate estimates?

Scope changes Overlooked tasks Poor developer-

user communication

Poor understanding of project goals

Insufficient analysis

No (or poor) methodology

Changes in team Red tape Lack of project

control Not identifying or

understanding impact of risks

6-49

Other Factors to Consider When Estimating Rate at which requirements may change Experience & capabilities of project team Process or methods used in development Specific activities to be performed Programming languages or development tools

to be used Probable number of bugs or defects & removal

methods Environment or ergonomics of work space Geographic separation of team across

locations Schedule pressure placed on the team

6-50

How can estimates be improved?

Experience! Lessons learned Best Practices

Revision Monitor Focus on

deliverables Control

6-51