Breaking Project Work Down

he 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 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 defense 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 artifacts 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 artifacts 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.

Leave a Reply

Your email address will not be published. Required fields are marked *