Capturing and Using Milestones - Managing the Plan and the Portfolio

So, the last time we chatted I discussed the importance of milestones.  With this posting, I'd like to run through the milestones that I use, explain why I think there important and discuss how I'm beginning to use them within the overall lifecycle.  For purposes of this discussion, I'm focused on the resources and time components of the project.  We can discuss the "real dollar" budget vs actual in a later posting.

Let's get started and dive right in to the discussion. 

As I've discussed in previous postings, my teams use MS-Project to plan and track our project activity.  Each project is assigned a unique project number and name.  The project number is used to assist in standardizing many of the project artifacts that get created throughout the lifecycle.  The unique project number is used on op level artifacts that define the requirements and technical specifications all the way down to defects logged so that we can tie all activity with a project back together.

The Project Manager has the responsibility to create the project file.  They use a standard template that has been updated and modified over the last four to five years. 

• NOTE: This is important once you create our template (or any other project artifact) don't let it sit and collect dust.  Occasionally, you need to go in and dust off the artifact, in this case the project template, and see if everything still makes sense.
  
  • Do you need to add or remove default tasks?
  • Do you need to reassign default resources?
  • Does it make sense to update the time frames (start and finish dates) associated with default tasks?
  • Do you need to restructure the predecessors?

The template has sets of default tasks and milestones that we have defined for each of the six phases of the lifecycle that we utilize.  These tasks and milestones identify standard activity that normally occurs across the various teams involved within the lifecycle.  Some of these tasks are business functions, some of the tasks are technical functions.  So, from a management standpoint, I'm interested in several things:

1. What are the stop and finish dates for each of the identified phases within our lifecycle?
2. What is the point where we have enough knowledge where we can identify a target delivery date with a high degree of confidence?
3. Is activity on track to hit the identified target dates?
4. Are we on track to hit the baseline targets - or does the project file indicate that we will miss the milestone dates?
5. How do the start and finish dates within a given phase track against the overall projections used in portfolio management?
6. Are the resources projected within the portfolio accurate against what is being tracked in the actual project?

Within each of the six phases of our lifecycle, I want to know the start and finish dates of specific activities - these are my milestone dates.  So, automatically, across our six phases, I'm keying on the start date of the given phase and then a milestone towards the end of the phase that signifies that we consider activity within the phase complete.  Sometimes, there is trailing activity following the "finish" milestone.  That's why I can't necessarily rely on the finish date shown in the summary task.  For most organizations, you can probably get away with relying on your start and finish dates within the summary task - however, there will be some organizations that are like mine where there is some miscellaneous activity that goes on that you don't necessarily want to recognize as holding up the next phase of activity.

Next, we need to know when we are going to deliver the product in to production.  We can do all the planning and building that we want.  But the Marketing and Sales folks generally want to know when it's going to be available.  In many cases, they have marketing plans and communication strategies triggered by the implementation date.  Within our lifecycle, we have a standard milestone triggered at the completion of our Detail Design activity.  This is when we place a stake in the ground and commit to a delivery date.  (Side note, as with all things in life, sometimes we end up missing the date, but this is our internal commitment.)  Once the Detail Design is done, we create our final baseline (notice I said final baseline).  Once the final baseline is in place - that is what is used to create final stats at the end of the project.

Here is where it get's interesting.  On a daily basis, we have created a program that goes in and extracts these milestone dates from all active projects.  As well as collecting the milestone dates, the routine also captures the identity of all resources involved in each of the six phases of our lifecycle.  (This routine will be expanded to also capture the baseline dates stored within the project file.  No, I haven't perfected the whole thing yet.  We still continue to iterate through this and mature our lifecycle and metrics.)  This routine, also goes in to the Master Portfolio and extracts the estimated start and finish dates for each phase of our lifecycle as well as the resource projections.  All of this information is extracted and placed in a data mart.

So, at this point, I've extracted and recorded in the data mart, the estimated start and finish dates based on our Master Portfolio, the actual start and finish dates according to the Project Plan, the final baseline start and finish dates and the milestone activity identifying completion of our Detail Design where we establish our final baseline.   On top of all this, I have the projected resource allocations through each phase as well as the actual resource allocations recorded in the Project Plan.

On top of the data mart, we have created a web site that allows us to drill in to any given project: active, on-hold or waiting to be initiated.  The web site allows us to compare the actual plan against the overall portfolio projections both from a timeline perspective and a resource perspective.  As a manager, I can begin to answer the questions from above.  I can compare actual the start and finish dates of each phase of the lifecycle to the baseline dates as well as the portfolio dates to see if something has changed and if we need to make adjustments.  I can tell if our initial estimates are off and whether additional resources have been assigned to a given phase of the project.  I can tell when something has slipped that will impact our overall delivery date.  I can mange to the exceptions and initiate conversations with the Project Manager when I see something slip or when a date suddenly moves up in the schedule.

This is what works for my organization and what has allowed us to significantly increase the number of projects moving through our pipeline and increase the pace of activity.  We are by no means finished, we continue to tweak our lifecycle and the way that we are managing our projects.  But, based on the statistics drawn from these metrics, we have made a difference in the way projects are managed within the organization.

Speak up! What milestones are you using and more importantly how are you using them within the projects you manage?

Tags: SDLC, Project Management, Timeline, Tasks, Milestones, Budget, Template, Management, Projects, Software Development, Applications Development

If you'd like more information on my background: LinkedIn Profile