Saturday, December 2, 2023

The latest news from the world of project management

How to fail well...

Failure Is the new success. Here are five ways that you can embrace...

5 Skills Needed To...

Why do projects fail? It's a question that invites a lot of interest and...

Embrace the change: Getting...

New IT systems for a growing business can be an exciting prospect and...

New Professional Body for...

The House of PMO, a new professional body for PMO professionals was launched...
HomeGeneralWhy you should...

Why you should stop saying sorry in IT Projects

IT Project Management
IT Project Management

I was in a client’s office kitchen with a project manager I was working with who with was making us both a cup of tea. He was standing in front of the drawer that contained all the cutlery when a colleague entered in search of a fork.

“Excuse me, John, can I just get in the drawer please.”

John (not his real name) replied, “Oooh, Sorry,” and moved.

What was he apologising for?

Sorry for getting there first? Sorry because whoever planned the kitchen put the kettle on the work surface above the cutlery drawer? Sorry for existing?

Thing is, having noticed this unnecessary “sorry” I now hear them everywhere.

A pedestrian engrossed in his mobile phone walked into my wife… she said, “Sorry”. An adjacent diner in a restaurant found a hair in his peppercorn sauce and so called over the waiter. “I’m sorry, there’s a hair in my dinner,” he said. Even last night, a neighbour called round with some really useful community news (gossip) and as I opened the door he said, “Sorry to disturb you.”

Sorry, ahem, you may be wondering what this has to do with Project Management.

Well, it’s a word that I hear a lot in professional circles too and while I accept that apologising for a delay or a budget issue may be courteous, I wonder whether overuse may be diminishing the meaning.

It’s not just when something goes wrong either.

A Project Manager once told me how she had been sent on an assertiveness course by her firm’s HR Director to stop her apologising when expectations of the board didn’t match achievable outcomes or the money they were willing to spend. “I’m sorry, you haven’t budgeted for the overtime needed to achieve that…”, “I’m sorry our IT architecture won’t interface with the software you want to buy…”, “I’m sorry the off the shelf package that is in our current budget range won’t adapt and grow with the business…”. After a day of assertive training, she learned to substitute “sorry” with “no”. Not “sorry we can’t”… just a firm, assertive “no”!

It was as if she felt she had had to defend herself when the impossible was being asked. Actually, an apology would only be needed if she had promised the impossible and then failed to deliver.

Most IT Project “sorrys” though are heard when there’s a spanner in the works.

A CIO once stopped me mid apology and what he said really made me think. I was on the way to meet him when an accident up ahead blocked the road. The radio travel report suggested that I was in for a lengthy wait and although my Satnav plotted an alternative route, I soon found that the surrounding area was gridlocked. I called the client from my mobile, apologised and explained the situation.

An hour late, I eventually arrived and before anything else I started to say sorry again – I guess that’s the way I was brought up. The client raised his hand as if to instruct me to stop.

“I don’t want to hear apologies David,” he said and, at first, I thought he must be REALLY cross.

“Look,” he said, “You already apologised from the car. Even then you didn’t need to. The accident wasn’t your fault, the bad town planning wasn’t your fault. Never apologise for things that are out of your control… thank people for their patience and for rescheduling to accommodate you but never take the blame when you’re not to blame.”

I’d never thought of it like that. I thanked him for his patience and for rescheduling to accommodate me.

He’s right.

How many times in a project do you find yourself apologising for someone else’s bad?

IT Projects are interwoven with dependencies. Delays and mistakes can have a ripple effect that resonates and bounces around like a boulder in a duck pond. Have you ever found yourself apologising to stakeholders or your client when a vendor has failed to deliver? Why are you apologising? You were holding up your end of the bargain. If you’re no more to blame for a delay or a budget overspend than I was for the accident on the road that day – why should you take the rap?

In fact, by apologising you are associating yourself with the problem. You’re saying this happened and I’m sorry … it’s my fault. You are effectively taking ownership of the problem!

Far better to take ownership of the solution.

Taking my CIO friend’s advice how much better would it be to openly acknowledge the error or delay, demonstrate a pin point awareness of the location of the bottle neck in the process and explain what you would personally be doing to put it right and when that would happen.

As a stakeholder or client which fills you with the most confidence? An apology or an action plan?

One of my IT Project Manager friends is a genius at this. When he makes calls like these, rather than apologising, he lists the consequences of a delay as felt by the client followed a subtle positive spin. For example, a vendor issue might cause a delay to market for a key deliverable so my friend would say, “Obviously this will delay the soft launch of the app so it will lose a week of forecast revenue but chasing this bug out now will make it more stable when it launches and lessen potential for reputational damage.”

I asked him why he does this and he told me that it’s two-fold. First, the client feels that he understands their pain and so trusts that he will put it right in their best interest and secondly… how can you be mad at someone when they’ve taken any wind out of your sails by verbalising exactly what you’d be most likely to vent about. In a case similar the hypothetical one above a client actually thanked him for helping them avoid a reputational banana skin!

Reserve apologies for when you personally need to ask for forgiveness. With that in mind, I make no apology for this shameless plug. Most apologies in the project management process come as a result of avoidable issues. Maintaining proper governance and transparency, smart use of a Project Management as a Service partner and regularly gap checking your capabilities against demands can mitigate most of these problems. I know a man who can help you with all this.

Research has actually shown there are physical and psychological benefits for both the giver and receiver of a sincere, genuine, timely and appropriate apology. Why would you want to water this down by over using the word?

The best IT Project leaders, I have learned, do not make “sorry” part of their regular vocabulary. They do not apologise when asked to do something they can’t, they don’t say sorry having a different point of view or alternative values. Instead “sorry” is reserved for only the most appropriate moments.

Find out more about Project Management as a Service from Stoneseed

Related Posts

Continue reading

How Knowing Your PM’s Favourite Rom-Com and BA’s Dog’s Name Could Help Optimise IT Project Success!

Isn’t it beautiful when an IT Project team execute and implement with total cohesion from top to bottom? When colleagues become team-mates, and when leaders understand who they are leading, I think a team becomes almost unbeatable. LESSONS FROM A...

IT Project decision making: How the best choice between two options can often be the third!

The “Crucible Moments” podcast is a fascinating listen, especially as Roelof Botha (whose thoughts are the inspiration for this blog) isn’t the main subject. He plays the role of presenter; the main guest is Jack Dorsey (former Twitter CEO who now runs the financial services company Block). The central narrative of the podcast is the evolution of Block from its origins as Square, and how they created Cash App, a ‘third’ option, which is now responsible for half of Block’s revenue. The strategy of expanding the number of options for consideration was instrumental in helping Block identify and eliminate what wasn’t working and focus on more profitable projects.

An interesting thought experiment: open-book IT Project Management

Empowerment, autonomy, ownership – these buzzwords have rattled around for a few years now in relation to IT Project talent. Most project managers, business analysts (etc) would agree that they have the power to schedule their own time, track their own progress and tasks and choose how they work, to some extent. It usually leads to improved performance – after all who knows how to do a job better than the person who does it day-in, day-out?! What if you could take this improved individual performance and amplify it across your whole project or portfolio?