An IT project rarely goes off track on a single day. Usually it is many small shifts: a milestone that arrives two weeks late, an interface that takes more effort than expected, a test phase that shrinks so the deadline can hold. Project control makes sure such deviations become visible early and that someone decides in time. This article explains how the control cycle works, which KPIs really help, how a status report should be structured and what changes in agile projects.
Project control, often called project monitoring and control, is the ongoing management of a project against its plan: tracking progress, comparing it with the plan, assessing deviations and deciding on actions. Planning defines what should be achieved by when and with which budget. Control keeps the project close to that goal, or makes sure the plan is changed deliberately when the situation has changed.
The second part of that sentence matters. Project control does not mean defending the original plan at any cost. It means making deviations transparent and bringing about a decision: take corrective action, adjust the scope, move the deadline or increase the budget. What realistic planning looks like as a foundation is described in our article Keeping IT projects on time and on budget.
Many projects have status reports, traffic lights and steering committees, and still the bad news only arrives shortly before go-live. Typical causes:
Project control follows a simple feedback loop that is repeated at a fixed rhythm, for example weekly in the project team and monthly in the steering committee.
Measure progress by results wherever possible, not by effort. A work package is done when its result has been accepted, not when the planned hours have been used. Clear definitions of done work well, such as "implemented, tested, accepted by the business".
Compare the actual state with the plan: schedule, cost, scope and quality. What matters is not only the current deviation but its direction. A milestone that slips a little further with every report is a clearer signal than a one-off delay.
Not every deviation needs escalation. Define tolerances in advance, for example how far a milestone or the budget may deviate before the steering committee decides. Within tolerance the project manager steers; outside it, the issue is escalated with options and a recommendation.
Every action gets an owner and a due date. The next report checks whether it worked. Without this follow-up, the control cycle turns into mere reporting.
A few well-chosen KPIs are better than an extensive dashboard nobody reads. For most IT projects, five to seven values from the following areas are enough:
Every KPI should answer a question that is relevant for a decision. If nobody can say what to do when it gets worse, the KPI does not belong in the status report.
The status report is the central tool of project control. It should be readable in a few minutes and make clear where the project stands and what is needed from its recipients. A proven one-page structure:
For the traffic light to mean something, its colours must be defined in advance. For example: green means the goal can be reached within tolerances. Amber means a deviation is foreseeable and the project manager is taking corrective action. Red means the goal can no longer be reached without a steering committee decision. Just as important is a culture in which an early amber report counts as good project management rather than failure.
Project control needs clear roles. The project manager runs day-to-day control and reports. The steering committee makes the decisions that go beyond the project manager's authority, such as budget, schedule or scope. Business units and other parties need to know when and how they will be informed. How to engage these groups effectively is shown in the article Stakeholder management in IT projects.
Set the rhythm at project start and stick to it. A steering committee that is cancelled when things are calm is often missing when it is needed. For urgent cases there should be a defined escalation path that does not wait for the next meeting.
Agile projects are controlled too, just with different means. Instead of a detailed overall plan, the product backlog is at the centre, and control works mainly through scope: what delivers the most value in the time remaining? The sprint review is the natural control meeting because real, working results are on the table.
A release burn-up chart, which shows completed and planned scope over time, is a useful KPI. It reveals whether a target date is realistic and whether scope is growing. A team's velocity helps with planning but is not suitable as a performance metric or for comparing teams. In many companies, agile teams work within a traditional frame with fixed budgets and milestones. How the two can be combined is described in the article Agile vs. traditional project management.
The second point in particular costs many projects their acceptance. If you treat quality as a control dimension of its own, you notice earlier when the deadline can only be kept at the expense of testing. How to run an orderly sign-off is covered in the article on acceptance testing.
Good project control is less a question of tools than of discipline. A fixed rhythm, a few meaningful KPIs, an honest status report and clear tolerances make sure deviations become visible early and the right people decide in time. This applies to traditional and agile projects alike.
Project control is the ongoing management of a project against its plan. It includes tracking progress, comparing plan and actuals, assessing deviations and deciding on actions so that schedule, cost, scope and quality stay within the agreed frame, or the plan is changed deliberately.
A project status report contains the overall status with a short reasoning, the status for schedule, cost, scope and quality, results since the last report, significant deviations with actions, the most important risks and the decisions needed from the steering committee. Ideally it fits on one page.
A few KPIs with a clear link to the project goal work best: milestone trend analysis for the schedule, budget consumption relative to progress for cost, change requests for scope, open defects and test progress for quality, and the most important risks. In agile projects, a release burn-up chart is added.
30-minute initial consultation — free and without obligation. Together we look at your project and show where control and reporting can become more effective.
Book a Free Initial ConsultationMore about our service: IT Project Management in Hamburg →