Skip to main content

Practice knowledge base

Resource request process

A resource request process creates a clear path for getting equipment, budget, people, or time so that decisions do not depend on personal arrangements.

Organization resource-request-process
Documentation sections

What it is

This is a working procedure that an employee or team uses to request the resources they need and track the status of the decision. The process defines the criteria, owner, response time, and possible reasons for denial. This practice solves the problem of delays, hidden approvals, and disputes about who can allocate equipment, budget, people, or time.

When it helps

  • Teams delay tasks because they do not know how to request people, budget, equipment, or additional time.
  • Resource decisions are made in private chats, and other participants do not understand why one request is approved and another is denied.
  • Managers spend a lot of time on repeated follow-up questions instead of seeing a complete request right away.
  • The request status gets lost: the initiator does not understand who is reviewing the issue or when to expect a response.
  • Priorities conflict with each other because there are no common criteria for urgent and regular requests.

How to start

  1. 1 Choose one channel for requests: a form, spreadsheet, or task in a tracker where the initiator, resource, reason, and desired deadline are visible.
  2. 2 Assign a process owner who checks that the request is complete and routes it to the person responsible for the decision.
  3. 3 Define the minimum criteria: why the resource is needed, what risk the request removes, and what alternatives have already been checked.
  4. 4 Define request statuses: accepted, needs clarification, approved, denied, postponed, and specify the owner of each status.
  5. 5 Review the first week of requests and remove any fields or approvals that do not help with decision-making.

Expected effect

Teams understand more quickly where to go for resources and what they need to justify. Managers receive comparable requests, can see the decision queue, and spend less time going back to the same follow-up questions.

Common pitfalls

  • Making the form too long: people will start bypassing the process through personal arrangements.
  • Not assigning a status owner: the request is formally submitted, but no one moves it to the next step.
  • Hiding the reasons for denial: the team sees the decision as arbitrary and starts arguing about the same resources again.
  • Handling urgent and regular requests the same way: critical blockers get stuck in the general queue.
  • Launching the process without reviewing the queue regularly: statuses become outdated and stop being useful for management.

Further reading

  • Book: Gene Kim, Kevin Behr, George Spafford, The Phoenix Project
  • Book: Eliyahu M. Goldratt, Critical Chain
  • Guide: Project Management Institute, PMBOK Guide, sections on Resource Management and Procurement Management
  • Book: David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business

FAQ

Who should own the process?

Usually, this is an operations manager, a functional manager, or the PMO. What matters is that the owner can assign people responsible for decisions and regularly clean up the request queue.

Can you start without a new system?

Yes. To get started, a spreadsheet or a task in your current tracker is enough. The main thing is a single entry point, clear fields, statuses, and a visible person responsible for the next step.

How can you tell whether the process is working?

Check whether there are fewer repeated follow-up questions, lost requests, and decisions made in private chats. A useful sign is when initiators can see the status themselves and know who makes the decision.

What should you do if managers bypass the process?

Look at what is missing for them: speed, the right to make an exception, or a convenient format. Keep a fast track for urgent blockers, but record the decision and the reason in the shared queue.