I built a video game about IT Asset Management. This is a sentence I did not expect to write at any point in my career.
Actually, I built two of them. One, IT Asset Tycoon, drops you into the life of an IT Asset Manager and asks you to survive twelve quarters of audits, shadow IT, shifting priorities, budget tradeoffs and the usual parade of avoidable mess.
The other, Stocked Up, narrows the focus to the day-to-day pressure of keeping a service operation supplied, balanced, and functional when demand, budgets, and timing refuse to cooperate. Both started as experiments. Both turned out to be a little more educational than I planned.
A lot of people hear about this and assume it was a novelty project, a way to make a dry subject feel more entertaining for a few minutes. And sure, part of the appeal was the novelty. If you try to talk to somebody about the ins-and-outs of Hardware Asset Management, you can see their soul leave their body in real time. If you tell them you built a game about it, at least they stay in the conversation.
But somewhere between designing the mechanics, deciding what should go wrong and figuring out what would count as “winning,” I ran into something useful.
Building these games forced me to reduce Asset Management to its moving parts. Every decision needed consequences. Every shortcut needed a cost. Every delay needed to hurt somewhere. Team chemistry, stress, planning, budgeting…it all had to matter. The system had to react the way real operations react.
In other words, the games had to feel like actual IT Asset Management.
And once I got into that mindset, I realized what I was building was a set of small simulations about pressure, tradeoffs and the little ways an operation falls apart when nobody is paying attention; and that feels pretty familiar.
HAM is a chain of decisions
There is a version of HAM that exists in slide decks and internal documentation, and it would make for a terrible video game. Everything is tidy. You procure the right devices, keep the records clean, manage refresh cycles, stay ahead of audits and maintain visibility without wasting money. Competent, sure. Entertaining, no. Realistic? Even less.
The real version is much more chaotic, which is exactly why it works. Shipments get delayed. Departments hire faster than expected. People order equipment outside policy because waiting is inconvenient. Laptops vanish. Docking stations enter the witness protection program. The spreadsheet says one thing, the floor says another, and Finance wants answers.
Once I started building the game around that version, I stopped thinking in terms of tasks and started thinking in terms of pressure. That is where the challenge lives; demand rises fast, data looks reliable but isn’t and the quick fix solves today’s problem while quietly setting up next month’s mess.
That is also where HAM starts looking a lot like real life.
Planning matters, and adaptation matters more
A game has to reward planning. If the player makes smart choices early, they should feel the benefit later. Otherwise you don’t have a challenge. But in this case, it also has to feel like real Asset Management, and real Asset Management does not care how nice your plan looked on Monday.
Vendor lead times move. Demand changes. Priorities shift. Projects show up disguised as “small requests.” Security tightens the rules. Leadership gets interested in one problem and drains attention from three others. A rigid plan doesn’t survive that very gracefully.
That tension turned out to be useful in game design. If every challenge has a perfect answer, the game feels fake. If every setback is random, the game feels unfair. The player needs enough control for their decisions to matter and enough uncertainty to feel the pressure of those decisions.
That is what HAM looks like when it is running well. You are not relying on a beautiful plan to save you. You are relying on a well-understood operating model. You know what you have, what matters most, where the margins are thin and which tradeoffs are going to cause trouble next quarter.
That is where the challenge lives. It is also where the fun is…if you are the kind of person who builds video games about IT Asset Management.
People are the real difficulty setting
One of the most revealing things about building operational simulations is how fast the human element reappears.
You can try to make the system purely mechanical: inventory comes in, inventory goes out, events occur, choices are made. Nice and clean. But before long, you run into the same reality every IT leader knows: performance depends heavily on people who are stressed, interrupted, under-informed, over-committed and still expected to make sound decisions.
A strong team can stabilize a messy environment through judgment, communication and discipline. A disconnected team, or even a well-meaning one with the wrong strengths pointed at the wrong problem, can turn manageable friction into recurring chaos. The same process will produce very different outcomes depending on trust levels, role clarity and whether people feel safe surfacing issues before they become expensive.
People decide whether to raise a red flag or hope someone else notices. They decide whether to follow the process or bypass it because it feels faster. They decide whether documentation is worth updating after the fire drill ends, and whether a standard is real or decorative.
If you want a better HAM operation, spend some time looking beyond tooling and process maturity. Look at handoffs. Look at communication under pressure. Look at what happens when demand spikes or something goes off script. Those moments tell you far more than a polished workflow chart ever will.
Shadow IT and audits both expose the same thing
You do not need a video game to learn that shadow IT exists. Every organization already has enough evidence of that. What a game can show very effectively is why it persists.
Shadow IT usually fills a gap. Sometimes the gap is speed, sometimes it is complexity. Sometimes it is poor communication, weak service design or a problematic procurement path. A system that is too slow, too opaque or too rigid creates demand for workarounds.
That does not mean you should shrug and accept it. Investigate the conditions that made it an attractive option!
I’ll never forget the time I found out Marketing was running a document repo under a desk off a hotspot to the public web. I shook my head for weeks trying to fathom how we got that far. But they needed it!
HAM professionals spend a lot of time cleaning up after decisions made elsewhere. That is part of the territory. The best Asset Management teams do more than restore order after the fact. They reduce the need for improvisation in the first place. They make the right path visible, responsive and credible.
Audits reveal the other side of the same problem.
You can carry loose processes, partial visibility and deferred cleanup for a while. Then, an audit arrives and suddenly everyone wants to know where everything is, who has it, whether it should be there and why the answer depends on which spreadsheet someone opened first.
Audits have a way of exposing the difference between a function that is busy and a function that is under control.
That showed up immediately in game design. If the player only had to survive the day-to-day, messy short-term decisions were too rewarding. There needed to be moments where the system judged the accumulated quality of the player’s choices. Did you keep your records current? Did you control the environment well enough to explain it back to someone else? Did you build an operation, or did you just keep juggling until the lights flickered?
That is one reason audits matter even when nobody enjoys them. They test discipline over time. They force evidence. They pull hidden debt into the open.
Winning in HAM looks boring from the outside
Games usually have clear outcomes: you win or lose. You hit the score threshold, finish the level, unlock the next thing. A game still needs that sense of progress. The player has to feel that smart decisions mattered, that the pressure was survivable and that by the end they had built something more stable than what they started with.
IT Asset Management is less cinematic.
You know you are doing well when refreshes happen on time, standards hold and inventory is trustworthy. Most of the victories are quiet. They show up as fewer surprises, better conversations, cleaner audits, lower waste, smoother provisioning and more confidence in the data.
The challenge was never to make Asset Management look more exciting than it is. The challenge was to make the player feel what makes it satisfying: holding a messy system together, making good calls under pressure, assigning the right effort to the right problem and seeing the payoff with fewer fires later.
If your HAM practice only works under ideal conditions, then it does not really work. The real test comes later, once budgets tighten, inventories drift, people improvise and projects pile up.
That is when you find out what you really built.