I have mentioned it before, but there is something that I like to call the golden hour in any multinational organisation. This is a particular time during the day when you can get the three major corporate time zones, ¹ all on a meeting at the same time.

It is normally somewhere between 1:30 and 3:30 UK time. You get an awful lot of large-scale broadcast meetings during this window because it is the only period where everybody is technically available. What this really means, however, is that a lot of important things that people should be paying attention to are all happening at once.

At most clients over the last decade I have seen the same pattern. You will have multiple repeat meetings that you really do need to attend in conflict with lots of other ones of equal importance, plus lots of individual team standups for projects that are cross-region. You would think people would handle this sensibly. Do not book a meeting when people are not available. But a lot of the time the big meetings are aggregate meetings. For example, you might have a weekly meeting where all projects review cloud costs, or where all projects are invited to work through delivery timelines, outages, or similar topics. They pick the time where everybody could theoretically attend because there are fifty, sixty, or more people on the call. In reality, there is never a chance they could all attend, so the meeting is booked in the slot where, in theory, they could.

The inevitable result is that people miss things. Yes, there will be follow-up communications, but the crucial detail you actually need may be buried in a single PowerPoint slide. In a PowerPoint deck of fifty, sixty or seventy slides, attached to an already crowded inbox, you are going to miss things. When enough major communications happen in this way, multiple people miss the same information.

Unfortunately, this is how you end up with something going wrong and the inevitable question is asked, ‘Why was I not informed?’ The answer is usually that it was in an email somewhere.

This is simply a warning note. You either need to protect this time window so that only one or two major calls are scheduled into it, or you need to challenge the approach and ask for communications to be split into regional time zones. As a PM or manager, this is your danger zone. You have to watch it constantly and, stressful as it feels, try to track all the individual updates that might affect your delivery when they arrive as general blasts during this period.

1. India, the US and Europe, [↩]

This is a lesson from earlier in my career that feels painfully relevant to our current cloud environments.

With all of the cloud services now available, one of the biggest changes we have seen is just how many features are suddenly at everyone’s fingertips. In particular, when it comes to on-demand infrastructure, you can now build things in seconds that would once have taken months. That speed has produced a slightly nervous response from a lot of infrastructure, compliance and finance teams, and for good reason. You can get something into production incredibly fast, unlock a lot of demand, and just as quickly build up a very expensive bill without really meaning to.

Remember, one of Amazon’s core principles is to make it easy for people to give them money, and they with AWS and the other cloud providers, brought that mindset to cloud provisioning with real enthusiasm.

The problem is that there never seems to be a sensible middle ground.

In many large organisations, infrastructure services now make it cripplingly difficult to get anything done, often far harder than it ever was with on-prem services or specialist hosting. It feels like the only two options on offer are total freedom or total lockdown.

We have been here before.

The first example that always comes to mind is Microsoft Access. When people wanted space on SQL Servers and were denied back in the day, they used Microsoft Access and Excel instead. When they wanted development capability and were denied, they built it themselves. It became a running joke to judge how frustrated the business was by checking the file systems to see how many new Access databases had appeared and how large they had grown.

Lotus Notes followed a similar pattern. In the early days, users were given templates and just enough rights to create their own databases. Huge numbers of them appeared very quickly. Some became production systems, then the servers filled up and chaos followed. The response was to clamp down harder and harder on new databases and features, until eventually it became so difficult to do anything at all that the core reason for having Lotus Notes disappeared. At that point, you might as well have just used a decent email client. In the end, that behaviour helped cripple the platform.

SharePoint inherited many of the same issues, just with different tooling.

Businesses will always route around blockages. You cannot stop that. What I am seeing again now is the same failure pattern. Crippling bureaucracy is being applied to infrastructure. A new easy-to-use tool appears, and instead of guiding its use sensibly, it gets locked down. What happens next is entirely predictable. Make it hard to get a Salesforce site or proper support, and the business will simply go and buy a new tenant. The same is true of Azure and AWS.

You have to find the middle ground.

If you let people have whatever they want, it spreads like wildfire. You do not get good value for money, and people start building their own little empires rather than delivering value to the business. But if you go the other way and make it cripplingly difficult for the organisation to grow, expand, or even function, then that demand will leak out sideways into shadow IT and unofficial platforms. At that point, you have a much bigger problem on your hands.

So when you are planning your services, and planning how users can request and consume them, remember this. If you make it too hard, you are actively stifling the business. It may comply for a while, but it will eventually find another way. History has shown this again and again.

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.