In recent weeks, I’ve observed that there seem to be three ways of communicating ‘news’ in IT Projects.
i) To communicate the news, update or information half as big as it is in reality.
ii) To communicate the news, update or information twice as big as it is in reality.
iii) To communicate the news, update or information exactly as it is in reality.
Think about it. It’s pretty much true, isn’t it? Negatives get downplayed or airbrushed and positives get exaggerated all the time. Only the third way of breaking project news, exactly as it is in reality, allows your reader to respond appropriately.
Picture the scenario. Your Project Management Office is already under pressure when you identify that a once key strategic IT project will no longer deliver outcomes that are aligned with business goals. It’s the main thing in your portfolio and frankly, without it, even you’d have to question the viability of your PMO. This happened to a friend and he asked me what I’d do.
The problem was the way the firm’s customers were accessing its products and services was changing, they were migrating to online and the IT Project my friend was working on was geared to making the in-store operation more efficient.
The options were (a) flag up your thinking and face the consequences, (B) continue as planned, or (c) fess up but downplay the problem and make subtle scope changes that plastered over the cracks. The project was on time, on budget and not due to be finally delivered for just under a year which meant everyone’s mortgages would be paid for another eleven months or so. My friend’s instinct was swinging behind (b) and (c), basically keep smiling and plough on.
Eventually, after some thought and discussion, I think his conscience or his professionalism got the better of him and he decided to front it out.
Well, the board was delighted with his integrity. Like my friend, the board’s strategic thinkers had identified a migration to online but unlike him they hadn’t identified that if the trend continued the current project would be almost irrelevant in less than five years. The Project team was tasked with a new mission they were to make the online customer experience better than their competitors’. This was in 2010. The project team members are still able to pay their mortgages today.
Philosopher Sissela Bok suggests that lying is a form of coercion. To not tell the truth is to lead the person with whom you are communicating to behave in a way in which they would not have behaved had you not spun the reality. Certainly, in IT Project terms a strategic response to a situation is greatly hampered by a lack of transparency in the way it is communicated.
Sometimes it’s not even a downright lie that comes back to haunt you.
I recall a board buying into an IT Project scope change on the basis that the improved sales order process it delivered would yield a 15% increase in sales. The claim didn’t stand up to scrutiny but no-one challenged it and approval for the tweak to the new software rollout was granted. On time and under budget it went live and twelve months later sales were up 5% year on year. Not 15%. The CEO started asking questions.
The problem was that it was never within the power of the IT project to ever deliver a 15% spike in sales. What it would do (and what it actually did) was deliver faster sales order processing, it reduced admin and allowed the sales guys more time to chase an estimated 15% more sales. Obviously, whether they did was up to them and the market climate which at the time was challenging, to say the least.
Looking at the facts … the project was delivered on time, under budget and it created an environment that allowed sales to increase by 5% in a difficult climate. You’d have to have a heart made of concrete to consider this anything other than a success but that’s what happened. There was no popping of champagne corks and that promise of 15% sales increase would come back to haunt time and again.
It wasn’t a deliberate lie and it wasn’t meant to mislead.
So … communicating exactly as it is, allows for a properly measured response but you should also be mindful of the language that you use. For example, I once saw an email in which a Project Manager predicted that “project success was virtually assured.” As a stakeholder or sponsor, if you read that at face value you’d probably relax and eagerly await the project delivery date.
Thing is, when he wrote the email, the Project Manager was aware of some potential challenges that could delay the project. They would also require some extra resources to overcome them. However, various random things would have to happen first for it to be an issue so he took a judgement call on the probability of the challenges even occurring. Chances were assessed as ‘minimal’ and so he decided to conceal the intelligence.
Then, the various random things happened and the project delivered late and over budget!
The problem with words like “virtually” is that they are misleading. What does it mean? In this context “virtually assured” means “almost” or “not quite”. How differently you would react, as a project sponsor, if your PM emailed to say the project was “almost” or “not quite” assured success?
A lot of the language I see in Project communication is the equivalent of claims in adverts that a mouthwash “helps prevent gum disease” or a snack can assist you to “lose weight as part of a calorie controlled diet”. The casual viewer takes in the message about preventing gum disease or weight loss but misses the inference that something else must contribute for the product to deliver the effect advertised. Toothpaste or not eating doughnuts probably play a greater role than the products being advertised but how many units would that message sell?
In this case, the Project Manager could have put a number on his prediction, like the bleach that kills “99.9% of known germs. The PM could have also spelt out the criteria, however unlikely, that could cause a potential delay and increase in cost .. so “project success … virtually assured” becomes “project success 98% certain, 60% in the unlikely event of A, B and C happening”. This would at least open a line of communication about the likelihood of A, B and C and might even prompt the sponsor to create a contingency budget.
The moral of the story is, tell the truth. The consequences of doing so are never as great as the consequences of lying, spinning or concealing the truth.
Back in the day, shining a light on an IT Project problem would probably have meant sponsors having to put their hand in their pocket to fix it. You’d tell the truth about a problem and then make sure that you were standing nowhere near a fan!
Times have changed, the Project Management as a Service market is sufficiently evolved now to ensure that a solution to most problems can be bought in often with no increase in your overall costs.
And that’s the truth.