Defining Project Milestones - Creating Work Packages

Defining Project Milestones - Creating Work Packages

Defining Project Milestones

Milestones deserve special mention. A milestone is an important event in a project, generally associated with a major work product or deliverable. They mark passage points in the journey toward completion, and every project should have enough of them, spread evenly throughout the schedule so that it is easy to measure achievement toward the final goal. With too few, you get the "big bang" project, where no one really knows until the very end if the project is on schedule. But too many can bog down the project's pace. An even spacing on a schedule calendar is desirable. Milestones have zero duration. They only mark a point in time when something important has been completed. They can be described for the end of one or more activities, or for a work product or deliverable, or for a designated group of these. It is best to use language that shows completion, such as "Done" or "Complete". In the C compiler example of "What Is a Work Breakdown Structure" Figure (c), the milestone for item 1.0 would be "Software for C Compiler Completed".

Stages or phases are not milestones but are collections of related product activities. On the other hand, milestones can be used to mark a stage or phase completion, as demonstrated in "Approaches to Building a WBS" Figure (b).

Creating Work Packages

The lowest level of the WBS is where the work gets done. These are the "leaves" on the tree representation, or the farthest indented activities in the indented list. These are called work packages and generally result in a work product being delivered. Work packages describe the work product in such a way that each is clearly distinguished from all other work packages in the project. They are generally explained with all the information required for a qualified person to execute the work. For software development projects, these normally correspond to the lowest identifiable objects or modules to be created in a deliverable system. The contents of a work package may include:

●  Description of the work product expected - software element to be produced;
●  The staffing requirements - who or how many people will do this activity;
●  Names of responsible individual(s) - who is responsible for seeing that it is completed;
●  The scheduled start and end dates - when the activity is expected to start and to end;
●  The budget assigned (dollars, hours, or other unit) - the effort estimate for the activity;
●  The acceptance criteria for the work - defect level or other quality measure.

If the project staff already know these things, which is common in organizations where the same group of software engineers work together every day, then writing up a formal work package is unnecessary because they already know the tasks required to complete the activity. On the other hand, when more control is required to organize a group that has never worked together before and has no common software culture to provide a framework, then writing down the work package information is very helpful because it minimizes vagueness about their assignments. It may also happen that a work package for a project becomes the scope of work for a whole subproject, which is further divided into more activities, managed as a project under the larger effort. The way to distinguish a subproject from a standalone project is to ask whether the subproject could stand alone on its own, without the larger project for context. A subproject's work product deliverable may be a standalone piece of software useful in contexts outside the scope of the current project. Creating custom software utilities is a good example of a software subproject. Most project management scheduling tools, such as Microsoft Project, have a place for notes about each activity and a way to print them as assignment handouts. This is great for getting a newly hired diverse group of software engineers to use the same processes.


milestones, wbs, software engineers, software utilities, processes
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus