Print

As a senior VP explained it to me, a project consists in a very stable geometrical shape : a triangle (assuming a constant quality - something we don't want to compromise). It's stable until someone decide to move one corner. In this very case, other corners will move in response to this change.

In order to spread the word about the famous triangle, following my recent experience in this field, and common mistakes made by junior project managers, I've decided to share lesson learnt on scheduling and forecasting.

Project Manager's duty

Now these terms are defined, one of the main roles of a Project Manager is to initially produce a forecast and the associated schedule for a given scope, to commit on these elements which are called Project Management Baseline (PMB), and to monitor progress against this PMB.

As perfectly highlighted in PMBoK (Project Management Body of Knowledge) guide, each change in the scope shall lead to look back to the Project Management Plan, and modifying the PMB accordingly.

The goal of this article is to explain how you get there first. It will be followed by several articles on how to manage and adjust the plan.

Estimating ? Scheduling ? Forecasting ?

Lets get in synch on the terms I'll use in this post:

Steps to build a well crafted initial forecast

Scope - First, define WHAT you have to do

As explain at least a dozen times in PmBoK guide, first of all, you have to know what you have to do, at the most granular level of details possible for the time being. Of course, at the begining of a project, it'll only be a best guess, but however, the sole fact of thinking about it helps to clarify:

This takes the form of a WBS which serves as a reference for all deliverables to be produced, as well as a structure which will host the list of activities required to build any of the work packages. The rule is "What is not listed in the WBS is not to be done".
Of course, for huge projects, WBS will be refined during project's life: it'll be very granular for first phases of the project and less granular for following ones. It also allows not to feel overwhelmed as it's structure allows drill-up and drill-down : a high level dependency between 2 work packages will be refined by dependencies on activities under these work packages : This process is called rolling wave planning.

Costs & durations - Estimates that will be the foundation of the plan

Now, you know quite precisely what you have to do thanks to your WBS, and the dependencies between work packages. It's time to estimate costs and duration for each group of tasks bundled in work packages.

I'll not elaborate much on this process as it's a topic on its own, and large numbers of articles are available on this topic. I just want to share lessons learnt from practical experience:

The goal of this part of the process is to obtain a schedule in which all dependencies have been registered and durations have been estimated. This schedule will provide you with the following information:

Schedule - Draft schedule & resources levelling

After the work performed on the previous step, you've got now a kinda unrealistic schedule, not taking into account the team size in scheduling (except if duration estimates are effort driven).

However, depending on the size of your team, you'll be either constained by resources availability (too small team) or schedule constraints (too large team). Working on tasks assignments and optimized size of the team will allow you to arbitrate between several decisions which will impact the engagement you take:

To sum this up, team size shall be carefully chosen to optimize constraints between pure schedule constraints and resources constraints in order to have the shorter schedule for the given team size and a team size which is sufficient to be resilient to some schedule risks but small enough to limit impact on costs when a delay occurs. This topic is dealt with in this article.

Refine your schedule leveled with resources, chose appropriate profiles (seniority, skills), name resources as much as you can (building a plan on not yet identified team member is a risk), and come to a realistic schedule, one you feel comfortable with.

Forecast - Putting together Scope, schedule, resources and costs

Now, your plan is taking off. You have estimated efforts and durations for all your work packages, you've got a schedule, you've carefully matured the size of the teams, and have established a realistic schedule thanks to all these pieces of information. Now it's time to build the Holy Grail of PM: project's budget.

Project's budget in currency is basically what is asked for to PM during initiation phase and precised during planning phase. Junior project managers often make the mistake of summing up costs of activities (often from scheduling tool such as MS project), material and infrastructures, subcontracting to establish project's budget. But this is an incomplete budget which often puts them in trouble.

Indeed, when you're comfortable with your schedule, you have some "holes" in resources assignments. These can result from skills profiles of resources you use, dependencies and size of the chosen team. These holes in assignments are not accounted for by scheduling tools, but in real life, once you've onboarded people, they're on board ! They'll consume your budget, even if tasks dependencies let them unassigned at some times. That's not a bad thing, because in case of risk occurence, they can help to mitigate impacts on schedule.

The goal of this phase is now to rely on resources leveled schedule to build a forecast or workload plan, which details resource per resource, work package per work package:

Building this workload plan will therefore provide you with a more accurate view on

Summed-up with subcontrating and material / infrastructure costs, you've got to add a management reserve to come to a project's budget with drill down/up to each node of WBS capability.

Conclusion

A PMB is the result of a comprehensive process and can be communicated only with appropriate assumptions taken on scope, schedule and team size. A well crafted project plan thoroughly describes all these elements, and provides information on forecasted budget per WBS node, and how these budgets are consolidated at project level.

A project plan audit shall always assess:

  1. How comfortable the PM is in drilling down and up into the WBS,
  2. If the WBS level of granularity is sufficient enought to estimate accurately work packages efforts and durations,
  3. If efforts and durations estimates are based on historical data,
  4. If organizational structure of the project is reflected in a balanced pyramid of costs,
  5. How risk balance between too small / too large team are mastered and,
  6. If free float with given team size have been budgeted with appropriate rates

In a further article, I'll explain how to manage deviations to the plan.