Typical mistakes and problems in the practice of using schedule network planning

With regard to schedule network planning, I have heard many times: "This is all good in theory, but it doesn't work in real life."

I absolutely disagree with this. I know many examples when the use of schedule network planning gave an effect hundreds of times greater than the cost of it.

At the same time, I would like to note that indeed, the implementation of schedule network planning is not always successful. But not because it is a bad tool, but because it is not always used correctly and correctly.

I have seen the process and results of implementing schedule network planning in several dozen companies and projects. Based on this experience, below are the most common mistakes and problems that I have seen in practice, as well as some recommendations on how to avoid them.

1. Implementation for the sake of implementation

In many cases, problems began at the stage of setting a goal, which sounded like "develop a schedule network schedule" or "implement the Oracle Primavera program." And this goal was formally successfully achieved: the necessary programs were installed, instructions were written, people were trained, schedules and schedule network models were developed. But there was no practical benefit from all this beauty.

Because schedule network planning is a means, not an end. The mere presence of a schedule network schedule does not provide any economic effect to the project. The economic effect arises due to the adoption of management decisions based on data from the schedule network schedule, which is described in detail in previous article:

Examples of such solutions could be:

• Measures to optimize timing based on analysis of the project's critical path;
• Coordinating the work of various contractors, setting deadlines for contractors/performers based on the general schedule network schedule for the project;
• Clarification of the planned timing of budget funds disbursement, taking into account the forecast for the timing of work in the schedule network schedule.

This is the recommendation:

Before you start implementing schedule network planning, think about what specific practical problems for the project you want to solve with its help. Next, evaluate the success of implementation based on the success of solving these problems, and not on the fact of the presence of schedule network diagrams as such.

The application of schedule network planning should not be "art for art's sake."

2. Duplication of processes

Sometimes, as a result of implementing schedule network planning, the situation looks like this:

That is:

Before implementation, the company had a planning/reporting department. He makes graphs and reports in Excel.

After implementation, in addition to the planning and reporting department, a new division appears (for example, a "project office or project management department"), which begins to create schedule network schedules for the same work (for example, in Oracle Primavera). Thus, projects have 2 types of schedules for the same work and double reporting.

Here I would like to note that with the introduction of schedule network planning, no new processes appear in project management. It simply changes the way the project performs planning and monitoring work.

Schedule network model: nothing more than a project schedule; accordingly, if it is available, there should be no other schedules for the project.

3. Distribution of responsibilities

When using schedule network planning, the question of distributing responsibility for planning work between project team members always arises.

Here are the following extremes:

1. Project team members take the position "you are specialists in schedule network planning - so make your own model, and we have nothing to do with it" and withdraw themselves from the process.
2. The planner takes the position "I am not responsible for the project and should not understand it. My job is only to enter into the program the data that I received from the project team members"

In none of the above cases, schedule network planning is almost guaranteed to "take off."

I consider the following principles of work organization to be good practice:

1. The project manager is responsible for the schedule, not the scheduler.
2. A network planning specialist must have at least an average level of understanding of the subject area and "speak the same language" with technical experts. The planner independently studies the project documentation as much as possible, turning to experts on specific issues.
3. The project manager must have authority over the planner: direct reporting or reporting within project roles in a matrix organizational structure.

Project planning and control is a team effort.

4. Excessive detail

One of the harmful phenomena in the use of schedule network planning is the desire to "plan everything down to the nail for 10 years in advance." We often saw how companies created schedule network schedules of several tens of thousands of operations and then could not keep them up to date, as a result of which the final benefit of the process was equal to zero.

At the same time, by keeping the schedule network schedule up to date I mean:

1. Update the model based on actual data about the progress of the project.
2. Accounting for project changes in the model.

From my practical experience as a specialist and manager in schedule network planning, I can say for sure: forming a model is not as difficult as keeping it up to date as the project progresses "in dynamics." Moreover, accounting for changes is the most difficult process. Because the composition of work and their sequence may change; The dynamics of changes are usually high, and taking into account such changes actually requires a constant restructuring of the logic of the schedule network model. At the same time, as the level of detail of schedule network diagrams increases, labor costs for accounting for changes can grow exponentially.

If you plan to use schedule network graphics, I highly recommend that you carefully consider the level of detail "onshore". This is not a question where you need to be guided by the principle "the more the better." Here we need a reasonable balance between the benefits of the model and the labor costs to keep it up to date.

5. Resistance

In fact, when the schedule-network planning technique begins to really work, it provides transparency in the project, clearly shows what the real reasons for missed deadlines are, and who is responsible for these failures.

Such transparency is not always needed, not everywhere and not for everyone.

At one of the interviews, the applicant honestly said: "I worked in Project N for about a year. Then the project was closed due to unprofitability. Of course, we lied in our reporting. If we hadn't lied, the project would have been closed much earlier."

From one of the managers in a major project I heard such surprisingly sincere words: "Your schedule network diagrams are, of course, generally good and correct. Only I have slightly different approaches to management: I will bring contractors into the project under enslaving conditions, and I will twist their arms until they do everything I need. I don't need transparency for this.".

However, such sincerity and directness is extremely rare. Accurate sabotage is more common, where arguments are actively used "everything is wrong in the calendar network diagram" and "the people who developed the schedule do not understand anything about the project".

Therefore, as soon as you begin to reveal the real problems of the project using the schedule network diagram, get ready to hold the defense (respond to criticism, including biased ones) and be patient.

Of course, such resistance is not always present - it all depends on the personalities of specific leaders.