The Work Breakdown Process

At the outset of every software project everyone's attention is focused on defining the scope of the project. This can be a very demanding undertaking; the project is often an integral part of a strategic objective that is of vital importance to the whole organization and getting the requirements properly defined is key to success. Of equal importance to gathering the right set of requirements is defining the work that must be done to build a software system which meets those requirements, and then performing the work. Breaking the work down and creating the project schedule is the first step in building the system. Failure to break the work down properly can lead to miscommunication with the project team or missing work necessary to deliver a requirement, and could ultimately result in failure to deliver the system the organization needs.

Breaking the work down must meet 2 objectives: the resultant work packages must represent a tangible deliverable that makes sense to the team member responsible for producing it and the project manager must be able to control it. By controlling the work package, I mean that that it should be monitored by the project manager in such a way as to alert them that a corrective action is called for to preserve the schedule. A work package that fails to meet the first objective will confuse a worker who attempts to create it and if that person is reticent about pointing out the confusion, will lead to wasted time and effort. Failure to deliver on the second objective will make it difficult for the project manager to determine when there are problems that would require correction.

The PMBOK® describes an iterative approach to breaking work down, ending when the work package can be assigned, budgeted, and managed with a minimum amount of effort. This guideline is fine, as far as it goes but it doesn't go nearly far enough to help the project manager of a software development project. In defence of the PMI®, it couldn't be precise enough to make it helpful to managers of software projects without making it irrelevant to managers of projects in other areas. The purpose of this article is to provide some tips and tricks which will help managers of software projects determine when they have defined the proper set of work packages.

Work should be broken down using all the documented information available that is relevant to the project. This documentation will include everything which describes the scope of the project: the Project Charter, the SOW, the Scope Statement, requirements matrix, etc. It will also include historical information such as schedules for similar projects, changes to the previous project, and Lessons Learned from similar projects. Each organization will approach projects differently and each project will have a unique set of documents available to it. Your job as project manager is to seek out all the documentation that could be helpful and determine which you will use.

To do a thorough job of breaking the work down, you should start with the tool you intend to use to manage the schedule. For most managers of software projects this will be MS Project (note: this is not a plug for Microsoft, just recognition of the dominance that tool has in the market place). Throughout this article I will refer to the project schedule in describing the process of breaking the work down and that is because MS Project integrates the Work Breakdown Structure (WBS) with the schedule. Attempting to break work down for even the smallest project without such a tool will be very time consuming and tedious. It will be impossible for larger projects.

Breaking work down becomes simple when the project under development is a repeat of a previous, similar project. Use the schedule (MS Project plan or other similar file) as a base for the new schedule. Use the plan from the previous project as your starting point, changing the names of the various components of the system to suit the new project. You can simply copy the old plan into a new file and make the necessary changes to the new file, or create the new file and copy and paste relevant lines from the old file into it. Obviously, the work required for the new project won't be the same as the work in the old plan, but the way in which the work is broken down should be the same. The way in which the work is done will likely remain the same, even when the new project introduces new tools. For instance, if your organization's QA process calls for unit testing of individual modules the work package that delivers a unit tested module will be required in the new plan as well. Testing performed by a QA organization will require the similar work packages in most projects.

The one drawback I find with MS Project is that, because it automatically creates a schedule at the same time it breaks the work down, start and finish dates are automatically provided when you enter a work package or summary task. Don't worry about dates when you break the work down. MS Project will default the start and finish dates based on the date you are working with it and the default settings. You will schedule the work later when you estimate the effort and duration of each of the packages and the dependencies.

Don't forget to consult other historical information when converting the information in the old plan into the new one. If you are lucky, the previous project will have Lessons Learned collected and archived in an orderly fashion and all you need to do is an intelligent search for any lessons pertaining to the definition of work packages. You could scan each lesson, where the total lessons are manageable, otherwise you'll need to use a search tool to perform the scan. Some search strings to consider: "estimate", "late delivery", or "schedule slippage". Frequently lessons are captured because something went wrong. Things that a bad WBS could cause would include missed work, poor quality (where a work package to perform unit testing was missed for example), or misunderstandings about the nature of work to be performed.

Not all organizations undertake Lessons Learned sessions for their projects and even when they do, all the information that could help you break the work down may not be contained in them. Among other artefacts that could yield useful information are change requests which implement preventive or corrective actions, implemented to prevent schedule slippage caused by poor work breakdown. Other sources will include risk registers, issue logs, action registers, or decision logs. If your organization is behind the curve in using these tools you should be changing that with your project. In the meantime, you may have to search e-mails to find evidence of the damage done by a faulty WBS. Referencing these artefacts should yield a good draft WBS. Do not forget to consult your organization's policies, standards, and guidelines when creating the WBS. These may have changed since the project(s) you are using as a reference, or the previous project manager may have failed to comply with them so make sure that your WBS supports them. Pay particular attention to standards, guidelines, and policies that pertain to quality. Failure to organize the work such that these are adhered to will lead to project failure.

Project managers undertaking projects that break new ground will need to do more investigative work to create their WBS. A project which uses new tools (e.g. a new programming language or new web platform), or techniques (e.g. SCRUM) will have a new set of summary tasks which will not be found in a previous project schedule. Starting at the project level, define a sub-project for each application to be developed. The software development methodology chosen will determine the summary tasks within each of the sub-projects (applications) in the plan. For example, if the Waterfall methodology is chosen, each application will consist of the complete set of requirements that application must support. The project will contain multiple sub-projects if an iterative approach such as SCRUM is chosen, one for each iteration. Each of these sub-projects will contain the set of summary tasks which support the way your organization does the work. This set of summary tasks may include summary tasks for writing the code, unit testing each piece of code, testing groups or sets of modules, QA testing each application, and QA testing each system. The project manager will determine the set of sub-projects and summary tasks necessary to support the methodology used.

Your project schedule should contain at least 3 hierarchical levels at this point. There is one possible exception and that is when the project is so large that breaking the work of each sub-project down into summary tasks and work packages would produce a schedule with too many items to be managed efficiently. I find that a schedule of 600 to 1,000 items is about the maximum that I can manage efficiently. Any more than that and the dependencies will create a schedule that cannot easily be altered without a time consuming analysis of those dependencies. You may not be able to make a decision on whether your project calls for one schedule or several schedules but, if your schedule contains several hundred items at this point you should consider multiple schedules. The schedule at this point should facilitate sub-division into one plan for each sub-project, or multiple schedules containing multiple sub-projects.

The summary tasks that you have defined at this point will depend on what your project delivers and the software development methodology chosen. The summary tasks for a project which calls for the development of software applications and systems will differ from those required for a project requiring the implementation of an off the shelf software application which will differ from those required for a project implementing a customized off the shelf application. There will be a set of summary tasks for each different activity called for by the approach, one for each application or system to be developed, customized, or implemented. At this point, you may want to break the summary tasks down one more level, to produce a 4th hierarchical level. For example, where the summary tasks are of the nature of "create XXXXX application", "code XXXXX application", or "customize XXXXX application" you may want to further break the work down into sub-components, one for each pieces of the application or system. One way to identify these sub-components is to consider who will be responsible for doing the work. Where multiple people will be responsible for delivering the summary task, break the summary task down into one component for each person who will work on it.

Your software methodology should dictate how the set of requirements is to be translated into a working system. This process may call for the translation of those requirements into multiple Functional Specifications and each Functional Specification may call for one or more Detailed Design Document. The determination of what set of specifications that are required to support your project will be determined by the nature of the organization: do you have a separate department for Business Analysts, Software Analysts, Programmers or are your programmers all Programmer/Analysts? The specification set will also depend on what your project needs to deliver. The documents required for a project delivering applications built from scratch will differ from those required for a project delivering customization and implementation of an off the shelf solution which will differ from those implementing a standard off the shelf solution. Each of the documents to be produced will call for a work package. There should be one or more work package for each document to be produced. There should be a separate work package for each set of activities required to produce a working document. For example, a work package to develop the document, one to review it, and another to update it from the output of the review.

Excluding any areas where work packages have been defined, you should have a schedule containing either 3 or 4 hierarchical levels by this point. A schedule with many more than 4 levels is likely to produce a WBS and schedule which cannot be managed efficiently. Likewise, beware of a WBS which would call for the assignment of work packages to more than one team member. It may be OK to have a junior programmer assist a senior programmer on a package, depending on your organization, but work packages that call for several senior programmers should be avoided. Now that you have a break down containing the optimal number of levels you are ready to break each level down into its component work packages.

The set of work packages each summary task should contain will depend on the nature of the software system to be delivered, the tools used to do the work (tools), how the work will be done (technology, policies, procedures, and standards), and who will do the work. Let' take the case of a project which will deliver a new system built from scratch first. This project will call for the building of one or more new applications, which will in turn call for the coding of several sets of modules per application and one or more modules per set. Each module must be developed, then unit tested. The work of coding the module should be done by one programmer, unless a senior programmer is responsible for training a junior programmer. A project which calls for the customization and implementation of an off the shelf solution would call for the analysis of each configurable feature or function, the provision of configuration information and testing. A project which calls for the implementation of an off the shelf solution might call for the analysis and configuration of ancillary applications necessary to integrate the application into an existing system, or analysis and configuration of existing applications in the system. Breaking the work down in these cases calls for you to determine who will be doing the analysis and be responsible for configuration of the application(s).

The work packages you define for the project should all belong to a preceding hierarchy level and will be the "child" or "leaf" nodes of the hierarchy. These will be the items that you will use to measure performance to schedule, and possibly performance to budget if the packages are cost estimated. You have not estimated the duration of the work required for each package at this point but your rule of thumb should be that the packages should be at least as long as the intervals between yourstatus reviews. My experience has been that weekly status review meetings are optimal for most projects so you should be looking for packages that are 1 week in length or more. This may not be possible when assignment of the work forces you to define packages that would take less than a week to produce. This means you either bundle those packages with others to produce a package of at least 1 week duration, or review the status of the items of shorter duration on their due dates.

Your last step will be to verify the breakdown with the project team members responsible for the work. This will also be an ideal time to estimate the effort and duration for the package and identify dependenciesbetween the various packages. There are 2 approaches to this activity. One is to review the packages with the team one member at a time and the other is to conduct a workshop to review the entire schedule. The advantages of using the workshop approach are that you can bring the entire team's expertise and experience to bear on the schedule, you can identify all the inter-dependencies and you can identify any packages that you have missed. The disadvantage is the time it takes to conduct the workshop; depending on the size and complexity of the project, the workshop could last for days. Don't make the mistake of rushing the workshop though, as this will lead to a deficient schedule. Interviewing each team member individually has the advantages that everyone can speak out without fear of disapproval of others on the team, and the time required from each team member is much less than that for the workshop. The disadvantages are that all the dependencies may not be identified and work may be missed.

The activities just described are not all related to breaking the work down, however doing them in parallel with the process of verifying your WBS makes sense. Team building is an additional benefit of bringing the team together in a workshop, especially if the members have not worked together before. Asking them to spend the amount of time that a workshop requires, several times before implementation begins will probably not be possible.