The Work Breakdown Structure (WBS) is a pretty well-known tool for managing projects. It is a formalized way to split a complex task into many small (and by that more easily manageable) parts. So instead of “install computers in rack” you have list with e.g. check availability of rack space, request network and SAN connection, arrange date/time with computer center, etc. This is probably a bit simplified, but you get the point.
I use the WBS a lot as soon as things become a bit more complicated. May favourite tool are spreadsheets, which have the following advantages:
- Everbody can use them
- You can send them around via email very easily
- Versioning is easy (via naming convention or use of a proper version control system)
What attributes should be maintained per task? I have the following:
- Task ID: Never use the lines from Excel. A simple re-sorting and you are screwed
- Status: green, yellow, red
- Progress: open, done, wip (work in progress)
- Area: Whatever makes sense to you. Examples: architecture, infrastructure, project management
- Owner: The person responsible for the task towards management. Please note that this guy is not necessarily the one who does (all) the work.
- Due date
- Activity log: Whenever something happens for the task, make a note with the date and your initials (you may not be the owner)
- Task ID cross-reference: Relationship to other task(s)
- External cross-reference: E.g. task relates to specific section of document
Depending on your requirements you may need additional information. You can also leave out some of the things from above, although I would discourage that if you don’t really know what you are doing. This list has been developed over a number of projects and sooner or later I was always thankful to have them.
So what is the relationship of the WBS to a project plan? The latter is generally more high-level, contains explicit dependencies, is more used to communicate with management. In many cases one line item in a project plan is basically detailed out by a WBS