The team in this story runs the monitoring estate for a mid-sized logistics company, and they had one job that quarter: move their alert correlation onto an AIOps platform without waking the on-call rota more often than before. Their first plan was a beautiful thing. Every day from the kickoff to go-live had a task in it, and the project lead, who we will call Dara, was proud that nothing was idle. Eleven working days, eleven deliverables. It looked efficient, and it was exactly the kind of schedule that breaks on the first small surprise.

This is a practical account of what happened when it did break, what the team changed, and how you can build slack into your own AIOps rollout without turning the project into a fortnight of waiting. The lesson is not about the AIOps tooling itself. It is about the joins between steps.

Where the first plan cracked

On day three, the data engineer needed read access to the metrics store so the platform could ingest historical series for training its baseline models. The access request sat in a queue for a day and a half. Nothing was wrong with the request. The approver was simply travelling. But day four was scheduled for tuning the correlation rules, and tuning needs data, so day four became a day of people staring at an empty console.

By day six the slip had spread. Rule tuning ran into the day reserved for connecting the ticketing integration, which ran into the day reserved for a dry run with the on-call engineers. Every task was individually reasonable. The schedule as a whole had no give anywhere, so a one-and-a-half-day delay at the start became a four-day delay at the end, and the go-live date that Dara had promised to the operations director moved with it.

The post-project conversation was short and unglamorous. Nobody had been careless. The plan had simply assumed that every handoff would land on the hour it was scheduled for, and handoffs almost never do.

The idea: slack belongs between steps, not at the end

The team’s second attempt used the same eleven working days of effort but spread them across fifteen calendar days. The extra four days were not put in a lump at the end, where they tend to get eaten by whatever is on fire. They were placed deliberately at the joins: after the access and data steps, after the rule tuning, after the integration work, and before the dry run.

Dara described the rule she used in plain terms. A buffer goes wherever one person finishes something and a different person must pick it up, and wherever the work depends on a system or a decision owned by someone outside the team. Inside a single engineer’s own focused work, estimates are usually fair. At the boundary between people, teams and approvals, they are wishes.

• After external dependencies. Access grants, firewall rules and vendor support tickets all got a spare day behind them.
• Before demonstrations. A demo to stakeholders was never scheduled for the day after the work it demonstrates.
• Around shared people. The one engineer who understood the legacy alert format was booked at two-thirds capacity, so a sick day would not freeze everything.

What the slack absorbed the second time

The second schedule faced three small slips, and none of them became a story. The access approval again took a day and a half. The spare day behind it swallowed it whole, and tuning started on the original date for the people who had data and a day later for the rest. The ticketing vendor returned a certificate error that needed a replacement key, which cost another day. That, too, landed in a buffer. And a storm closed one engineer’s office for a morning, which the team simply absorbed because the dry run was not booked until the day after the spare day.

The total delay was real, about three days of lost time in aggregate. The visible delay on the go-live date was zero. The team shipped on day fifteen, as the plan said, and the on-call rota saw fewer escalations in the first fortnight than in the quarter before. The buffers did not make the work faster. They stopped small slips from compounding into missed commitments.

If you are weighing how to place spare time in your own rollout, the thinking behind getting an AIOps introduction right for a team is a useful companion, because the people side of adoption is exactly where the joins live.

How much slack is enough

Dara’s team did not invent a formula, and you should be suspicious of anyone who offers one. Their working habit was modest. They looked at each join, asked what the most likely small failure there was, and set aside enough time to absorb one such failure but not two. If a join could plausibly fail in a way that cost a week, that was not a buffer problem. That was a risk to be escalated and handled directly, with a different plan.

They also made the buffer visible rather than hiding it inside task estimates. A padded estimate is a private secret that the padder will be tempted to spend. A named, empty block on a shared calendar is something the whole team can see and agree to protect. When someone proposed using a spare day to get ahead, the answer was a question: would you rather finish early on one step, or protect the date for the whole rollout?

Some practical rules came out of this:

1. Do not schedule work into a buffer unless something has already slipped. If nothing has, the day is simply a day of lower pressure, which is a perfectly good outcome.
2. Re-check the remaining buffers after every slip. If two of four are gone by the halfway point, tell the stakeholders then, not on the last day.
3. Keep one buffer immediately before any public commitment, whether that is a go-live or a sign-off meeting.

When the join is outside the building

The same logic applies far beyond IT. Anyone who has coordinated something across organisations, such as arranging care or a stay in another country, knows how many joins there are in the paperwork alone. The BestSpineHospitals medical tourism facilitator is a case in point: its pages are organised country by country, and visitors submit appointment requests through an online form. The practical point for any such journey is the same as for a rollout: leave room around the dates, documents and lodging so that one late approval does not topple the rest.

A checklist you can steal

Before you lock the next AIOps milestone plan, walk through it with a pen and mark every handoff. For each mark, ask three questions. Who owns the step before it? Who owns the step after it? What small thing is most likely to make the first one late? Then give that join the least amount of spare time that would absorb the answer.

Then read your calendar the way Dara’s team learned to. If every square is full, you do not have a plan. You have a prediction that nothing will go wrong, and the second week of the project will be spent finding out how wrong that was. If, on the other hand, you can point to four deliberately empty squares and explain why each is where it is, you have a schedule that can survive contact with the real world.

Related reading on the same site: how the platform informs IT decisions covers what happens once the rollout lands, and the rollout is far easier to land when its calendar has room in it.