Creating the Project Plan

January 2001

Part 4 of 4: It's easy to forget tasks or incorrectly allocate resources,

even with a correct estimate of effort and time.
by William H. Roetzheim
One of the most difficult tasks for a project manager is creating a baseline that will be used to
manage a project's development effort. Even with a correct estimate of effort and time, it's
easy to forget tasks, incorrectly allocate effort among tasks or fail to allot enough resources
for maintenance. Software estimating is a science that can be learned; it is possible to
accurately and consistently estimate development costs and schedules for a wide range of
projects, then quickly create a project plan. These articles have provided you the tools you
need to understand step-by-step approaches to estimating the cost and schedule for your
projects.
In the first article, "Estimating Software Costs" (Project & Process Management, Oct. 2000), I
covered the various methods of estimating the size of a program (called program volume). I
discussed the traditional measures of Lines of Code and Function Points, in addition to
introducing other approaches, and, finally, I revealed how to prepare a preliminary, unadjusted
estimate using that information. In "Project Cost Adjustments" (Project & Process
Management, Nov. 2000), I reviewed the concept of project cost adjustments for variations in
the project environment and illustrated how to create an accurate estimate of the time and
cost required to develop a new application. "Calculating for Reuse" (Project & Process
Management, Dec. 2000) explained how to quantify the impact of software reuse and
commercial components and libraries on your estimate. Finally, this article describes how you
can use your new insight into project cost and schedule to create a complete project plan
The
Work
Breakdown
Structure
The most fundamental building block of a project plan is the work breakdown structure (WBS).
The WBS contains a list of tasks to be accomplished, and you can implement a template WBS
in a spreadsheet as a list of task names, task percentages of effort and task descriptions. A
simple WBS template applicable for many e-commerce jobs is recreated in Table 1.
Once you've determined the correct total effort for the job using the approach and information
described in the first three articles in this series, you can use the percent of effort to quickly
and easily allocate that effort among all of the tasks in your WBS.
The
Deliverable
On most projects, you will be required to create technical documentation.

Plan

Typically, this facilitates communication during development, assists in maintenance and

provides milestones for payment.
The first step is to create another template, this time of document titles and descriptions.
Templates of documentation are often referred to as standards; however, we can go beyond
this initial step. It's valuable to include an estimate of the page count for each document in
your project plan. This information helps set client expectations, defines the document scope
for the developers who will write the documentation and acts as an estimate of review time.
I've found that the correct number of pages of documentation can be predicted using the staff
months of development effort as the input. This is accomplished using the following formula:

Pages = A * B (Person Months)

To apply this formula, you raise the person months of effort to a variable (C), multiply the
results times another variable (B), then add a third variable (A).
Table 2 contains a sample deliverable planning standard applicable for many e-commerce
development projects.
Using the standard, illustrated in Table 2, let's calculate the estimated page count for Software
Design Description (SDD) on a 50 person month of effort project.
Begin by noticing that the values for A, B and C are 0.00, 8.00 and 0.91 respectively. The
calculation is as follows:
Pages = A + B (Effort) = 0 + 8 (500.91) = 8 * 35 = 280 pages
Estimating
Maintenance
Effort
It's often necessary to estimate maintenance effort as part of your planning process. You may
need to plan for an adequate maintenance staff, or you may need to provide a warranty on the
software. Both tasks require you to estimate the effort required to provide these services.
First and foremost, you must ensure that you share a common understanding of maintenance
work with your customer. At the CostXpert Group, we divide maintenance activities into three
categories: corrective, adaptive and perfective. Standard bug fixes are considered corrective
maintenance, while adaptive fixes involve modifications to the software required by such
changes in the operating environment as database or operating system upgrades, compiler
version changes and so on.
Perfective maintenance is Figure 1. Distribution of Maintenance Effort
the most complex, in that
it involves changing the
code to allow the software
to
meet
the
same
requirement
but in
a
significantly
more
acceptable manner. The
largest
example
of
perfective maintenance is
modifications of the code
to improve performance in
trouble spots. Note that
not all changes to the code The appropriate distribution of maintenance effort based on
to add new functionality
research by Capers Jones (Estimating Software Costs,
are
considered
McGraw-Hill, 1998).
maintenance, nor are any
changes that are based strictly on user preference.
Figure 1 shows the approximate distribution of maintenance effort based on one study by
Capers Jones (see Estimating Software Costs, McGraw Hill 1998). Table 3 also illustrates the
proper categorization of each maintenance activity based on the approach detailed in this
series.
I've found that steady state maintenance annual effort is proportionate to development effort
(this conclusion was initially proposed by Barry Boehm, then confirmed by numerous
researchers). The range varies between 3 and 20 percent of development effort. The vast
majority of projects fall in the more narrow range of 12 to 17 percent of original effort.

For example, suppose you have a project that requires 50 person months of development
effort. You estimate that the maintenance effort will be 15 percent. The annual budget for
maintenance then needs to be 50 * .15, or 7.5 person months of effort.
I qualified this statement by saying "the steady state maintenance." At the CostXpert Group,
we've found that it takes four years of maintenance following delivery to reach the steady
state for a typical system. During this period, the maintenance effort will be greater than the
steady state effort. The optimum maintenance effort actually drops off exponentially from a
value roughly twice the steady state value immediately following delivery to the steady state
value at the start of the fourth year. During this time, the additional effort is spent on
corrective and perfective maintenance.
This concludes this series, which has covered all aspects of developing a software project
baseline. Though everyone has a favorite theory as to why software failures occur, my
experience and work while with the Mitre Corporation, the Cost Xpert Group and Booz, Allen &
Hamilton has taught me that more projects are doomed by poor cost and schedule estimates
than by technical, political or team problems. Capers Jones's extensive research, found in his
book Estimating Software Costs, makes a similar claim. It's no surprise, therefore, that so few
companies and individuals understand that software estimating is not just an art, but a science
that can be learned.
Table 1. A Simple Work Breakdown Structure Template
Task
Project
Management

Percent

Description

Planning and
10

Project estimating, planning and

risk management.

Define Business Strategy

Define the business strategy and

document it in a creative
fashion.

Define Marketing Strategy

Define the marketing strategy

and document it a creative
fashion.

Define Requirements

Define system requirements in

both
documentation
and
prototype form, plus define a
production or style guide.

Design Site

30

Prepare functional specifications,

technical
specifications,
site
architecture and test plan.

Build Site

19

Build the site, including the front

end, middle-tier, agents and
interfaces.

Test Site

19

Test the site, both at the unit

level and the integration level.

Deploy Site

10

Deploy
the
site,
including
acceptance testing and user
documentation when required.

Table 2. A Sample Deliverable Planning Standard

Deliverable

Software Development5.00
Document Plan (SDP)

Description

0.08

0.91

Describes a developers plans for

conducting
a
software
development effort. This is

expressed in the form of a

project
Gantt
chart,
supplemented by one or more
Project Work Orders covering the
various phases of work.
Strategic Brief

Creative Brief

2.00

2.00

0.90

0.90

0.91

Documents strategic business

objectives, measures of business
success,
stakeholders
and
stakeholder objectives.

0.91

Defines
target
audience(s),
objectives, market and product
positioning,
branding
and
relationship
between
Web
strategy and overall market
strategy.

Software Requirements
3.00
Specification (SRS)

1.21

0.91

Specifies the requirements for a

computer program and the
methods to be used to ensure
that each requirement has been
met.

Prototype

1.00

0.00

1.00

System prototype.

Functional Specifications 0.00

4.00

0.91

Defines back-end and middle-tier

functional requirements from a
business perspective.

Technical Brief

4.00

0.91

Defines the technical details of

the system design, including
object design.

0.91

Describes the site architecture

with sufficient detail to allow the
site
to
be
configured
for
deployment.

0.91

Describes plans for acceptance

testing of a computer program.
It describes the software test
enviroment, identifies the tests
to be performed and provides
schedules for test activities.

8.00

0.91

Describes
the
program-wide
design decisions, the software
architectural design and the
detailed
design
needed
to
implement the software. It
includes the middle-tier object
and application server design,
pseudocode
for
all
key
algorithms and business rules,
field mappings for all screens,
sort,
select
and
display
requirements for reports, and
detailed
data
format
specifications for all interfaces.

2.27

0.91

Site architecture

0.00

0.00

Software Test Plan (STP)5.00

Software
Design
0.00
Description (SDD)

Software
Description (STD)

Test5.00

2.14

0.12

Describes the test preparations,

test cases and test procedures
to
be
used
to
perform
acceptance
testing
of
a

computer program.

Software
(SUM)

User

Manual

15.0

2.10

0.91

Instructs a hands-on software

user how to install and use a
computer program. It includes a
tutorial
describing
how
to
accomplish specific user work
tasks identified as Operational
Scenarios
in
the
Software
Requirements, Specification, and
it also offers a comprehensive
reference to all screens, reports
and menu choices.

Table 3. Proper Categorization of Maintenance

Category on figure

Maintenance Category

Emergency program fixes

Corrective

Routine debugging

Corrective

Accommodate changes to input data filesAdaptive

Accommodate changes
operating system

to

hardware

Adaptive

Enhancements for users

Not included as maintenance

Improve documentation

Not included as maintenance

Improve code efficiency

Perfective

Other

Other