Corporate term: “Admin Rampart”

Posted on by Mark Myers Leave a comment

Definition

An “Admin rampart” is an odd but very real construct. It is a defensive structure, usually built by one team, silo, or functional area to protect itself from the perceived aggressions of another.

Explanation

Often the creation of “Admin Ramparts” is the unintended consequence of a well-meaning initiative.
A large corporation realises that it is drowning in paperwork and process, to the point where it is actively impeding delivery to the business and even to itself. In response, it launches a drive for simplification or boundary breaking.

In practice, this rarely breaks down the old issues. Instead, new processes are created in the hope that they will simplify delivery. The critical flaw is that the existing processes are very often not removed first. Another layer is simply added on top, usually by the team creating the new framework. This is done to demonstrate progress and the aim of simplifying delivery.

Meanwhile, the areas whose boundaries and controls are being challenged frequently respond by placing even more dependencies in front of their current processes, as they feel they are losing control of their own deliveries and so want to place responsibility safeguards in place for the inevitable “blame game”; sometimes these dependencies become cyclic and impossible to achieve for a new delivery. The result is that regardless of whether you follow the new route or not, you still have to complete all of the old steps as well, often just under a different name.

This back-and-forth, without ever dismantling what already exists, produces admin ramparts. These become great walls of paperwork that serve to deflect blame, avoid responsibility, and maintain control, rather than enable delivery.

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.

 

Planning the Next Three Months.

Posted on by Mark Myers Leave a comment

That time has rolled around again when a major client decides to shift direction. In this case, the client has moved to an “internal first” approach in which all projects are by preference run by internal staff rather than consultants or vendors. Part of a rather neat way of upskilling their permanent people.

I have been through this two or three times before. It is an expected part of the corporate life cycle. The challenge is not the decision itself, but how you handle it. Given the nature of what I do and the skillset I have, I am usually involved in several projects at once, each with its own timeline and statement of work. Even though I have been working on multiple projects over the last couple of years for the same global group, they will not all finish neatly at the same time. About half will wrap up at the end of the financial year. but one will carry on for a couple of months beyond that.

This leaves me with only a 50 percent commitment for the first 2 months of 2026. Normally this is not a problem. You simply take on additional clients, join my fellow LDC Via members on other projects, and carry on as any consultancy would. This time is a little different because I have been on call for this particular client for more than a year. Moving back to a restrictive and rigid time allocation could spoil an excellent existing relationship.

So how should I handle it?

In this case, skill development has come to the rescue. Like everyone else, I have been upskilling in AI and related technologies, but the deeper I dug into the true nuts and bolts of its implementation rather than simply jumping on the bandwagon, the more I realised how serious a discipline it really is. AI integration is far more than bolting a chatbot on top of your database. There is an enormous amount of nuance and variance in structure and architecture if you want it to be genuinely useful to a client.

Add a few months of relatively fluid time, and the situation more or less screams “deep dive learning”. Fortunately, there are proper boot camps where you effectively become a developer for a couple of months, work in sprints, and demo at the end of each one. It is an intense way of learning, and the one I have enrolled in and paid for should fill the gaps in the AI knowledge I have identified from my work so far.

It also means I will remain on call for the major client through January and February, giving them the level of delivery they want at the price that suits us both. I get the learning in, and the next client benefits from everything I have picked up.

What surprises me is how new this mindset seems to be for some colleagues. This is not contractor thinking. This is consultancy thinking. You plan ahead by at least three months, build your capabilities, and make sure that for the next engagement you’re stronger than the last.

And on that note, if you are looking for a technical PM or an integration architect at the end of February, do feel free to knock on my door. Or speak to LDC Via and we will see how we can help.

Management Tip: Try To Get Your Delivery Dates Out of Sync with Other Projects.

Posted on by Mark Myers Leave a comment

A sneaky little tip for project managers is to try to move your project delivery times to be out of sync with the usual delivery patterns for your organisation.

Most projects tend to aim for the same delivery date, often tied to the end of a large corporation’s financial year, usually December. That seems sensible enough on paper, but in practice, it causes a predictable pain.

In today’s service-oriented infrastructures, where there’s a shared pool of resources, budgets, and dependencies, any delay in one project tends to ripple across the lot. As a result, all the deliveries bunch up at the same time. That’s fine; because as managers and architects we are paid to deal with that kind of thing, but what we often forget is that everyone else is paid to do the same thing at the same time.

The outcome? The last few months of any given financial year are pure mayhem. Every team wants extra time, extra effort, and extra support from all the shared support teams to push their project over the line. Everyone’s pulling on the same people and systems at once.

If I had my way and could get involved right at a project’s inception, I’d always try to schedule its delivery for a quieter time of year, when other projects aren’t all competing for the same shared effort. It’s a small adjustment that I find makes a huge difference to delivery quality, stress levels, and overall sanity in your teams.

Priority Without Consequence in Projects

Posted on by Mark Myers Leave a comment

When you are running any form of migration, integration, upgrade, or indeed any project that touches a live business process, there will always be a battle between BAU 1 and the project. This battle can be over resources, vendor time, budget, or even something as core as system uptime. Inevitably, there will be a debate about who gets their stuff first.

The default position is usually that BAU takes precedence. A production issue always wins against everything else. However, if you are managing either BAU or the project, you must remember that every priority comes with a consequence. This is the part that often gets overlooked.

For example, a BAU team might say, “We’ve got a production issue, we need the developers to drop everything,” or “We need to cancel the weekend outage because we have to work through it.” It makes no difference what the specific request is. The key point is that even when one side’s priority is accepted, it is often assumed by that side that there will be no consequence or no cost for exercising that priority.

When this happens, you will often need to have the awkward but necessary conversation: “Yes, we’ll all pile into the BAU problem, but this will have the following knock-on effects.” I would strongly advise anyone running projects to be crystal clear on this at the time. People have very short memories about these things, and later you will hear questions such as “Why is your project late?” or “Why has BAU been impacted?” Without a proper paper trail, it becomes very hard to justify the outcome.

So when you have a situation where one side’s work must take priority, acknowledge it, accept it, and then record the consequence. Provide a bill, whether that is measured in lost time, extra budget, or a revised delivery date. It is the only way to maintain fairness and transparency between BAU and project work.

  1. Business as usual [↩]

Integration Support Challenges in Production

Posted on by Mark Myers Leave a comment

Now this is an incredibly dull subject, but one that many companies continue to struggle with when it comes to integrations.

All integrations, by their very nature, are quite brittle processes.

They often involve converting data from one format to another, and because they cross multiple systems and ownership boundaries, they can be difficult to pin down when things go wrong.

Many of the endpoint systems that are integrated into have very restrictive support models, and security rules often mean that each team can see only a limited part of the picture.

So, once the project work has been completed and everything is technically “working,” as it should, then the real challenge begins, which is how do you actually support it in the long term?

Of course there will be issues around monitoring, workflow, ownership, and escalation paths, but ultimately it comes down to one thing:

Responsibility.

People rarely want to follow a formal process that leads to them having to pay for it to be fixed. Instead, you’ll hear, “Oh, X is broken, call Y.”

It’s human nature, and integrations tend to encourage this kind of finger-pointing.

“It’s your bit that’s broken, not mine.”

The best tip I’ve found for handling this is to ask a very simple question…

Is this a new piece of code, a new application, or a new machine? If so, who are you paying to look after it?

That’s the crux of the matter. If there’s no budget, then most departments will quite rightly say, “That’s not our responsibility,” unless it’s a simple configuration change or something that clearly falls within their existing remit.

But integrations rarely work like that.

They almost always introduce new code, new objects, or new dependencies.

So, the next time you’re trying to work out who owns a piece of integration work, just follow the money.

Whoever is being paid to maintain it is responsible for it. If no one is, then you haven’t yet found an owner. And if someone is willing to take the funding or resources, then they are, by definition, the right people to make responsible.

It’s a simple question, but it saves a lot of pain.