A war list is an informal term for a concise list of priority items used when a project is starting to spiral slightly out of control. It is most commonly employed by a task force.
Explanation:
A War List, often just a single-sheet on an Excel file, might initially start as a very long list of all the things that need attention on a project. However, it is the project manager’s responsibility to organise and prioritise this list, transforming it into a structured “order of march.” The War List differs from a regular task list because it is typically managed manually, frequently updated by the project manager themselves in a spreadsheet. It serves as their personal working document to track and manage tasks. While other team members are not expected to update this list directly, it remains accessible as a constant, living reference for the team.
Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.
Quick tip for anyone painting Word Bearers in the Warhammer 40K tabletop world. You will have seen the runes that they are famous for covering their armour with and that appear on their transfer sheet:
Well, it turns out they are just Enochian “the mystical language recorded in the journals of John Dee.” which is open source and for which you can find lots of open fonts to make your own
I also include one here in case they all disappear: enochian
I had a fascinating experience recently that really highlighted how far software development has come, and how some things haven’t changed at all. It began, as many of my days do, with trying to resolve a conflict between two technical teams who weren’t seeing eye-to-eye.
Normally, getting everyone in a room to clarify dependencies is straightforward enough, but this time, something unusual was at play.
On the surface, it seemed like a typical methodology clash: one team heavily leaned toward waterfall approaches, while the other embraced agile development. Easy enough, right? Just find common ground between methods and move on.
But as the discussion unfolded, it quickly became apparent there was more to the issue. Both teams, despite their methodological differences, consisted mainly of younger developers with around ten years of professional experience. And yet, the deeper we dug, the clearer it became that struggles to understand each other’s challenges was rooted not in methods, but in the technologies they were using.
One team was working with a cloud-based service UI, a modern SaaS environment where flexibility is the norm. Defining and changing fields in such systems is almost effortless: you can quickly roll back changes, validation updates automatically, and code provides clear flags and warnings. Fields are disposable, easy to manage, and quick to modify even at the last minute.
Contrast this with the other team’s world, developing for a mainframe system that has been around for more than three decades.
Here, field definitions are anything but flexible. Fields are strictly limited in length, difficult to modify once provisioned, and changing field types after the fact is practically impossible. In some cases, the system demands pre-provisioning fields en masse just to have some flexibility later, making every change a monumental effort.
This stark difference in environments had created a disconnect. Each team was frustrated, not realising the other’s technical constraints. The cloud-based team couldn’t comprehend why changing fields could be such a big deal, while the mainframe team couldn’t understand why the cloud team kept pushing changes that seemed careless and that made assumptions.
It was fascinating because usually, this kind of misunderstanding happens between technical and non-technical teams or between business stakeholders and developers. But this was a rare case of two technical teams misunderstanding each other simply because their platforms and experiences were worlds apart.
For me, it was a powerful reminder: integration specialists and project managers today don’t just bridge business requirements and technical execution, they also need to bridge knowledge gaps between entirely different technological eras. It’s not enough to understand the technology you work with; you have to grasp the challenges faced by those working on completely different platforms, sometimes from a completely different generation of computing.
If you work in a support, technical, or specialist role, you’ve probably felt the urge to dismiss a project manager’s status or planning demand with “I’ll get to it later.” or “FFS” but before you do, it helps to remember what drives their behaviour.
Project managers are hired to deliver one outcome, nothing more, nothing less.
Especially in contract roles, their performance is judged almost exclusively on whether the project’s scope, timeline, and budget are met. They aren’t rewarded for keeping infrastructure stability long term or for preserving team morale. They’re rewarded for shipping.
Prioritise deadlines over comfort: If a subject‑matter expert is at capacity, the project manager may still push, because slipping the schedule is costlier to their success and thus them than your overload.
Ignore peripheral fires: Issues that don’t directly block the project often fall outside their remit, even if they matter to you.
Understanding this incentive structure doesn’t excuse poor behaviour, but it does offer practical ways of working with them:
Clarify capacity early: Spell out what’s realistic, agree on trade‑offs, and document them.
Frame updates in impact terms: Explain how delays or scope changes affect the critical path; PMs will adjust if the risk is explicit.
Escalate strategically: When workload or morale is at stake, involve sponsors who balance delivery with sustainability, even offer to talk to the sponsors directly to help fight your case.
A project manager’s laser‑focus can feel abrasive, yet it’s the same focus that keeps initiatives from drifting. Recognise the problems they face, communicate to them within that context, and you will be able to get a better working relationship.
Recently, we encountered an interesting issue related to field size validation when integrating newer systems with older backend systems, particularly involving Chinese characters and UTF-8 encoding.
Modern systems typically handle Chinese characters correctly as single characters. Thus, if you set a validation limit of, say, 255 characters on an input field, each Chinese character will count against 1 of that limit.
However, when these characters are passed to older backend systems still using UTF-8 encoding, each Chinese character may expand into multiple UTF-8 character slots. As a result, data originally within your set limit can unexpectedly exceed the backend’s field size, causing overflow errors or truncation.
You can see this in action below, comparing the results of encoding various characters to UTF-8:
