Most project plans start with a schedule of all the
individual tasks that comprise the work of the project and this schedule is
usually organized using a project management tool, with MS Project being the
most common. These tools will support assigning the activity to a project
resource, relating the activity to a work package, estimating the effort the
activity will require, estimating the duration of the activity, and capturing
any dependencies between activities or work packages, in short everything you
need to organize the work except how to break it down. Breaking software
development work down can be tricky because the individual software components
being developed are too large to be manageable and it is difficult to identify
components that are small enough to be manageable.
I will try to provide you with some tips and tricks that
will make the breakdown of the work simpler and make the chore of breaking work
down on your next software development project a little easier. This article
addresses the breakdown of the work only, not effort or duration estimation, or
establishing relationships between the work packages or activities. What you’ll
get after following the advice here is a WBS, not a schedule. You will find
references to schedules in this article because the WBS and schedule are
actually part of the same file, managed by the same tool. It may help you to
think of the WBS as a phase in the development of your schedule.
The key thing to remember about your Work Breakdown
Structure, or WBS, is that it is not a static document. It can change over the
course of the project as the nature of the work changes and may even provide
insights into the work that will suggest new ways of organization which save
time or money. The "Rolling Wave” approach is also a common method for planning
software development work, especially for applications that are new to the
performing organization. The "Rolling Wave” approach requires the project
manager to define only the work of the next project step in detail and leave
the rest defined at a high level. These influences over the WBS mean that you
will be constantly changing how you’ve organized the work in your schedule.
Check your project management knowledge base, if you have
one, for any similar projects. You may be fortunate enough to identify one that
was sufficiently similar to use its MS Project file or schedule rather than
starting from scratch. Do this very carefully. You may end up creating more
work for yourself than you save if the project you select is not sufficiently
similar. Contact the project manager who authored the project plans to gain insight into the similarities and differences between their project and yours, then make the decision.
The next step to capturing the work in your MS Project plan,
or other project tool, is to identify all the key deliverables and milestones.
There are several sources for this information: the Statement of Work (SOW),
the Project Charter, and the project Scope Statement. These are listed in
search order here. Don’t attempt to establish any relationships between the
various deliverables and milestones at this point, that step will come later.
You must enter dates for each of the items you enter but don’t worry about
accurate estimates for work effort or duration at this point. The one exception
to this rule is the entrance of milestones. MS Project defines milestones as
activities with no duration, so when entering a milestone set the duration to
Your third step will be determining what software
methodology you will use to develop the software. Each different methodology
will require a different approach to organizing the work in your MS Project
file. Once you have chosen the methodology that is best suited to your
project’s and project team’s needs, enter the milestones that are relevant to
that method. You should always include a planning phase during which the
deliverables will be your project plans and any other planning artifact the
project requires, and a build phase where the work gets done. You will usually
also have closeout phases during which ownership of the software is transferred
to the support organization and the project records get archived. How the build
phase is broken down into sub-phases will depend upon which development
methodology you choose.
Organizing the work of the first iteration of an iterative
development project is very similar to organizing the work of a project using
the waterfall method. Subsequent segments of this article will address breaking
the work down for the first iteration. Work for subsequent iterations in an
iterative project can be blocked out identifying the key deliverables planned
for the iteration. Include any milestones which will go along with each
iteration, such as gate reviews, planning sessions, user testing, and etc.
A work package is a stand-alone piece of software that will
support one or more features called for by the requirements for the
application. When I say stand-alone, I don’t mean that the software is an
application on its own, rather a module, function, or web page that will be
developed individually and compile with other components to create the
application. The work packages are dependants or children of the deliverables
already defined in your file. A software module or web page is a perfect
example of the work package. Your deliverable might be a new e-store for England
and that deliverable might be made up of 25 pages, one for each of the products
to be sold in your e-store. The deliverable might be a configuration and order
application to run on an inventory database and your work package might be the
log in function.
These work packages should be defined in collaboration with
a software development, web design, or database design subject matter expert
(SME) because what you are defining is not all the features and functions your
application, web site, or database will have, but rather how the work will be
done. Your SOW may contain a quite detailed list of features that might not
reflect the way the work will be done. For example, you may have a requirement
to include a picture of the item for sale on every purchase page of your
e-store, but the inclusion of the picture is more of a guideline than a work
package. Your WBS should reflect the way the work is to be organized.
Work packages should include all the work required to
prepare the package for inclusion in the code library and integration into the
application or web site. This will include, unit, thread, or function testing
but usually not system testing.
Activities are descriptions of the work which will be done
to produce the work package. For example, creating the log in function for your
application would require the programmer to design the function (possibly
producing a detailed design document), hold a design review, code the function,
hold a code walk-through, and test the function. The function might actually be
broken down into component parts. Let’s take the example of our log in
function. This might be broken down into the capture and checking of the
userid, the capture and checking of the password, and the assigning of user
privileges to the session.
Don’t get bogged down in the details of how the work should
be done. The purpose of capturing the work in the WBS is to organize it and
supervise its completion. Details that don’t describe a piece of work to be
done, or don’t describe a piece that will be separately tracked should not be
captured in your WBS. Here’s a rule of thumb for determining whether there is a
need for breaking the work down further. Ask yourself this question "Is this the
activity that I want to receive a status update for at the status review
meeting?” If the answer is "No, I need more detail” then you need to break the
work down further. If the answer is "No, the meetings are only weekly and this
work would take no more than a day to do” then you are trying to break the work
down further than you should.
A need may arise later in the project to break the work down
further, say into activities that take no more than a day to accomplish. This
could be the result of a performance issue with a team member which you choose
to address by micro-managing that person’s work, or as a corrective action
project wide when deadlines are being missed project wide. Break the work down
in your WBS when that time comes, but not before.
Breaking the quality assurance work down is somewhat easier.
The work falls into two major packages: creating the test suites and test
cases, and executing them. The test suite will usually be granular enough for
you to monitor and control quality assurance work, unless individual test cases
are large enough to require more than a days worth of work to produce or
execute. Include any plan reviews and test case walkthroughs your project calls
The execution of QA test cases will invariably lead to
failed test cases and re-work. Don’t forget to allow for this activity in your
WBS. From the point at which the QA testing begins, put a stake in your WBS to
accommodate the re-work that will be the outcome of testing. For projects using
an iterative development method, the re-work from the previous iteration will
compete with new features for resources in the next iteration.
Your WBS is not a static document; it changes constantly to
keep pace with changes in the project. By the time you’ve passed from the
planning phase to the build phase and changes to the project become a factor,
you will be dealing with a schedule and not just a WBS.
Most change requests in software development projects deal
with changes in requirements. These changes will cause the WBS to change if
approved. Changes that introduce new features or functionality will require a
further iteration of work breakdown. Your first step will be to determine where
the new features or functions should fit within the existing structure. Where
the new feature replaces an existing feature, its placement will be determined
by the placement of the replaced feature. Placement will be determined by the
nature of the feature and the timing of its delivery for new features. Break
the work of producing the new feature or function down using the same method
you used to create the original schedule. Don’t forget to take into account the
impact on testing activities the new feature will have.
You can save yourself some work here. Change requests for
new requirements should be estimated for their impact on the project budget and
schedule. The cost estimate will be determined by the amount of effort required
to develop the feature and the duration estimate will be a product of the effort
and the resources. The impact on the schedule is then determined by its
placement in the schedule "network”. MS Project and other project scheduling
tools are specifically designed to support "what if” scenarios and you will
find that with a little effort you can derive an accurate prediction of the
impact on the schedule of a proposed change. Saving this "what if” scenario
provides you with a revised schedule should the change be approved. Your only
concern will be the posting of work from the current schedule to the new one.
Change requests are not the only source of change to the WBS.
Learning goes on all the time during projects and that learning will inevitably
lead to new and better ways of doing the project work. Some of these discoveries
may be so profound that they will change the nature of the application being
built, or the final delivery date in which case they become requested changes
to the project. For learning that does not affect final delivery date or the
nature of the product, no change request is necessary, but you do need to
capture the new approach in your WBS.
You may become aware of these changes during status review
meetings, job huddles, or one-on-one meetings with team members. You will
usually find out about the change when you ask specific questions related to an
activity in the schedule only to find out that activity is not the one the team
member is working on because they have found a better way to do the work. Explore
the impact of the new way of doing the work to assess its applicability to
other work. It is your job to leverage learning that improves efficiency across
the project team. If the impact is profound enough it may require a change
request, otherwise update your WBS to capture the new way the work is being
Other sources of change are: breaking the work down too far,
not breaking the work down far enough, and the need to monitor a team member’s
work more closely. None of these reasons require a change request. They may
require you to investigate the rest of your WBS to determine if you have made
the same mistake elsewhere.
Your degree of success in capturing all the work and
breaking it down correctly will determine how well your project management tool
(MS Project or other) will work for you. A well organized and maintained WBS
will allow you to predict with a great degree of accuracy when your project
will be finished. Marking work as complete as it gets done will also allow you
to report on how well the project is performing to schedule and determine when
preventive or corrective actions are called for. Investing time and effort to
create the WBS and then maintaining it diligently will give you the measure of
control over the project schedule that you seek.
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.