Approvals Without a Committee: Who Decides What

Tuesday, 14:30, at Harbourview Clinic. Priya runs a desk of three and has just counted the tickets waiting for the Software Review Group. It meets on the first Thursday of the month and last met two weeks ago. There are twenty-three waiting tickets. Nineteen are for programs the clinic already owns seats for. Three are for free tools. One is for a dictation add-on that a consultant called Amara needs for a clinic that starts on Monday. The group has six members, two of whom attend. And it was set up four years ago after a receptionist installed a screensaver that turned out to be something else. Priya has the dictation ticket open and is drafting a message to Amara that begins "Unfortunately the next review is". She stops, because she can already hear how it ends.

An approval is a recorded yes from the one person who owns the decision the request is asking for. Without a committee means each question inside a software request goes to the single person who can answer it. The questions are: is it allowed, who pays, is it safe? They go in a ticket, in hours, rather than to a group that meets. A committee is what an organisation builds when it has been burned once and does not yet know which question burned it. So it asks everyone every question, monthly. This article is part of our Software Installs & Licence Requests series. And it is about replacing the meeting with a short list of named people and a rule for which of them is asked.

It covers why committees form and why they stall, followed by the three questions and their four routes. Then come the pre-approved list that needs nobody and the manager who approves the cost and nothing else. Next are the security look for anything new, the one-line business case, recording the approval on the ticket, and the stalled approval and the chase. A short war story and the approval matrix to copy come last, in that order.

Why Committees Form and Why They Stall

A software review committee is nearly always a scar. Something was installed that should not have been, and nobody could say afterwards who had allowed it. The organisation's answer was to make sure that next time everyone would have allowed it. The instinct is sound and the mechanism is wrong. The screensaver at Harbourview was not a failure of too few approvers. It was a failure of no record and no question about what the program did. A committee answers that failure with six people and a monthly date, and the six people, being busy, send two.

Committees stall because a group decision waits for the slowest member and belongs to none of them. A manager asked "does your budget pay for this" answers in a day, because it is their budget and their answer. The same manager may be one of six members of a group asked "should the clinic have this". They answer at the meeting, if they attend, after a discussion in which nobody is the owner of the no. Decisions made by a group are made by nobody, and nobody is very hard to chase. (Nobody is also, in my experience, reliably out of the office.)

The cost of a committee is paid by the requester and never seen by the committee. Amara's dictation add-on is a free program that costs the clinic nothing and touches no patient data. It has been on the consultant's own laptop for a year. The committee will approve it in nineteen days, after a meeting at which it is item fourteen. Meanwhile Amara will dictate into her phone and e-mail the recordings to herself, which is the outcome the committee exists to prevent. A process that takes longer than the workaround is a process that selects for workarounds. The fix is not a faster committee. It is no committee, and three questions instead.

Three Questions, Four Routes

Every software request is answered by asking three questions in order, and each question has one owner. First: is it on the pre-approved list? If yes, nobody is asked anything, and the ticket goes straight to install. Second: does it cost money, now or at renewal, beyond seats already owned? If yes, the person whose budget pays is asked, and only about the money. Third: is it new to the organisation, meaning no copy of it runs anywhere on the network yet? If yes, whoever looks after security is asked to take a look, and only about the risk. A request may reach the end of the three questions without being on the list and be neither paid nor new. In that case, it goes to the desk lead with the requester's one-line business case. The desk lead's job is then to say yes and add it to the list, or say no and say why.

That gives four routes, and the whole design is that most requests take the shortest one. At Harbourview, Priya ran her twenty-three waiting tickets through the three questions. Nineteen were on the list or on a licence the clinic already owned with seats spare, and needed nobody. Two were free and already running in another department, and went to her with a one-line case. One was paid, and went to the practice manager. One, the dictation add-on, was free and new. It went to Jonas, who looks after security alongside the network, for a look that took him twenty minutes. The committee's next agenda had twenty-three items on it. By Thursday it had none.

The order matters because each question is cheaper than the one after it. The list is a lookup, free. The money question is one person's one-word answer, and a no there saves everyone the security look. The security look is real work, twenty minutes to an hour. And it should only be spent on requests that have already cleared the money. Ask the cheap question first and the expensive one last. And the expensive one gets asked a few times a quarter instead of a few times a week.

The Pre-Approved List Needs Nobody

The pre-approved list is the set of programs the organisation has already decided anyone, or anyone in a named role, may have. And a request for one of them is not an approval question at all. The decision was made when the entry went on the list. Asking it again for every requester is asking the organisation to re-decide something it has decided. That is what committees do and why they fill up. The list belongs to the desk lead, grows from the exceptions that keep recurring, and is the subject of Reducing Software Request Friction. Here the point is only its place in the approval design, which is first. Its effect is that the approval workflow never sees most requests.

The one check that survives on a pre-approved paid program is the seat count, and it is a check, not an approval. If the clinic owns ten seats of the records viewer and nine are in use, the tenth goes to the requester without a question. If all ten are in use, the request has become a purchase, and the second question, who pays, applies to the eleventh seat. The seat count comes from the licence register, which is the subject of Licence Tracking Without a Tool. A desk without a register cannot run the pre-approved route for paid software honestly. It cannot tell a free tenth seat from a bought eleventh.

Resist the urge to add "unless" to the list. "Pre-approved unless the requester is a contractor", "pre-approved unless it is the second copy", "pre-approved unless the manager objects" each turn a lookup back into a question. The questions accumulate until the list needs a committee to read it. An entry is on the list for everyone it says it is for, with no exceptions, or it is not on the list. If an entry needs conditions, write the conditions into who it is for ("all clinical staff") and leave the rest off.

The Manager Approves the Cost, and Nothing Else

The manager who holds the budget is asked one question, whether their budget pays for this. And the discipline of the whole design is not to ask them anything else. Not whether the program is suitable, which they cannot judge. Not whether it is safe, which is the next question's owner. Not whether the requester really needs it, which is the one-line business case's job and which the manager will read in passing anyway. The manager's yes means "pay for it from my budget". And a manager asked only that answers quickly, because it is a question about their own money and they know the answer.

Ask with the number in the question. "Can your budget cover a seat of the drawing add-on for Luis, at the price on the supplier's quote attached, renewing yearly?" is answerable in one word. "Please approve the attached software request" is not. The manager has to open the attachment, find the cost, work out whether it recurs, and decide whether "approve" means something more than paying. Put the cost, whether it recurs, and the requester's one-line case in the three lines the manager will read. And the approval comes back in the same hour more often than not.

The manager's yes also has to come from the manager. A requester who writes "my manager says it is fine" has reported a conversation, not supplied an approval. The desk asks the manager anyway, politely, with the three lines. This is not distrust; it is the record, and the record protects the requester as much as anyone. Six months later, the renewal arrives and the manager asks who approved a yearly cost against their code. "You did, in the ticket, in your own words" ends the conversation. "Luis said you were fine with it" starts a different one.

The Security Look for Anything New

The security look is a short, bounded check of a program the organisation has not run before, done by whoever is responsible for security. And its output is one of four words: yes, no, conditions, or refer. On a desk of three, the person responsible for security is usually the desk lead or the person who also runs the network. The look is twenty minutes to an hour. It is not an assessment, not a penetration test and not a procurement review. The moment it starts to look like one of those, the answer is "refer" and the request goes to whoever does that work properly. The desk's job is to decide whether the thing is ordinary. Everything that is not ordinary goes to the security function, and the desk does not try to do their job with a search engine and a lunch break.

The look asks plain questions and writes the answers in the ticket. Who makes it, and do they say so plainly, with terms a person can read? What does it do with the organisation's data: does it send any out, store any elsewhere, or sign the organisation up to anything? What access does it want on the machine: an ordinary user's, or an administrator's, and if the latter, why? Is it the kind of program that touches the things the organisation cares about most? Those are patient records at a clinic, drawings at an engineering firm, the ledger at a bank. Has anyone else, anywhere, raised a concern about it that a quick search turns up? None of these needs a specialist. All of them need to be written down, because the answers are the reason the yes is a yes. The next person to ask for the program should not have to make Jonas answer them twice.

Conditions are the useful middle answer and the one committees never give. "Yes, on the clinic laptops but not on the reception machines." "Yes, with the data-sharing setting turned off, and the desk installs it rather than the requester." "Yes, for a month, and we look again if more than five people want it." A security look that can only say yes or no will say no to anything it is unsure about. And a security look that can say "yes, like this" gets the requester their program and the organisation its boundary. Write the conditions into the install note and the catalogue entry, so that they travel with the program and not with Jonas's memory.

A free program is not a special case, and nor is a browser extension, a plug-in or something the requester already uses at home. New is new. What the desk says when the request is for something free, personal, or already in use by half the department is the subject of Unapproved Software Asks and the Shadow IT Conversation. The approval design only says that the security look is the gate those requests pass through and that it takes less than an hour. That is less than the time it takes most requesters to find the download page.

The One-Line Business Case

The one-line business case is the requester's sentence saying what the program lets them do that they cannot do now. And one line is the whole specification. "I need to compare two versions of a drawing and the viewer we have cannot show differences." "Clinic letters come back from the typing service in two days and the add-on lets me dictate them directly." "The spreadsheet we use for the rota crashes above two hundred rows and this one does not." A line like that lets the manager decide about the money and the security lead decide about the risk. It lets the desk lead decide whether the catalogue already has something that does the same. All of that is possible without a conversation.

Ask for one line and mean it, because a longer case is harder to write and no easier to decide. The committee at Harbourview had a two-page request form with a section headed "Strategic Alignment". The requesters filled it in with a sentence and the committee did not read it. The strategic alignment of a dictation add-on is that letters go out faster. Nobody needed a page for it. A form that asks for a paragraph gets a paragraph of padding around a sentence of fact. And the padding is what the approver has to read past. Ask for the sentence.

The one line also catches the request that is really a problem. "I need a PDF editor because the forms the council sends will not open" is not a software request. It is a ticket about forms that will not open, and the fix may be a setting, not a purchase. The desk reads every one-line case with the question "is there a cheaper way to get what this sentence says". About one in ten, at most desks I have seen, has one. That one is the request the organisation is happiest to have declined, because the requester got what they wanted and nobody paid for anything.

The Approval Recorded on the Ticket

An approval that is not in the ticket is a rumour. And the rule is that the approver's yes sits in the ticket's history under the approver's name, in the approver's own words. The easiest way is for the approver to reply in the ticket. The next easiest is for the technician to forward the approver's e-mail into it. That way, the message, its sender and its time become part of the history. The worst is a note saying "approved by Tom by phone", which is the technician's memory of a conversation. The technician's memory is the one piece of evidence nobody will accept when the renewal is questioned.

Most small-team help desks have no approval step built in. The convention that replaces one starts with a waiting status and a note to the approver with the three lines they need. It ends with the approver's reply landing in the ticket. The convention in full, with how to make it visible in the queue, is in Approvals Without a Workflow Engine. If you run QuerySolv, the approver's yes can sit in the ticket as an internal note the requester never sees. Or it can be a public reply they do see. The complete event history shows when it arrived and who it came from. Either way the ticket holds the decision, not somebody's inbox. In any tool, the test is whether the approval survives the technician leaving.

Record the no with the same care, and record the conditions with more. A declined request with its reason is the most useful thing on the ticket for the next requester who asks for the same program. And a yes-with-conditions whose conditions were never written down is a yes. The conditions go into the install note and, if the program is added to the catalogue, into the catalogue entry. That way, the next install carries them without anyone having to remember. Jonas's "yes, with the data-sharing setting off" is worth nothing if the second install, by a different technician, leaves the setting on.

The Stalled Approval and the Chase

A stalled approval is a ticket waiting on a person who has not answered. And the desk's rule is that it chases on a schedule rather than on a feeling. After two working days, send a reminder to the approver with the three lines again, because the first message is under forty others by now. After five, send the same reminder with the requester copied. That way, the requester can see who the ticket is with and the approver can see that the requester is waiting. After ten, the desk lead asks the approver's own manager whether someone else can decide. That is an escalation of the decision rather than the ticket and is done the way Saying No Upward describes: in writing, with the deadline, without heat. The wording of a reminder that gets a reply rather than an apology is in Follow-Up Messages That Get Replies. The schedule is what this article adds.

Tell the requester at every step, because the stall is invisible to them and the silence reads as the desk's. "Your request is with Tom for the budget; I chased today and will again on Friday" costs one sentence. It prevents the ticket a requester raises on day six asking whether anyone has looked at it. The requester cannot chase their own manager comfortably; the desk can. When the desk says who the ticket is with, the requester usually can too, over coffee, which is faster than any reminder. The desk's job in a stall is to make the waiting visible and to keep it from being mistaken for the desk's own delay.

Set an end to the wait and say it on the form. A request that has had no decision after a stated number of working days, fifteen at Harbourview, closes as "no decision reached". A note to the requester says it can be reopened by replying when the approver is ready. This is not the desk refusing; it is the desk declining to carry a ticket that nobody with authority is willing to decide. A queue with forty requests "waiting for approval" from the spring is a queue telling a lie about the desk's backlog. The honest shape is a closed ticket with the stall recorded and the door left open. The mechanics of stalls in general, and the approver who never answers anyone, are in Approval Workflows That Do Not Stall, which is about access requests and applies here unchanged.

Count the stalls by approver, quietly, and read the count once a quarter. Most managers answer in a day. One or two answer in a fortnight, every time. The fix for that is not a sterner reminder but a conversation between the desk lead and that manager. The question is whether that manager wants to delegate the decision to someone who is at their desk. Most say yes with relief. The approval they were not answering was never a decision they wanted; it was a message they could not find.

A Short War Story: The Seven-Week Compare Tool at Redbrook Engineering

Redbrook Engineering ran software approvals through a monthly Technology Review Board. An engineer called Sofia submitted a request for a free file-comparison tool in the week after a meeting. It would be heard at the next one, which was cancelled, and then at the one after. That meeting approved it, seven weeks after she asked. In week three Sofia had found a web-based comparison service. She uploaded two versions of a client's drawing to it to see what had changed, and went back to work. The client found out because the service indexed the drawings, which nobody at Redbrook had known it did. The client raised a complaint that took the engineering director, the desk lead and an outside adviser twenty hours to answer and a long letter to close. The review board's minutes for the month showed the tool approved without discussion. The desk lead, Marcus, replaced the board that autumn with three questions and three names. The first free tool requested under the new design was approved in forty minutes. Jonas's counterpart wrote in the ticket that the tool kept files on the machine and sent nothing out. The lesson Redbrook wrote into its new process was the one the board had never minuted. An approval that takes longer than the workaround is an approval of the workaround.

The Approval Matrix

The matrix below is the one Priya pinned beside the desk after the committee's last meeting. And it is read top to bottom for each request, stopping at the first row that applies. Each row names the question, the one person who answers it, and what they are asked and nothing more. It also names the time the desk expects an answer in and where the answer is recorded. Fill in the names for your own organisation, including the deputy for each, because an approver on leave is the commonest stall of all. Then put the matrix on the catalogue page, so that requesters can see who will be asked about what before they ask.

Priya sent Amara the dictation add-on on Wednesday morning, after Jonas's look, with the one condition he had set written into the install note. The Software Review Group's remaining members were told by e-mail that the group was retired and that the three questions replaced it. They were told that any of them could ask to see the count of approvals by route at the end of the quarter. One of them did, and the count was ninety-one requests. There were seventy-four needing nobody, eleven needing a budget holder, five needing Jonas, and one referred. That total was more than the group had decided in a year and had taken, in total, less time than one of its meetings.

Frequently Asked Questions