Timeboxing is an internal time limit set on key tasks in a project. But be careful: setting this limit is not enough to protect the margin. Only the continuous monitoring of the actual progress in relation to the time consumed (and the contractual budget) makes it possible to transform this terminal into a management tool.
If a task costing 8 man-days consumes 11 man-days, the consumption gap is often only visible at the end, once the margin has been reduced. Without an early detection mechanism, it is difficult to adjust the shot. This is a classic trap in consulting firms and IT Services : to guarantee quality, we let time stretch. Each task then consumes more man-days than the bare essentials, a surplus that is neither sold nor rebillable, and will therefore be discreetly absorbed by the project's margin.
Worse: this extension immobilizes the consultant, who is no longer available for the rest, creating a domino effect that postpones the entire workload plan for the following month. If, at the level of an isolated consultant, this slippage may seem anecdotal, it multiplies at the level of a firm to eat away at the overall profitability without ever triggering an alarm.
That's where timeboxing comes in. Most often reduced to an individual productivity method (Pomodoro, agenda blocks), on the scale of a project, it allows the project manager to set a time limit on tasks that involve the margin, continuously monitor what has been done against what is planned, and arbitrate the perimeter as soon as the drift emerges. The question is where to place these limits without falling into permanent control, and how to react when a team reaches the limit without having finished its mission.
What is project-scale timeboxing?
Where does timeboxing come from and what is it based on?
Timeboxing is the process of setting a non-negotiable amount of time for a task or project milestone in advance, and then, if the team is approaching the ceiling, adjusting the content of the deliverable rather than the duration. The end date does not change; it is the perimeter that adapts.
This method comes from software development. James Martin formalized it in 1990 in Rapid Application Development, to get out of endless IT projects, where delivery receded with each added feature. His rule: divide the project into cycles of fixed duration and deliver, at the end of each cycle, a version that works, even if incomplete. The length of the cycle does not change; The content delivered, yes.
The objective is not to deliver less than what the customer has ordered to meet a deadline. The adjustment relates to the discretionary part of the deliverable (the refinement), not to the contractual commitment, which is subject to an amendment. On an audit whose limit is approaching, a secondary analysis that the client will not read can be lightened, or the formatting of the document shortened. A recommendation provided for in the contract, never.
Setting up a timebox means giving yourself an internal deadline. When a task approaches or exceeds it, it is up to the project manager to arbitrate the scope (what is included, the level of finish), without touching the date or the value promised to the client, before drift eats into the margin. But we still have to see this threshold coming: setting the limit also requires monitoring progress, the rest to be done and the time consumed.
Is timeboxing an individual, a team or a project?
The timeboxing method comes in three ways, which are best not confused.
- At the individual level, the most famous, a consultant frames his or her working range, from 25 to 90 minutes, in the spirit of the Pomodoro technique. Useful to last a day.
- At the level of a team, certain times for meetings or customer workshops are capped: two hours for a scoping, a quarter of an hour for a daily review.
- At the project level, especially in departments and in an agile method, a task is framed over a defined number of man-days. It is on this framework that the margin is calculated.
What is the difference between setting a timebox and a deadline?
Three points of reference overlap: the deadline, the timebox and the time sold. They do not measure the same thing.
The deadline is a deadline scheduled with the client. It sets the time when the deliverable is expected, and nothing more. It does not say how much work the task should cost, or what to do in the event of an overflow. Two missions delivered on the same date may have consumed 5 or 15 man-days: the date holds in both cases, the margin does not.
The time sold is the benchmark for the margin. On a package, the customer pays for a number of days set in the quote. It is this figure that is used to calculate the margin at the end of the mission: the days actually consumed are compared to the days sold.
The timebox is an internal working time budget, set under the time sold and based on the realistic estimate of the task. When a task reaches it, it's time for the project manager to arbitrate the scope (what is refined, what can be cut) rather than postponing delivery.
Exceeding the set time box does not mean that the deadline has been missed. This is an indication to the project manager and the consultant that there is a risk of cutting into the margin, and that a decision must be made while there is still time.
At the end of the mission, we compare the time consumed and the project progress in relation to the time invoiced, not against the timebox. These are two different readings of the past tense.
Note that for a project under direct management, the client pays for the time actually spent on the project. If there is no contractual reference, the timebox can be used as a benchmark to identify abuses.
| Benchmark | Nature | What it limits |
|---|---|---|
| Deadline | A date | When the deliverable is expected |
| Timebox | An internal time budget, under the time sold | How many man-days a task should cost |
| Time sold | A commercial commitment | What the client pays, and therefore the margin at the end of the assignment |
Is Scrum sprint a timebox?
A Scrum sprint (or other agile method) is a strict timebox of 1 to 4 weeks, and the events that make it up are themselves capped in duration. In a Scrum project, the agile framework already carries the essence of timeboxing.
All events in this method have time limits to respect:
- 8 hours for a project scoping;
- 15 minutes per daily point;
- 4 hours at the end of the period for the sprint review;
- 3 hours for the retrospective.
In a 100% agile project, timeboxing is carried by the Scrum framework. In other methods, it is up to the project manager (or each consultant) to set the time limits for each task individually.
For more information on the Scrum method, read the Scrum Guide 2020.
Timeboxing, time blocking, batching, Pomodoro: what's the difference?
Timeboxing applied to a project is often confused with individual productivity methods with neighboring names.
| Method | Scale | In plain English | Are you leading a project? |
|---|---|---|---|
| Timeboxing | A team, on a task or a project | A number of man-days is planned for a milestone, we deliver at the allotted time without changing the duration, even if it means imperfect finishes | Yes (the only one of the four) |
| Time blocking | An individual, his agenda | A time slot is reserved for a task, with no maximum duration imposed | No |
| Pomodoro | An individual, his concentration | 25 minutes of work, 5 minutes of break, and we start again | No |
| Batching | An individual, his or her current tasks | All emails processed at once at the end of the day | No |
What is found under the generic label "timeboxing" on the internet often frames the work of an individual, never a team or a portfolio. The Pomodoro helps a consultant to concentrate, the time blocking organizes his agenda: neither of them says how five consultants collectively last the time of a task, or how a manager referees twenty missions. A 25-minute timer does not secure a charging plan. The challenge of a consulting firm or a IT Services lies in the margin of its project portfolio and the man-days consumed by dozens of consultants.
Why does the time of your projects overflow, even with a good costing?
A time estimate, even a correct one, does not protect against abuses if no one ensures that the deadlines are met. Several well-documented mechanisms explain why budget overruns occur even when the initial costing was good, and that projects get out of hand without us seeing it coming.
One task takes up all the available time
This psychological bias is underestimated in project management: the natural tendency of work to expand to occupy the entire allotted time. This is the essence of Parkinson's Law, formulated by Cyril Northcote Parkinson in 1955: work extends to occupy all the time available for its completion.
A task that can be done in 7 man-days, but with a budget of 10 days in the schedule, will systematically consume these 10 days. The gap is filled by an accumulation of details, proofreadings and "comfort" checks that bring no real added value.
These excess days are not sold or invoiced: they are taken directly from the project margin. No one perceives them as an anomaly, because the time budget is respected, while it is possible to contract it.
The Perfectionism Trap in Consulting Engagements
An audit, a scoping note, a financial model can always be refined: one more analysis, a cleaner slide. Unfortunately, it's often the best consultants who spill over the most. Their demand for the quality of the deliverable pushes them beyond what is necessary. And the project manager, due to a lack of visibility or room for manoeuvre, does not always have the means to have it delivered as is.
Invisible additions that inflate the scope of a task
In a meeting, the client asks for a small addition. The consultant accepts to preserve the relationship. Nothing is traced or re-encrypted. Repeated over the duration of a mission, the difference becomes significant: this is the mechanism of the scope creep.
Let's take an audit costed at 10 man-days. Over the course of the exchanges with the firm, the client adds additional requests, and the mission actually reaches 13 days consumed. For a project in time-based mode, these requests are directly billable. For a fixed-price project, this additional time was not provided for in the contract, but it was produced. Without an agreement to reframe the scope, this time consumed in excess will be removed from the project margin.
It should be noted that in both cases, exceeding the scope will immobilize a consultant longer on the mission, which makes him unavailable for other missions and will potentially affect the resource planning of the firm or theIT Services more generally.
The special case of the Scrum sprint that overflows
The Scrum sprint is by nature a timebox. However, this discipline is often eroded: the daily point that slides from 15 to 30 minutes, the sprint review that drags on beyond the allotted slot, or the duration of the sprint that is extended just to finish this last user story.
Taken in isolation, each overrun seems minor, almost anecdotal. But when accumulated, they neutralize the time constraint that is the basis of agility. The hidden cost is real: for a team of five consultants, a daily scrum that doubles in duration represents the equivalent of 6 man-days over a 4-week sprint.
How to set up timeboxing at the scale of a project?
How much time should be allocated to a task?
The timebox is not the time sold to the quote. This is a realistic estimate of the real time that the task, posed internally, will take. A good setting is tight enough to create a useful constraint, and neutralize the Parkinson's effect, without becoming untenable. This estimate is refined from one mission to the next, with the experience of the project manager and the history of comparable projects.
In addition, rather than a safety margin on each task, it is better to have a pooled reserve for the entire project (there are always contingencies). Tasks that are finished ahead of schedule then compensate for those that are overflowing.
It should be noted that the more exploratory tasks a project includes (never done before), the larger this reserve must be.
Should you timebox each task or only the most important ones?
Be careful not to fall into managerial excesses. Controlling the time spent by each consultant on everything quickly turns into micro-management, with effects that end up being read in HR data: turnover, absenteeism. Conversely, controlling too few of them is tantamount to detecting drifts too late.
The timeboxer task is one that produces an identifiable deliverable: an audit, a product feature, a restitution. Priority is given to timeboxing critical tasks, those whose overspending puts the budget, and therefore the margin, of the entire mission at risk: a structuring deliverable, a task on the critical path, a high-load milestone. On these tasks, the gap between planned time and actual time becomes an advanced signal: if it widens, the entire mission budget risks slipping, not just the task.
Finally, a rule of granularity : beyond 15 man-days, a task benefits from being divided into time-boxed sub-deliverables. Below 2 to 3 man-days, it is better to aggregate it with others in a single timebox.
What to do when a task reaches its ceiling?
When tracking shows that a task reaches its timebox, there are two possible responses:
- strict timeboxing: the task stops even when unfinished, and the project manager takes stock of the situation with the consultant;
- Flexible timeboxing: the consultant finishes, accepting the risk of a real overshoot.
If the pooled reserve of time is depleted and the contractual commitment itself is threatened, we leave the register of current arbitration for that of project recovery, which calls for other decisions.
A timebox should never stretch out without anyone being aware of the change in deadline. If a task regularly takes longer than expected, it means that the target was poorly calibrated and needs to be corrected.
How can we ensure that the planned times are met?
Everything is therefore based on early detection: you still need to know, along the way, that you are approaching the ceiling. This is the role of time tracking. Tracking times means continuously comparing the time achieved, declared to the CRA, with the planned time and the actual progress. Without this monitoring of time, the overshoot is only visible at the closing; With it, the signal falls while we can still act.
The indicator that counts is the gap between time consumed and actual progress:
- a task that has consumed 60% of the budget but is only 40% advanced is on alert;
- A task that has consumed 60% of the budget and is 60% advanced is healthy.
Stafiz does not put the timebox for you: for each time entered in the CRA, the tool allows you to compare the time achieved and the planned time, update the remaining time to be done and the landing of the margin, then alert the project manager and the mission director in the event of an anticipated deviation.
Each time the CRA is entered, the consultant enters the time spent on the project in the monitoring tool. For his part, the project manager informs the rest to be done and the milestones reached. The gap between the time consumed and the progress of the project is calculated with each new entry, and alerts in the event that the planned time is actually exceeded, or if the forecast calculations anticipate a project drift.
From isolated project to portfolio management
Timeboxing takes on a whole new dimension at the scale of a project portfolio. Across all the missions of a service company, the monitoring of time and the gap between planned and completed feed into the management of profitability and resource planning in a global way. On a structure employing 50 consultants, every time estimate, every point of billable utilization rate quickly represents dozens of billable days per year at the level of a portfolio, and therefore a significant part of the turnover.
This type of monitoring is impossible to do in an Excel spreadsheet or a classic project monitoring tool as soon as the missions and the number of consultants multiply. At each time entered, Stafiz:
- allows you to compare realized and planned;
- updates the remaining work to be done and the budgetary landing of the margin;
- then signals the deviation at the moment when it is taking shape.
Discover project management with Stafiz
It is this ease of management at the global level that the consulting firm Greenworking came to seek by adopting Stafiz. Sound resource planning and its invoicing were based on Excel files, which were less and less tenable with growth: utilization rate blurry, remaining ability difficult to read.
❝
Stafiz provides a quick and accurate view of several key indicators of the management of a consulting firm: the availability of employees, the availability of employees, the availability of employees, the availability of the utilization rate, invoicing of missions and follow-up of purchase orders. This is a real difference compared to Excel files that have to be manipulated in all directions, and the data can be consulted in real time and instantly on the tool.
Florentin Seux
COO
Frequently asked questions:
