Milestone Planning

Latest revision as of 15:44, 28 February 2021

The characteristics for a successful plan are to provide a path that lead towards a specific goal within a projects scope. The path to create a decent plan can be divided by various activities, uncertainties, phases, and decisions. The similarly between those unknown variables are that they are a part of a milestone plan which is an essential project, program and portfolio management tool. Managing or using a milestone plan allows management on different detail levels. The tool can navigate between important phases and its decision points. ^[1]

A milestone plan is constructed by milestones instead of focusing on activities. When using a milestone plan in a project planning it gives a goal- and result orientated planning. ^[2] In a beginning of a project a milestone plan can give assistance to clarify some of the deliverables for the project within the present knowledge. It is important to know the project goal(s). Some project goals are not concrete and therefore alternated although the planning. Changes though the planning is necessary to reach a common goal that satisfies all stakeholders. The goal can be redirected by new knowledge and that is why it is important to have milestones which create decision points on “are we going in the right direction, or do we need to alternate our future planning?” or “have we achieve the deliverables for this milestone?”.

This article will explore a few scenarios where a milestone plan is either used in a program plan or a contribution to create a monitoring tool that allows a common review of the project, program, or portfolio achievements. Furthermore, the concept and approach in a milestone will be reflected and the limitations regarding a milesone plan will be discussed.^[3]

"Be aware that the images may be incorrectly aligned with the text if the screen resolution of your PC is set to other than 125%"

[edit] Context

Figure 1: A organizational strategy inspired by figure 1-3, page 12 from PMBOK® Guide – Sixth Edition (2017) ^[4] made by Victor Nørregaard Schwærter.

• A Project has a life cycle and contain various elements such as activities, objectives, focus, benefits etc.

• A Program is defined by multiple projects which are grouped together. With subsidiary projects it is possible to track the interdependencies and which intended benefits are achieved. This may not be possible by managing each project individually.

• A Portfolio is an effective managing of multiple programs and projects. Portfolio is a process with subsidiary programs and projects that are grouped to gain strategic objectives. ^[4]

Planning is an essential part of every aspect for managing a project, program, or portfolio. A milestone plan can be used and executed in all detail levels and are used for different purposes. One reason could be that a project and a program both include elements of time. Time regarding a project or a program indicate that it is temporary. Even if a program takes years or decades to fulfil its planned achievements. In contrary, a portfolio does not need a specific deadline.

A portfolio encompasses various elements of initiatives and work is not related to each other, to attain the planned benefits. The beginning of initiatives is related to an organization’s strategic plan. The organization’s strategic plan can control the start, or the end of a specific investment. This means the owner(s) of the portfolio are grouping resources dependent on different subjects such as the geographical area, work that are delivered to the same client, etc. In these scenarios it can be complex to use a milestone plan.

A plan that consist of milestones for a portfolio could be used, but it cannot obtain concrete monitoring, because activities not necessary are linked together in a portfolio. To get an overview of the relationship between projects, programs and portfolio: figure 1 can be used. Figure 1 illustrates a strategy regarding an organization as an example. As mention earlier, a portfolio can contain other portfolios and programs. Portfolio management can include stand-alone projects or have multiple programs before it reaches the portfolio level. The objective of these variations is to gain the planned benefits or sub-goals. Furthermore, it is important to notice that the relation between a project, program, or portfolio is they all share resources and stakeholders.

This information is critical, because there is a limit to the resources and which project it is allocated to. The variation for the structure of portfolios is important regarding resources. You can ask yourself “does a portfolio have 3 programs and 5 projects that need resources?” or “does a portfolio consist of 1 program with 10 projects?” This difference changes the allocation of resources and the strategy to group resources for every part. ^[3]

[edit] Explanation and its purpose

[edit] Complexity in projects

A milestone plan is a logical path towards the purpose of a project. However, projects are complex. A project is typically divided into parts of purpose, people, complexity, and uncertainty. All parts are important and provide methods, knowledges, and tools to deal with every aspect of handling a project. In general a project requires a schedule to stay on track. When all activities of a project is made clear and known, the schedule is depended on time. This is possible when all activities are clear and known. In many cases it is not the case. When working on a case many questions and uncertainties will rise. Most uncertainties are linked to the missing knowledge on the topic. Is it a "common project with high knowledge or is it a unique project with low knowledge?" This can increase the complexity drastically and to control complexities, they can be divided into subcategories. A quick view of possible complexities in a project is:

• Technical and task complexity
• Time complexity
• Goal complexity
• Social complexity
• Organizational complexity
• Legal complexity

Every subcategory relies on methods, concepts, or tools that helps solving the equation for complexity. This is were the milestones can be used as well as a Critical Path Analysis, Gantt chart, etc. When investigating complexity in projects you look at questions like: “how much time does it take to complete an activity or task?” and “when can an activity begin then it will achieve the planned result?” or “how many resources does an activity need and does it require help from individual expertise?” ^[5]

By diving into the complexities of a project it is vital to know the scope of the project. Goals for a project is usually set to a predate based on the initial knowledge. In other words, the main task for complexity is to create structure. There are many ways to create structure for a project, however, the main objective for this paper is to use a milestone plan tool to create structure for your project. The layout for explaining and discuss a milestone plan is inspired by the literature Power i projekter og portefølje , in which a practical approach concerning a milestone plan is explained. ^[1]

[edit] Step by step

Figure 2: A projects purpose divided into deliverables inspired by figure 5.2, page 151 from Power i projekter og portefølje^[1] made by Victor Nørregaard Schwærter.

The first step toward a structure is to separate the purpose of the project into deliverables, which is needed to be able to make milestones. When all deliverables are fulfilled the projects purpose is achieved and that is illustrated in the right-side of figure 2. As it is visible, the purpose is divided into deliverables. To achieve every delivery there is created work packages. These work packages are main activities that later leads to a delivery. A work package contain multiple activities and they can be either goal- or result orientated. Several projects are using Work-Breakdown-Structure, shortened WBS. This method provides a hierarchy that break a project into phases, deliverables, and small work packages. When a delivery is concrete it will become possible to manage. As an example, a construction of a house is divided by several deliverables which involved contractors. With a separation of the contractors, they will experience to be limited to a specific amount of time. Also, they may do critical work before another contractor begins. So, a contractor is responsible to work within a certain time and trust other to deliver their work on time. If one contractor is delayed it can delay many activities. If this occurs and it pushes other activities, then the critical path is located. Another example would be for an organizational project of change The deliverables for a case like this could be by separation into subjects as organizational structure, work patterns, implementation of a new IT systems, provide guidance for employees, etc. The common question for both examples is: "is the knowledge high or low?" A carpenter has built a wall numerous times and knows how to estimate the time to finish one wall. Nearly all participants involved in the construction of the house knows the required time for doing their work. A project of change in an organizational has other factors than estimate the work and delivery of physical products. To change an organization, it also demands a change of people and their individual work routines. They must learn how to adapts and execute a new implement as an example. As mention earlier, this could be by learning a new IT system or a radical change in their everyday work life. Also, people tent to disagree changes because it affects them. ^[1]

Figure 3: Definition of milestones inspired by figure 5.3, page 153 from Power i projekter og portefølje^[1] made by Victor Nørregaard Schwærter.

The second step is to establish milestones regarding the work packages that are illustrated by a diamond shaped geometry in figure 3. A milestone is a sub-delivery that leads to certain deliverables. Milestones can depend on another milestone. As discussed earlier in the first step, there are two ways to achieve a schedule. Typically, one way is to have a project that has been standardized which means the activities are known. This structure tents to focus on activities before using milestones. The other way is when activities are unclear, then it is important to keep track on the deliverables. This structure uses milestone before focusing on activities. If activities are unknown, it would be best to establish milestones. A reason to use milestones before activities is that a milestone does not alternate throughout a project. There are many possibilities or rather activities that lead to a milestone. A quick example could be that you are bicycling home to your parents, and you know three different roads to get home. The distance and time for the three roads are important, but the main objective is that they all lead you home. The roads symbolize activities and your parents’ home is a milestone. This is three different ways to reach your sub-delivery to get home. ^[1]

Figure 4: Understand the milestones logical order inspired by figure 5.5, page 156 from Power i projekter og portefølje^[1] made by Victor Nørregaard Schwærter.

The third step is to understand and organize milestones into logical ties or dependencies between milestones. They may be time depended. For being so, the logical order is just as important as every milestone achieving its goals. To illustrate this the milestones are added to figure 4. The milestones after the black milestone are changed due to the result from the black milestone. Other aspects for the black milestone are that it has several resources attached. This means there could be more areas of responsibilities within it and they are all depending on the result. If the deadline for a marked milestone are changed it is important to include all parts concerning the specific delivery for that milestone. If there are two work packages that shares several milestones it will be recommendable to combine them into one, because they properly have the same deadlines. ^[1]

Figure 5: A milestone plan divided into phases inspired by figure 5.6, page 157 from Power i projekter og portefølje^[1] made by Victor Nørregaard Schwærter.

The fourth step happens after all milestones are established and dependencies between the milestones are determined. The separation into phases can be created and this is shown in figure 5. The figure shows the deliverables and work packages separated into phases. The purpose of the phases is to divide the project into main subjects. It happens when a project changes character and the initial knowledge increase and the uncertainties decrease. With every phase the knowledge increases and the uncertainties decrease. The critical purpose for a phase is to finish a main subject that provide a clear perspective for the next phase. The first phases are early analysis or design phases where it is used to create clear problem statements. When a proper problem statement is done the beginning of work packages can be distributed. When performing the implementation phase the manager can provide guidance and coordination for all deliverables. All milestones do not have the same deadline at the same time. ^[1]

Figure 6: Decision points inspired by figure 5.7, page 159 from Power i projekter og portefølje^[1] made by Victor Nørregaard Schwærter.

The fifth step is to include decision making or decision points near a new phase. In figure 6 is added a decision point to every phase. These decision points are useful to monitoring and plan the next move for a new phase. It is important to discuss the criteria for starting a new phase. The stakeholders must approve going further with the project and focus on the next phase. Aspects must be discussed, such as "has the uncertainties decreased enough to continue with next phase and do we reach our expected result at this point?” or “do we have to rethink our anticipated budget or risk management and is this project relevant anymore?" Those questions are an essential part to estimate a qualified guess for the future. Do not make the mistake to forget including decision points because "has the phase achieved its goal?" Practically, it is advisable to mark the deadlines for each decision points then a project manager or other stakeholders can prepare for them.^[1]

Figure 7: Critical path by figure 5.9, page 161 from Power i projekter og portefølje^[1] made by Victor Nørregaard Schwærter.

The sixth step it about defining the activities that fulfils the needs for every milestone. The activities are not clearly defined for every milestone. That is one of the reasons it is good to start dividing the main activities when the knowledge is high enough. It is not necessary to know all details in the beginning. That is why it is better to have an overview for the whole project with a milestone plan. To complete the activities, questions stating “how, when, and where” is needed to accomplish the project. Besides knowing the activities, it is important to secure that the activities does not clash into one another. This occurs when activity A is more critical than activity B. This phenomenon is called the Critical Path Analysis which is illustrated by figure 7. Furthermore, it is about investigating which path that can delay the entire project if something is delayed. Several activities can be ongoing but if they are not linked together or near a milestone they are not as critical. This is also illustrated by figure 7 where the deadlines for each activity is different and activity A in this case is the critical one.^[1]

[edit] Guidance with a practical approach

Figure 8: Application of a milestone plan on a project to build a house made by Victor Nørregaard Schwærter.

To give an example of how to use a milestone plan in practice this section will focus on a project that has the job of building a house. To describe this milestone plan figure 6 will be used and filed with information as seen in figure 8.

The purpose of the project is to build a house, which has been done numerous times. That means the knowledge level is high, and uncertainties are low, since there are standards for, how to build a house. It is common to use a milestone plan that is created by the known activities. Along the way, activities are used to determine milestones and then a deadline is fixed. The approach for this case will mainly follow the previous section: Explanation and its purpose.

When building a house there are several contractors involved which include their corporation and knowledge. That is important for the project. When you want to build a house and you are paying, you become the Builder or owner of the house. It means that you are in charge, but you do not need knowledges regarding buildings So, the deliverables are divided into category as contractors, payments, documentation, quality check, etc. These deliverables are not completed at the same time, but they are all depending on one another. Those deliverables are shown in figure 8. As an example: you need to install the plumbing and electrical installations before closing the flooring. If the floor is closed before they are done, it is impossible to finish their work. This example does illustrate a need for a milestone because the floor cannot be finish before the pluming nor electrical installations are finished. The activities for building a house is known. An estimation for a deadline is possible when corporation with the contractors.

Using milestones for planning decide the delivery date of the house, but those milestones can even be used for ongoing payments to the contractors. As an owner, you are not obligated to pay all the expenses to the contractors or other involved in the beginning of a project. This depend on the agreement between the owner and contractors.

In a case like this: it would be practical to get an overview for the phases depended on the initial knowledge level upon building a house. There are known phases which is commonly used when building a house and those phases are: design phase, project design, implementation phase, and operation and maintenance. In other cases where standard is not available it would be advisable to find similar projects or literature that can provide guidance. Concerning the decision point, it is used to monitoring the project and its deadlines. These dates are important tool to control and check the contractors if they are following the schedule or not. Typically, a schedule for a plan is created with a Gantt chart. A Gantt chart is a scheduling tool that can illustrate and monitor a project into the desired detail level. Often are this done digitally, and the schedule follows the milestone plan. ^[6] By combining a milestone plan with a Gant chart, it creates a practical way to monitoring without a daily visit to the constructions site. On a construction site is it recommendable to use a management method called Lean management. ^[7] In short terms it provides for example a weekly meeting on the site where all contractors are together to discuss the present challenges that has occurred. On these meetings the opportunity to discuss and deal with the known critical part of the project or which elements that can influence the project in the future if they are delayed.

[edit] Limitations

There are many aspects to a milestone plan that need attention and clear meaning. First, a milestone plans application strongly depends on the project strategy. Up until now a milestone plan is mostly explained by an implementation strategy. This type of strategy tent to focus more on detail levels rather than the principles on how a project can reach its goals that are planned by the base organization. This means that an organization can describe how a project should reach it goals and compromise several activities. In the previous sections, milestones are described to be dated as deadlines or events which often is correct but mixes two components together. A milestone consists of what we want to achieve and when we are there, that is the deadline or event of a milestone. Now, we know want to achieve and when its deadline is, so "how does a project manager or stakeholder determine that we have reached our goal?" and "is the delivery a physical product, or is it an abstract quality?" Those two questions: are worlds apart, because they are not comparable. It is great to make a milestone plan, but if a delivery, or a goal does not have a verification tool or description it is hard to tell whenever a delivery reaches the expectations for that specific milestone. This is a huge point, because if the goal for a delivery is not clear then: "when are the delivery good enough to proceed to the next milestone?" ^[2]

Another reflective thought on milestone plans and its application is "how detailed can or should a milestone plan be? A milestone plan is a logical path toward the purpose of a project. Milestones are not supposed to changed even if there are radically changes to the activities. A milestone is a robust structure that stand its ground throughout a project lifecycle. Furthermore, a milestone plan does not need to be in great details, because every achievement is descried and how it is going to be evaluated. The activities within a milestone can changes due to gained knowledge or decision making from stakeholders etc. Again, this does not change the intention for a milestone. This does not incite that detailed planning is unimportant, because it is not! It is important to plan in detail when it is necessary and not just, because you have to make a detailed plan. An early detailed plan can lead to unnecessary discussions because a milestone can reach its goals in different ways. Every milestone needs separate activities and therefore a detailed plan could be made for each milestone. The start of a milestone is something that is determined by a project manager. When activities for a milestone is known is it possible to create a schedule, because an estimation of time can be done by knowing the activities. For scheduling into further details a digital Gantt chart are usually used. ^[2]

In context to project, program, and portfolio management: it was discussed that a milestone is most suitable for a project, or program. This may be true upon a common understanding of a milestone plan being used for concrete projects or programs. As discussed earlier: "what define a milestone success and are the delivered deliveries enough?" This may be clearer within a project, or program, because the purpose, or scope can be measurable. In contrary, when managing a portfolio: "how can we determine whenever a milestone is achieved or not?" Of cause, there must be a description of what a milestone should reach, but "when is it good enough?" It is not impossible to obtain, but due to the uncertainties and its complexity it becomes easy to lose track of the scope in the process. Especially, when a portfolio can take years and even decades to achieve. Furthermore, addressing the milestones in a way that allows non-experts to understand the scope of the project is good practices for programs and especially portfolios.

In general, a milestone plan can be used whenever you are a project manager in a project, program, portfolio management. The important aspect: is to navigate between the initial knowledge and which goals that are set for the scope. This discussion is based on subjects form the annotated bibliography and a critical article which discuss milestone planning in different approaches. ^[2]

[edit] Annotated bibliography

• Attrup, M. L. and Olsson, J.R. , Power i projekter og portefølje, DJØF Publishing (2008), ISBN: 978-87-574-1665-7.

This reference discuss the concepts of various management tools including milestone plan. It establishes the basis for at great planning within a practical approach. Beside the basis knowledge, it successfully connects specific parts to a project, program, or portfolio management. When planning a project independently the path to achieve it may be different considered to several reasons. Some of the reasons could be the present knowledge and which effect it has on stakeholders and the steering committee. This balance of information on the concrete management tools and how to implement them on a project, program, or portfolio is why this reference is annotated.

• Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition). Project Management Institute, Inc. (PMI).

This is a standard regarding project management and knowledge. It provides knowledge on the relationship for project, program, and portfolio management. The relationship is illustrated by an organizational approach toward an understanding that embrace the differences.

• Andersen, E. S. (2006). Milestone planning—a different planning approach. Paper presented at PMI® Global Congress 2006—Asia Pacific, Bangkok, Thailand. Newtown Square, PA: Project Management Institute. Retrieved form https://www.pmi.org/learning/library/milestone-different-planning-approach-7635.

The article: Milestone Planning - a different planning approach, critically discuss different approaches referring it all to a milestone plan. Besides, a reflective and constructive explanation for what a milestone is and when can a time schedule be planned etc. those subjects and other aspects are described with convincing details and references. Furthermore, the author is capable of navigating between different topics and create concrete statements. This is some of my reason to recommend reading this article to everyone that is interested in milestone planning. This article by expand your knowledge upon the topic.

[edit] Reference

1. ↑ ^{1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13} Attrup, M. L. and Olsson, J.R. , Power i projekter og portefølje, DJØF Publishing (2008) - Chapter 5, page 145-201 ISBN: 978-87-574-1665-7
2. ↑ ^{2.0 2.1 2.2 2.3} Andersen, E. S. (2006). Milestone planning—a different planning approach. Paper presented at PMI® Global Congress 2006—Asia Pacific, Bangkok, Thailand. Newtown Square, PA: Project Management Institute. Retrieved from https://www.pmi.org/learning/library/milestone-different-planning-approach-7635
3. ↑ ^{3.0 3.1} The Standard for Program Management — fourth edition. ProQuest Ebook Central https://ebookcentral-proquest-com.proxy.findit.dtu.dk.
4. ↑ ^{4.0 4.1} Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition). Project Management Institute, Inc. (PMI). Retrieved from https://app.knovel.com/hotlink/toc/id:kpGPMBKP02/guide-project-management/guide-project-management.
5. ↑ Geraldi, J., Thuesen, C., Oehmen, J., & Stingl, V. (2017). How to DO Projects? A Nordic Flavour to Managing Projects. Dansk Standard. DS Handbook Vol. 185
6. ↑ Wilkens, T. T. (1997). Are you being misled by your progress Gantt chart? PM Network, 11(8), 42–45.
7. ↑ Moujib, A. (2007). Lean project management. Paper presented at PMI® Global Congress 2007—EMEA, Budapest, Hungary. Newtown Square, PA: Project Management Institute.