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

There’s a useful analogy I once heard from musicians about how orchestras really work. Officially, the conductor runs the show. They set the beat, they give the cues, and everyone’s eyes are on them. To the audience, it looks as though the conductor is firmly in control.

But orchestras have their own quiet safety net. If the conductor is incompetent, unreasonable, or simply fails to lead, the orchestra doesn’t fall apart. Instead, it starts following the lead of the “first trumpet” ¹. The clever conductors will realise this, and self-aware ones take it as a sign: if the orchestra is following someone else, something has gone wrong in their leadership.

Most of the audience will never notice the shift. They’ll assume the conductor is still in charge. But the musicians know, and so do the more experienced listeners.

I think this is the best analogy I’ve ever come across for corporate projects. If you’re the project lead, the “conductor”, and you find that people are no longer coming to you with problems, or that you’re having to chase rather than being sought out for help, chances are you’ve already been quietly replaced by a “first trumpet”.

This isn’t a role that anyone really wants. It’s an extra burden on the person who has stepped up, often reluctantly, because the team still needs direction. The only real solutions are for the formal lead to:

1. Step aside.
2. Fix what’s going wrong,
3. Replace the “first trumpet”

If you suspect this has happened to you, the best thing you can do is find out who your team is actually following and ask them genuinely where you’ve gone wrong. They’ll usually tell you, because they don’t want your job; they’d much rather you were doing it properly.

Projects, like orchestras, need a conductor. The trick is to remain the one the team chooses to follow.

Update

I got some feedback on this from an old friend and it looks like the origin instrument suffered a little bit from Chinese whispers, and rather than “First Trumpet”, it should really be “Lead Violin”

“As a trumpeter, I would love to say this was true, but it’s really the Principal 1st Violin, who also has the title “Leader” for this very reason. Three reasons for that choice:1) the violinist is at the front where everyone can see them 2) it’s easier to follow their bow movements than it would be to follow any movements made with a trumpet 3) they are playing most of the time (unlike the trumpets) so there’s something to follow”

“I’ve certainly played in concerts where this happened… if you go back a few hundred years, conductors weren’t a thing, and orchestras were usually led by someone playing – often the harpsichord. Most jazz bands still run this way. I guess you don’t need to go back that far to find a dev team without a scrum master of whatever they’re called…”

1. that is the head trumpeter in an orchestra[↩]

Management and technical resources speak very different languages. We’ve all known this for ages, and I don’t just mean the acronyms and formal formats that each side uses. They genuinely see the world in slightly different ways. What feels like a perfectly clear form of communication to one side can be almost incomprehensible to the other.

This gap shows up most clearly when one side is expecting something specific from the other but only phrase it in their own terms. I see this most often in status updates.

Managers tend to approach status updates in a holistic way, covering the entire project. If you’re unlucky, this might mean multiple slide decks. More commonly, it takes the form of long, structured emails sent out at regular intervals to the technical teams. The problem is that these communications are very much TL;DR ¹ to the tech teams. Somewhere inside there may be a specific task for an individual, but the actual responsibility, timing, and relationship to other work isn’t clear to the technical teams that are doing the work.

This is where project managers need to go the extra mile. Yes, it’s important to produce that “state of the nation” overview for the project. Yes, senior stakeholders often want slide decks that show the big picture at a glance. But if you expect deliverables from technical teams, especially when there are multiple teams with separate budgets and priorities, it’s far better to follow up with individuals or team leads.

A simple, targeted email to the responsible contact in each team, spelling out exactly what you need and by when, cuts through the noise. Without this, you risk adding to the confusion. Technical staff are often bombarded with 10, even 15, different project update calls in a single day. These inevitably clash, contradict, or simply blur together.

If you want results, you can’t just carve out a block of “admin time” in people’s calendars and expect it all to be absorbed. Keep your asks small, specific, and clear. The less of people’s time you waste, the more effective the outcome will be.

1. or “Too Long Didn’t read”[↩]