The IT administration mistakes that cost the most time are not dramatic. They are a record kept in several places instead of one, a row with no named owner, a history overwritten rather than added to, and an entry nobody ever closed out. None of them causes a problem on the day it happens, which is exactly why they survive.
This article is general information about records and administration. It is not technical, security, contract or legal advice, and it contains no configuration guidance. Agreement and license terms differ from one agreement to the next and belong with the supplier and your organization’s own advisors.
What these mistakes have in common
Every mistake below shares one trait: it produces a record that looks fine and is wrong. That is the expensive combination. A missing record announces itself the first time somebody looks for it. A record that is present and quietly inaccurate gets believed, acted on, and passed to the next person.
The cost always lands in the same place, too. Somebody has to reconstruct from invoices, email threads, and whoever remembers. That reconstruction is tedious when it goes well, and considerably worse when the person who knew has moved on.
So the fix in each case is not a better system. It is a smaller, duller habit applied consistently.
The IT administration mistakes that come from scattered records
| Mistake | What it looks like | What it takes to unpick |
|---|---|---|
| Records in several places | Purchasing has one list, whoever hands equipment out has another, finance has a third | Reconciling lists that each use different names for the same thing |
| Personal calendars used as the renewals calendar | Renewal dates live in individual calendars nobody else can read | Rebuilding the dates from statements after one has already passed |
| Internal nicknames instead of invoice names | The register says one thing, the charge says another | Matching charges to rows by elimination |
| No route in | Anyone can commit to a subscription without a row appearing | A full sweep of statements, claims and inboxes, repeatedly |
| Serials typed from memory | The record cannot be matched to the device on the shelf | A physical walk-round with a clipboard |
Four of those five are the same mistake wearing different clothes: there is no single agreed place where a fact lives. The fix is to pick one place for each kind of record, say so out loud, and stop maintaining the alternatives. Two places that disagree are worse than one place that is incomplete, because at least an incomplete record knows what it does not know.
The fifth, serials typed from memory, is worth singling out because it is so easily avoided. Copy the characters as printed, or photograph the label. Nothing downstream works if the paper record and the physical object cannot be tied together.
The IT administration mistakes that come from missing owners
A record with no named person attached is the most common defect in IT paperwork, and it is the one that quietly stops everything.
Rows owned by a department. “IT”, “Operations”, “Finance” — these cannot answer a question. When the renewal arrives and the owner is a team, the question circulates until somebody makes a decision by default, which is usually to let it renew.
Entries with no owner at all. These produce reminders that land on everybody. Everybody assumes somebody else has it. A reminder with no name is noise, and after a few cycles people stop reading the whole list.
Equipment issued to someone who left. The record is not blank, it is wrong, and wrong records do not attract attention. The informal handover between two colleagues is where this starts, and the fix is one line: date, previous holder, new holder.
Deferred decisions with no owner and no date. “We will look at this next time” is not a deferral, it is an abandonment with a polite name. Give it a person and a date or do not record it as pending.
The underlying rule is short. Every row, every entry, every open request has one named human against it. Not a shared mailbox, not a function, not a rotation. A name.
Mistakes that come from editing instead of adding
Records that are edited in place lose the thing that makes them worth keeping.
- Overwriting the last condition check with the latest one. A run of entries saying a device is fine is what gives meaning to the one that says otherwise. Overwrite them and you are left with a snapshot that cannot show a trend.
- Correcting what somebody reported to match what was found. The reported description is evidence of what they experienced. Tidying it up makes the note neater and less true. Record the finding separately and let both stand.
- Deleting rows for things that ended. The question “did we ever have that?” comes up constantly. A row with a status change and a dated closing line answers it on the spot. A deleted row turns it into an investigation.
- Replacing a decision rather than adding the new one. Last cycle’s decision is context for this cycle’s. Stacked decisions show a pattern, such as several cycles of renewing without anyone questioning it. A single current decision shows nothing.
- Undated additions. An entry with no date cannot be placed in a sequence, so a note built this way becomes one block of prose that nobody can read as a history.
All five have the same remedy: add, date, and leave what was there before visible underneath. It costs a line and it is the difference between a record and a rumor.
Mistakes that only show up at handover
Some of these are invisible until the person who has been holding everything together is not there. By then they are costly to fix and nobody knows what they did not write down.
Notes written as personal memory aids. Shorthand, assumed background, abbreviations that made sense inside one team. The author reads them fluently; nobody else can. Write for the colleague who has never seen the request and the problem disappears.
Unwritten exceptions. The subscription that is billed oddly, the device that lives somewhere unusual, the request that is always handled a particular way. These live in one person’s head and leave with them.
No closing line on anything. Requests that stop being worked on without being closed out, equipment that comes back without a return entry, agreements that end without a final note. Each leaves an open item that a successor must investigate before they can trust the record at all.
Nothing dated. A successor’s first question about any record is when. If the answer requires asking somebody, the record has already failed.
Treating any of this as a project rather than a habit. A register built once and never kept current is a snapshot that ages badly, and it is more dangerous than no register at all, because people still believe it.
A short checklist to work through
Read your own records against these and fix whatever fails. The order is deliberate: the cheap fixes come first.
- Does every row, entry and open request have a named person against it?
- Is there exactly one agreed place for each kind of record, with the alternatives retired?
- Does every renewal and expiry date have a day, not just a month?
- Is there a route in, so new purchases and commitments create a record at the moment they happen?
- Are additions dated and stacked, with nothing overwritten?
- Do items that have ended carry a dated closing line rather than being deleted?
- Would a colleague who has never seen any of it be able to read a record once and carry on?
That last question is the only test that matters, and the honest way to run it is to ask someone to try. Hand the records to a colleague, say nothing, and note every question they come back with. Each question is a gap you were covering with your own memory. Fix those in order and the rest of this list mostly takes care of itself. The worksheets behind each of these habits, including the register and calendar layouts, are on the Free Resources page.