What to do to turn a schedule into a work plan

What to do to turn a schedule into a work plan

In a conversation with an engineer in a large construction company, he said: “We don’t use the schedule as a work plan”.
“What? Why?” I answered, surprised – after all, they have so many projects and each project has a schedule! So how is it possible that a schedule is not a work plan?
“How can you turn a schedule into a work plan?!” He asked. “If you can answer that, you’ll be a great help!”

Before addressing that question, we must first ask ourselves something else:

IF THE SCHEDULE IS NOT A WORK PLAN – WHO NEEDS A SCHEDULE? IN OTHER WORDS, THE PROS AND CONS OF CREATING A SCHEDULE.

What is a schedule?

A good schedule defines all tasks required and the estimated duration required for each task. In addition, it defines the network logic – which tasks come before and after others. A good schedule will also provide the resources required per each task and sometimes even the cost invested in each task.

Why not to create a schedule?

Creating a schedule requires a great deal of time – work time, thinking time, planning time, time for asking questions (What can be done next? What needs to be done before…?) and time for finding the answers and defining them on the Gantt (the schedule). Time, as you all know, is an expensive resource.

Creating a schedule does not just take time – creating a project schedule requires special software. “Waterfall” projects require programs like Tilos, Primavera, Project or ASTA and Agile projects require software like Trello, ClickUp, Monday.com – or perhaps you prefer something else.

The software comes with a cost and will require certain operating skills, acquired through a course (i.e. time and money) or provided by an expert that we hire – i.e. another expense.

The schedule reveals the project status. Simple as that. The schedule can tell us that the project is late or early, it can demonstrate that the project is very complex, filled with embedded risks (and explain those risks) and it shows everyone the planned work method and the difficulties. In other words, when there’s a schedule, it’s a bit difficult to “keep secrets” in the project.

The previous paragraph is true for anyone who knows how to read a schedule. But schedules have a “language” of their own. The language consists of tables and graphic configurations that must be studied. If you don’t read “Schedulese”, it looks complex and intimidating, especially for schedules consisting of hundreds of tasks.

If there are so many cons to creating a schedule - why do it?

When constructing a good schedule, we must define the tasks for execution. Merely defining the tasks creates order – order in the work processes required for the project, order in understanding the project and its logic – and what is more and less important in the project.

Constructing the schedule makes us think about the project. If we said that we want to “build something” – then when preparing the schedule, we have to think about the “How”. How do we want to build that something. Rephrasing the question from “What do we want to build” to “How”, makes us rethink and thoroughly examine our project.

The schedule reflects the project: The schedule reflects the project structure – perhaps our project consists of several projects? – and it reflects the processes required for the project – perhaps we have to act in several different areas? For example, we might have to create several software programs and consolidate them or concurrently build several bridge piers.

The schedule will enable us to identify project obstacles – for example, waiting for special approvals from various factors that prevent us from continuing with the project, or that tasks performed by an expert or machine cannot be conducted at the same time, but rather serially. There are issues that, once we see them, we’ll say “We knew that, it was obvious!” However, there are quite a few issues that surprise us when we discover them on the schedule and realize their importance and the challenges they create.

When the schedule is updated, one can see the project status at any time – what tasks need to be done today, which tasks should have started already, which should have been completed and… when do we expect to complete the project!

A schedule sent to all participants involved in the project creates a basis for discussion between the project participants. It enables “alignment” to make sure that everyone is synchronized – both in the order of the tasks and when each task is performed.

If the project ends and the parties are unable to agree on a figure (money) that suites everyone, then the schedule has another role, years after the project ends – in legal claims. The basic schedule and its updates, from first to last, will play a pivotal role in any claim based on schedules.

If we were to summarize the question in a table, it would like this:

If we decide that the advantages of constructing a schedule exceed its disadvantages, we will go to the first question of how to turn a schedule into a work plan:

WHAT IS THE FIRST THING NEEDED FOR A SCHEDULE TO BE A WORK PLAN?
The answer is amazingly simple. The schedule must be real.

What do I mean?

The schedule must be one that we believe in. A schedule that we intend to uphold. Task durations must be reasonable durations. The order of activities must correspond with the order by which we intend to execute the project. If there’s something in the schedule that we do not believe in, it will not turn into a work plan.

WHEN THE SCHEDULE IS REAL, WHAT DOES IT NEED TO BE NOW?
Intact Schedule.

Why? Because reality does not accept what software takes for granted.
In other words – we can write and create whatever we want with software. The point of origin for software is: You, human beings, you know what you want – and if that’s what you wrote, it’s probably what you meant.
Compared to software – reality is not lenient. If something can’t happen – it won’t.

All scheduling flaws relate to issues that might create a problem in practice or which cannot exist in reality.

How do we know if our schedule is intact or whether it is flawed?
By mapping all of the scheduling flaws with HCP-Go.

HCP-Go detects all of the flaws in the GANTT chart (schedule).

Some flaws can be found manually. For example, are there tasks on the schedule unlinked to successors? But there are things that can only be detected when looking for paths, for example, successor tasks appearing before their predecessors… (Tasks with predated successors).

HCP-Go not only detects the flaws, it also maps them and generates a list of tasks to be corrected and what is needed to be fixed. This enables you to optimize the schedule and create a schedule that corresponds with reality.

Reasons for flaws include:

    1. Human errors. They will clearly happen, especially with schedules consisting of hundreds of tasks. These flaws are usually easy to correct.
    2. The second type of error derives of some kind of difficulty. For example, we did not link tasks because, when we did, the project was delayed. So, we deleted the link and said we’d get back to it – but didn’t. Mistake.
      For every mistake we find, we must ask – Why? Why did you write that? Why did you think that? The answers to these questions are fascinating, revealing many problems and allowing you to deal with them early, when they are still just on paper, and not under way. This is the time to handle them and prevent the difficulty. People sometimes try to ignore these project flaws. Perhaps they’ll just disappear??? Here’s a spoiler – they never do…

Here’s an example to an HCP-Go analysis of a real project schedule:

This is the goal that you seek when completing an HCP-Go analysis:

NOW THAT THE SCHEDULE IS REAL AND INTACT – WHAT SHOULD YOU FOCUS ON?
The answer is divided into 3 parts:

    1. Critical Paths: The critical path – according to CPM, the critical path – according to HCP
    2. Hidden critical paths
    3. Tasks to be conducted this week/this month

CRITICAL PATHS: THE CRITICAL PATH - ACCORDING TO CPM, THE CRITICAL PATH - ACCORDING TO HCP

A short explanation of the two methods:

CPM examines each task and uses forward and backward calculations to determine the extent to which it can shift on the timeline.
Those that cannot be shifted are assigned a total slack of 0, creating the critical path according to CPM.

HCP maps the project schedule according to paths and finds the project paths – existing task sequences.
The information derived of sequence analysis is fascinating and it enables translation of “Schedulese” to English.

Let’s go back to the previous mini-example.

CPM will calculate the total slack for each task, providing 5 total slacks for 5 tasks.
HCP will actually detect 4 paths in this small example.

HOW DOES THE DIFFERENCE BETWEEN CPM AND HCP APPEAR IN THE SCHEDULE?

Let’s take a look at a schematic example of a project.

  • The project begins on January 1st and ends on Jan 2nd – the next year. (Row 0 and Row 1)
  • Each path consists of many tasks – perhaps even dozens. Remember, this is a schematic illustration.
  • The critical path by CPM (Row 2) begins on March 1st. Why does it start in March and not in January? Constraint or delay. For example, you cannot start before obtaining special approval (such as a construction permit) or you cannot begin without an expert who can only arrive in March, or any other constraint – reality is more powerful than imagination… Once the constraint is cleared, on March 1st, it takes 10 months and that is the time that defines project completion, as they lead to the latest project date.
  • Therefore, according to CPM, the dates for all tasks on this path cannot be moved and they have a total slack (TS) (or Total Float) of 0. This is the critical path by CPM, on all existing software:
  • HCP maps the project paths. The mapping reveals that there is a different critical path than that defined by CPM, beginning on January 1st and going on for 11 work months (Row 3).
  • Since it is the longest on the entire network, the HCP Duration Slack (DS) will be 0.
  • Note that this path ends earlier than the latest project completion. As such, according to CPM, we will have a total slack of 1 month.
  • The HCP method further found another path, also different than the critical path by CPM and also longer than the critical path by CPM – going on for 10.5 months (Row 4). This path does not begin on the earliest date of the project, but rather one month after the project begins – on January 29th – and it ends earlier than the project completion date.
  • Therefore, the total slack (according to CPM) is 0.59 month and the slack according to HCP will be 11 days (0.5 month).

Which of the three paths should project managers focus on? Answer: All three.

Project management will only be partial if it focuses on just one of the three paths. Project managers must be aware of the three paths and their tasks and they must manage them with the same executive attention!! In the absence of executive attention, the project tasks will be delayed, causing a delay in the entire project.
Knowing about all three is the first key to project success.

With HCP-Go, project managers complete the project successfully. Want to talk to Tal Levanon about it?

HIDDEN CRITICAL PATHS

The critical path according to HCP is the project’s longest path.

A hidden critical path is shorter than the longest path. The difference between them reflects the HCP Duration Slack (DS).

In other words, all of the tasks comprising the critical path under HCP will be assigned 0 in the HCP DS column.

All tasks comprising the hidden critical paths will be assigned the HCP DS for the path that they create.

In the previous example, we saw the hidden critical path (Row 4) with 11 slack days, as it is 11 days shorter than the longer path on the network and all tasks that make it up are assigned 11 in the HCP Slack column.

Tasks to be conducted this week/this month

Tasks to be performed are located using the project filter.

Filter: Date Range

It appears in the View Menu → Filter → Date Range…

Pressing it will reveal a screen where we enter the early date on which we want to begin the section. We will then press “OK”.

This will open the next screen where we enter the latest date on which we want to complete the section. We will then press “OK”.

The screen will display only the tasks to be performed between the first date selected (i.e. beginning of the week or month) and the second date selected (i.e. end of the week or month).

WHAT ELSE SHOULD YOU KNOW?

GENERAL OVERVIEW (1): FEASIBILITY MAP FOR SUCCESSFUL PROJECT COMPLETION.

Evaluating project success – Feasibility of meeting the schedule, execution, scope and budget. All by mapping the schedule according to paths. How does the magic happen? For details, read Article 1.2  the bottom line: it is very easy to read the map and see what’s happening with each of the projects. At any level – whether you are junior managers or more senior executives, or if you are deciding on an investment. The next questions you need to ask are why is it happening? And what can and should be done now?

The response we continuously get from project managers is: “That’s what I thought about my project – but I couldn’t prove it!”

GENERAL OVERVIEW (2): MAPPING PROJECT PATHS - PATH HISTOGRAM:

When mapping paths according to HCP, we get a histogram. The X axis is each path’s slack regarding the longest path and Y is the number of paths in this slack.

The following sentence required many years, many projects and many HCP activations:

The histogram for projects that are applicable – not easy and not simple, but can be done and completed in time – looks like a normal distribution chart called a Gauss Chart or Bell Chart – or the beginning of one.

This is an example for such a project – applicable, which can be executed and completed as planned:

The histogram for a schedule with many problems looks like an EKG chart and just as we, as human beings, can’t live without a pulse – this “pulse” is very bad for projects!

GENERAL OVERVIEW (3): MILESTONES

Under milestones, it is important to compare the contractual end date to the date defined by control and it is worthwhile to examine the change compared to the previous evaluation in order to determine whether there is a trending change.

If you create a table in the spirit of this one – give us the credit. 😊

To read more about histograms and for another example, press here, Article 3.1.  

IN CLOSING – WHAT TO DO AND HOW, IN ORDER FOR A SCHEDULE TO BE A WORK PLAN?

HOW DO YOU RUN HCP-GO?

  1. Download the free version of HCP-Go to your project, Here
  2. Open your project in MS Project. On the Task ruler you’ll have the two HCP-Go icons:
  1. 3. Press Go and Run Analysis.
    4. For further instructions, watch the clip below.  

AND NOW, ANY SCHEDULE WILL BE A WORK PLAN!

Share on facebook
Share on linkedin
Share on whatsapp

Are there people you care about? It’s time to share!
Want to ask something or comment? Cool! Here, in the comments…
Want to tell only me something? Note at the beginning of the comment – and the comment will not be published.

Leave a Reply

Skip to content