The Importance of Control in a Project

The plan was approved in March. Everybody in the room signed up to the dates, the scope and the budget. Three weeks later somebody asks the obvious question: are we still on it?

The answers come back as impressions. The development team feels behind. The supplier insists the hardware is fine. Spending looks roughly where it should be. Nobody is lying, and nobody can answer the question, because there is nothing concrete to compare the project against.

That gap is what project control exists to close. Not a monthly ritual and not a slide, but the machinery that turns an approved plan into information somebody can act on while there is still time to act.

What control actually means

Three words get used as though they were interchangeable, and that confusion is why so much tracking effort produces so little.

Monitoring observes. It gathers what is happening: hours logged, tasks closed, invoices received. Reporting communicates, packaging that raw material for an audience. Control is the step in between, and it is the one that gets skipped.

Control compares what is happening against something that was agreed, measures the difference, and hands somebody a decision. Observation without a reference point is not control. It is data collection.

A dashboard full of live figures feels like control and is not, because nothing on it says what the figures were supposed to be. One number beside its approved counterpart is worth more than twenty standing alone.

That also sets the limit of what control can do. Control does not make a project succeed, and it cannot recover time already lost. What it does is shorten the gap between a deviation happening and somebody competent knowing about it, which on a long project is the difference between an adjustment and a rescue.

You cannot control a project without a baseline

Control needs a reference, and the reference has to be fixed. This is where teams most often go wrong: they compare today’s plan with today’s reality, which always agree, because the plan was quietly edited every time reality moved.

A baseline is a saved snapshot of the plan at the moment it was approved. It stops being editable, which is what makes it useful. Three of them carry most of the weight:

• Cost baseline. What the project is expected to spend, spread over time to match when the work happens. Without that distribution you can only compare totals at the end, too late to matter.
• Schedule baseline. The dates committed for each stage and deliverable. It answers whether the project is late, a different question from whether anybody is working hard.
• Scope baseline. The activities that produce the deliverables, as approved in the work breakdown structure. It is what makes per-activity progress meaningful, because each item has an agreed definition of done.

One condition applies to all three: the plan has to be formally approved before it becomes a baseline, by the steering committee, the shareholders’ meeting or the sponsor, depending on how the organization governs its projects. A baseline nobody signed is a private opinion about the future, and it convinces no one in an argument.

ITM Platform lets you store as many baselines as you want and mark one of them active, saving the schedule dates, the budgeted and estimated hours, the costs and the expected revenue at that moment. Those values then sit beside the current figures in the project’s General, Budget and Gantt views, in lists, in reports and in the API. Project baselines covers how a baseline is created and switched.

The four things worth controlling

With a reference in place, control has four objects. They are not equally easy, and they fail in different ways.

Scope. Whether the work being done is the work that was agreed, and whether the result meets the requirements set at the start. The useful rule is binary: a task that does not meet its requirements is not partially complete, it is incomplete. Teams that let a task sit at 90% done for three weeks have lost scope control without noticing.

Deadline. Whether the agreed dates still hold. One detail deserves more attention than it gets: the first schedule is normally drawn without a margin for risk, and that is deliberate. A margin declared in the original plan gets absorbed by everything except risk, because every delay finds a reason to use it. Keep the contingency separate from the committed dates, and release it on purpose rather than by default.

Cost. Two things need watching, the total cost of the project and the treasury position, which is to say when the money actually leaves. A project can be inside its budget and still create a cash problem by concentrating its purchases in one quarter.

Risk. Risk control is the one that pays for itself, because an unforeseen event hits the targets immediately while other deviations build up gradually. The discipline is to identify risks, plan the response before the event rather than during it, and review the list as the project changes shape. The six phases of risk control set out that cycle in order.

Progress is not the same as hours spent

The most common substitution in project tracking is to treat consumed effort as completion. Half the estimated hours are gone, so the task must be halfway there.

Hours consumed ≠ progress achieved.

The two describe different things. Progress is the proportion of the work actually done, and somebody has to assess it. Hours are an input, and a task can burn its whole estimate while producing nothing usable. Keeping them apart is what makes a deviation visible: a task at 30% progress with 80% of its hours spent is a problem you can see, and a single blended number hides it.

The assessment belongs to the person close enough to the work to judge it, normally the task manager or the project manager.

The comparison is simple arithmetic. Expected progress at today’s date comes from the baseline, actual progress comes from the person doing the work, and the difference is the schedule variance you either absorb or escalate. Rolling task progress into summary tasks and the project total gives you that comparison at every level of the plan.

ITM Platform keeps progress separate from hours consumed and accepts a progress report from the timesheet, the task’s Progress section, the Gantt chart or the API, then rolls task progress into summary tasks and the project total. Waterfall project tracking describes each of those entry points.

Cost control before the invoice arrives

Money is where control gets reduced to a single comparison, budget against actuals. Two numbers cannot tell you whether a deviation came from a bad estimate or from bad execution. Three can.

Figure	What it is	What question it answers	When it moves
Top-down budget	The amount allocated to the project, set by hand at approval	What are we authorized to spend?	Rarely, and only through a formal change
Bottom-up estimate	The cost calculated from the tasks and resource allocations in the plan	What does the plan as it stands now cost?	Every time the plan is re-estimated or re-staffed
Actual	Logged time valued at resource cost, plus recorded purchases and invoices	What have we committed so far?	Continuously, as hours are reported and invoices arrive

Read in pairs, the three figures separate the two failure modes. Estimate against budget tells you whether the plan was ever affordable, and it is available before any money is spent. Actual against estimate tells you whether the work is costing what it should. A project whose estimate exceeded its budget in week one has an estimating problem that execution discipline will not fix.

ITM Platform shows all three in the project’s Budget tab: the top-down budget you set by hand, the bottom-up estimate calculated from tasks and resource allocations, and the actual values drawn from logged time and recorded purchases, with the option to set a new baseline there. Project budget explains how those blocks relate.

Turning control into a decision

Control that stops at measurement is an expensive hobby. The output has to reach somebody who can change something, at a point when changing it is still cheap.

That means settling three things before the project starts rather than during its first crisis. How often the comparison is made, which for most projects means weekly at task level and monthly at steering level. Who reads it, named individuals rather than a distribution list. And what triggers an escalation: a variance above an agreed percentage, a milestone at risk, a forecast overrun beyond a set amount.

Thresholds agreed in advance keep the conversation about the project instead of about the messenger. When the rule was written down before anybody knew which project would breach it, reporting a deviation is compliance rather than confession, and more problems surface while they are still small.

The report is the vehicle, and it is worth more when it carries a forecast than when it recites history: what the status is, what moved, what the current estimate says about the end date and the final cost, and what decision is being asked for. Everything you should include in a project status report goes through that content in detail.

Next steps

• Try ITM Platform and set a baseline on a project you are already running, then compare this week’s progress and cost against it.
• See what planning and monitoring covers, from the work breakdown structure and the Gantt chart to progress reporting and variance against the baseline.