Here is a pattern worth recognising if you work anywhere near IT operations. Someone senior says, “We need to do something about AIOps,” a ticket gets opened with exactly that sentence, and three months later a lot of effort has gone into something nobody can describe as finished. Nothing was wrong with the people. The request was the problem. A vague ask produces vague work, and the cure is smaller and cheaper than most teams expect: write a clear brief before you ask anyone to build, configure or advise on anything.

This is a diagnosis post, so let us treat it like an incident. First the symptoms, then the likely causes, then a fix you can apply this week.

Symptoms that point to a vague request

You do not need a post-mortem to spot a request that was never properly written down. These are the usual tells:

• People in the kickoff meeting describe the goal in different words, and nobody notices until week three.
• The first demo is impressive but answers a question nobody asked.
• Scope keeps growing because there was never a sentence saying where it stops.
• When the work wraps up, the argument is not about quality. It is about whether it counts as done.
• The on-call engineers who will live with the result were never asked what hurts most.

When a couple of those ring true, do not hunt for a technical culprit first. Usually the outcome, the deadline, the limits and the finish line existed only inside one person’s head.

Root cause: the request skipped the boring part

Operations people are good at runbooks and bad at writing requests for themselves. We will happily document how to fail over a database and then send a one-line chat message asking a colleague to “look at our monitoring.” The same discipline that makes an incident timeline useful makes a request useful. It forces choices early, while they are still cheap to change.

There is also an honest human reason. Writing the brief exposes disagreements. Once you try to put “what does done look like” on paper, you find out that the platform lead and the service owner meant different things. That discomfort is the whole point. Better to meet it on a Tuesday afternoon in a shared document than in a heated review a quarter later.

The fix: a one-page brief with five short answers

Keep it to a page. If it needs a table of contents, it is not a brief. Answer five questions in plain sentences.

1. What outcome do we want?

Describe the change in the world, not the tool. “On-call engineers can see which of last night’s alerts belong to the same underlying problem” is an outcome. “Deploy an intelligent correlation engine” is a purchase. Outcomes can be tested by a person who missed the meeting, and purchases cannot.

2. By when, and why that date?

A deadline with a reason is negotiable in the right way. “Before the quarter-end freeze” tells a helper what really matters and what could slip. “ASAP” tells them nothing and quietly teaches everyone that dates are decoration.

3. What is the budget range?

Think of it as a range, not a number to defend. Saying “somewhere between a small experiment and a full quarter of one engineer’s time” is enough to stop someone proposing a programme you cannot fund. It also lets the other side suggest a phased route you had not considered.

4. What are the constraints?

List the fences: systems that must not be touched, data that cannot leave a region, change windows, tools already in place, approvals that take a fortnight. Every item here is a surprise you have removed from the future.

5. What does done look like?

Write two or three observable checks. For example: “Last month’s noisiest incident replays in the new view as one grouped item,” or “The handover document exists and a person who did not build it has followed it once.” If you cannot imagine checking it, rewrite the sentence until you can.

A worked before-and-after

Before: “Please improve our incident response with AI.”

After: “Goal: shorten the time between a customer-facing alert and a named owner. Date: ready for the planned freeze in six weeks, because that is when load rises. Budget: a small pilot, not a platform purchase. Constraints: read-only access to production telemetry, no changes to the paging rota, data stays in our current region. Done: for three recent incidents, the owner is identified from the new view faster than it was in the original timeline, and the on-call team has signed off that the output is understandable.”

The second version is only a few lines longer, yet it can be answered, estimated, argued with and tested. The first can only be nodded at. If you want background on getting the wider team ready for this kind of work, the walkthrough on introducing AIOps into an IT team without the usual stumbles covers the people side, and the piece on tackling IT problems in real time is a handy companion for writing the “what hurts today” paragraph.

Where this applies beyond your own team

The same brief works whether the help is inside the company or outside it. A contractor, a vendor engineer, a part-time specialist or a colleague from another team will all answer more usefully when the page exists. It also protects you: when the finish line is written down, a fair conversation about extra work becomes possible, because both parties can refer back to one agreed line.

Plenty of hiring now happens through online marketplaces, and the brief matters even more there, because you are asking strangers to respond to a few lines of text. ProfessNow works this way: you choose the kind of professional and the place, read through the profiles on offer, then submit a booking request, so the text you paste in is effectively your first and only chance to be understood. Having the five answers ready means that message takes a minute to write instead of an hour of guessing.

Common mistakes when writing the brief

• Describing the solution you already imagined. You close off better ideas and bake in your assumptions.
• Hiding the budget. It does not get you a better price. It gets you proposals in the wrong size.
• Leaving out the people affected. A five-minute chat with the on-call team will improve the outcome line more than any template.
• Treating the brief as a contract. It is a conversation starter. Update it when you learn something, and date each revision.
• Making it too long. If nobody reads past the first screen, you wrote a report, not a brief.

A quick pre-flight check

Before you send it anywhere, read the page as if you were a stranger with no access to your Slack history. Could you tell what is wanted, by when, within what limits and how anyone would know it worked? If a colleague reads it and describes the goal in a different sentence than yours, you have just saved a month. Fix the page, then send it.

The takeaway is small but sturdy: most stalled operations projects began as a vague sentence. Spend twenty minutes turning it into five answers, and the rest of the work gets calmer, cheaper and far easier to finish.