Timelines - Not Just Something To Look At!

I've spent the last two posts discussing the role of the Project Manager - what I think is important for the Project Manager to do within the role that they play and how they not only need to manage the assigned Project Team, but also how they need to manage across and up thru the organization to be successful. Today, I'm going to switch gears and discuss one of critical items that the Project Manager owns.  The Project Timeline - for the purposes of this discussion, I am focusing on Project Timelines associated with the development of software.

Project Timeline Definition: The timeline consists of a series of interrelated tasks and activities within a given period of time representing the work effort needed to deliver some set of functionality in to the production environment.

We've discussed the overall Project Lifecycle in several previous postings.  For the purposes of speeding the discussion up, I'm going to assume that everyone is familiar with the stages of the lifecycle that I've discussed:

1. Discovery - defining the box around the activity of the project, documenting the goals of the project effort, the expected deliverables, potential costs and any deadlines that must be met.
2. Requirements - detailing both the functional and non-functional capabilities, features and attributes of the project deliverables.
3. Technical Design -  detailing the technical road-map (Technical Specification) that will be used to satisfy the identified requirements.
4. Development - the construction of the deliverable, including infrastructure and application pieces needed to satisfy the Technical Specification including both functional (user features) and non-functional (response time) items. 
5. Test - executing regression and new feature/function testing to ensure that existing functionality was not broken by the introduction of new features/function and that the new feature/functions work as expected.  Would also include load testing to ensure that the system performs within accepted time parameters.
6. Implementation - Activity associated with moving the new system in to the production environment.  This includes the code delivery, database changes, parameter file changes and infrastructure changes in to the environment.

Even with the simplest project, some combination of the above phases of the Software Development Lifecycle (SDLC) will be executed.  All of this activity combined together represents the Project Timeline.  From the very first discussions identify what might or might not be included in the final delivery to the actual implementation and post-implementation activity needed to validate that the system is working properly and that end users can begin using the functionality delivered within the project.

As stated in previous postings, not every project needs to follow every stage of the defined SDLC process or create every artifact defined within the process.  However, every project needs the minimal amount of ceremony and documentation necessary to ensure the success of the project.  More complex projects will require more ceremony - simple projects will require very little.  No matter the size of the project, there is still a start and finish date associated with the activity of the project.  Some organizations may not formally begin tracking activity on a project until it gets to the requirements stage, and that's fine.  Whenever you begin - you begin, and that is the start of your timeline.

So why is all of this important?  Well, first and foremost, the Project Sponsor and the management team are going to be interested in the overall timeline and how current progress matches up against expected progress.  In other words, how is reality matching up to the rosy picture that was painted at the beginning of the project?

Now, for the Project Manager to really manage the activity associated with the overall project, there must be reflection points where the team can evaluate activity done on the project to date and reassess the remaining activity to validate current expectations as it relates to the overall budget, resources and the Project Timeline.  Within the organizations that I've been associated with over the years, we have established standard points within the overall SDLC process where this assessment is performed and the results then communicated up to the Project Sponsor and the Senior Management Team.  In the organization that I currently work for, we formally handle this after each of the following milestones:

1. Requirements Completion: This is the first chance to validate the high level timeline initially envisioned when the Project was first initiated.  By this point everyone should understand what is going to be delivered, the touch points between the various systems/sub-systems, whether new infrastructure will need to be deployed and what testing/validation may be necessary.
2. Project Level Design Completion:  At this point the Technical Specifications have been generated and assumptions from the Requirements Phase have been validated.  Information needed to understand what 3rd party pieces need to be incorporated in to the delivery have been identified and initial cost-estimates are available, internal labor has been estimated and specific touch points between systems have been identified.
3. Detail Design Completion: At this point, the team involved in the construction of the system have been involved and taken the Project Level Design (Technical Specification) and turned it in to actual directions that the Software Engineers and Infrastructure Engineers will follow to create a system that satisfies the Project Level Design (Technical Specification) and ties back to the Requirements.  All activity/tasks related to the project have been identified and estimated.  All external costs have been confirmed.  All internal labor costs have been identified.

After the Detail Design Completion is hit, the Project Manager is responsible for establishing the final baseline.  To be honest, we currently are establishing baselines at each of these reflection points.  We are then using that information and feeding it back in to the teams to help them as they generate estimates for new project related activity.

At each of the above reflection points you are able to provide updated budget, timeline and resource estimates to the Project Sponsor and the management team.  This will be used to validate whether it still makes sense to pursue the project - or if the approval to move forward needs to be revoked.  

Why would they revoke a project that has made it this far in to the SDLC?  Any number of reasons:

1. The project no longer makes economic sense.  Initial cost estimates were too optimistic and did not account for all of the activity within the project, both internal and external.  Final labor costs or licensing costs may make the project unviable.
2. The Project Timeline does not allow the business to achieve the strategic goals associated with the identified deliverable.  Maybe the project had to be delivered by a specific date to beat a competitor to market and missing the date means missing the sales potential.
3. The defined deliverable no longer provides the competitive advantage necessary to gain in the marketplace.

As Project Manager, it is your job to establish additional milestones within each of the phases of the project to gauge whether the team is on track.   This also means looking at on-going activity within the project and the activity of individual team members to ensure that they are spending enough time on their assigned tasks to keep current activity aligned with the planned activity.

1. Did you allocate a resource full-time to the project?  Are they actually staying focused on assigned tasks and spending their workday on your project?
2. Was their a production issue that diverted assigned project resources?  What impact is that going to have on the overall timeline when they just spent the last four days resolving an issue for one of your largest clients?
3. Is activity on another project impacting the ability of assigned project resources to work on your project activity?  Your most senior developer has been stuck working an issue for the last 3 weeks on a separate project integrating code with a 3rd party who has been unresponsive.
4. An external party missed delivery of promised code or infrastructure pieces that are critical to the delivery of your project and they can't delivery the necessary functionality for another month.

There are a lot of things that will end up impacting the overall Project Timeline.  The Project Manager needs to continuously review current status against the plan and then work to remediate slippages identified within the overall Project Timeline.  Many times, the Project Manager will be able to do this without escalating up the chain.  However, some issues will require that the Project Manager escalate issues to the necessary resource manager, Project Sponsor, PMO, other management team members across the organization or the Senior Management Team for resolution.

How are you managing the Project Timeline within your organization?

Tags: Project Manager, SDLC, Project Management, Project, Management, Manager, Lifecycle, Software Development Lifecycle, Development, Software Development, Project Timeline, Timeline

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

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

Standard Milestones - What you want consistency?

If you're creating your project file from scratch for each project that you're managing, I have a short and simple question for you.  Why?

Step back and take a look at the projects that you're managing.  They all have the same phases (ok, small assumption here, I'm banking on the fact that you're preferred process within your organization is not a seat of the pants process).

1. Someone came up with an idea and sketched out the scope of what they wanted done.
2. Someone decided to flesh out that idea and put some requirements/stories to the idea.
3. Someone got involved and created a design for what the product would end up looking like.
4. Someone took the idea, requirements/stories and design and built the thing.
5. Someone then decided to test the thing to make sure that it worked.
6. Someone had to move it in to the production environment.

Now, maybe your organization is small and that "someone" was the same person start to finish. Or, maybe your organization is a little larger and you have dedicated teams doing all the work.

Regardless, if you are the Project Manager on any size project, it is your job to manage all of this activity.  Now, I personally don't care if you're managing all of this stuff inside of MS-Excel, MS-Word, MS-Project or some other tool.  I have always chosen MS-Project because I like it, others have differing opinions and I'm not going to pick bones about the specific product you use to manage your projects.  I want to talk about the way that you use the tool.

A couple of key points:

1. If you haven't created a template for the projects you manage - that's step 1.
2. If you don't have a set of standard milestones that you manage to within your projects - that's step 2.
3. If you don't pull data out of the plan and measure it regularly - that's step 3. 

As Project Managers we should not only be looking to manage activities within our projects to the 3 standard goals: time, money and resources.  If we are really doing our jobs, we are also trying to eke out efficiencies along the way.  One of the primary ways that you can drive efficiencies within any process is through standardization.

If you standardize the way that you run your projects - the team members that you use for projects know what to expect.  It makes it easier from project to project - they know what information you're looking for, they understand how you want it communicated and through the use of standard milestones, they know what goals you're driving to and what is important.

Just as important, the project sponsor sees a consistent set of milestones and metrics that you are using to drive your projects.  They begin to get a feel for what things are important to know about within the project, they understand how to begin looking at standard milestones to get a feel for whether the project they are championing is on track, whether resources might need to be reallocated if certain pieces of the project are falling behind, their confidence level in the process goes up as they see measurable data vs feel good talking points.

You can find plenty of standardized templates on the web for software development - though I highly advise against just pulling one down from the internet.  In previous posts, you've seen me rail against taking someone's idea of a SDLC process and cramming it into your organization.  The same is true for project artifacts - including the Project Template.  The Project Template should be driven by the culture of your organization.  It should include the phases that your organization and team feel are important, and it should include the tasks and milestones that you feel reflect the work effort that your company and team value.

There is a fine balance between not enough detail in the plan and too much detail in the plan.  Hint - err on the side of simplicity.  Start small and add additional detail as there is consensus across the organization that more detail is needed.

So, you're probably wondering - what's the difference between a task and a milestone?  Good question!

1. A task represents a package of work to be completed within the overall effort of the project - it is a tangible delivery that has resources, time and budget.
2. A milestone is placeholder used to signify that a collection of tasks have been completed and by itself does not have resources, time or budget.  Milestones represent points of interest within the overall SDLC that allow the Project Manager and Project Stakeholders to make judgements on the progress of the overall project.

Now, that you've generated a project template and you've standardized the milestones within your project - what do you do?

Okay, here's the secret sauce - first take a snapshot of the overall plan and establish your baseline schedule.  Only update the baseline if the Project Sponsor agrees that the overall timeline, budget or resources can change - or, if within your process you have identified specific points within your lifecycle where you re-establish the schedule and then reset the baseline.  (Typically, many organizations reset the baseline once final designs have been completed and they have a firm understanding of the development effort.  Within an Agile process, this would represent each sprint.)

Once you've baselined your project - you can begin analyzing activity within the overall project and reference the baseline.  This allows you to:

1. Identify slippage associated with dates - things that get done faster usually aren't a problem.  Understanding when things are going to take longer than expected is when the Project Manager really needs to step in and drive activity.
2. Identify cost differences.  If you're using your project template correctly, you're not only accounting for resources assigned to specific tasks and the timeline for each task.  However, I'd challenge you to go one step further and track all of the equipment and software that need to be purchased for the project within the Project Plan.
3. Identify when resources are over-allocated - this is a huge need within most organizations.  Anecdotally, they can tell when resources are swamped, but they have a tough time proving to management that more resources are needed.  Well, if you're tracking your allocations within your project and your capturing the actual time spent on tasks, you will be able to prove when you're over-allocated.

Hopefully, you've seen my previous postings on establishing and using metrics within the SDLC process.  If so, you know that I'm a big believer in measuring what is valuable to your organization.  If you haven't been producing standard metrics from your Project Plan up to this point, now is the time to start.  You should be able to track progress against your milestones and be able to report that up to the Project Sponsor.  You should be able to compare current milestone dates to baselined dates and report slippage up to the Project Sponsor.  You should be able to identify when people are falling behind and, hopefully, step in sooner to mitigate the overage.

Have you standardized your Project Plans and are you using the Project Plan to drive activity within the overall SDLC?

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

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