If, buts and maybes. Mind your IT Project language
Can certain words cast a negative shadow on Project Management thinking?
Originally published on CIO.com
I walked into a Project Management Office recently, and on the wall, in large letters above the Project Leader's desk was the phrase 'No "Ifs", "Buts" Or "Maybes"'.
At first, it looked like one of those platitudes that you often see, sharing wall space with "Be The Change You Want To See" and "Teamwork Makes The Dream Work" (apologies if you have those on your wall). I asked the team leader, Malcolm, about the poster and he told me it was his own creation, to remind him of his personal philosophy about the use of language and the impact that it can have on IT Project outcomes.
He explained briefly how he believed that "if", "but" and "maybe" were words that could cast a negative shadow on Project Management thinking. I thought about what he said on the drive home and wished we'd had more time together.
When I got home an email was waiting for me that went into more detail, so I thought I'd share it with you and perhaps start a conversation about what other words, phrases and hard-wired beliefs we should banish from our collective Project Management vocabulary.
Here's what Malcolm wrote about "if", "but" and "maybe"
"If" introduces a conditional clause ... 'if the sun shines we can have a picnic'. There's no place in our Project Management thinking for presupposed conditions that dictate outcomes. If it rains, then we'll have our picnic indoors or on a rug in the garage. Too many IT Projects fail because of dysfunctional conditions ... my epiphany came years ago when a project leader used to say things like "if the scope creeps anymore we're in fatal trouble", "if delivery is delayed there will be penalties", "if we exceed our budget for outsourced services, we’ll have to cut back on overtime". In each of these cases, we'd either rein in scope creep or ensure that impact on delivery or budget was clearly communicated and agreed, explain why delivery was delayed and renegotiate a new date or make the case for more budget for overtime ... rarely were any of the "ifs" fatal.
"But" opens the door for excuses. 'I'd love to go on that picnic but it's raining'. In IT Project Management "but" can kill innovation. Again, I had a eureka moment when I heard a CIO once say "It would be great to be able to have an extra Project Manager for a few days but the budget won't stretch". I did the maths and the penalties saved by meeting KPIs on a huge project alone would have justified the 'expense'. This project was also devouring resources from across the portfolio, making them late, so extra skilled talent would have had a massive positive impact ... BUT apparently, it was too expensive.
David’s note: Actually, hiring in talent through the Project Management as a Service (PMaaS) can often be done without net increase in portfolio/project expenditure.
"Maybe". The most indecisive Project Manager I ever worked with used the word 'maybe' A LOT! With the benefit of hindsight, he was putting off making a decision until he really had to. I recall one afternoon, in the early days of phone apps, we had an app that just wasn't ready for launch ... it had a few bugs ... needed baking a little longer! We asked if we should delay, should we get the project sponsor to make the call, the PM answered 'maybe'. All the maybes added up until the time to make the call had passed – it really came back to bite us!
Google the word "maybe" and among the searches that comes back is a graph that shows usage of the word from 1800 to 2008. We are in the grip of a 'maybe' epidemic that has been rising since the 1970s! What does maybe mean? It means you're not certain, you're unsure ... we have no room for "maybe"!
Interesting isn't it?
By the way, I love Bernie Roth's approach to the word “but". In his book “The Achievement Habit”, the Academic director of Stanford's famous 'd.school' suggests that you say "AND" instead of “BUT”. He writes, “When you use the word 'but', you create a conflict (and sometimes a reason) for yourself that does not really exist.”
In other words, to use the example quoted by Malcolm, it would be great to have an extra Project Manager for a few days — AND the budget won't stretch. Using AND instead of BUT you acknowledge that the need and the budget concerns both exist, and this allows you to find a solution that meets both clauses. You could ask for extra budget, actually get some quotes, look to save elsewhere. BUT, on the other hand, kills the idea of hiring that extra pair of Project Management hands.
When you use the word AND, “your brain gets to consider how it can deal with both parts of the sentence,” Roth writes.
I'd love to hear from you - what other words could vanish from OUR lexicon and not be missed?
Personally, I always mentally rebuke myself whenever I present an alternative solution as "the other way" ... rather than "another way". As if my idea were the only other possible fix - the arrogance of it!
Which word or phrase would you like to see the back of in IT Project Management?
Whilst I agree with the sections of the article on 'But' and 'Maybe', I do have an issue with the 'If's being 'a negative shadow on project management thinking'.
Surely each conditional clause can be looked upon as a Risk - (IF it rains; IF the scope creeps ...; IF delivery is delayed ...) and as such the risks need to be identified, preferalby as early as possible, so that contingencies can be planned in case the IF becomes reality. The project manager would then monitor the project / weather forecast / change requests / delivery schedule and have a plan to deal with each scenario as it arises.
I would suggest that a Risk Analysis would be very positive Project Management thinking, and not to plan for the 'ifs' would be a lot worse.
The point Jerry makes is a very good one – by definition risks are something that may happen and therefore can be directly replaced with an IF statement.
I think the point i was trying to convey in the article is the need for clarity of definition within project delivery, rather than somehow proposing that we could provide absolute certainty around the operating environment and banish all risks and the need for risk management altogether – after all what would happen to all those RAID logs !