Using MS Project to Manage Project Milestones



The PMBOK® describes a milestone as a significant point or event during a project. Project milestones are also referred to as a Phase Gate, Stage Gate, Check Point, or Decision Point. In other words a milestone represents a significant point in time when a predefined segment of work has been completed, or the when a specific event has occurred.


Some examples of common project milestones include:

Recognizing Work Completed:

  • Project Baseline Complete
  • Technical Design Complete
  • Code Complete
  • System Testing Complete
  • Iteration 0 Complete
  • Sprint 1 Complete

Recognizing Events Occurred:

  • Business Case Approved
  • Software Solution Selected
  • Proof of Concept Approved
  • Software Installed
  • User Acceptance Test Approved
  • “Go Live”
  • Project Closed

A milestone may be mandatory, acknowledging compliance with external regulations or the organization’s SDLC, or optional in nature, recognizing completion of specific project work or events. In either case, managing milestones enables effectively measuring and communicating project performance throughout the project cycle — rather than waiting until the end of the project “hoping” the project is successfully delivered. I have been in more than one project briefing where a project stakeholder stated, “Shouldn’t we have known about this problem earlier in the project.” In every one of these situations, if milestones were established and managed properly, the problem would have been identified, and corrective actions implemented much earlier in the project life cycle. MS Project provides several features that enable establishing, and managing project milestones. I describe several of these features below in my 5 tips to manage project milestones.

5 Tips to Manage Project Milestones

1. Highlight key “junctures” in the project – During the process of creating the baseline project plan, milestones should be purposefully identified and inserted into the schedule. These milestones highlight compliance with SDLC requirements (e.g., stage gate approvals), completion of specific work or events (e.g., requirements complete), or connections of project work to external dependencies (e.g., approval of project deliverables by a government agency). These are all planned points in time during the project that you will measure planned vs. actual progress (time, effort, cost, and scope). For this reason you want to make sure that milestones are “sprinkled” throughout the project life cycle — milestones should be inserted every 10-20% of the overall project duration. Within MS Project a milestone is established by inserting a task with 0 days in duration (depicted with a u on the Gantt chart). I also find it helpful to highlight the project milestone with a different color text (see sample MS Project schedule below). In addition, MS Project provides filters and views that effectively communicate the project milestones.

2. Understand dependencies – Connecting predecessors to project milestones defines the work or events that must be completed to “declare victory” for that point in time during the project. In other words, dependencies are utilized to define what “done looks like” for each project milestone. In addition, dependencies attached to the milestone establish triggers for work to be initiated upon completion of the milestone (in the form of successors). Effectively planning the milestone successors helps ensure a smooth transition between phases / stages of the project. The picture below depicts using the MS Project’s Predecessor – Successor view to establish and review the dependencies tied to the project milestone.

3. Progress measured based upon milestones – Special attention is paid to project performance as it relates to project milestones. Finish variances tied to the project milestone are utilized to identify how completion of the milestone is tracking (vs. baseline plans). As variances are identified, dependent tasks / deliverables are reviewed to identify the source of the schedule related problems, and identify / implement the appropriate corrective actions. This represents an effective and efficient approach to quickly review and communicate project performance. Below is an example of tracking schedule performance associated with project milestones.

4. Change assessed based upon impact on milestones – The schedule impact associated with a project change must be assessed based upon impact on the project milestones, as well as the end of the project. Managing impacts at the project milestone level ensures that all stakeholder commitments are understood before implementing change requests (e.g., external project dependencies, scheduled events). Simulating the implementation of the project change within the project schedule provides in a very tangible manner the impact of the project change on the project milestone (see sample below).

5. Celebrating Success & Capturing Lessons Learned – It represents a best practice to celebrate success and capture lessons learned at project milestones. Milestone based celebrations energizes teams to take on the next phase of the project. As I mentioned in my blog on Project Celebrations, the celebrations should “sized” appropriately based upon the event or work completed. Capturing lessons learned at the end of a project milestone provides a couple valuable benefits:

  • It is most effective to capture lessons learned while they are “fresh” in the minds of the project team.
  • Capturing lessons learned at project milestones provides the ability to implement actions that will improve the team’s project delivery capabilities in future project phases. This approach is actively practiced in Agile projects, in the form of retrospectives performed at the end of each sprint.

Using SharePoint to Communicate Milestone Progress

While MS Project provides strong capabilities to identify and track project milestones, the project site on SharePoint can be leveraged to communicate the current status of project milestones. I utilize a custom list to create the Milestone Tracking list in SharePoint. Many stakeholders do not have access to MS Project, and the milestone list represents an easy to access and understand vehicle to consume milestone performance related information. In addition, this list can be easily incorporated into the on-demand project status report available on SharePoint.

Avoiding 7 Pitfalls – Using SharePoint to Improve Project Delivery

SharePoint 2010 is an enabling tool utilized to dramatically change the project environment. Creating a more productive project environment helps you launch the continuous improvement phase of your Project Management “Best Practices” program from a more efficient and effective starting point. Key elements of a more productive project environment include:

Collaboration – Enhancing your project environment to create more effective interaction between team members.

  • Providing a single source for the truth
  • Upgrading version control for key project artifacts
  • Establishing closed loop communications

Streamlining Processes – Utilizing a tool to establish or enhance project management related processes.

  • Establish structure via lists and libraries
  • Use workflow and alerts to reduce cycle time associated with reviews/approvals

Measuring Performance – Capturing the data required to measure project performance, and make the appropriate “course corrections”.

  • Measurements are a by-product of the project work performed
  • SharePoint provides a platform to communicate “real-time” project performance metrics

I have worked with a number of clients that have seen some incremental improvements in their project environment using SharePoint, but they have not realized tangible improvements in their project delivery outcomes. I will generally find common themes / problems in situations where SharePoint has not enabled more consistent and effective application of project management of best practices, and improved project results. These are all pitfalls that can be avoided with a well planned and executed SharePoint implementation to upgrade your project environment.

7 Pitfalls to Avoid

1. Do Not Move Beyond Document Management – Most teams start with using SharePoint to store project artifacts. In most cases this represents a technology related improvement (from share drives to SharePoint), but the tangible benefit of this function is limited to making it easier to find documents with a better search engine. I encourage teams to launch the new project sites with more than document libraries right out of the “starting gate”. Making the leap to using SharePoint as more than a document repository after the initial launch of the new project site always seems to require more focus and effort to achieve successful adoption of the new processes.

2. What Best Practices? – Many teams launch the new project site, and then start to think about what they could use it for. It is best to identify the core project processes and best practices that you want to improve through the implementation of SharePoint in your project office before the launch of the new project site. Project management best practices that are prime candidates to be incorporated in your SharePoint implementation include:

  • Organizing Project Deliverables
  • Managing Risks & Issues
  • Change Management
  • Managing Project Milestones
  • Project Status Reporting
  • Team Roles & Responsibilities
  • Project Meetings
  • Project Metrics

3. Teams Building “Their Own” – Trust me on this one, you do not want teams starting from a blank project site, and creating their own project management “best practices” on the fly. It pays huge dividends to take the time up-front to create a “template” for the project site. This template is used to create each new project site. The template ensures that the teams have a common “starting point” for implementing project related process. The project template also ensures that project metrics and reports are created in a consistent manner, and enables more effective “roll-up” of information to the project portfolio level. The following are examples of what should be included in the definition of the project site template:

  • Definition of metadata (e.g., definition of project status – Red, Yellow, Green)
  • Site permissions, using predefined project roles/groups
  • Libraries for project deliverables, organized in a consistent manner
  • Lists for managing key project information (roles & responsibilities, risks & issues, change requests)
  • Predefined workflows for specific processes that involve reviews / approvals (e.g., change control)
  • Views for communicating information to stakeholders in a consistent manner

4. Integration Gaps – Working at clients that do not have SharePoint fully integrated in with their overall infrastructure makes you understand the impact integration can have on your SharePoint implementation. For example, when clients do not have “single sign-on”, your team quickly gets annoyed with logging onto SharePoint each time they access the project team site. Pretty soon you find they access the site less frequently, and do not view it as a core element of completing project work. Another example of integration of SharePoint within your overall infrastructure is email. When your infrastructure does not include Outlook 2010, the project team cannot take advantage of the integration to fully automate workflows (e.g., approval of project changes) or manage team meetings (e.g., meeting workspaces).

5. Collaboration is Not a “Team” Thing – If the project team sees the value in the collaboration tools and processes, they will take ownership for updating and maintaining the project site. The value of collaboration is significantly diminished if the project manager is the only person providing updates to the project site.
The collaboration tool must represent the single source for current project information. As the project manager, you need to make sure team members use the tool in this manner (e.g., discourage people from maintaining work in progress offline on their own laptop).

6. Over Engineering the Project Sites – Many clients have a tendency to over engineer the project sites. Over engineering presents itself as elaborate structures for document libraries, capturing too much information to perform processes, or creating complex workflows for reviews and approvals. Ultimately adding all of these “bells and whistles” makes it harder for project teams to understand and utilize the site, and usually does not do anything in terms of driving better project results. The project sites should be set-up in a manner that requires very limited training to on-board new team members. In addition, avoid creating document libraries with many levels of folders – use metadata to organize the documents.

7. Projects End, Make Sure Your Artifacts Do Not – With a little luck, your projects have a beginning and an end. Decisions need to be made at the end of the project in terms of what happens to the project site. The information captured on the project site throughout the project life cycle represents intellectual property that can be leveraged to improve future project delivery efforts. Organizations that do not purposefully store and utilize project archives generally make minimal progress in the area of continuous improvement.

A Proven SharePoint Implementation Approach for your Project Office

The standard approach related to implementing a collaboration platform to upgrade your project environment includes the following:

  • Identify (or confirm) the “critical few” best practices that should be emphasized and integrated into the collaboration platform.
  • Establish some standards / guidelines that would be used by each of the teams (and a place where these standards are accessible). Some examples include:

    When to create project site

    What are the standard elements of the project site

    What meta-data is important for standard reporting or site organization

    Create templates for key lists and libraries (risks/issues, change requests, status reports document libraries)

  • Depending on the experience of your project team, you may need to provide training for the team on SharePoint. At a minimum you need to get your up to speed on the specifics associated with the implementation of SharePoint within your project environment.
  • Get started. Don’t wait until everything is perfect before you launch your new project environment. You will never get complete consensus on the standards/guidelines, and there is an opportunity cost associated with delaying the launch of your new project environment.
  • Establish processes to identify and capture best practices in the context of your new project environment. As these ideas are incorporated into the standard best practices they will be reflected as tangible continuous improvements.




PM-Foundations – Using Progressive Elaboration

Have you ever been assigned a project that seems to be “stuck” in the starting gate? There are stakeholders that support of the project, but there are too many unknowns, and not enough funding, to get the project launched properly. Here are some of the usual characteristics of this scenario:

Benefits: The benefits have not been fully developed. Benefits have been identified at a high level, but measurable benefit targets have not been established, or committed to. Stakeholders feel that quantifying the benefits will be dependent on making significant product and project related decisions (requirements, solutions, costs, time to market).

Requirements: Requirements are at too high a level to be able to define the work to be completed. Resolving open requirements related decisions, and adding specificity to the requirements will have significant implications on timelines, work effort, and cost estimates. Stakeholders also feel that requirements will be influenced by the capabilities and costs associated with potential solutions.

Solutions: There are several options available to solve the business problem. The different options have a wide range of costs, capabilities, and effort/time to implement. Decisions cannot be made on the final solution until due diligence on the solutions options is completed, and the requirements are more fully defined.

Funding: Project sponsors feel that the project has strong management support, but funding cannot be obtained until the business case is developed. The management team feels that without the business case they will be signing a “blank check” with no commitment on the project ROI. For the business case to be finalized the team needs to understand more about the benefits, requirements, and solution options.

In this scenario you often feel that you are caught in a “chicken and egg” type situation – which comes first the benefits, requirements, solutions, or funding. The obvious answer is you need to go through the planning process to make relevant product and project related decisions, and establish the baseline plan. However, given this scenario there are still several challenges with getting the planning process launched:

  • Based upon the significance of the unknowns at the starting point of the project, there are a wide range of outcomes from the planning process – benefits, requirements, solutions, costs, and time to market.
  • Due to the size or complexity of the business problem, the planning process represents a significant effort.
  • Funds or resources are not approved to complete the planning effort.

What should you do? This situation represents a great opportunity to apply progressive elaboration techniques (also known as, rolling wave planning). The PMBOK® describes rolling wave planning as a progressive approach to detailing the project management plan, where planning and supporting processes are completed in an iterative and on-going manner. This means that you plan to define and refine the project management plan beyond the initial planning process – completing project work to turn an unknown into a known, and updating the plans accordingly. Below I discuss several tips to using progressive elaboration to effectively launch & plan your project, and manage stakeholder expectations.

An aside on the analogy of “peeling the onion” to describe progressive elaboration: Completion of the project planning process is utilized to remove the surface layers of the onion. In many projects you are able to quickly cut through a cross-section of the onion and get a clear picture of the onion layers (future project work). In other cases, due to the complexity / size of the business problem, you need to “peel back” many layers of the onion before you are in a position to cut through a cross-section of the onion to understand the full scope of the product and/or project. This is the situation where progressive elaboration represents an effective project delivery technique. There are things you can do as a project manager to effectively manage stakeholder expectations during the process of “peeling the onion” using progressive elaboration techniques to establish an effective project delivery approach – no need for tears during this process.

6 Tips on Using Progressive Elaboration

1. Plan what you know – The place to start is to develop detailed plans (scope, schedule & cost) for the work that is required to better define the product and project. Many people would refer to this activity as the “plan for the plan”. This initial planning effort may require a single iteration or several iterations to complete, depending on the size and complexity of the business problem to be solved. Developing this portion of the plan allows you to talk to project sponsors about what it will take to make key product and project decisions, and develop a baseline plan. This plan will include many of the following key deliverables:

  • Business requirements
  • Solutions Analysis
  • Solution Selection
  • Project Management Plan (project schedule, project budget, project scope)
  • Business Case (project ROI)

2. Use Planning Components – Decomposition of the plan will not be possible for all deliverables or components of the project (sub-projects) for future phases. Planning components are inserted into the WBS to depict deliverables or sub-projects that cannot be decomposed to the work package level. The planning components represent “placeholders” for the project areas with significant unknowns. Without planning components it is not clear to stakeholders the areas where additional work will be added to the plan upon completion of the initial phases of the project. It is difficult for stakeholders to visualize deliverables and sub-projects that are “missing” from the initial plan.

3. Establish a timeline & a rough order of magnitude – One of the problems that stakeholders have with progressive elaboration is that they are uncomfortable investing in “up-front” work without having any visibility of what the “end game” looks like. Inserting planning components to depict future phases, and assigning rough order of magnitude type estimates (-10% / + 50%) helps establish an early perspective of the overall project plan (timeline and cost). This approach creates angst for many project managers because they believe that once an estimate is presented (no matter how preliminary it is), it is the date or cost that stakeholders will remember. My response to this concern is that there will be many situations where the stakeholders will not give you a choice but to present the “entire” picture. When I put together a plan in this scenario, I clearly depict the timeline and budget in two buckets: 1) what is known vs. 2) what is unknown. I will also clearly articulate the difference in level of precision associated with the two buckets.

4. Insert meaningful milestones – Milestones always represent a key component of a good plan because they highlight key events or achievements within the plan (e.g., approval of key deliverables, completion of project phases). With the use of progressive elaboration, milestones take on new meaning and importance. They represent points in time when the project team will have more information, and plan to make adjustments to the project plans. In most cases, there will be a milestone that establishes when the project baseline for the entire project will be completed and approved.

5. Get funding for the first “wave” – The key to the initial planning effort is to clearly articulate the scope, timing and cost associated with establishing the plan for the entire project. Your goal as the project manager is to obtain the funding for the “up-front” effort, and approval to launch the project. Before the project will be funded and launched you must convince key stakeholders of two things:

  • Based upon what we know today, this project has enough merit to invest in an “up-front” planning effort.
  • The “up-front” effort will be successful based upon the information detailed in the project management plan (scope, schedule, cost, and project management approach).

6. Progressive elaboration in an Agile delivery model – By definition, rolling wave planning represents an iterative approach. Therefore, this approach can be adapted well to an agile delivery model. Many agile teams refer to the “up-front” effort as “Iteration 0”. During “Iteration 0”, the team defines, priorities & estimates the product backlog, creates the initial product roadmap (articulating the initial content of each sprint), and plans the first sprint in detail. At the end of each sprint, the agile team will continue to use progressive elaboration techniques to re-prioritize the product backlog and adjust the product roadmap.

%d bloggers like this: