Project Planning & Monitoring Specialist
PRIMAVERA P6 / SCHEDULING / DELAY ANALYSIS / TOOLS
Project Planning & Monitoring Specialist
PRIMAVERA P6 / SCHEDULING / DELAY ANALYSIS / TOOLS
Run by Jehanzaib Rana, PMP, working with contractors and consultants on a project or portfolio basis, remotely or on site.
Sixteen years in construction. Eleven on site: supervision, survey, site engineering, then directing reinforced concrete from substructure to handover. Project controls became the main work in 2021. Primavera P6 daily since 2018.
The eleven years matter more than the five. They are why progress data gets checked here rather than accepted.
Baselines and master schedules built from first principles, with a work breakdown and activity coding that survive contact with the project. Progress updating and monitoring against the approved baseline. Look-aheads, S-curves, resource histograms, productivity analysis, cashflow forecasts.
When a programme slips, that becomes delay analysis, Time Impact Analysis, and extension of time claims supported by contemporaneous records, kept from the start rather than reconstructed the week before submission.
Procurement is treated as part of the schedule. Lead times cause as much delay as the work does, and they are usually where the argument about whose delay it was ends up.
The range runs from a single programme to portfolio monitoring across 45+ concurrent projects for a state-owned contractor. Master schedules, baselines, S-curves and cashflow forecasts are consolidated there to the level an executive review actually needs. Different problems at each end. One project is about the sequence. A portfolio is about which of the forty-five is quietly slipping, and which one deserves the attention this month.
Behind all of it sits a habit borrowed from outside planning: Lean, Six Sigma and supply chain method applied to the process rather than the programme. Where does the week actually go. Which step is waiting on which. What is being counted twice, and what is being counted by three people in three different ways. A schedule that slips every month is usually reporting a process problem, and the programme is the last place to fix it.
A master programme is written in activities. A site is run in pours, lifts, gangs and working days. Same job, two languages, and most programme failures are translation failures rather than planning failures.
A site engineer judges productivity by what the gang produced against what it should have. A planning engineer judges it by earned progress against baseline. A cost controller judges it by value against spend. Three people, one week of work, three answers, all of them right. The argument is rarely about the week. It is about what each of them is counting.
Both ends of that conversation are familiar here.
Oman, the UAE and Pakistan. Highways, bridges and flyovers. Retail and commercial buildings. Industrial and power-sector civil works.
Baselines have also been built for overseas clients without setting foot on site. Remote planning works better than most people expect, provided the information coming back is disciplined. That is a planning problem, not a distance problem.
Three markets teach you that the contract, not the country, decides how a delay gets argued. What travels is the method: a defensible baseline, records kept as the work happens, and an analysis that holds up when someone is paid to take it apart.
The Excel and VBA tools on this site came out of doing the job, not from a product plan. Progress updating, delay analysis, programme generation, reporting. Each one started as an answer to something that was taking too long by hand, on a programme with a submission date attached.
Which has one consequence worth stating. They were written by someone who has to submit the output, not just ship the software. A wrong number is not a bug report here. It is a submission coming back.
Most planning gets taught as software training. You learn which buttons to press, and the reasoning behind them is left for you to work out on the job, usually while someone is waiting for the programme.
The material here starts from the other end. Why a delay belongs to one party and not the other. What makes a baseline hold up when it goes for approval. What to write down today so that a claim can be proved a year from now. There are flashcards for the terms that come up in every meeting, a levelling drill against the clock, and short problems with one right answer.
It is written for engineers early in their careers: people who have the degree, have the software, and have not yet had anyone explain the thinking. No account, no cost, and it stays that way.
Most of what is here was learned on site from people who explained things they had no obligation to explain. Engineers starting out now are mostly handed software and left to it. This section is a small correction to that, and it gets kept up whether anything else on this site earns anything or not.
PMP, Project Management Institute
MS in Project Management
B.Tech Civil, Honours
Primavera P6 daily since 2018