Internal tools rarely fail because of one bad decision. They fail because of fifty reasonable ones. Someone asks for an extra field, then a report, then an export for the accountant, then a chat box. Each request is small and each has a sensible author. A year later the tool is slow, hard to explain and expensive to change, and nobody remembers agreeing to any of it.
The cure is not to refuse more. It is to decide earlier, once, what the tool is not for. A short not-doing list does that. This article explains how to write one, who should own it and how to use it without becoming the person who always says no. It is aimed at owners and managers of small companies who commission or maintain custom tools.
Why a list of "not" works better than a list of "yes"
A feature list says what exists. It says nothing about what was considered and left out, so every old idea comes back as a new request. A not-doing list records those decisions together with the reasons.
It also changes how a request is judged. Without a list, the question is "is this a good idea?", and almost everything is, in isolation. With a list, the question becomes "does this fit the purpose of the tool, or does it belong somewhere else?" That is a faster and less personal question to answer.
Start from the purpose, not from the backlog
Write one sentence that says what the tool is for and who uses it. For example: "This tool lets the office team record customer orders and see their status." Everything the tool does should serve that sentence.
Then ask what people might reasonably expect it to do that is not in the sentence. Typical candidates:
- Reporting beyond the basics. Orders are recorded here, but analysis happens in the spreadsheet or the accounting system.
- Customer-facing access. Staff use the tool; customers do not log in.
- Replacing another system. It does not issue invoices if the accounting software already does.
- Special cases for one person. It does not support a private workflow that only one colleague uses.
- Free-form storage. It is not a place for attachments, notes and anything else people want to keep.
Add items from the history of the tool as well. Look at requests you have already declined or postponed. Each of those is a candidate, because it will come back.
Keep the list short and give each line a reason
Five to ten items are enough. A list of forty items will not be read. For every item, write three things in one line each:
- What the tool will not do. In plain words, such as "It will not send e-mails to customers."
- Why. "E-mails to customers go through the mailing system, which already keeps consent and unsubscribes."
- Where the need is met instead. "Use the mailing system; the tool shows a link to the order for copying."
The third line matters most. A refusal that points somewhere useful is much easier to accept than a bare no. If there is no better place to meet the need, that is a sign the item may belong in the tool after all.
Agree it with the people who use the tool
Draw up the first version with the tool owner, the main users and whoever pays for changes. A thirty-minute meeting is usually enough. Read the purpose sentence, go through the candidates and ask each person whether they could live with the item on the list. If someone cannot, discuss it then, not three months later when the request arrives as a complaint.
Keep the finished list where people already look: at the top of the documentation, or on the page where change requests are submitted. A list nobody sees cannot prevent requests. If you already have an intake routine, as described in our article on handling change requests after launch, the first question on the form can be whether the request touches anything on the list.
Decide who may change it
A list that anyone can edit is only a wish list, and a list that nobody can edit becomes outdated. Choose one named person, usually the business owner of the tool, who can remove an item or add one. Changes should leave a short note: the date, the item and the reason.
Moving an item off the list is a real decision with a cost. It should be priced like any other piece of work. Our article on fixed-price estimates for small software jobs shows how to separate what is in the number from what stays out, which is the same idea applied to a single job instead of a whole tool.
Use it as the start of a conversation
When a request lands on an item, do not simply quote the list. Say what you see: "This is on the not-doing list because of the mailing system. What are you trying to achieve, and can that be done there?" Often the real need can be met another way. Sometimes the request exposes a change in the business, and the list should change with it.
If the requester still feels strongly, the trade-off is simple to state. Adding this means either more budget or giving something else up. The owner decides, and the decision is recorded. For requests that fit the purpose and are not on the list, the usual scoring and scheduling applies, for instance the short intake and quarterly decision described in feature requests for an internal tool.
Review it twice a year
Set a date, ideally together with other regular checks on the tool. Go through each item and ask whether the reason still holds. A supplier may have changed, the company may have grown or the other system may have been replaced. Remove items that no longer make sense and add the ones that came up repeatedly since the last review. Ten minutes is usually enough.
Common mistakes
- Writing it as a punishment. The list describes the tool, not the users' bad ideas.
- No reasons. Without a reason, every item looks arbitrary and gets argued again.
- Too long. Anything over ten items is a policy document, and people stop reading it.
- Never revisited. An outdated list blocks good changes and loses its authority.
- Applied only to others. If the owner makes exceptions quietly, the list stops working at once.
A first step
Write the purpose sentence of your most important internal tool today, then list three things people have asked it to do that do not fit. Put reasons next to them and show the page to the main user. That small draft is already a working not-doing list, and you can grow it from there.
Sources
- Practical guidance based on common software maintenance practice, offered as a planning aid. The examples are invented for illustration. No client results or performance figures are claimed in this article.