Defining the Detail-Level Plan

Now that we’ve successfully kicked off our project, we have a solid charter, an engaged team and an overall sense of what needs to be done. It is now time to dive deep by flushing out the detail-level plan and finally vetting with the entire team.

To start, I organize all the plan-related information gathered to-date and drop it into my project planning tool (e.g., MS Project or Smartsheet, depending on client preference). This information includes the:

  • Anticipated timeline and target milestones through go-live
  • Key deliverables (the “big things”)
  • Dependencies (what needs to be done or available before and/or after each task)
  • Resources (team members and any black-out periods)

At this point, we have what can be considered a skeleton plan ready for meat to be added to the bones. To do so, I’ll organize discussions with team members as follows:

  • For independent / stand-alone deliverables, I’ll meet with the person(s) responsible.
  • For sets of interdependent tasks (or work streams), I’ll hold group meetings with those responsible.

During these discussions we’ll confirm and flush out details of each major (and minor) deliverable. My approach to doing so includes breaking each deliverable down into bite-sized tasks by:

  • Determining the steps to be taken to complete each deliverable at the smallest unit of work that can reasonably be specified (i.e., the incremental sequence of tasks, each of which takes hours to a few days, leading up to completion of the major deliverable)
  • Identifying owners
  • Obtaining time estimates (click here to read the prior post on this topic)
  • Mapping the dependencies (predecessor / successor relationship) for each

Following are key pointers relative to the above…

Break deliverables down into “inch pebbles”

The reason it is important to break down large deliverables or tasks into incremental steps (of hours to no more than a few days) is to better understand the nature of the work to be completed, enabling better management of the project and dramatically reducing the risk of timeline slippage.

That is, if we have a task that someone indicates will take 20 days to complete, we can find ourselves mid-stream into that task’s completion timeline when the owner realizes they have “much” more to do than originally anticipated. The result is we may have to add multiple days to that task’s completion due to a lack of detail established during the initial planning stage.

Instead, if we’ve broken that 20-day deliverable down into several bite-sized chunks, we can track progress at a more granular level and will know (much sooner) if we remain on track or if a (now, relatively slight) course correction is required.

Don’t hard code dates

In its purest form, there is really only one date that needs to be entered into the project plan: the start date. That is, “most” of the other tasks are in some way related to the start date. As such, if we simply add our tasks to the plan and religiously setup predecessors and successors, the start and end date for each subsequent, related task will be calculated automatically. And, as we make adjustments (e.g., it is determined that a task will take more or less time than specified), we can simply update the time estimate for that task and the tool will re-project dates for any related downstream tasks accordingly.

The alternative, which I’ve seen too many project managers wrestle with, is hard coding dates which ultimately results in significant time spent on an ongoing basis to maintain the plan (dates) as the project (and reality) unfolds.

Note, there are exceptions to the rule (of not hard coding dates) including, but not limited to, the following examples:

  • A resource becoming available on a specific date
  • The date for which a vendor/supplier/distributor contract ends (or begins)
  • Quarterly and/or year-end close that we need to plan around

The point is, only hard code dates for items when it is absolutely certain there are no tasks in the plan that could serve as its predecessor.

Finalizing the plan

To be clear, this is an iterative process (much like combing the snarls out of a child’s hair). That is, I continue through the above cycle over and over and over again until ALL the details have been woven together into a cohesive plan without hitting any snarls. We now have a detail-level plan that is ready to be vetted with the cross-functional team.

To vet the plan with the team, I simply leverage our core team meetings. We may accomplish this by reviewing logical segments of the plan (if it is a particularly large project) in a few meetings or go through the entire plan end-to-end in a single setting. Doing so provides the entire team the opportunity to view and understand all the moving parts, the interrelationships and MOST importantly how each team member’s work fits into the overall plan. What I often find is the team becomes utterly mesmerized by the level of detail and specificity that has been defined which provides a much better understanding of and respect for the amount and nature of work to be completed. And, finally, we’ll have gone a long way towards instilling confidence that the project objectives will actually be achieved.

At this stage, our planning has either confirmed we can achieve the “desired” (a.k.a. target) go-live date specified in the project charter, or it has been determined that it is at risk. If the date is at risk:

Given that we have our team engaged and a detail-level plan which has been defined with and vetted by the team, it is now time to execute! This, in parallel with continuing to refine the plan as reality unfolds.

In closing, if you are looking to improve PM capabilities in yourself, or organization, feel free to reach out for an initial, no-cost consultation.

Click here to return to our topical index of articles on High Performance Project Management.

2 thoughts on “Defining the Detail-Level Plan

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s