During the handover of a departing work planner, a list slides across the table: nine macros, four spreadsheets with formulas 'you should not touch', a downloaded utility for DXF names and a network folder simply called 'old2'. The successor nods politely and thinks: which of these actually still run, and what breaks if I throw one away?
That is what tool sprawl on an engineering team feels like: every little helper was once a good answer to a real problem, but nobody has an overview of the whole anymore. Even teams that run a maintained toolbox like Thundercad next to Inventor face the question of what else is quietly running alongside it. In this article: how to surface what is actually in circulation, how to decide per item between adopting, replacing or retiring it, and how a lightweight intake process keeps new sprawl out.
How every department builds a shadow toolkit
Sprawl is not a sign of sloppiness but of resourcefulness without direction. An engineer who does the same clicking every week builds a macro for it on a Friday afternoon. A work planner who has to reshape BOMs for purchasing puts a spreadsheet full of formulas next to them. Both solve their own problem, and that is exactly why it keeps happening: every problem gets its own solution, from its own maker, in its own place.
The risk is not in the helpers themselves but in what is missing around them. There is no owner once the maker leaves or changes roles. There is no version control, so nobody knows whether the copy on the network share is the right one. There is no documentation, so a formula with a mistake keeps calculating unnoticed for years. And an update of Inventor or the operating system quietly knocks over a macro that a release process genuinely depended on. The longer you wait, the better the odds you find out in the middle of a busy project.
Taking stock: surface what is really running
You can only decide once you know what exists. Just do not ask by email 'which tools do you use?', because half will be forgotten: precisely the little macro that has been humming along for years does not feel like a tool. Instead, spend an hour sitting next to each colleague and watch what actually gets clicked. Also check the places where helpers tend to gather: toolbars and add-ins in Inventor, startup folders, and network folders with names like 'tools', 'macros' or 'temp'.
Record five things for every item you find:
- What does it do, in one sentence?
- Who uses it, and how often?
- Who can repair it when it breaks?
- Which data does it touch: only its own screen, or BOMs, drawings and exports that go to production?
- What happens tomorrow if it stops today?
On a team of five engineers, a round like this easily turns up a few dozen items. That is not an embarrassment, that is the starting point. The list itself is already a win: for the first time, someone can see the whole picture.
Decide per item: adopt, replace or retire
With the list in hand, you make an explicit decision per item. Three outcomes are enough:
| Decision | When | What you do |
|---|---|---|
| Adopt | It works, it is used and it solves a real problem | Name an owner, pin the version in one place, write short documentation, train a second person |
| Replace | The job is standard, maintenance leans on one person or the item touches production data | Move to a maintained alternative and only switch the old item off afterwards |
| Retire | Nobody remembers what it is for, or it duplicates another tool | Announce it, archive it, switch it off and clean it up for good after a waiting period |
Two questions from the table deserve honest arithmetic. Whether a job merits its own tool at all depends on frequency, error risk and the time it takes; that model is laid out in When does automating pay off? Three thresholds. And when replacing, the build-versus-buy question shows up. We will not repeat that trade-off here: use iLogic or a ready-made toolbox? When to choose what as your decision model. The pattern is familiar though: a pile of loose export and clean-up utilities often folds into one maintained toolbox like Thundercad, so updates and support sit with a vendor instead of with the one colleague who happens to know how to code.
Does your inventory list contain a row of home-built export, clean-up and BOM utilities? Spend a month testing whether one maintained toolbox can take that row over.
Try 30 days freeRetiring without a revolt
A tool you take away without explanation resurfaces somewhere else within a month. So retire visibly. Announce which item is going, why, and what the alternative is. Allow a transition period in which old and new run side by side, so nobody has to switch in the middle of a project. Archive the old item with a short description instead of deleting it: if someone asks about it half a year later, you can retrieve it and understand it.
Then measure whether it is missed. If nobody asks about the old spreadsheet for three weeks, the decision was right. If there is protest, you have learned something about a need your inventory missed, and that is worth more than being right.
A lightweight intake process against new sprawl
Without agreements, the growth starts again the day after your clean-up. The answer is emphatically not a committee and not a paperwork circus, because then everyone goes back to building in secret. One sheet with four questions is enough for anyone who wants to introduce something new:
- Which problem does it solve, and how often does that occur?
- Is there already something on the list that can do this?
- Who becomes the owner, even if the maker leaves?
- Does it touch data that goes to production or to a customer?
The only hard rule: anything that touches released data is on the list and has an owner. Beyond that, keep the tone inviting: building is fine, hiding is not. Discuss the list a few times a year in your regular team meeting and it stays current without turning stewardship into a full-time job.
Frequently asked questions
Would banning personal macros not be much simpler?
Simpler yes, more effective no. A ban drives the helpers underground: they end up running from a USB stick or a private folder, out of sight entirely. Channelling works better: building is allowed, as long as it is on the list and has an owner. You keep the resourcefulness and lose the risks.
Who should manage the inventory list?
Someone with technical authority and a bit of earmarked time, usually the CAD administrator or a senior engineer. More important than the job title is the mandate: this person may mark an item for retirement and is involved in every new intake. Without that mandate, the list is decoration again within a year.
When is a home-built tool due for replacement?
As soon as maintenance leans on one person, the item touches production data or every Inventor update causes tension, the risk outweighs the convenience. If a maintained alternative exists, the choice is quickly made. If you want to test whether a toolbox can take over part of your own list, you can try Thundercad free for 30 days.