work breakdown structure (WBS) is a key project deliverable that organizes the
team’s work into manageable sections. The Project Management Body of Knowledge
(PMBOK) defines the work breakdown structure as a “deliverable oriented
hierarchical decomposition of the work to be executed by the project
team.” The work breakdown structure visually defines the scope into
manageable chunks that a project team can understand, as each level of the work
breakdown structure provides further definition and detail.
What’s a Work Breakdown Structure?
fixture in classic project management methodology and systems engineering, the
WBS is a method that breaks a project down into a hierarchy of deliverables,
tasks, and subtasks. It’s a helpful tool that defines a detailed cost or time
estimate and provides guidance for schedule development and control.
by using a WBS, you should be able to take a top-down look at your project and
break it into the tasks and subtasks that will get you to completion. By
breaking your project down into tasks, you’ll find that you can start to see
the forest through the trees. It’s a simple, yet methodical way of organizing
and understanding your project scope in smaller, manageable components.
Why Use a Work Breakdown Structure?
a WBS for any plan or set of tasks helps you get granular about the work that
needs to be done on any given project. If you estimate your projects based on
units—whether it be weeks, days, or hours—using a WBS will help you understand
very quickly if your estimate will exceed the intended budget or deadline.
How to Use a Work Breakdown Structure?
you’re comfortable with the overall process of creating a WBS, you will be able
to adapt the practice to any project—from moving your house to building a
complex database with 75 offshore teams. That’s right, the WBS will be your friend.
But before you go off and start creating these documents (and on-point
estimates), let’s walk through a process that will help ensure a solid,
Step 1: List High-level Deliverables
you’ve got a project scope, you’re going to find getting started on your WBS
very easy. If you don’t have a scope, you better turn right around and talk to
your clients or boss about the scope. Starting any project without a scope is
dangerous, because it sets the stage for what will be delivered and when.First,
sit down with your team and list out what will need to be delivered in order to
meet your project’s end goal. For instance, if you are building a new website,
you might deliver:
sure you’re being very inclusive of all tasks, and that you’re not leaving
anything out. For instance, if you’re working on a website redesign project,
have you accounted for content? If you miss a deliverable now, you will regret
it. So, listing things out as a team is very helpful, as it ensures that all of
your bases are covered. A team conversation will also help you to set
expectations for who will be responsible for deliverables and tasks, all while
engaging the team on the overall process of the project. See, you’re winning
Step 2: Think About Tasks
you’ve identified the high level deliverables for your project, you’re going to
take a deeper look into what actually needs to be done within each one of them
individually. This isn’t just a simple
exercise where you say, “Who will do this and how long will it take?” It goes
much deeper than that—and that’s a good thing because that is how you will be
able to create a better estimate.
As you dig into the high level
deliverables, you should discuss (or ask yourself):
needs to be done to create this deliverable?
other related project tasks will contribute to successfully completing this
are the requirements of the tasks?
we cutting any corners here?
you conduct this exercise, keep in mind that you truly want to list every
possible task that could go into the high level deliverable. Remember, the
point here is to account for all time so that you can create a reasonable
estimate. You won’t be able to do that if you’re not thinking it through
the website redesign as an example, here is how you might break up the first
deliverable, which was “Sitemap”:
the current structure with 5 site users
the sitemap in a spreadsheet
the first low-fidelity version with the team
the structure using the team’s input
a visual version of the sitemap
description of the new sitemap
the sitemap to clients
meeting with clients
list of tasks is an estimate for all of the work that will need to be done in
order to get to a finalized sitemap. This might not be the way you’d do it, and
that is just fine. When you sit down with your team to discuss these tasks,
you’ll want to be sure that you’re operating with a common understanding of how
things are done, or that you’re at least talking through the process you want
to enact. No matter what, listing out every single detail will help you to
spell out the effort it will take to complete the deliverable.
Step 3: Get Granular
right: you want to make your WBS as detailed as possible. The only way to do
that is to examine every step that you’ve identified and list out tasks. It’s
all about elaborating effort and determining the work that will need to be done
in order to successfully complete the deliverable. It’s a process that takes
time and thought, but if you make an investment to do this, you’ll find less
room for missed expectations and budget overages in the long term. So, take the
next step and detail out what will go in to each task.
the website redesign as an example, here is how you might break up the
deliverable, which was “Test the current structure with 5 site users”:
users for time
up findings and recommendations
one task is proof that any single line item in a scope can be an expensive one!
Not only did this example include 6 subtasks, it also included a line item that
requires payment to a party outside of the project. You’re going to want to
know about these expenses in advance of scoping your project, and your clients
will too. So be sure to account for them early on so nothing comes as a
surprise when you are knee-deep in your project.
Step 4: Format and Estimate
you’ll find that Work Breakdown Structures are presented in flow charts that
resemble website sitemaps. That format happens to work very well because it
shows a hierarchy of tasks and is easily numbered and referred back to. But,
some people like to list them out on whiteboards or put them in spreadsheets.
The format isn’t what matters here—it’s the completeness and accuracy of the
tasks included. You can create your WBS in any format that makes you
you’ve listed all of your tasks and subtasks in a format that makes sense,
you’ll want to re-review it and make sure that you’ve included all of the
possible tasks and subtasks. Once that’s confirmed, go through the list and
discuss each task in terms of level of effort. This could be in minutes, hours,
days, weeks…it really depends on how granular you need to get and how your
organization estimates projects. Assigning an increment of time to each task
will help you to add up a total estimate of time (and possible cost), and will
help you to create a project plan when you get to that step in your project.
When you’re done, you will know if you’re in scope, out of scope, or actually
operating on another planet. It’s true: you might run this exercise and find
that you’ve articulated too much time or effort to do everything within the
scope of the project. The good thing is that you’ve set the baseline for what’s
needed, and as a group, you can scale back on tasks to fit the scope or the
timeline(and help yourself avoid the awkward deliverable due date dance).
The Quick Work Breakdown Structure
you’ll get requests to add to your project scope. In that case, you’ll need a
quick (but solid) estimate to float by a team or a client—just to ensure that
you’re covering your bases with that new thing. Maybe you don’t have the time
to pull the team together to run through the steps above, but using a WBS in
this instance to map out a quick set of deliverables can be extremely helpful.
In fact, creating a quick WBS on your own can be extremely helpful when a
client tells you they have X dollars to spend or X days to get something done.
If you map out your tasks to get to an estimate, you can easily explain what
can and cannot be done. And, if your estimates are too high, you can lean on
your work breakdown structure to negotiate the scope down quickly.
example, if I had to cut down on cost/time on building that sitemap, I could
likely remove the “Test the current structure with 5 site users” step from my
“sitemap” deliverable (though that could be risky and I might not want to do
that). Use the WBS to your advantage this way and you’ll not only create a
project estimate that maps to a specific budget, you’ll work out a solid set of
it Down Now!
with any tool or methodology, you need to do what’s right for your project,
your team, and you. Maybe the steps and in-depth amount of detail outlined here
won’t work for you. That’s okay. If you use the principles that the WBS
encompass—listing deliverables and tasks—to create your own estimate, you will
find a level of accuracy that you may not have found in the past. And, if you
hang on to those estimates, you will find that you can use them on future
projects as well.
Estimation Process for Successful Software Planning, Measurement and Control
effective software estimate provides the information needed to design a
workable software development plan. How well the project is estimated is
ultimately the key to the project’s (and product’s) success. An effective software estimate provides
important information for making project decisions, projecting performance, and
defining objectives and plans. Without
the proper guidance in a project, the results could be disastrous. Viable
estimation is extremely valuable for project success for nearly any software
project from small agile projects to huge projects.
projects more successful by properly estimating and planning costs, schedules,
risks, and resources. It be gins by covering the fundamental problems of
unreasonable software estimation: not planning up front; failure to use viable
estimates as the bases of an achievable project plan, not updating the plan and
estimates when a project changes, and failing to consider the uncertainties
inherent in estimates. Most estimates are prepared early on in the life cycle
of a project, when there are typically a large number of undefined areas
related to the project. The steps presented in this regard provide a complete
method for developing estimates and plans.
ten step estimation process that begins by addressing the need for project
metrics and the fundamental software estimation concepts. It shows how to build a viable project
estimate, which includes the work involved in the actual generation of an
estimate, including sizing the software, generating the actual software project
estimate, and performing risk/uncertainty analysis. Finally the process rounds out with a
discussion on validation of the estimate, obtaining lessons learned, and use of
the estimate throughout the project. Based
on the book, Software Sizing, Estimation, and Risk Management: When Performance
is Measured Performance Improves, by Daniel D. Galorath and Michael W. Evans
(Auerbach Publications, February 2006, ISBN: 0849335930)
Step One: Establish Estimate Scope and
and document estimate expectations. When all participants understand the scope
and purpose of the estimate, you’ll not only have a baseline against which to
gauge the effect of future changes; you’ll also head off misunderstandings
among the project group and clear up contradictory assumptions about what is expected.
Documenting the application specifications, including technical details,
external dependencies and business requirements, will provide valuable input
for estimating the resources required to complete the project. The more
detailed the specs, the better. Only when these requirements are known and
understood can you establish realistic development costs.
estimate should be considered a living document; as data changes or new
information becomes available, it should be documented and factored into the
estimate in order to maintain the project’s integrity.
Two: Establish Technical Baseline, Ground rules, and Assumptions
To establish a reasonable technical
baseline, you must first identify the functionality included in the estimate.
If detailed functionality is not known, ground rules and assumptions should
clearly state what is and isn’t included in the estimate. Issues of COTS,
reuse, and other assumptions should be documented as well.
Ground rules and assumptions form the
foundation of the estimate and, although in the early stages of the estimate
they are preliminary and therefore rife with uncertainty, they must be credible
and documented. Review and redefine these assumptions regularly as the estimate
Step Three: Collect Data
Any estimate, by definition, encompasses
a range of uncertainty, so you should express estimate inputs as least, likely
and most rather than characterizing them as single data points. Using ranges
for inputs permits the development of a viable initial estimate even before you
have defined fully the scope of the system you are estimating.
core information must be obtained in order to ensure a consistent estimate. Not
all data will come from one source and it will not all be available at the same
time, so a comprehensive data collection form will aid your efforts. As new
information is collected, you will already have an organized and thorough
system for documenting it.
Step Four: Software Sizing
you lack the time to complete all the activities described in the ten-step
process, prioritize the estimation effort: Spend the bulk of the time available
on sizing (sizing databases and tools like SEER-AccuScope can help save time in
this process). Using an automated software cost and schedule tool like SEER-SEM
can provide the analyst with time-saving tools (SEER-SEM knowledge bases save
time in the data collection process).
is generally the most significant (but certainly not the only) cost and
schedule driver. Overall scope of a software project is defined by identifying
not only the amount of new software that must be developed, but also must
include the amount of preexisting, COTS, and other software that will be
integrated into the new system. In addition to estimating product size, you
will need to estimate any rework that will be required to develop the product,
which will generally be expressed as source lines of code (SLOC) or function
points, although there are other possible units of measure. To help establish
the overall uncertainty, the size estimate should be expressed as a
Whenever possible, start the process of
size estimation using formal descriptions of the requirements such as the
customer’s request for proposal or a software requirements specification. You
should re-estimate the project as soon as more scope information is determined.
Five: Prepare Baseline Estimate
and schedule are derived from estimates, so if an estimate is not accurate, the
resulting schedules and budgets are likely to be inaccurate also. Given the
importance of the estimation task, developers who want to improve their
software estimation skills should understand and embrace some basic practices.
First, trained, experienced, and skilled people should be assigned to size the
software and prepare the estimates. Second, it is critically important that
they be given the proper technology and tools. And third, the project manager
must define and implement a mature, documented, and repeatable estimation
Step Six: Quantify Risks and Risk
is important to understand what a risk is and that a risk, in itself, does not
necessarily pose a threat to a software project if it is recognized and
addressed before it becomes a problem. Many events occur during software
development. Risk is characterized by a loss of time, or quality, money,
control, understanding, and so on. The loss associated with a risk is called
the risk impact.
must have some idea of the probability that the event will occur. The likelihood
of the risk, measured from 0 (impossible) to 1 (certainty) is called the risk
probability. When the risk probability is 1, then the risk is called a problem,
since it is certain to happen.
each risk, we must determine what we can do to minimize or avoid the impact of
the event. Risk control involves a set of actions taken to reduce or eliminate
management enables you to identify and address potential threats to a project,
whether they result from internal issues or conditions or from external factors
that you may not be able to control. Problems associated with sizing and
estimating software potentially can have dramatic negative effects. The key
word here is potentially, which means that if problems can be foreseen and
their causes acted upon in time, effects can be mitigated. The risk management
process is the means of doing so.
Step Seven: Estimate Validation and
this point in the process, your estimate should already be reasonably good. It
is still important to validate your methods and your results, which is simply a
systematic confirmation of the integrity of an estimate. By validating the
estimate, you can be more confident that your data is sound, your methods are
effective, your results are accurate, and your focus is properly directed.
There are many ways to validate an
estimate. Both the process used to build the estimate and the estimate itself
must be evaluated. Ideally, the validation should be performed by someone who
was not involved in generating the estimate itself, who can view it
objectively. The analyst validating an estimate should employ different
methods, tools and separately collected data than were used in the estimate
When reviewing an estimate you must
assess the assumptions made during the estimation process. Make sure that the
adopted ground rules are consistently applied throughout the estimate.
Below-the-line costs and the risk associated with extraordinary requirements
may have been underestimated or overlooked, while productivity estimates may
have been overstated. The slippery slope of requirements creep may have created
more uncertainty than was accounted for in the original estimate.
A rigorous validation process will
expose faulty assumptions, unreliable data and estimator bias, providing a
clearer understanding of the risks inherent in your projections. Having
isolated problems at their source, you can take steps to contain the risks
associated with them, and you will have a more realistic picture of what your
project will actually require to succeed.
Despite the costs of performing one, a
formal validation should be scheduled into every estimation project, before the
estimate is used to establish budgets or constraints on your project process or
product engineering. Failing to do so may result in much greater downstream
costs, or even a failed project.
Eight: Generate A Project Plan
The process of generating a project plan
includes taking the estimate and allocating the cost and schedule to a function
and task-oriented work breakdown structure.
To avoid tomorrow’s catastrophes, a
software manager must confront today’s challenges. A good software manager must
possess a broad range of technical software development experience and domain
knowledge, and must be able to manage people and the unique dynamics of a team
environment, recognize project and staff dysfunction, and lead so as to achieve
the expected or essential result.
Some managers, mainly due to lack of
experience, are not able to evaluate what effects their decisions will have
over the long run. They either lack necessary information, or incorrectly
believe that if they take the time to develop that information the project will
suffer as a result. Other managers make decisions based on what they think
higher management wants to hear. This is a significant mistake. A good software
manager will understand what a project can realistically achieve, even if it is
not what higher management wants. His job is to explain the reality in language
his managers can understand. Both types of “problem manager,” although they may
mean well, either lead a project to an unintended conclusion or, worse, drift
down the road to disaster.
Software management problems have been
recognized for decades as the leading causes of software project failures. In
addition to the types of management choices discussed above, three other issues
contribute to project failure: bad management decisions, incorrect focus, and
destructive politics. Models such as SEER-SEM handle these issues by guiding
you in making appropriate changes in the environment related to people,
process, and products.
Nine: Document Estimate and Lessons Learned
Each time you complete an estimate and
again at the end of the software development, you should document the pertinent
information that constitutes the estimate and record the lessons you learned.
By doing so, you will have evidence that your process was valid and that you
generated the estimate in good faith, and you will have actual results with
which to calibrate your estimation models. Be sure to document any missing or
incomplete information and the risks, issues, and problems that the process
addressed and any complications that arose. Also document all the key decisions
made during the conduct of the estimate and their results and the effects of
the actions you took. Finally, describe and document the dynamics that occurred
during the process, such as the interactions of your estimation team, the
interfaces with your clients, and trade-offs you had to make to address issues
identified during the process.
You should conduct a lessons-learned
session as soon as possible after the completion of a project while the
participants’ memories are still fresh. Lessons-learned sessions can range from
two team members meeting to reach a consensus about the various issues that
went into the estimation process to highly structured meetings conducted by
external facilitators who employ formal questionnaires. No matter what form it
may take, it is always better to hold a lessons-learned meeting than not, even
if the meeting is a burden on those involved. Every software project should be
used as an opportunity to improve the estimating process.
Ten: Track Project throughout Development
In-process information should be collected
and the project should be tracked and compared to the original plan. If
projects are varying far off their plans refined estimates should also be
prepared. Ideally, the following attributes of a software project would be tracked:
in terms of staff effort, phase effort and total effort
found or corrected, and the effort associated with them
characteristics such as development language, process model and technology
dynamics including changes or growth in requirements or code and schedule
progress (measuring performance against schedule, budget, etc.)
structure in terms of size and complexity
Earned value, combined with quality and
growth can be used to forecast completion very accurately and flag areas where
managers should be spending time controlling.