Breaking Software Development Work Down

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.

Starting Out

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 zero days.

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.

Work related to the software to be delivered by the project is not the only work your WBS should capture. Deliverables from project management will usually be specified in the SOW, Project Charter, or Scope Statement. Even when these deliverables are not specified, you should capture them in your WBS. Your Change Management, Communications, Procurement Management, Requirements Management, Resource Management, and Risk ManagementPlans will all contain deliverables, work packages and milestones which need to be captured in the WBS.

Work Packages

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

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 for.

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.

Completing the WBS

Maintaining the WBS

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.

Change Requests

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.

Common Changes

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 done.

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.

Conclusion

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.