Requirement intake and baseline

Procurement work begins with the outcome a user needs, not with a preferred supplier's name. “We need new printers” might describe inadequate capacity, recurring failures, or a lack of support for existing machines. Each diagnosis could lead to a different response, cost, and risk. Record the request as received, then interview the user, technical owner, and budget owner to identify a problem that can be checked. The specialist does not decide alone that buying is the answer. They establish the need and alternatives for an authorized decision. The CIPS procurement cycle moves from specification through market engagement, selection, contracting, and supplier management, so a weak starting definition affects later steps .

A useful need record answers seven questions. Who uses the output? Which task does the present situation obstruct? What volume is required, over what period? What observable result would count as success? When must the solution work, and what happens if it is late? Which constraints are real, such as compatibility or delivery-site capacity? Who owns the budget and approval? Attach the evidence available for each answer: service tickets, transaction counts, failure logs, or a site observation. Mark an answer unknown when evidence is missing, with a person and date for confirmation. An unsupported number looks precise but can distort quantity and evaluation.

Separate a request, an underlying need, and an assumption. “Buy 40 devices” is a request. “Process 1,200 transactions weekly within an agreed waiting time” is a need. “Each device processes 30 transactions per week” is an assumption to test against operating and downtime data. If ten existing devices are underused because work is allocated poorly, the purchase quantity may change. The specialist need not run a full operational redesign: record the gap and escalate it to the process owner. Conversely, a verified repair history may show that replacement is justified. The point is to make the reasoning visible before choosing a sourcing route.

Establish a baseline before specifying a solution. Define the denominator and period: for example, 87 of 100 orders due in one month arrived on time. On-time performance is 87%; it is not an “average delay of 13%,” which measures something else. Record exclusions such as canceled orders or orders not yet due. Note the dataset, extraction method, and date so the measure can be repeated after award. Where the user's record conflicts with the warehouse record, retain the discrepancy and seek a reconciliation rather than silently merging them. Ask whether a process adjustment could meet the need and whether the cost of inaction is documented.

Next, make a one-page need card: problem, user, current and expected volume, baseline, desired service, confirmed constraints, information gaps, initial alternatives, stakeholders, and decision boundary. Prioritize by disruption, required date, and ability to plan. Calling an item “urgent” does not itself waive competition or approval rules. If finance and operations disagree about volume, show a low and high scenario, name the assumption that drives each, and seek approval of the planning basis. The card is an input to the specification and market scan, not an authorization to sign or order.