This article is the third in a series of related articles
with tips and tricks on producing a schedule for your project. The first two
entitled "Creating the WBS" and "Scheduling
Relationships” describe how to produce your Work Breakdown Structure (WBS) and
scheduling networks. The ultimate objective of these two exercises is to
produce the project schedule, but before you can schedule the project work you
first need to estimate the effort required to perform the tasks and activities
in your WBS, then estimate duration based on the number of resources assigned
to the task or activity.
This article focuses on tips and tricks for effort
estimation, load leveling, and working within budget and schedule restraints
but the end goal is the production of the project schedule which requires the
WBS and identification of relationships. If you haven’t already done so, I
encourage you to read the first two articles in this series. This article also
makes reference to MS Project because that is the scheduling tool that this
author is familiar with. I’m not trying to endorse MS Project here, there are
several excellent tools available for scheduling such as Primavera. If you
happen to use a tool other than MS Project, you’ll have to translate the MS
Project features and functions I refer to into the equivalent features and
This article builds on the best practices espoused in the
Project Management Body of Knowledge (PMBOK®). For readers who have acquired their PMP® certification, much of what I
describe here will be familiar. For those of you who haven’t, there are many
excellent PMP Courses available that provide you with PMP® exam preparation training.
There are many estimation methods that can be used for
estimating software development effort. Googling the keywords: "software
development effort estimation” produced 534,000 results for me. An increasingly
valuable reference source for this subject is Wikipedia. I’m going to restrict
the methods I discuss to 3 for this article, and those 3 are:
Analogous - uses historical information
Parametric - uses estimation tools
Top-down - uses project constraint information
There are different tools that support each of these different
types and your choice of method will be determined by the tools available to
you, to a large extent.
Analogous estimation depends on the availability of
historical information and is generally the most accurate of the methods. Even
if you don’t have this information available to your project, you should
consider starting your knowledge database to capture the information from your
project so that it is available to future projects. The information you’ll need
to capture will include: the number of lines of code per estimated package, the
programming language used, the complexity of the package, the skill level of
the programmer(s), and the effort in hours or days to develop the package. The
analogous method will usually be the most accurate because it takes into
account a number of variables that won’t change across projects such as:
software tools, databases, source libraries, and the project team. The method
that relies on industry information can’t take these factors into account.
Parametric estimation is usually used for construction
projects where there there is a plentiful supply of that information. Software
projects don’t have that kind of information available to them and have to rely
on tools to make up for this deficiency. Two of the tools most commonly used
are Function Point Analysis and COCOMO (COnstructive COst MOdel).
Function point analysis (FPA) relies on the application
being broken down into small components which are assigned to one of 5
catagories: External Input (EI), External Outputs (EO), Internal Queries (IQ),
Internal Logical Files (ILF), and External Interface Files (EIF). These are
then assigned a complexity value of high, medium, and low depending on the complexity
of the component. Complexity is determined by the number of file types
referenced, number of record element types, and number of data element types.
The formulas used by function point analysis are quite complex and I would
advise taking training in the method before attempting to use it. There are
also IFPUGs (International Function Point User Group) that you can join to
access the experience of other practitioners.
COCOMO also uses formulas to determine effort and cost.
While Function Point Analysis uses a function point as a base, COCOMO uses the
number of lines of code as a base. I would say that you should not attempt to
use COCOMO if you are attempting to estimate a web site development project.
The variances between the effort required for developing 1 line of HTML code
when using a tool such as Dreamweaver and no tool is great. There is also a
great degree of variance between the number of lines of HTML generated
depending on the web development tool used. COCOMO uses modifiers such as
required reliability, performance constraints, memory constraints, development
tools, and programmer skill sets to weight the lines of code estimated. These
modifiers are numerous and using them should not be attempted without some
Both FPA and COCOMO rely on a baseline to produce an
estimate. FPA uses a baseline unit of effort for each function point score
(e.g. if the baseline is 1 hour and the FPA score for the point is 10, the
estimate is 10 hours). COCOMO requires an estimate of the number of lines of
code and a baseline unit of effort for 1 line of code. COCOMO actually divides
programmer skills into 5 different categories with an adjustment factor for
each. Making effective use of each method will require some intensive
These two methods may be used for both bottom-up and
top-down estimation, but will yield more accurate results when each piece of
the application or web site is examined on its own. The one exception to this
rule is when you use historical information to do your estimation and your
project is very similar to the one you use as an estimation base.
Effort estimation will be at the individual work package
level, or above so the effort must be divided among its components until the
individual activities have an effort estimation. There may be a simple one to
one relationship between activities and work packages, or one work package may
have several activities. You will need to determine the ratio in which the
effort will be split to accurately assign effort to each activity where a many
to one relationship exists. If you encounter problems in determining the effort
required for individual activities you may want to eliminate the activities
from the WBS and manage the work at the work package level.
A top down approach is most useful when you are given
project constraints for budget and/or schedule. A budget only constraint means
that you can only develop the features and functions that fit within that
budget. A schedule only constraint means that you can develop as many features
and functions as can be completed by the hard stop set for the project. This
means that you must assign as many resources as necessary to a task so it will
complete on time. I have never encountered a project without some form of
budget cap, whether the cap was expressed in monetary terms or resource terms.
Most projects are scalable in that you can apportion your
budget between design, build, and test (Quality Assurance) in a fixed
proportion. The proportion is likely to change depending on the software system
you’re building, the tools you use to build it, and the people who are building
it. For most cases the build portion of the project will consume more resources
than either the design or test portions. Try a default split of 25% design, 50%
build, and 25% test if you have no other information to go by. Factors that
will tend to drive design costs up are complex and intricate user interfaces,
and unclear or ambiguous requirements. Factors that will drive build costs up
are system complexity, component integration, lack of automated test tools, and
lack of compile and system test tools. Factors that will drive up QA costs are
the unavailability of test data, lack of automated test tools, and lack of
adequate testing in the build phase. One way to reduce QA costs is rigorous User
Acceptance Testing. Software development projects always have trouble eliciting
users for testing so here’s a tip that may help: make user training contingent
on, or part of, user acceptance testing.
Assigning effort to the child levels of each of design,
build, and test is done the same way as described for Parametric methods. This
requires you to determine the ratio which should be used for assigning effort
to each of the individual deliverables in the WBS. From this point, you will
determine a ratio for assigning the budget to each of the major work packages
in the deliverable and so on, until you have assigned an effort value to the
lowest level of your WBS.
Duration estimation occurs when resources are assigned to
the activities in the schedule. An activity which requires 10 days of effort
will last 10 days when one programmer is assigned to it, or 5 days if 2 are
assigned to it. The resource assignments will be constrained by the resource pool
available to the project, the skill sets of that pool, and any schedule or
budget constraints placed on the project. You should attempt to assign
resources to the project activities so that the resources are engaged and leave
the project in an orderly fashion. This means that you don’t bring in 20 C++
programmers for 2 days, dismiss them for 3 and then re-engage them for 1 day.
MS Project has a feature which allows you to manage resource
pools and even supports dividing the pool up into groups based on skill sets.
Define your resources in MS Project, then assign resources from that pool to
the various activities in your schedule. Software Development project managers
frequently have to contend with resources who are "part time” on their project.
You must be realistic and conservative when establishing the percentage of
their time that will be devoted to your project when they are working two or
more assignments in parallel. Use the MS Project resource calendar to block out
the times that a resource is unavailable to the project when a resource will be
devoting 100% of their time to your project for one period and 100% of their
time to another assignment for another period.
Identify all the holidays the project will span and mark
these in the project calendar. You’ll have to mark holidays in individual
resource calendars where your team is geographically dispersed and enjoys
different holidays. Mark any training that is planned as part of the project,
or was planned outside the project in the individual resource calendars of the
team members receiving the training.
Assign resources to activities so that the project completes
as soon as possible. The project’s Critical Path will determine the date the
project completes and MS Project will automatically reflect the length of the
Critical Path once you’ve created your networks properly.
Budget and Schedule Reconciliation
It is common to encounter a clash between the budget cap set
for a software development project and the requirements for the project. There
are a finite number of ways which can be used to reconcile differences between
the budget cap and the calculated effort/cost of the project. One method is to
substitute automation tools for effort where these tools would achieve a
reduction in effort. The advantage of the automated tool is that its benefit
will live on long after your project is completed.
Quality Assurance test costs can be reduced by engaging the
user community in testing and having them follow the test scenarios created by
the QA team. User Acceptance Testers come from the user community and normally
their cost will not be allocated to the project.
Increasing the money you spend on resources is another
method of reducing the budget, believe it or not. The COCOMO tool assigns a
factor of .71 to a senior programmer and a factor of 1.46 to a junior one. It
is highly unlikely that the senior programmer will make over twice the wage of
the junior one, and in my experience the difference in their effectiveness can
be greater than 2 to 1.
The last resort is to trim work from the schedule. This may
be done without having to drop any of the requirements, but that is highly
unlikely. Beware of shortcuts such as eliminating testing, design reviews, code
walkthroughs, etc. Eliminating effort spent in design and testing will
inevitably lead to increased costs.
Look for less costly ways of delivering the same
functionality first. Customers will always choose a Cadillac approach to
building a log in screen, but may settle for a Chevy, or even a Volkswagen
approach when confronted with the cost. Eliminating requirements will be your
next step. Prioritizing the requirements in your Business Requirements Document
will make discussions around which requirements to drop much simpler. Start by
eliminating those requirements which have a high effort estimation and a low
Project managers who are performing the project for an
external customer will not have the ability to eliminate any deliverables from
the project. Project managers who are delivering a project for an internal client
will have more leeway. Eliminating deliverables is the last resort and should
be done based on the cost and business impact of the deliverable.
Scheduling is the next constraint to consider. Since
schedule and budget are closely related in a software project, you should have
a schedule that is close to the set delivery date once the budget cap has been
met but may require some fine tuning. Your Critical Path is the first place to
look for savings. Can you assign someone working on a task not on the critical
path to one on the path for a period of time? Can you swap a senior programmer
working on a non-Critical Path activity for a junior one who is working on the
Critical Path? Shorten the Critical Path as much as possible using these
After you have assigned your resources in the most efficient
manner possible, you still may not be able to meet the deadline. You will need
to consider compressing the schedule in that case. Look for dependancies
defined as "hard” which are not really hard. Typical of these will be the need
of an approved Detail Design Document before beginning coding. "Crash” the
schedule where this makes sense to do.
The next steps are the same as the ones for budget
reduction: feature simplification, requirement elimination, and finally as a
last resort, deliverable elimination. The good news here is that the budget
will get reduced as a result!
Most of us tend to be linear thinkers, that is we tend to
concentrate on one task at a time and MS Project supports this approach very
well. Unfortunately, in the process of shortening the timelines for the project
we will probably overlook the definition of a reasonable work week for every
resource on the project. MS Project provides a feature they call the resource
histogram to check for this. Run this feature after your schedule has been
updated to meet budget and schedule constraints.
You’ll have to work within the existing constraints to level
the load. Do this by changing work assignments such that everyone on the team
is working 40 hours a week (or whatever constitutes a standard work week for
your project) for the course of their planned assignment to the project. Assign
more than one person to a task which has a resource working on it 80 hours a
week. Look for ways of shortening the Critical Path with resources who are idled
for portions of the schedule.
Load leveling using the MS Project feature is a tricky and
time consuming task requiring many iterations. Leveling each resource in
isolation may work for you if you remember that the leveled resource cannot be
assigned anything else in the plan. You should also explore the option of
overtime if you budget allows this.
You should always strive for a schedule that delivers the
project ahead of any dictated delivery dates. There are two ways to do this.
One is to simply use an artificial final date which provides the buffer. Let’s
say your mandated delivery date for the project is July 31st, 2010.
Add a buffer of one month to your schedule by using June 30th as
your completion date and schedule your project accordingly. The other way is to
use the mandated date as the final date and to buffer each of the activities in
the Critical Path. Let’s say an activity is scheduled to last 20 days in your
original estimate and that activity is on the Critical Path. Add a 5 day (or
25%) buffer to that activity and do the same for each activity on the Critical
Path. The advantage of doing this is that it allows you to manage the buffer at
a much more granular level.
The schedule you derive from performing these exercises is a
project baseline. You should have this schedule approved by your project
sponsors along with your other plans. You probably don’t want to ask your
sponsors to review the schedule item by item, but should at least have them
review the major milestones and deliverables. Encourage them to review the
schedule after approval and provide it in the form of an HTML file or Excel
spreadsheet so that they can view it.
schedule is your best resource for monitoring and controlling your project.
Don’t invest all the time and effort to produce a brilliant plan and then allow
it to degrade due to a failure to keep it up to date. Every time a team member
identifies a better way of doing something, every time a team member completes
a task, update your project schedule. All the time you invest in the creation
and maintenance of an accurate project schedule will be rewarded by your
ability to provide stakeholders with accurate information and a project that
delivers the goods on time.
The tips and tricks described in this article
implement some of the best practices promoted by the PMI (Project Management
Institute). These are taught in most PMP® courses
and other PMP® exam preparation training products. If you haven't
been certified as a PMP® (Project Management Professional) by the
PMI and would like to learn more about certification, visit the three O Project
Solutions website at: http://threeo.ca/pmpcertifications29.php.
three O Project Solutions also offers a downloadable software based training
tool that has prepared project managers around the world to pass their
certification exams. For more information about this product, AceIt, visit the
three O website at: http://threeo.ca/aceit-features-c1288.php.