Managing Project Deadlines (Project Schedule)

The main difference between project activities and operational activities is the presence of certain terms during which the result must be achieved, and without managing these terms, the very existence of project activities makes no sense. Managing project deadlines is probably the main skill with which the very profession of a project manager is associated.

As you remember from the definition, a project is, among other things, a certain result obtained within a certain period.

If at first glance it seems not so difficult to determine what is included in the content of the project, and you can even estimate what needs to be done to achieve this, then how can you understand how long these actions will take?

It would be very cool if it turned out that, for example, we expect that we will do the project for 3 months, and this means that 33% of all activities will fall on each month.

But in fact, this rarely ever happens. You can even say never, because then it's a process, not a project.

External factors intervene, for example, reorganization in your company, the interest of stakeholders has a floating dynamics, risks happen, the project team goes on vacation, contractors get sick. And in principle, the activities during the life cycle of the project are distributed unevenly, as if they have different densities. And so on.

So how do you make project timelines predictable and manageable? After all, a lot depends on how long it will last and whether it will be completed on time: the resources and budget involved, reputation and much more (and sometimes your bonus).

Let's find out.

It usually happens that as soon as the idea of a project arises, a person immediately appears (for example, someone from the customer's side) who says: "Well, everything is very simple and clear here. So you can just start and in about a couple of weeks, well, at most, in a month, everything will be ready." And then he suddenly decides to make sure that you (the project manager) share his point of view and asks you: "Well, what do you think? Maybe even faster?"

What's the answer here? Sometimes you just want to say (maybe even somewhat emotionally): "You didn't understand anything! In fact, there is a car and a small trolley and it is not yet clear what resources will be required, and how soon the budget will be allocated and whether everyone will go on vacation - summer is coming soon. " But instead, you smile friendly and invite this hurried person to read the outline of the schedule, in which the deadlines are indicated. Don't forget to warn everyone that this is only a sketch for now. And that you still have a lot to clarify – both in terms of types of work, and the availability of resources, and the duration, and, possibly, even the order of implementation.

After we see the schedule in front of us (quite detailed), we can say that everything is more or less clear - it is necessary to follow it, try not to lag behind and not to be ahead (yes, to be ahead is also rarely good).

In order for such a schedule to be drawn up, it is necessary not to forget the following points:

• Define operations (work, activity);
• Identify the relationships between them;
• Estimate the resources required for work (activities);
• Estimate the duration;
• Make and regularly update (adjust) the schedule itself.
• So, we define and document (this is very important!) the composition of the operations that we need to achieve the goals of the project.

Project operations are the small elements that make up the work packages that we have learned to define in the hierarchical work structure (DPI). It is in this form that operations can be useful for controlling the timing of the project, the resources involved, and monitoring implementation. Since they are detailed enough to estimate exactly their duration and the resources that are needed for them.

It should be borne in mind that sometimes during the initial scheduling, we cannot sufficiently detail any package of works. Perhaps because external circumstances beyond our control do not yet allow us to do so. For example, we are waiting for some new clarifying information. So we'll detail that point later. The main thing is not to forget. This method is called the oncoming wave method. That is, the nearest actions are planned in detail, and the actions of future periods are planned at a less detailed level.

It also happens that some schedule or part of the schedule developed for another project can be used for your current project. So even better – if the initial data has not fundamentally changed – then you already have a proven schedule. It only needs to be adjusted. Don't forget to pick up the documentation for that project with a description of the lessons learned - perhaps there will be some mention of the schedule?

The figure below shows a schematic diagram of the Work Breakdown Structure.

Work Breakdown Structure

We will talk about the assessment of the relationships of operations, the types of dependencies between them, the assessment of resources and the duration of operations separately.