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