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:

  • Estimating: Science (or art :-)) of guessing the amount of work (often expressed in man*hours or man*days) required to perform a set of tasks.
  • Scheduling: Series of actions aiming at putting all tasks into consistent sequences of work, identifying dependencies between tasks and prerequisites (external dependencies), risks of delays and leading to delivery dates estimates
  • Forecasting: Series of actions aiming at establishing overarching project budget (in project's currency) taking into account schedule, estimates, team size and seniority, procurement and overall risk

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:

  • What you will have to deliver (eg. a bridge crossing a river) in the end
  • How you'll split this major delivery into more manageable phases
  • What you will have to deliver as "Work Packages" for each phase (eg. First foundations, second, main pillars which themselves are made of 2 masts and spacers...)
  • Therefore which basic elements you'll need to be supplied (eg. Raw material such concrete, iron girders or means such as a big crane)
  • Skills required to perform activities (eg. laying a foundation into a river is not something easy for any John Doe...)
  • Dependencies between tasks
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:

  • Use three points estimates as much as possible. It forces teams to figure out that there is risk hidden behind the tasks, and try to imagine which one could occur and what could be the impact on progress. And by reviewing the results, you'll have a metric on the level of confidence in estimates and will be able to list risky tasks (for which standard deviation is important)
  • Build your baseline by taking into account some contingency at each Work package level. This will allow you to build a not too agressive schedule
  • Think about risks. An integrated approach is proposed by Dr David Hillson here (available for free for PMI members)
  • Avoid overlapping phases. Project team has better performances being focused on a small number of topics at a time

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:

  • Minimal duration of the project
  • Critical path (or paths) and free float in this best case scenario
  • Number of near critical paths

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:

  • If team size is too small, you'll smooth workload consumption and will have a much longer schedule than in the previous schedule without resources levelling, entailing potential delay in the overarching plan

  • If team size is too big, you'll fit to a very agressive schedule, only constrained by dependencies and milestones. You'll have less queuing risk on resources, but far much risk of overrun in case milestones are not achieved

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:

  • Booking for the project (% of involvement, start-up and end date)
  • Vacations
  • Daily rate (several years long projects shall also take into account inflation depending on resources countries)
  • Seniority
Building this workload plan will therefore provide you with a more accurate view on
  • Resources related costs
  • Plug the holes in scheduling tool output
  • Based on resources daily rates costs of each resource
  • An overview of your project's seniority pyramid

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.

Comments  

#1 เครื่อ 2014-09-16 19:25
Thanks for a marvelous posting! I really enjoyed reading it, you're a great author.I will remember to bookmark your blog and may
come back at some point. I want to encourage you to definitely continue your great
work, have a nice morning!

You have no rights to post comments