An IT Project or programme that needs everyone present, every week, has a single point of failure built in. Why empathy, and capacity, decide if IT projects survive.
A programme that depends on every single person being present, every single week, has a single point of failure built into its plan.
We rarely write it down that way, but it’s true – isn’t it?
Does your project have the capacity for empathy?
One of those “credit where credit’s due” moments is happening right now.
Recently, without going into too much detail, a project manager friend has been dealing with things more important than Gantt charts.
His aging father has needed more support and love.
His boss has done something rather remarkable. He has created a safety net around my friend’s role, allowing him as much time as is required to attend to his father’s needs, without worrying that his workload will pile up or the business will suffer.
As a leader you have a choice: apologise that there’s nothing you can do (and sometimes that’s the hard truth); or put on your thinking cap and do whatever you can.
My friend is one of those solid types; never misses a day sick, always delivers projects on time and in budget, and for me, he always picks up the phone for a fresh perspective or replies to a “give me an outsider’s take on this” email.
In other words, he’s the employee you want to keep!
Sadly, IT Projects rarely have capacity built in for such empathy; they lack resilience to normal human variability. This team was different – they came up with a plan!
THE PLAN?
The boss had put on his thinking cap! He was promoted from my friend’s level, so was able and happy to “step back”. (Side benefit: He is finding the updated hands-on experience useful. Time has moved on since his promotion and having access to “current experiences” is eye-opening!)
Colleagues care about their friend. They have found that they sometimes have extra capacity to share the workload and help out.
Then, when that is not enough, it just so happens that they have a friendly Project Management as a Service provider on speed-dial. Smart!
It seems to be working for everyone. An unexpected bonus is that my friend has talked of a new level of loyalty to his employer and his team.
When folks step up to help with something you care intensely about, it’s amazing what walls you’ll run through for them.
I wish his Dad well. It’s hard when your parents get older and become more reliant on you, as a society we need to be there for each other during these seasons of our lives.
DAM IMPRESSIVE!!
It reminds me of a story I read this year about an aerospace company that was working on a high stakes government contract, their schedule that had no slack anywhere.
Midway through, a dam burst near the town where much of the team lived. Homes were flooded, streets turned to mud, and several team members went to their project manager with the same request: they needed time off, unpaid if it came to that, to go and help dig their community out.
The PM had every reason to say no. The contract was tight, it was a key client, and losing people mid-sprint is exactly the kind of thing that turns a project red.
He said yes – go help!
This team, like my friend, came back with more loyalty and more drive and the projects that could have slipped – didn’t.
The point of both tales is that, rather than stall these projects, empathy actually saved the schedule.
Empathy is a decision. Capacity is what makes the decision affordable.
PEOPLE PROBLEM OR CAPACITY ISSUE?
If you’re the one running the programme, someone still has to keep the thing alive while half a team is away, up to their knees in mud.
Every project leader would like to be the PM in both stories. Very few I talk with feel they can be, because releasing someone mid-programme rarely means the work doesn’t stumble.
It usually lands on the desk of whoever’s left, or it slips, or the CIO ends up explaining a delay to a steering committee that doesn’t care why the schedule moved, only that it did. Being generous with your team, in other words, tends to come with a bill attached that someone (you) has to pay.
If one person’s life changing can derail your project, you don’t have a people problem – you have a capacity problem.
Consider these perfectly ordinary scenarios:
- A team member’s child is taken ill and suddenly parent trumps project manager.
- A new baby arrives and the person who used to answer messages at 9pm no longer does, understandably.
- Someone’s moving house, or grieving, or dealing with something at home that has nothing to do with work but every right to take priority over it.
How would your projects cope? Do you have the capacity to keep on course?
Thankfully, you put your friendly PMaaS provider on speed dial, right?
CAPACITY AS A SERVICE
Quietly, and usually without anyone outside the programme ever knowing it happened, PMaaS can resource under-resourced projects over the line. We’re not a fifth team member sitting on the bench waiting for something to go wrong – who can afford that?
We’re deployed flexibly, into whichever gap opens up. If it’s the RAID log and the schedule that need holding steady while someone’s away, we step into that R. If it’s vendor coordination that needs covering so three suppliers don’t drift out of sync during a fortnight where the usual person is elsewhere, we do that.
The shape of what’s needed changes depending on what’s happened, and that’s rather the point. A dedicated hire can often only ever be as useful as the one role they were brought in to fill.
PMaaS talent can move to wherever the gap actually is.
GOVERNANCE
You know, there’s a governance side to this too, and it matters more than it might sound.
A CIO who can say “we’ve got the flexibility to cover this” isn’t just being kind, they’re actually managing risk.
I know I wrote it but this line has made me think. “A programme that depends on every single person being present, every single week, has a single point of failure built into its plan.”
It’s quite a sobering thought!
Having a partner who can flex in when life happens isn’t a soft benefit sitting alongside the delivery plan, it’s part of the delivery plan.
A colleague calls this “designing projects around bad news, just in case”. I think there’s a kernel of truth in that. Most weeks nothing goes wrong and nobody needs to lean on anything. It’s the other weeks, when something does go wrong, where having a plan decides whether a programme finishes on time.
Or finishes at all.
Or finishes having quietly burned through the goodwill of the people who delivered it.
Stories like these get told because project leaders made a human call under pressure.
What doesn’t get told, is what it takes for the rest of us to make those calls safely.
That’s the part that Stoneseed is proud to help with. It’s less dramatic – I’ll take that every day of the week.
The moment of empathy itself, that’s yours to give, and like my friend’s boss you deserve all the credit when you do.
We’ll take care of the bit that underwrites it.
So, while you’re putting the human back into human resources, your IT projects don’t fall over.
“A project lacking capacity is actually a project with a single point of failure built into its plan”
That’s certainly the starting point for a conversation.
More about Project Management as a Service from Stoneseed
Sources and inspiration https://blog.iil.com/when-empathy-rescues-the-project-schedule/
