Who really knows the critical path on a Bosaso build?

A delay claim on a Bosaso build can name the wrong trade when nobody holds the logic behind the programme. Critical path analysis skills gaps in Bosaso show up as a bar chart drawn from dates rather than a linked logic diagram, so no one can show which activity actually controls the completion date. When a gate or a slab slips, the argument turns on who was last seen on site.

What does critical path analysis actually require?

It requires a network of activities joined by dependencies, with durations and float calculated from those links, not a list of dates typed into rows.

A real critical path comes from four inputs. First, a full activity list broken down far enough that each item can be measured. Second, logic links: this pour waits for that steel fixing, that blockwork waits for this curing. Third, durations taken from the crew and plant actually available, not from a wish. Fourth, the forward and backward pass that produces float for every activity.

When any of those inputs is missing, the path is guessed. A guess often ignores curing time, gaps between delivery and the point of use, and the fact that one crew cannot pour two elements at once. Confirm the local constraints, such as curing periods, delivery lead times and working hours, with your own engineer and your suppliers. The result is a schedule where everything looks urgent because nothing has float. Ask the planner to show the links behind the top five activities. If the answer is a list of dates, the analysis is not there.

How do skills gaps hide the real delay driver?

They hide it because a schedule that is not properly linked cannot show which activity ran out of float, so attention falls on the loudest problem instead.

A supervisor without network logic training reads the bar chart as a sequence of promises. When a delay appears, the nearest trade gets the blame. The actual driver may sit three steps back: a late approval, a missing test record, a lift that could not reach the plot, or a decision that waited on someone off site. None of those show up if nobody mapped the dependencies.

This matters for quality, not only for time. When the wrong trade is blamed, the fix is usually pressure. A crew pushed to recover lost days may add water to a mix, fix reinforcement faster than the lap detail allows, or backfill before a test result arrives. The defect surfaces weeks later and the schedule gets blamed again.

Ask your own engineer or records office to identify the drawings and submissions held for similar plots, and ask two contractors how they build their programmes. Compare answers against the logic on your own project.

How do you test a schedule before you accept a delay claim?

Test it by asking for the logic links, float values and updating record behind any date, then checking them against the site.

Start with the baseline. Ask for the file, not a printed chart, and ask the planner to walk through the links on the activities that matter. Confirm which activities carry zero float and how that was calculated. Ask when the schedule was last updated and what changed.

Then walk the site. Compare progress against the update, not the baseline. Look for activities that started before their predecessor finished, which usually means the logic was wrong or the link was removed to hide a clash. Check delivery records and test dates against the dates in the file.

Confirm any technical limit, such as curing periods or lap lengths, against the project specification and the engineer, not against the programme alone.

What to do next

Before the next progress meeting, ask the planner for the schedule file with logic links, float values and the last update date. Pick the three activities that carry zero float and trace each one back to its predecessor. If the links do not match what happened on site, treat every delay claim until that point as unproven and recheck it.