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