Two ways of looking at the same set of systems
A standard audit checks boxes. A layered review reads dependencies. Neither is wrong — they answer different questions.
Back to homeWhy the comparison matters
A company considering this work has often already had some kind of systems review, usually from an IT provider assessing security or an accountant flagging licensing costs. Those reviews are useful, but they are built to answer a narrower question than the one that usually matters most: not "is this system current," but "what would happen to the rest of the business if it changed."
The distinction below is offered so you can judge which kind of answer you actually need.
A standard audit, and a layered review
| Question asked | Standard audit | Layered review |
|---|---|---|
| Is the software current | Yes, primary focus | Noted, secondary |
| What depends on each system | Rarely covered | Core output, the dependency sheet |
| Where data is entered twice | Occasionally noted | Specifically recorded |
| Who owns each system | Not usually asked | Recorded against each entry |
| Recommends replacements | Often, as the deliverable | Not at the review stage |
What sets a layered reading apart
The dependency sheet is the clearest difference. Instead of a list of software with version numbers, it sets each system against the processes that rely on it and the person or department that owns it. That single document can change how a leadership team talks about the systems in question — the conversation moves from "should we replace it" to "what would actually be affected if we did," which is a more useful question to answer first.
The other difference is timing. A sequencing session does not assume your team has spare capacity; it works out what fits around the trading calendar you already have.
On results and evidence
We do not publish case outcomes in numeric form, since each company's starting position differs too much for a single figure to mean much across contexts. What we can say is that the dependency sheet and sequencing document are built to be used after the engagement ends — referred back to during budget planning, staff changes, and future vendor conversations — rather than filed away once delivered.
Cost against what it replaces
A landscape review runs three weeks and covers interviews across your functions; a comparable internal effort would draw the same amount of time from staff who already have full workloads, spread out informally over months rather than concentrated into a defined engagement. The comparison worth making is not against doing nothing, but against the cost of the same work happening piecemeal, without a single written record at the end of it.
What working together looks like
Rather than a single report delivered at the end and never discussed again, the interviews themselves tend to surface things staff had not mentioned to management, and the final documents are written to be read by people outside the IT function as much as inside it.
On lasting results
A dependency sheet is slower to go out of date than a licensing audit. Software names change, but the shape of what depends on what tends to persist, so the document stays worth consulting after the engagement is over.
A few common misconceptions
If this distinction is useful to you
A short conversation is usually enough to work out which kind of review would help most in your case.
Get in touch