Two little words is all it took. Two little words that changed the destiny of a project and the project manager. Now these two words were spoken by the CEO of Group Operations for a major UK bank, but they were only two words. The two most under used words in project management.
There was a major project underway to replace the core banking system for the bank. The existing system was running on some ageing Unisys kit that was difficult to manage and prone to outages. Not a great situation for the bank or its customers. So this project was going to replace the system with a brand new one running on the latest IBM mainframe systems. The budget had doubled and the project manager was gleefully telling anyone who wanted to listen that he expected it to double again before the project was done.
It was a big project by any standards. Today it would be a £1bn+ mega programme, but back then it was another big project. It was about 18-24 months in when the new CEO of Group Operations arrived. Like any good executive, his first task was to take stock of the business and people he had inherited. The core banking system was right at the top of his priorities. So he rolled out the first of my two words…..
He asked why the bank was investing so much time and money in the project. He was told about the problems with the Unisys mainframes and how critical the core banking platform was to the bank. But things had moved on. Whilst the project team were beavering away, the Unisys support team had installed the latest A series Unisys mainframes. These were much more resilient. In fact they hardly ever failed. And even when they did, they were very easy to bring back up. So the core reason why the core banking system replacement project had been initiated was no longer valid. All from one little word. Why.
Now the bank could have carried on but the CEO rolled ut his second little word – no! No we will not continue with a needless project eventhough we have invested money in it. The return was no longer there.
So two little words – why and no – challenged and then stopped a project.
How many times have you, as a project manager, asked why your project is needed. Or asked why your project should continue. Too many people are afraid to stop a project fearing it will be classed a failure. Sending good money after bad would be the real failure. I have stopped several projects r programmes I have either run or reviewed because I couldn’t get a justifiable answer to the question why. Stopping a project that is either no longer needed or is destined to fail to deliver the required benefits is a success. You save the organisation money. You free up resources to be put to better use generating new benefits.
No isn’t just for when you are deciding to continue or stop a project. Project managers must learn to say no throughout the project or maybe even at the start. A good example of this came about during a 2 day senior managers course on project management. We had run 6 or 7 intensive 12 day courses for project managers and this 2 day senior managers course was to explain to their bosses what the project managers had been through and the issues they had raised.
One exercise was a team game. To add a bit of pressure we would through in an extra question that had to be answered before the team could continue. One team had the MD of Operations in it. He said ‘no’ to the extra task. He argued that the project had been set at the start of the game and that he was not going to accept a ‘change control’ i.e. more work, just because we said so.
It may have been a game, but he was dead right and we amended the learning points from that exercise to include that challenge for all future courses. How many times do you accept changes into your projects despite the additional pressure and risk that the extra work entails. Shouldn’t you be saying ‘no’ more often?
Nobody is saying that you shouldn’t accept change requests. Projects are, by their very nature, uncertain and requirements will change. But each change should be assessed and challenged and only accepted if the resulting risk, use of contingency, delay or increase in resources is accepted by the business and the project manager believes it can still be achieved. Too often project managers are bullied or squeezed to accept unrealistic changes and then get blamed for the inevitable delays or overspends.
Good project managers continuously ask why throughout their projects. And they often say no – to new, unreasonable requirements, to demands on their time that are not conducive to delivering the project, to requests for their best resources. Always ensure you have a good rationale for saying no before you do. But if someone wants something, the answer is no, now what’s the question?
Do you have examples of asking why or saying no? Share your experience by leaving a comment below.