View source for The best milestone plan is simple but with depths!

''Developed by Jonas	Hammer''


==Abstract==
The planning part of a project is essential to succeed. The milestone plan is one of the most used planning tools, but also one of the hardest to master! It may seem simple, but many project managers tend to ‘overuse’ milestones as a motivation tool, and therefore adding too many milestones, and labeling every minor task completion as a milestone. This ‘overuse’ often has a negative effect on the team members’ motivation, as it’ll cause loss of luster and distinctiveness, not to mention the time consumption! 
That is just one of many mistakes and issues related to milestone planning. 

This article will explore and explain the optimal usage of the tool. The Milestone Plan will, if done correctly, act as an enormous motivation tool along with making sure the project is on track and on the way to success.

The following article will look into the correct way of defining a milestone and how to probably use the milestones to create a usable plan and get the golden overview!
==Article==
===Big Idea===
A milestone is in its basic form a stone that tells you that you’re one mile down the road. They provide reference points, and are used to reassure travellers that they’re on track, and to indicate distance travelled or distance remaining. 

In a project, a milestone defines a completion of something. The only requirement is that the milestone is tied to a quantitative measurement, an internal or external deliverable, or a significant turning point or transition in the project. It is basically an important event marked on a timeline that is recognized when successfully reached.
[[File:milestonesimple.png|right|200px|Figure 1: Basic Milestone Plan with start and end date]]
The Milestone Plan serves as an essential guideline for every project, from big to small. It has a variety of purposes as it shows how the intermediate products, or deliverables, build towards the final output and therefore gives an important overview. This is much needed, as this overview is required to keep the project under control and to identify upcoming bottlenecks and therefore giving the possibility of taking preventive actions well ahead of the critical point. 
The Milestone Plan is furthermore used as motivation tool. A goal and a vision gets the team together going towards the same goal, on the same path, a plan keeps the team on that path, and the Milestone Plan combines these two and adds continuous motivation
It is important to point out that the milestone plan is not to be mistaken for a replacement for any other tools, it is however a strong addition to any project and should never be left out. It can even take care of the entire planning spectrum of a project if done right; keep reading and you’ll soon know why and how!
===Application===
The milestone plan can be made when the project goal and deliverable have been settled and confirmed. It is often even taken in consideration in the fuzzy front end of a project, when negotiations, according to the bid and contract, are made with the customer as the deadlines is coming to an agreement and the plan is being visualized.  
[[File:milestone_top_level.gif|left|500px|Figure 2: Top level Milestone Plan, with the total overview and possibility to go in depths to another more detailed level.]]
====Setting the milestones====
Placing milestones on the timeline is a difficult task. It is important to have an even plan with the exact amount of time and space between each milestone. This will promote motivation through sub-goals, by giving the team something to strive for. It is important that the milestones are not too far apart as the team members will forget about it, but it is equally important that they’re not too close as you’ll loose interest and not get the feeling of achieving something as too many minor events are celebrated.
For example, if you’re constructing a car, you don’t need to celebrate the delivery of a bolt for the wheel. Yet it would be a nice thing to celebrate when the wheels are on the car!
A good rule is to have 10% of the total project time duration between each milestone. It should, however, never exceed a 2-week interval to have the continuous motivation.

It is therefore important to define prober milestones for your specific project.
====Define a milestone====
Before you create the timeline with your events you need to determine what kind of milestones you want to “celebrate” and what kind of milestones that makes sense for your project. 

Milestones can be grouped under several classifications and each defines an event in its own kind.

▪	Phase transitions occur when the project goes from one phase to another. For example if a product goes from designing to construction a prototype (from software to hardware). You can basically divide phase transitions into six stages: information gathering, or marketing research, planning, design, development, testing, and delivery. Each transition from one stage to another is a viable milestone!

•	Rates of total completion are commonly used milestones when the project involves repetition without sequential advancement to the next stage. A good example is a training exercise in which milestones are set for the percentage of employees fully trained or certified, e.g., 25, 50, 75, and 100 percent. This gives the benefits of giving a clearer understanding of the process of the project and understandable by all stakeholders regarding their involvement.

•	Performance recognition milestones are achievements that are not directly connected to the advancement of the project, but recognize the quality of the work performed. For example, in the construction of a plant, a typical milestone would be to recognize periodically that employees have logged in a certain number of work hours without a single safety incident.

•	Deliverables represent tangible evidence of progress towards the project’s goals. It is therefore a commonly used milestone, as it is also easy to determine.

•	Task completion has its resembles with deliverables but define a completion of a specific task. A task milestone could be the completion of the roof on a building, and another to finish the plumbing and so on. This is easy applicable and gives a great overview of the project, not as easy interpreted as the ‘rates of completion’ milestone though, but provides more opportunities regarding the degree of details. It is of great understanding used internal in a project.

A perfect plan for motivation contains some of everything! 

You will also need to keep in mind, that milestones needs to be somehow challenging and carry a degree of risk for failure. This is done to inspire your team members to stay motivated and feel a greater sense of accomplishment.
====Creating the plan====
Now that the preferable milestones have been set on the start-to-finish-timeline, you will need to determine the degree of details for each milestone shown on the plan. This is however the part that is hard to master and very time-consuming. It is important to get the right level of details for the user, but not too much as the plan will loose its ability to provide the golden overview.
The overlook of the milestone plan needs the exact amount of information valid to that specific user/reader. 
The best Milestone Plan can fit onto a single page! 
[[File:Gantt2.jpg|700px|right|Figure 3: Milestone Plan made in cooperation with the Gantt-chart method.]]

Large and complex projects often need more than one Milestone Plan, as a single plan might not satisfy all the planning needs on the strategic level. In this case “Subsidiary milestone plans” are used. Each Milestone on the master plan goes into a Milestone Plan of its own in a deeper level. 
For example there is a master Milestone Plan for a car itself, with milestones such as having the chassis made, installing the engine and so on. When a stakeholder is looking on the master plan to see when the wheels are getting fitted, they don’t care about the subsidiary milestone of the tire getting fitted to the rim. This is however a milestone on the next level, the deeper version only containing milestones for the wheel itself. 
This way of doing Milestone Plans is made by incorporating the WBS (Work-Breakdown-Structure)– with each level and string acting as a subsidiary Milestone Plan.
====Basic how-to====
Here’s a step-by-step how-to guide of the basics regarding a Milestone Plan.

#	Determine start and end date and set up the timeline.
#	Define the audience and balance the “plan-level” accordingly.
#	Define milestones worth “celebrating”.
##	Keep in mind to choose milestones that complements the recommended time interval and the audience. 
#	Insert the chosen milestones in the timeline and put in relevant details for each milestone.
#	Mind the critical path!
##	Add buffers if needed to counteract for unforeseen risks and time delays.
#	Supplement the milestones with relevant data.
Now all you need to do is to take a step back and enjoy your newfound golden overview!
===Limitations===
Looking at bigger projects, for example delivery-projects as constructions of all sorts, buildings, ships, etc..., it does, of course, has to be a unique production as it would otherwise just be a factory task. It might seem “simple” to create the Milestone Plan on these conditions, as you have the goals set, and a contract defined. A contract often contains specific dates where deliverables needs to be delivered and a logic order for when tasks need to be done. It is here you’ll see the biggest advantages of the Milestone Plan but also the biggest pitfalls. You will have an overload of information and data and possible milestones to keep track of from the, often, comprehensive, contract and agreements. Of course that is why a Milestone Plan is needed, but to create that plan out of all the data, you need to master the critical path and proper risk management as well as choosing the suitable milestones and appropriate timeline. It is important that the plan can adapt to unforeseen events, without having to redo the entire thing.

Milestones are used to monitor a progress, but there are drawbacks and limitations to their effectiveness. Milestones focus primarily on the progress of the critical path, and can therefore neglect non-critical activities. Resources are therefore focused on the critical activities and even moved from non-critical activities to critical ones to ensure that milestones are met. This can provide a false impression that a project is on schedule even though some activities are being ignored.

A milestone plan is easy to practice but hard to master!

===Annotated bibliography===
•	http://www.brighthubpm.com/project-planning/68427-successful-project-milestone-planning/
o	Brighthubpm.com has some well-explained articles of basic milestone planning along with many other interesting articles regarding project management!

•	http://www.brighthubpm.com/project-planning/68429-project-planning-typical-milestones/ 
o	Another great, basic, article from Brighthubpm.com that gives examples of typical milestones.

•	http://www.brighthubpm.com/templates-forms/128506-milestone-templates-for-excel-/?cid=parsely_rec 
o	Yet another article from Bighthubpm.com. This one is with and about templates for milestone planning! Gives some great and free tools for milestone planning.

•	“Milestone Planning” Prepared by: Jörg Aldinger, IBIS 8 Matr. 152028 at the University of Applied Sciences, Heilbronn 
o	In opposition of Bighthubpm.com, this document explains much ore deeply how a milestone plan is used to its fullest!

====Additional links to other wiki-articles with additional and useful information:====
=====WBS=====
http://apppm.man.dtu.dk/index.php/Work_Breakdown_Structure_(WBS)

=====Gantt=====
http://apppm.man.dtu.dk/index.php/The_Gantt_chart_and_the_usage_nowadays

http://apppm.man.dtu.dk/index.php/Gantt_Charts_as_a_Tool_for_Project_Management

http://apppm.man.dtu.dk/index.php/The_Gantt_Chart

http://apppm.man.dtu.dk/index.php/Gantt_Chart

=====Critical path=====
http://apppm.man.dtu.dk/index.php/Critical_chain_project_management_(CCPM)

=====Risk management=====
http://apppm.man.dtu.dk/index.php/Project_Risk_Management_and_Project_Risk_Management_Processes

http://apppm.man.dtu.dk/index.php/Management_of_risk

http://apppm.man.dtu.dk/index.php/Managing_Uncertainty_and_Risk_on_the_Project