146 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

The final group of best practices are covered in CMM Levels 3, 4, and 5. In fact,
many criticize the CMM for deferring these practices until higher levels. "How can
you possibly omit such and such until level X? You won't reach that level for three
years and such and such is essential today." This is a valid criticism when taken out
of context, but the levels are in the CMM because people can absorb only so much
change a t a time. It would be great to bring in all the best practices a t once, but that Customer
is hardly feasible. Executive
Sponsor
Reviews, inspections, and walkthroughs (see Chapter 9) let people look a t the work Producer
of others to find and fix errors early and remove misunderstandings.
Reusable items cut down on the new work to be done. Reuse is an excellent goal,
but few people have it. It is difficult t o capture work done to date, put it in a library,
and make it easy to search, retrieve, and reuse. Source code is not the only item you
can reuse. Aim to reuse parts of CM plans, requirements, designs, test scripts, and
test data. Always think about reuse when building something for the first time. Ask
what could be done differently that will make the item reusable. Also ask if some-
thing is available that can be reused to fit the current need.
Testing early and often is essential. Errors kill projects because if found late, the
cost of fucing them is far out of proportion t o their value. Inspect, test, and review
products early. Use visibility t o get people thinking about the work of others.
The PSP emphasizes simple methods of defect tracking. Where were errors com- Figure 6.14 The project contc
mitted? Who found them? How? Where? When? How long did it take t o fix them?
What kind of errors were they? What practices will let us find them earlier or prevent
them? These are difficult questions, but the answer8 are available and valuable.

6.3 Making the project visible: Planning techniques constraints. Time, money,
challenge them ("if we buy
6.3.1 Project context can save 3 months and $50
All these items come tc
The first thing I do on a new project is create a project context document. This docu- want from the project, not
ment is for my development team and me only-no one else. A project context dia- titative. They are an inteq
gram structured as in Figure 6.14is on the first page; the rest of the document dis-
cusses the diagram. The project context diagram is very different from the context The final two blocks in 1
diagram in Figure 5.7 (see Chapter 5). The context diagram is a high-level dataflow paper. The system requirer;
diagram. The project context diagram, on the other hand, shows the context or set- design concept is a one way
ting of a project. Figure 6.15 shows a p
As the figure shows, the left side of the diagram contains the names of the cus- Jones Inc. to give you an ic
tomer, executive sponsor, and our team (producer).The developers must know who is the company and project a~
and is not the customer. Do not disdain outsiders who w a n t t o help, but know and The project context dial
listen to your customer first. The customer and marketplace objectiues are the proj- put them on paper where I
ect's high-level goals. They are qualitative not quantitative and come from marketing documented, I share them
or customer surveys. They will influence the project requirements. the diagram and refme it. '
Also influencing the project requirements are the three items on the right. Exter- this document and share i
nal requirements include compatibility issues and support required by others. The and months.
new system will not exist in a vacuum. It must work with existing systems and or- The ideas in the docum
ganizations. In the same way, the project must fit with company and project policies. created in an hour constra:
Businesses have personnel work standards and rules. List these so that everyone tell new development team
knows what is influencing management's decisions. Finally, there are the project's this away from the custom1
,
Executive
Sponsor
Customer

Producer
I

L
Customer
Marketplace
Objectives

Project
Requirements

System
Requirements
(High-Level)

System
Design
Concept

Figure 6.14 The project context diagram

.
I

C
0
n
S
t
r
a
i
n
t
S
PLANNING 147

External
Requirements

Company and
Project Policies

constraints. Time, money, and equipment are limited. State the limitations and then
challenge them (“if we buy SQL Super instead of using the same old Power team, we
can save 3 months and $500,000”).
All these items come together into the project requirements. These are what we
want from the project, not the system. These requirements are qualitative and quan-
titative. They are an interpretation of the objectives in light of the constraints.
The final two blocks in the diagram are simple attempts at building the system on
paper. The system requirements are what we want from the new system. The system
design concept is a one way to achieve those desires.
Figure 6.15 shows a project context diagram for a new accounting system for
Jones Inc. t o give you an idea of how these blocks are filled in with project data (both
the company and project are fictitious).
The project context diagram helps me gather my thoughts about the project, and
put them on paper where I can see them. ARer I’m satisfied that my ideas are clearly
documented, I share them with the initial, small development team. We work over
the diagram and refine it. The project context puts us all on the same track. We keep
this document and share it with each new person who joins the project over weeks

The ideas in the document are not concrete. Do not let the system design concept
created in an hour constrain the project. Use it for what it is-a simple, quick tool t o
tell new development team members what the project is about in general terms. Keep
this away from the customer, who can easily misinterpret your intent.
/I t
 -
PLANNING 149

Analyze the requirements for X.

Design at a high level for X.
Design at a low level for X.
Build components for X.
Test components for X.
Integrate and test components for X.
Test system for X.

1 Figure 6.16 shows an example. Across the top f the figure are four products for
an accounting software package called D-Count (t ere should be more products, but

I
this is sufficient for the example). Note the addition of a system product. Always add
this to the product list because every project will have tasks devoted to the project
itself. Make a task card for each task block. Use plain 3 x 5 or 5 x 7 cards or Post-Its
of this size. Each task card will eventually contain all the task elements shown in
Figure 6.1. The example in Figure 6.16 will have 28 task cards. This is probably too
many, but it's easier t o discard tasks later than to think of ones you should have

System D-Count Software User's Manual Test Suite

~ Analyze I [ X n i T
~ Requirements j Requirements

1~ - D e n i g n T ' ~-al
1 High-Level I ! Designat-
High-Level I
I
1
Designat
High-Level 1'
Design at Design at Design at
~..

' Build

~~

System
, Test ~

Test Concepts
work breakdown structure,
I50 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

3. Lay out an initial task network. Figure 6.17 shows the initial task network Figure 6.18 shows the fi1
for the example in Figure 6.16.Tack o r tape the task cards to the walls and management software pack.
connect them with yarn or string, or cover the walls with white boards, tape software will generate a Ga
the task cards on the boards, and connect them by drawing lines on the tion than you could possibly
boards with markers. Use large Post-Its instead of regular cards t o make this Document the decisions n
easier. the user's manual will be w
gins. This is unusual. Why d
The initial task network is structured around the three main products (D-Count tives? What factors pushed t
software, test suite, and user's manual). These have horizontal strips of tasks associ.
ated with them. The three task strips join a t control gates or milestones-junctioas Use the project managen
that stop the project and give everyone a chance to think before embarking on a new PERT and Gantt charts. POE
(expensive) flurry of activity. The task strips are parallel, which means tasks can be doing the work. The project I
performed simultaneously if the people are available. Assign people to tasks at this thing wrong, listen and cha
time. harder. You will destroy you
Creating the initial task network requires some thought, but it is mostly a me.
chanical process. Put the tasks associated with each product in strips. Place a control 6.3.3Cards on the wall
gate after system high-level design, aRer the low-level design of each product, and Cards on the wall is a work
before all the products are integrated. 6 ) , but it is also an excellent
ple working a task network
4. Refine the initial network. This is the creative and difficult part of the proc- ticipants own the plan, and
ess. Delete, add, combine, and rearrange the cards. Move them around and volve people from as many
change their connections. Change the people, time, resources, inputs, and and so on) as possible.
outputs on each card. Challenge the people refining the network. "Could your
people outline the user's manual in three days?" 'Won't you need to finish the
design of the main routine before you design that subroutine? How can you do
them in parallel?"

The refined network is the project's schedule-your commitment to everyone-and

you must take it seriously. Allow for vacations, illness, and training. Give your people
the time and resources they need to succeed.

\
Figure 6.17 Initial task network for the example in Figure 6 16 Figure 6.18 The final task netwc
 152 THE SOFTWARE PROJECT MANAGER‘S HANDBOOK

a ...,....
.....I.. Use prerequisites when1
and use a repeatable proct
tion. Estimates without pa
with metrics. If an organii
sign, build, and integration
tions), its people know ho1
predict how much time thf
pline, mature process, and
If the prerequisites are r
viding the tasks or produr
easier (almost anyone can I
divide-until-small task is 1
duces the feeling of creatin
tion will require. Perform
temptation t o fall back on
(just solve it) and work thn
Flgure 6.19 Cards on the wall planning session. Be realistic. For most, tl
software. An optimistic est
the job). I t can also mean
As the project manager, don’t worry too much about the task network-that will working 80 hours a week fc
get done. Instead, focus on the people. If someone is sitting back a t the table, bring
There are two main trp
them to the wall. Suggest a few stupid ideas and move cards related to them to the
The Rayleigh model is an e
wrong place. Push them into asserting their expertise t o correct you. Make them
PSP is an example of the I
work on the plan until they own it.
ence, and both work. Do nc
Prepare for the cards on the wall session in the same way you would prepare for a hours to perform.
JAD session (see Chapter 5). A cards on the wall session involves a number of people
for one to five days. It costs money, so it deserves and requires forward thinking.
Find a room off site t o minimize interruptions. Ensure it has ample blank cards,
yarn, empty walls or white boards, tape, pens, paper, bathrooms, refreshments, com-
puters, printers, and so on. Do not start until everyone arrives. Get a commitment 6.4.1 Rayleigh model
from management that everyone will stay until finished. Do a warm-up exercise like
The Rayleigh model gives,
a task network for celebrating after the project.
for a project are realistic.
This may seem like a silly gimmick, but it works. Some may ask “Can’t one person 19961 [Putnam 19971 deve
just do the schedule and have others comment on it?” This approach might work, but
The model is based on 1
the plan would always belong t o the person who created it. It is “Bill’s plan,” not your
Lord Rayleigh). As Figure
plan.” When people own a plan, they work hard to see it succeed.
project beginning with der
uct. The horizontal axis is
6.4 Making the project visible: Estimating staff-months per month. 1
of the project. This shows
techniques The first vertical dottei
Estimation is predicting the size of a product or the length of a task. Most people do tial operational capabilib
not estimate well, even though estimation is an essential part of planning. It’s taken ware reaches final operati
me years of successes and failures t o evolve the following guidelines: cal dotted line is 39 perce
percent of the total, and
Know the purpose of the estimate and the desired accuracy. If someone needs the Many people think they L
estimate for an informal discussion and it need be only within an order of magnitude,
This model states that thl
pause and give an answer. If the survival of the business depends on the estimate
point, the remaining 61 PI
and it must be accurate within f 2 percent, an offhand reply would be disastrous. You
are more likely to encounter the first example in practice.
 PLANNING 153

e prerequisites whenever they are auailable. Have metrics from past projects
use a repeatable process. Metrics provide a reliable foundation for any estima-
Estimates without past data are dangerous. A repeatable process is a partner

t how much time the same steps will require on the next project. Their disci-

tation to fall back on a familiar task. Resist the temptation t o start coding now

t can also mean a failed project (more time and money than estimated or
0 hours a week for 40 hours pay).
are two main types of approaches t o software estimating: macro and micro.
eigh model is an example of the macro approach; the Probe technique in the

.4.1 Rayleigh model

The Rayleigh model gives you an overall project perspective to help ensure that plans
6m a project are realistic. Larry Putnam and Ware Myers [Putnam 19921 [Putnam
15961 [Putnam 19971 developed this model from years of experience.
The model is based on the Rayleigh curve (named after the 19th century physicist
lord Rayleigh). As Figure 6.20 shows, the curve is the actual effort expended in a
project beginning with design and ending with the delivery of a highly reliable prod-
&.The horizontal axis is time in the project. The vertical axis is the current effort in
staffmonths per month. The area under the curve is the total effort or staff-months
ofthe project. This shows the cost (staff-months times dollars per staff-month).
The f i s t vertical dotted line is a t time TD.This is where the software reaches ini-
tial operational capability (100. The second vertical dotted line is where the soft-
ware reaches final operational capability (FOC). The area t o the left of the first verti-
cal dotted line is 39 percent of the total area, the area between the dotted lines is 39
percent of the total, and the remaining 22 percent is in the long tail to the right.
Many people think they are done when the software works for the first time ( 1 0 0 .
 1

154 THE SOFTWARE PROJECT MANAGER’S HANDBOOK

Staff Month
Per Month

Flgure 6.21 Equi

Figure 6.20 The RayleighCurve tivity paramel

these numbers
The Rayleigh curve fits the staffing of large software projects. The curve begins an even more i
when design does. The project needs only a few people a t that time because there is Use the esl
only so much anyone can do. After the designers divide the design into parts, the d a t e d to find
parts need further design and division, so more people join the project. Coding begins in staff-years;
to the left of the curve’s peak, and staffing increases again. The software is ready far to multiply th
user testing near the curve’s peak, the IOC. Testing involves the maximum number month (staff-y,
of people for the project. Staffing declines after testing as the testers, and some pro-
grammers move on to other projects. The remaining programmers correct the errors Checking pm
found during testing. As the number of errors declines, so does the number of pro- validity of pro
grammers. The software reaches an acceptable threshold of errors at FOC and is de- neering softwz
livered. As the figure shows, however, 22 percent of the work remains in responding in 18 months 7
t o the customer and supporting the product. staff-year). Tk
Figure 6.21 lists the equations for the Rayleigh model. The first equation (11, de- 31,481 to acco
rived by F’utnam and Myers, gives your organization’s productiuity parameter. The software has
authors consider productivity t o be more than just LOC divided by time. The produc. 19971. (Remen
tivity parameter is calculated from past project performance and indicates the 01- parameter sea
ganization’s overall capability. The product size is the (often argued) lines of code can tell from ,
(LOC) in the delivered software. This method requires using LOC, but there are significantly h
methods for converting function points to LOC. Effort is the staff-years needed for fort, and cost
the project. B is a special skills factor that ranges from 0.16 for products with 5,000 gate to see if
to 15,000 LOC t o 0.39 for products with 70,000+LOC [Putnam 19921 [Putnam 19971. meet their pro
This constant compensates for the differences in different size projects. (Larger praj.
ects have more people, which requires more communication. This means more meet. Estimating t
ings and more miscommunication, which c a n lead t o more errors.) Time is expressed build parts of
in years. tion). Figure 6
Next is the software equation. Notice that time (T) is raised t o a power greater of phases befo
than one. This reflects the nonlinear nature of software projects. That is, software feasibility stuc
products twice as big require much more than twice as much time and money. product size ir
The software equation lets you calculate the time, effort, and cost of a project company’s pro
given your organization’s past performance and the estimated LOC for the project. bility study st
You merely insert the final LOC, the staff-years of effort, the time required in years, few more p o l
and the correct special skills factor B from a similar project and calculate the produc. size and calcu
 PLANNING 155

(1) Productivity Parameter = Product S i y

(Effort/B)'"* Time'"

(3) Th,"= 8.14 * (Product SizeIPmductivlty Parameterp'.' in months

(4) Effort in man ?ears = 15 * B * Th,"'with T In years

(5) Effort in man months = 180 * B * Tb2 with T I " years

(6) Cost =Man Months * $Man Months

ea Figure 6.21 Equations of the Rayleigh model.

Time

tivity parameter. Most organizations, even those without metrics programs, have
these numbers. In the next section, I describe how to use the Probe approach to get
h e curve begins an even more accurate estimate of the proposed product's LOC.
because there is Use the estimated LOC for this project and the productivity parameter just cal-
1 into parts, the culated to find the minimum TDfor this project. Equation (2) is for calculating Tomin
:t. Coding begins in staff-years; Equation (3) lets you calculate in staff-months. The final step is simply
ware is ready for to multiply the staff-months (or staff-years) of effort by the average cost of a staff-
ucimum number month (staf€-year)for your organization.
i, and some pro-
mect the errors
number of pro- Checking proposals. As Figure 6.22 shows, these equations can help you check the
FOC and is de- validity of proposed plans and costs. The company here proposes t o write an engi-
s in responding
neering software package with an estimated 300,000 LOC, which they hope to build
in 18 months with 800 staff-months a t a cost of $9.99 million (charging $150,000 per
staff-year). The first calculation shows that their productivity parameter must be
quation (l), de- 31,481to accomplish this. History says the average firm that produces engineering
oarameter. The sohare has a productivity parameter of about 14,000 [Putnam 19921 [F'utnam
ie. The produc- 19971. (Remember that the 31,481 is not as bad as it seems because the productivity
dicates the or- parameter scale is nonlinear.) Assuming the company is about average (which you
1) lines of code can tell from past project performance), the 14,000 value gives a schedule and cost
but there are significantly higher than proposed. Use the 14,000 value and calculate the time, ef-
ars needed for fort, and cost as shown. Do not accept this proposal. Explain the doubts and investi-
lets with 5,000 !ate to see if the company can justify the higher productivity parameter needed to
Putnam 19971. meet their proposal.
I. (Larger proj-
ns more meet-
e is expressed
Estimating time before main-build. The Rayleigh model pertains to the main
build parts of a software project (design, code, inspection, testing, and documenta-
tion). Figure 6.23 is another view of the Rayleigh curve that shows the relative times
Power greater of phases before the main build. The first phase is what h t n a m and Myers call the
It is, software feasibility study. A few people analyze the requirements of the system, estimating the
ioney. product size in ranges (minimum, expected, and maximum size). These sizes and the
t of a project company's productivity parameter let you calculate Tomlnas shown earlier. The feasi-
r the project. bility study should last only one fourth of TD.The functional design phase is where a
ired in years, few more people perform the high-level design. They revise the estimate of product
e the produc- size and calculate a better TD.This phase should last only one third of TO.
 156 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

Estimated Size = 300,000 lines of code

Proposed Time = 18 months = 1.5 years

Effort = 800 man-months = 66.6 man-yean

Cast Rate = $150.000 per man-year

Coat = $9.99M

Required Productivity Parameter =

(GG.6/0.39)'"* (1.6)'"

= 31,481

Industly Average Pmductivity Parameter = 14,000

T, ~ = 0.68 * (300,000/14,000)"'"=2.54 man-years

Effort = 15 * 0.39 * 2.54' = 95.86 man-years

Cast = $150,000 * 95.86 = $14.4M

Figure 6.22 Checking the validity of a proposal for an engineering system.

Man-Months

PerMonth t

Main
Functional

... ....
Study

0 TD
Figure 6.23 Relative time prior to main build.
 PLANNING 157

0.5 1.0

Past Data Shows

Productivity Parameter = lO,OOO/((201(12*0.16))'M (11/12)") = 5,142
Expected Lines of Code = (20.000 + 30,000)12= 25,M)O
Minimum To=8.14 * (25,00015,144)0~43= 16.1 months = 1.34years
Effort = 180 0.16" 1.34O." = 69.3 manmonths
Total Cost = 69.3 manmonths 510,000 per man-month = 56.93M
Emn= 69.3 man-monthsl16.1 months = 4.3 people

Time Actual Rounded Manpower Actual Rounded Months

Length Time Months Ratio Manpower People
Ratio (months) beople)
0.15 2.42 2 0.5 1.72 2 0-2
0.3 4.83 5 1.0 4.3 4 2-5
0.7 11.27 11 1.5 6.45 6 5-11
0.85 13.69 14 1.0 4.3 4 11-14
1.0 16.1 16 0.5 1.72 2 14-16
16-20 2 people
Flgure 6.24 Simple'estimationmodel of a 25.000 LOC project.

Planning project staffing. Figure 6.24 illustrates a 25,000 LOC project. The
squared-off curve indicates that people are added to the project in whole units (no
half or quarter people). This curve is for relatively small projects. Different curves
are used for different size projects [Putnam 19921 [F'utnam 19971. This curve is nor-
malized so that the average project effort is 1.0 on the vertical axis and the time t o
reach FOC is 1.0 on the horizontal axis. The shape of the curve will always be as
shown for this project size.
Data from past projects leads to a productivity parameter of 5,144. The TDcalcu-
lation yields 1.34 years or 16.1 months, and the effort is 69.3 staff-months. Given our
cost of $10,000 per staff-month, the total cost of the project is approximately $7 million.
If you replace the normalized numbers on the curve with actual ones, the 1.0 on
the horizontal axis becomes 16.1 months (in this curve and for this size project, the
IOC and FOC are the same). The 1.0 on the vertical axis is effort divided by TDor 4.3
people. The table a t the bottom of the figure shows the conversions for normalizing to
Time actual numbers. The first column is the normalized time numbers. Multiplying each
by 16.1 produces actual time in months, which you then round off to get a practical
number. The next three columns pertain t o manpower. Multiplying the normalized
numbers by 4.3 gives you the actual manpower, which you again round t o whole
numbers (people).The result is that two people will be the staff the first two months,
four people the next three months, six people the next six months, and so on. Two peo-
ple will probably be needed to support the customer for four months after delivery.
158 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

A closer look a t this example shows the dollars and cents value of process im- Figure 6.
provement. The cost ($7million) seems expensive for 25,000 LOC. Start a t total cost basic technb
and trace backward. The cost is a simple multiplication of effort. The biggest con. lems you car
tributor to effort is time raised to the third power. Cut the time and effort by stream. similar t o PE
lining the process and cost will fall dramatically. The time equation has a constant, estimates fo
the LOC, and the productivity parameter. Increase the productivity parameter md past estimat
all the expensive numbers fall. If this rises from 5,144 to 10,000(not that much as Figures 6
this is a nonlinear item), To would fall to 12 months, and effort would fall to 29.3 Figure 6.27 I
staff-months. The cost would be about $3 million instead of $7 million. Thus, a single, parts of the
one-year project would save $4 million. Process improvement is expensive and time The relative
consuming, but as these figures show, it has a definite payoff. fill in the tal
The Rayleigh model delves into more topics than I can discuss here. It lets you
calculate the proper staff build-up rates, peak staff time, defect rates, and so on.
Read more about this model in books and papers by Putnam and Myers. Tens of
years and hundreds of actual projects are the model's foundation. It is not theory. It
works a t work.

6.4.2 PSP's Probe

The Personal Software Process [Humphrey 19951 uses Probe to predict the product's
size and the required build time. In Probe (short for Proxy-Based Estimation), you
substitute experience on similar past products and projects t o predict future ones.
Figure 6.25 shows an overview of the estimating process. You combine the basic
design for the product with historical size data (proxies) to estimate the size of the
new product. The size estimate and historical productiuity data (more proxies) let you
estimate resources, including time. The next step is to put the tasks and times into a
schedule (make schedule). Finally, you execute the plan t o produce the product, feed
back the actual size and time t o the historical databases, and gather metrics. Metrics
are crucial t o the success of the process.

Figure 6.26 0)

Rf
..
C;
L
Make Schedule
c;
I
L
D.
I/(
Execute Plan , Gather Mstrica L
sl
I TC
Pmduct
Figure 6.25 Overview of the PSP planning and estimating process Figure 6.27 CI,
 PLANNING 159

xocess h- Figure 6.26shows the elements of the estimate size step in Figure 6.25.This is the
t total cost basic technique of taking an unsolvable problem and breaking it into smaller prob-
iggest con- lems you can solve. The steps consist of dividing the product into small parts that are
by stream- similar to parts from past projects. You can then use the actual sizes of past parts as
1 constant,
meter and past estimated and actual projects using linear regression.
t much as Figures 6.27and 6.28 give additional task breakdowns in estimating product size.
911 to 29.3 Figure 6.27 shows a table that starts with data on past sofiware. You then categorize
3, a single, parts of the software by function type and list them in the left column of Figure 6.28.
' and time
The relative sizes of these parts form the column heads in Figure 6.27.You c a n then
Win the table with actual numbers from past projects.
t lets you
nd so on.
3. Tens of
Basic Design
theory. It
I
Divide into parts - -

Keep dividing until

1 the answer is Yes
product's Do parts resemble parts
NO

ion), you m lusmrical data?

ones. 1 Yes
:he basic Select similar parts
ze of the from historical database
i) let you
es into a
Estimate size from
uct, feed similar parts
Metrics
1
Sum it up

4
Adjust using
linear regression
Figure 6.26 Overview of the "estimate size* step in Figure 6.25,

Relative Size Very Small Medium Large Very

Small Large
Catego@----..

Calculation 8.3 42.1 75.6 99.6 136.5

Data 7.5 44.3 82.1 102.4 155.2
I/O 6.9 39.6 71.5 107.5 144.5
Logic 11.2 45.2 69.7 95.2 157.6
Setup 7.7 33.6 83.2 93.1 160.2
Text 9.5 51.2 77.9 89.6 141.6

Figure 6.27 Classifying historical data to determine product size.

 160 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

Name Category Relative Lines of Code htul

Size from Historical

Source Code
Table Ira(

Main-mutine Setup Small 42.1

Fileenpen-andrreate UO Medium 71.5 XCi
Percent-remaining Calculation Large 99.6
... ... ... ...
Balancesummary UO Very Lame 144.5 I-

Initial Total Estimated Size: 1,566.6 Lines of Code

*ma
Flgure 6.28 A table for estimating product size.

Cca

The PSP uses lines of code to measure product size. Figure 6.28, a size-estimating
table, shows subroutine categories and sizes in LOC. Many argue that subroutines
are passe in an object-oriented world and that LOC is a bad measure of software size.
I will not debate that here. My advice is to adapt Probe using whatever works-LOC,
function points, number of data-entry screens, pages in a book, slides in a presenta-
tion, object classes, and so on-but be consistent throughout. Here I continue to use
subroutines and LOC, but this is not the only scheme that will work with Probe.
To derive the table in Figure 6.28, you first design the product at a high level to
produce a list of subroutines. You can then categorize each subroutine, decide on its
relative size, and fill in the rightmost column with numbers from the table in Figure
6.27. Sum the rightmost column to get the initial estimate of LOC. The next step,
linear regression, will produce the final estimate.
Figure 6.29 shows the linear regression equations. Most people use a rule of
thumb-add 40 percent to the initial estimate-to get this number. Linear regression
arrives a t a final estimate with more rigor and less subjectivity. Do not be alarmed if
spreadsheets and handheld calculators provide answers in five minutes. Linear re-
gression fits a straight line through data, as shown by the top half of Figure 6.30, a Figure 6.30A
plot of the estimated LOC vs. the actual LOC for five projects. Linear regression
equations not only calculate the equation of the line passing through these points,
but also the actual LOC that corresponds to the estimated LOC on the line. Anyone The final
can draw a line on the graph that seems to fit the points. Linear regression provides the size estir
a line that has the best fit for the points. The bottom half of Figure 6.30 shows the and the actu,
final estimates for several initial estimates. similar t o siz
actual size of

Final Estimated LOC = P. + (Pi* Initial Estimated LOC)

Time 1
Z(Est1mated LOC. Actual LOC,) .n Estimated LOCAvo*Actual LOC,,,
P,= Z
X( Estimated LOC,)'. n*(Estimated LOC,,)* P=
for n prior projects
fi

Po= Actual LOC,,. B, * Estimated LOC.,, Po= Ti,

Figure 6.29 TrOnSfOrmingthe initial estimatedsize to the find estimated size using linear
regression. Figure 6.31 Ca
 PLANNING 161
*lull ux
t

nes of Code

!, a size-estimating
? that subroutines
re of software size, Data
ever works-LOC, Estimated Actual
des in a presenta- 550 675
I continue to use 1100 795
:with Probe. 1500 1450
1750 1200
at a high level to 2100 2315
tine, decide on its
ie table in Figure p a = 0.96
C. The next step, 3! I= -43
Actual LOC = -43 + (0.95)*(EsimakdLOC)
de use a rule of Calculated Values
Linear regression Initial Estimate Final Estimate
not be alarmed if 1000 917
lutes. Linear re- 2000 1877
of Figure 6.30,a Figure 6.30 A graph of linear regression for five projects.
#inearregression
gh these points,
the line. Anyone The final step of Probe is to use linear regression to produce a time estimate from
ression provides the size estimate. As Figure 6.31 shows, the equations for this use the estimated size
' 6.30 shows the and the actual time of past programs. These equations can then be graphed in a way
similar to size estimating. If estimated sizes of past projects are not available, use the
actual size of past projects in these equations.

I Time Estimated = Po+ (p, * M C Estimated)

I
P = x(L0C Estimated, * Time Actual,) .n * LOC Estimated,,. T h e Actual,,,
E[ W C Estimated,)'. n'(WC Estimated,,)*
for n prior projects

Po= Time Actual A v P~ ,* LOC Estimated *"u

ising iineai
Figure 6.31 Calculating estimated time from past project size in Loc
162 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

Probe transforms a seemingly impossible estimating problem into small, possible

I 6.4.4 Judgir
steps. However, it does depend on data from past projects, which is one reason Hum-
phrey teaches the PSP in steps, postponing its introduction until after the student Reviewing an
has completed several projects. Use the PSP or some other means t o begin recording you must revi
size and time data. It will seem like bureaucracy, but it is the only way t o provide the 19961. Figure
visibility you need to estimate and plan future projects. to meet in its I
Probe also transforms a qualitative rule of thumb (like add 40 percent to get a
final estimate) into a quantitative, visible estimate. Because it is visible, people can
work through it, understand it, and improve it. The graphs and equations give form
and discipline t o otherwise fuzzy ideas.
Humphrey created Probe t o work with an individual programmer on one-person 1.
projects (the numbers in examples here are from such projects), but you can easily 2.
extend this technique to multiperson projects. Probe can estimate the size and time 3.
of any task type (the number of slides in a presentation, the time to prepare it; the
number of people to attend a meeting, the length of the meeting, and so on). 4.

5.
6.4.3 A technique for simple estimation
This book is about approaches that work a t work. Sometimes the most powerful ap 6.
proach is also a simple one. I've found value in a straightforward estimation tech-
nique that does not require past data. Instead it uses the idea of a low, high, and I.
most likely estimate for any quantity (size, time, difficulty, and so on) [Putnam 19921. Flgure 6.33 A CI
Figure 6.32 gives the equations for this technique. The first produces an estimate
from a low, high, and most likely ranking. The standard deviation for the estimate
comes from the low and high estimates.
% error indicates the confidence in the estimate on the basis of the standard de-
viation and estimate. If this value is 20 percent or higher, the estimate needs more
work. A large difference between high and low signifies too many unknowns. Break
the item being estimated into smaller, more manageable, less risky parts and derive
estimates for the parts. Repeat this process until the percentage of error is near 10
percent.
The final three equations show how t o combine estimates for many parts. This
gives a final estimate for an entire project as well as the percentage of error. Again, if
the percentage of error is too high, rework the estimate.
This simple, quick, and effective estimating method works well if past data is not
available. However, laziness should not be your motivation for using it if such data is
available.

Estimate = L o w + 4'Most Likely + Hieh Total Estimate = ZEstimate

6

Standard Deviation = High. Low Total Standard =Square rwt@ (Standard Deviation))
6 Deviation

% Error = Standard Deviation X Error Total =Total Standard Deviation

Estimate Total Estimate
Figure 6.32 Simple estimation. Figure 6.34An (
 PLANNING 163

small, possible 6.4.4 Judging an estimate

ie reason Hum-
ter the student Reviewing an estimate is a necessary part of planning. If the estimate is insufficient,
begin recording you must revise it. Figure 6.33 gives a checklist for reviewing estimates [ P a r k June
I to provide the 19961. Figure 6.34 [ P a r k J u l y 19961 gives a list that each organization should strive
to meet in its estimating efforts.
w e n t t o get a
ble, people c a n
dons give form

on one-person 1. Are the objectives of the estimates clear a n d correct?

vou c a n easily 2. Has the t a s k been appropriately sized?
size and time 3. Are the estimated cost and schedule consistent with
irepare it; the demonstrated accomplishments on o t h e r projects?
on). 4. Have the factors that affect the estimate been
identified a n d explained?
5. Have s t e p s been taken to ensure the integrity of the
estimating process?
powerful ap- 6. Is the organization's historical evidence capable of
imation t e c h - supporting a reliable estimate?
'w, high, and 7. Has the situation changed since the estimate was prepared?
utnam 19921. Figure 6.33 A checklist for reviewing an estimate.
an estimate
the estimate

rtandard de-
Six Requisites for Reliable Estimating Procedures
needs m o r e
1. A corporate memory (historical database).
3wns. Break 2. Structured processes for estimating product size and reuse.
s a n d derive 3. Mechanisms for extrapolating from demonstrated accomplishments
r is near 10 on past projects.
4. Audit trails (values for the cost model parameters used to produce
each estimate are recorded and explained).
parts. !Phis 5. Integrity in dealing with dictated costs and schedules (imposed
or. Again, if answers are acceptable only when legitimate design-to-cost or
build-to-cost processes are followed).
d a t a is not 6 . Date collection and feedback processes that foster capturing and
correctly interpreting data from work performed).
iuch d a t a is
Seven Indicators of Estimating Capability
1. Management acknowledges its responsibility for developing and
sustaining an estimation capability.
2. The estimating function is supported by a budget and funds.
3. Estimators have been equipped with the tools and training needed
for reliable estimating.
4. The people assigned as estimators are experienced and capable.
Deviation)') 5. Recognition and career paths exist such that qualified people want
to serve as estimators.
6. Estimators work with process improvement teams to quantify and
track progress in software process improvement.
7. The estimating capability of the organization is quantified, tracked,
and evaluated.
Flgure 6.34 An organizational and capability checklist for reliable estimating.
164 THE SOFTWARE PROJECT MANAGER’S HANDBOOK

6.4.5 Tailoring techniques to the process model

Each project will use the basic task network, cards on the wall, and estimating tech-
niques, but the order, time, and way in which they are used will vary across projects.
Most of the variance stems from the process model being used.
In the next sections I give examples of how you can tailor the use of these tech-
niques to the particular process model. Each example revolves around a software
company that employs 10 people. It has been doing banking applications for the last
decade and has changed as the computing industry has changed (mainframes to net
works of PCs, text-based interaction to GUIs). A primary customer is 80 percent of ib
business. The software company wants to grow by serving new customers. Assume
that in each case you are the project manager.

Waterfall project. Your primary customer wants a new report capability. This is
similar t o many of the projects you’ve done in the past. You and your customer know
the product well, so you select the straight waterfall process.
Use the basic techniques in a straightforward manner. List the deliverables and
create a work breakdown structure (WBS) for each (analysis, high-level design, low-
level design, build, test, and integrate and test). Put these task cards on a wall in an
initial task network. Hold a half-day cards-on-the-wall session to refine the task net- Flgure 6.35 P
work. Use Probe to estimate product size for each task and the time required to build
it. Sum these to get a total for the project. Use the Rayleigh model to check the va-
lidity of your estimate. If the de
diagram in
Execute the plan. This is a simple process for a simple product
grate the ri
tions as twc
Evolutionary project. A small, young accounting firm, that heard about you t o Probe an
through your primary customer, asks you to develop a complete accounting system Execute
for their business. Your company is not familiar with accounting businesses and the Determine
accounting firm is not sure what they want and need. with the cu
This project requires an evolutionary process. Figure 6.35 shows three evolution- they so dis:
ary plans. The top plan is the generic view of evolutionary projects using a series of tions and n
V-charts. If the si
The next plan is the first plan for the project. You must work down to the x to nal limit. ‘I
learn the customer’s requirements. You can then design, build, test, and integrate techniques
the requirements in which the customer has the most confidence. That brings you to This WI
the second x , where work stops. The next area of the plan is unknown. At the second ter 7 for m
x , everyone will know more about the product, and work will continue with greater
basics rem
confidence. The endpoint of the project (far right) is known. Work will stop at that chart and 1
time or when the allotted funds run out.
Work out the details of this first plan. Treat this first, short evolution as a com- Spiral pr
plete project. List the deliverables, make a WBS, lay out the initial task network, business b
hold a cards-on-the-wall session, use Probe on each task, and check it all with the ties. At lei
Rayleigh model. you are UI
Execute the plan until you reach the second x . At this point everyone is smarter, business r
and the project is far less risky. Calculate the time and money left to go before will gain I
reaching the final limit. Decide if the project should continue. Maybe this is just not ness t o of
going t o work, or maybe the customer knows enough now to buy some shrink- wasted ti1
wrapped applications. proach thi
 PLANNING 165

Generic
Evolutions
1 estimating tech-
Plan 4 1.
r

Y across projects.

me of these tech-
,ound a software
tions for the last
iinframes to net-
80 percent of its
'\
itomers. Assume \ lJnbowvn

pability. This is
' customer know
Seeand - ,-
man
',
leliverables and I\, past New Plan Unknown
'vel design, low-
on a wall in an
"$,, /i" \,\ ,/ \\\ \ ~r ~ /
ne the task net-
Figure 6.35 Planning an evolutionary project.
equired to build
'0check the va-
If the decision is t o continue, plan the next two evolutions. The second plan (last
diagram in Figure 6.35)shows this. Each evolution will design, build, test, and inte-
grate the requirements with the highest level of confidence. Treat these two evolu-
tions as two complete projects. Start with the deliverables and a WBS and go through
ard about you to Probe and the Rayleigh model.
mnting system
nesses and the Execute these two evolutions. This brings you to the third x in the second plan.
Determine the time and money left before the final limit. Is the customer satisfied
with the current product? Are they so happy they want to extend the final limit? Are
iree evolution- they so disappointed they want to quit now and cut their losses? Answer these ques-
;ing a series of tions and make a decision.
If the situation is satisfactory, plan evolutions that will take the project to the fi-
wn to the x t o nal limit. Treat each evolution as a project and reapply the planning and estimation
and integrate techniques.
;brings you to
At the second This was a risky project with many unknowns-many invisible items. (See Chap-
2 with greater
ter 7 for more details on managing risky projects.) A disciplined application of project
I1 stop a t that basics removed the unknowns one at a time. The invisible became visible. The V-
chart and the planning and estimating techniques let you work through the difficulties.
don as a com- Spiral project. A local, well-established printing company wants to expand their
task network, business by adding image processing, photographic processing, and graphics capabili-
t all with the ties. At least they think this is what they want. They are somewhat uncertain, and
you are uncertain about attempting the work. Your people know neither the printing
ie is smarter, business nor image and photographic processing. However, if this works, the printers
to go before will gain market share and your company will have a new, very popular line of busi-
iis is just not ness to offer customers. On the other hand, if it does not work, everyone will have
some shrink- wasted time and money and damaged their reputation. The two of you agree to ap-
proach this as partners and share costs.
166 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

This is a risky project that could fail at several distinct points. The spiral process Execute tl
is the best choice here because, as described below, it contains plans for several next cycle an
points a t which management can decide t o quit. Figure 6.36 shows a spiral for this complete prc
project (see also the discussion of Figures 6.7 through 6.9). This is a generic spiral t h i s plan anc
except for the products given in the third or lower right quadrant. These are the de- acceptable? I
sired products of each cycle. The first product is a concept of the final system. If the mates? Do y'
first spiral can produce a concept (every product in a spiral is a big iD, the project can suing? If it it
move on and your task becomes filling in the blanks. If not, stop the project. The see. the experienc
ond spiral attempts t o find algorithms for image and photographic processing. If you All the re
can find these algorithms, you will attempt t o write processing subroutines in the suing cycle; 1
next cycle. If the processing works, the next cycle will explore how the users will use
The proje
the system. Its goal is to determine the type of user interface required. If everything
the customei
works in the first four cycles, the fifth cycle will be a straight waterfall process to
middle. Thai
build the system.
not a disaste
Begin planning by sketching the spiral. Estimate a time period and cost for each
cycle. This is a rough estimate and gives everyone an idea of what the entire project
might cost. Plan the first cycle as if it were a complete project whose deliverable is a 6.5 Con
system concept. Build a WBS and go through all the steps as in the previous exam-
ples. Limit the product so that the cycle will end before you spend too much time and The project 1
money. planning, a~
Project plan
ments and d
There isn
other than t
Objectives, Evaluate Risks ter 2 and AI
Constraints, for Each Alternative
for that base
Alternatives /' That the
/' the project,
maintaining
the baseline
CM plan.
The proj
work. The p
of products
the CM pla
sound judg
completed, I
daily. It is e
ect, Project
do so have I
The CM
practical m
longer than
system /
1 ies of the pl
Plan the Validat/Review Risks
Next Cycle
Commit or Stop
Build the Product
1 6.6 Stai
of this Cycle
i All-in-one I
Figure 6.36 Planningwith a spiral process
understand
 PLANNING 167

ts. The spiral process Execute the first cycle as planned. At the end of it, the fourth quadrant, plan the
ns plans for several next cycle and update the rough plan for the entire spiral. Treat the next cycle as a
ows a spiral for this complete project and work through all the planning and estimating steps. Review
s is a generic spiral this plan and the history of the first cycle in detail. Was the product of the first cycle
It. These are the de- acceptable? How close were the actual time and expense of the first cycle to the esti-
’ final system. If the mates? Do you and your customer think this business opportunity is still worth pur-
g if), the project can suing? If it is, continue to the next cycle. If not, quit now. Everyone is smarter from
the project. The sec- the experience and no one has wasted too much time and money.
ic processing. If you
All the remaining cycles are like the first. Execute them as planned; plan the en-
subroutines in the
suing cycle; review everything, and decide whether to continue or stop.
v the users will use
iired. If everything The project may reach the end of the final cycle and deliver the new capabilities t o
raterfall process to the customer. It is entirely possible that a spiral project will stop somewhere in the
middle. That is its nature. If the project stops, however, it will be because of a plan,
not a disaster.
1 and cost for each
! the entire project
Ise deliverable is a
he previous exam-
6.5 Configuration management
.oo much time and The project plan belongs in the functional baseline. It fits here because requirements,
planning, and risk management revolve around each other in timing and people.
Project planning itself, however, does not fall neatly into one baseline like require-
ments and design because planning crosses many baselines.
There isn’t much t o say about putting the project plan into the functional baseline
other than to do it, following the process set forth in the project’s CM plan (see Chap-
ter 2 and Appendix B). The functional baseline and the Configuration Control Board
ative for that baseline already exist; as project manager, you need only initiate action.
That there is not much to say illustrates the simple power of CM. At this point in
the project, the project manager does not have to search for people interested in
maintaining the functional baseline. They are already designated in the CM plan as
the baseline’s CCB. All that remains to bring the product to the people is to follow the
CM plan.
The project plan contains information that changes often, such as the task net-
work. The project manager will need to reestimate the duration of tasks and the size
of products a t regular intervals as well as rearrange tasks in the network. However,
the CM plan is designed so that the project manager and the CCB must exercise
sound judgment in how they incorporate changes to the project plan. As tasks are
completed, some on time, others early, and others late, the schedule changes-almost
daily. It is easy to enter schedule changes into a commercial product (Microsoft Proj-
ect, Project Scheduler, and others). It is not easy to track every change. Attempts to
do so have always frustrated me.
The CM plan empowers the CCB to control their baseline the way they see fit. A
practical method is to put the project plan into the baseline monthly for projects
longer than a year (twice monthly for shorter projects). The CM staff must keep cop-
ies of the plan for each month.

6.6 Standards
All-in-one military and commercial standards are available to help project managers
understand the necessary tasks. An IEEE standard can help in documentation.