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.

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 ¹ 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 [↩]

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.