Why Break the Work Down?
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.
Documentation & Tools
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.
Comments