Once, in what seems like a very long time ago, an inexperienced but highly motivated Project Manager, armed with a shiny new Prince 2 certification, put together one of his first risk management workshops. He published and circulated agendas, understood his stakeholders, invited the appropriate ones, booked rooms and made sure everyone was in attendance. Once everyone was seated, the Project Manager began the session by explaining the format on how it was going to be run, what the expected outputs of the session would be, why they were important and how they would be used for the life of the project.
So far, so good.
After the PM had finished his introduction and had full control of the room, he began the session steaming down the path of risk management glory! Everyone knew why they were there, knew what the project was delivering and understood the value of session. The PM in question thought things were going swimmingly, right up to the point that a more seasoned resource asked this awkward question.
“Shouldn’t we define our success criteria for the Project first?”
*insert facepalm here*
I am both unhappy and happy to say that the Project Manager in question was me. I have made a few mistakes in my career, and in the overall scheme of things, this one wasn’t massive. The Project was successfully delivered, I lived to tell the tale. Most importantly, I remembered this and learned from it.
So what was the big deal?
Well to put it simply, I fell into the same trap that the business was falling into. I believe it is confusing “output” and “outcome” within the scope of project management and getting hung up on the output. Everyone knew what the output of the project was “we’re going to implement ‘X’” and it will be great! However, the more important question is “why”? Seems pretty simple but some businesses and Project teams get so enamoured with the output and sometimes the outcome gets lost by the wayside…I mean, the project budget was approved, so the project was justified. No need to worry too much about the “why” anymore, right? Particularly with a Business screaming at you to “just get on with it”. In my experience, this is VERY common in IT related projects as IT guys (of which I am proud to call myself one) LOVE a shiny new toy or piece of technology. Should there be any business readers be chortling at an IT person’s expense here, I’ve also seen senior managers get very excited by document scanning solutions, but cannot always articulate the projected dollar benefits that such a solution will give them in the end.
So why is this important?
Well, a few reasons. This includes, but is certainly not limited to:
1. If a Project Sponsor gets carried away with approving change requests, how do you know where to draw the line financially? If CR’s start eating into your business benefits very quickly, a PM needs to be able to tell the Project Control Board if a Business Case no longer stacks up.
2. If a project runs over time, or budget. How do you know when it is time to shut the project down? I’ve seen projects just continue on as the business feels “it’s almost there, let’s just spend another month or two” without realising it may not be fiscally prudent to do so. The benefit no longer outweighs the Project spend.
3. How do you comprehensively articulate and categorise a Project issue if you do not have the filter of the “Project Outcome” to measure it against. Sure, you can measure it against the “output” i.e. a Document Management solution, but how much of that matters compared to the benefits that the solution will deliver to the business, and subsequently, the project issue associated with this?
4. As per the above anecdote, a Project risk MUST be put against the criteria of Project outcome or Business benefit. This is absolutely key, particularly when measuring impact should the risk materialise into an issue. It will also help with identifying an appropriate risk management plan, a trigger for that plan to be enacted and a plan should that risk become an issue.
So, the moral of the story? Don’t get too hung up on an output at the expense of an outcome. Outcomes are absolutely key and should apply the old SMART acronym to them as a sanity check. If the outcome you are trying to articulate is not Specific, Measurable, Attainable, Relevant, and Timeboxed, you may be wasting your time and valuable business resources. Oh, and if you’re an inexperienced PM, don’t be afraid to own up to a clanger! Take your “licks”, learn from it and move on. A good PM always has a few scars to show and a few tales to tell. I think in the end it makes you a better operator!