While the completion of a deliverable can be a milestone, it does not necessarily have to be. Your goal with a milestone is to give you a point to gauge the time and costs spent thus far, then compare them to estimates to see how far off course you are.

Entry and exit criteria are used for the purpose of evaluating when you've entered a new phase or left a completed phase. Criteria are set up by you and are not generally utilized for tasks, only for new turning points in the project.

Iteration is the process of repeating a task, an element of a task, an activity, or some other component of a project. Testing is probably the most common example of a project activity that requires iteration.

Having to repeat yourself—either because the scope has changed and you have to go back to get new sign-off, or a task needs to be repeated again, or some other component requires repetition— is something you' l l have to be prepared for throughout the project management process. Seldom will we finish each task on time, within budget, and as required.

Pecomposition is a much harder job than it might at first appear. You have to think about all of the components that might go into making up a deliverable—figuring out all the nuances that accompany its manufacture. You' l l likely get the assistance of a business analyst and a technician or two in order to thoroughly decompose the elements of a deliverable. Careful decomposition results in the creation of accurate tasks that will result in the deliverable.

The stakeholders must arrive at consensus on the WBS, and the project sponsor(s) must sign off on it.

A vendor' s bid for equipment won' t be on the WBS, but a contractor' s detailed SOW tasks will be. You don' t want to fall into the trap of detailing every little nut and bolt of a project while formulating your WBS. Make it definitive, yes, but excessively granular, no.

The lack of completion of a predecessor task will prevent the next (successor) task from beginning. Exit criteria indicate when you ' re moving from task to task; they don't decide or determine whether you do so. Iteration means a step or

action is repetitive; being iterative doesn't itself prevent things from moving along.

Small projects aren't generally going to require a milestone, though you can certainly add one. In general, large projects with lots of phases and activities are the ones that require milestones.

Milestones typically consist of a description, the entry criteria (how you ' l l recognize the milestone), and the exit criteria (how you' l l know when you ' re leaving the milestone). Usually, milestones aren t associated with predecessors or successors. Milestones are always of zero duration.

Risk response control is an element of the controlling phase of your project and doesn' t require a formal element that' s submitted with the finalized project plan. You will include any training, implementation, and support plans that you' ve created, however.

The project plan starts with a table of contents (TOC). D

The Scheduled Tasks section of the project plan contains your WBS. If you' ve set up your WBS in Microsoft Project, you could print out the task list and include it in your project plan documentation. Note that the project plan is more than the WBS—the plan is a complete report on how you' re going to accomplish the deliverables. The WBS is certainly the most important part of a project plan, however.

You utilize the Environmental Issues section of your project plan to discuss these topics.

You likely won' t include someone ' s general administration

duties in your WBS, unless those duties directly impact the task that's being considered.

The sticky-note method is very elementary, and it's a great way to sort through all of the elements of your client's deliverables, then key them into your favorite WBS-creation method (whether spreadsheet or PM software).

Any of the listed components might be candidates for iterative treatment—where you have to go back and get new plan approval because you've had to modify the plan, for example, or where you refine the project's design based upon further input.

All projects, regardless of size, require a WBS. The WBS is the description of what you're going do to, when you're going to do it, who'll work on each task, and how long it's going to take.

The placement of milestones serves the purpose of getting a radar fix on the amount of money you've spent and the number of hours invested thus far. You can place milestones anywhere in the project, and the ends of activities or phases, or completion of components, are great places to do so. Changing personnel doesn't make any sense in terms of the definition of a milestone. As a general rule, milestones wouldn't be set to trigger the accomplishment of one task and movement into another, though there might be some minor exceptions to this. For example, when you've finished the printing module for your code and you're ready to snap it into the main modules, you might have a milestone that fires.

At least four milestones would be a necessity in such a project. You'll stop to take a look at each module's completion, as well as the server infrastructure when it's

done. That being said, however, you may opt for more milestones in places where this seems credible (completion of one software module's complex sub-module, for example).

The sponsor is the one who's able to authorize the expenditure of the resources necessary to create the project's deliverables. As such, the sponsor has the final signing authority for the project plan, even though stakeholders have input into the draft of the plan.

The way that communications work, the stakeholders may be saying the same thing, only putting it a different way; or one of them may be confused about the project plan element you're discussing. You should first try to make sure they both understand the issue. If they have a clear-cut difference in opinion, the next thing to do is to make your best decision about who's right and consult the sponsor.

Was this article helpful?

0 0

Post a comment