{"id":11782,"date":"2026-11-08T17:30:00","date_gmt":"2026-11-08T17:30:00","guid":{"rendered":"https:\/\/www.cotocus.com\/blog\/?p=11782"},"modified":"2026-11-08T17:30:00","modified_gmt":"2026-11-08T17:30:00","slug":"it-request-primer","status":"publish","type":"post","link":"https:\/\/www.cotocus.com\/blog\/it-request-primer\/","title":{"rendered":"Writing an IT Request: A Beginner’s Primer and Glossary"},"content":{"rendered":"

If you are new to working with outside IT help, the vocabulary can feel like a barrier. Terms such as scope, acceptance criteria and deliverable appear in emails as if everyone had been born knowing them. This primer explains the handful you need, in the order you will use them, and shows how they fit into a one-page brief. A clear written request is the most economical step in any technology engagement, and it requires no technical depth, only careful thinking about what you want.<\/p>\n

Why begin with a written request<\/h2>\n

It takes no effort to word a technology job loosely, and a great deal of effort to finish one that was worded that way. “Improve our deployment process” can mean a new pipeline, a documented checklist, a training day or a tool purchase. When the request does not choose, the person answering must choose for you, and their choice reflects their habits, not your needs. A short brief shifts that decision back to the person who understands the business.<\/p>\n

Mini-glossary for beginners<\/h2>\n

Brief<\/h3>\n

A short document, ideally one page, that states what you want, by when, with what limits and how you will judge the result. It is a request, not an agreement.<\/p>\n

Outcome<\/h3>\n

The change you want to see once the work is done, written in terms of what people can do or what stops happening. “Releases no longer need a weekend” is an outcome. “Install a pipeline tool” is a method.<\/p>\n

Scope<\/h3>\n

The boundary of the work: what is included and, just as important, what is excluded. Scope is the single word behind most project arguments, so write it down early.<\/p>\n

Constraint<\/h3>\n

A fixed condition that shapes the work, such as an existing cloud provider, a compliance rule, a team size or a freeze period. Constraints narrow the options and make replies more precise.<\/p>\n

Deliverable<\/h3>\n

A concrete thing handed over: a document, a configured system, a training session, a report. If nobody can point to it on delivery day, it is closer to a hope than a deliverable.<\/p>\n

Acceptance criteria<\/h3>\n

The pass-or-fail checks you will run on delivery. They are the technical form of “what done looks like.” Good criteria are observable, such as “a new team member can reproduce the setup using the document alone.”<\/p>\n

Budget range<\/h3>\n

The spread of spending you are prepared to approve, with a note on what it covers. A range is more useful than a single figure because it lets the reader propose options.<\/p>\n

Assumption<\/h3>\n

Something you are treating as true without having confirmed it. List yours, since a wrong assumption is a hidden risk. Suppose you assume the infrastructure team will provide access in week one. If that is untrue, the date moves.<\/p>\n

Assembling the glossary into one page<\/h2>\n

Put the terms in this order: outcome, deadline, budget range, constraints, deliverables, acceptance criteria, assumptions. Seven short blocks, each one to three sentences. The result reads like a compact specification, but because it is brief it will actually be read by the person you send it to.<\/p>\n

Before you write, it may help to see what a similar organisation was trying to achieve with its own operations tooling. An overview of sequencing an operations improvement effort step by step<\/a> shows how much groundwork sits behind a single request, and why writing assumptions down is worthwhile. Likewise, a comprehensive explanation of what advisory work on machine-learning operations covers<\/a> will help you phrase deliverables in terms an adviser recognises.<\/p>\n

Where the request goes<\/h2>\n

If your own network cannot supply a person, a directory can help. ProfessNow is an online marketplace where you look up a trade in a given town, read the profiles people have published, and then submit a booking request<\/a>; its list of categories includes technology and business consulting. The brief you wrote above is what you paste into the message. The directory introduces you; the page explains you.<\/p>\n

A beginner’s worked example<\/h2>\n

Imagine a five-person team that wants to stop deploying by hand. A weak request reads: “We need DevOps help.” A strong brief reads as follows.<\/p>\n