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.
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.
Lets get in synch on the terms I'll use in this post:
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:
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:
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.
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:
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.
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:
In a further article, I'll explain how to manage deviations to the plan.