Sabotage The Project

Sabotage the Project – Pragmatism Bypass

“This is OUTRAGEOUS!”  Looking back into the rage haze that had descended over me, I can’t really be sure if I said it, or shouted it, or screamed it.  Memories of emotions are unreliable though.  Odds are that I croaked or whimpered it, but for the purpose of today’s story let’s assume I bellowed it Brian Blessed style…

“Well, I’m sorry you think that but it’s your mistake and you’re not progressing until you fix it,” came the reply.

The project had just failed a stage gate review.  Appalling isn’t it?  You’re reading the blog of someone that was working on a project that failed a stage gate review.  You can use the comment section at the bottom of the page to mock me, I deserve it.

But guess what had failed it…

The project was at the Planning Stage and trying to get started on Delivery, but there was the small matter of the stage gate first.  And before you start judging, let me assure you that the plan was good.  All of the mandatory documents were good.  Funding was approved and ready.  The process of going through programme board for approval before getting final portfolio level approval had been successfully completed and minuted.  So why were we being stopped?

A file naming convention failure.  For a single document, the project plan, the filename had not been updated.  Instead of:

[yyyymmdd]_[Project Name]_[Project Plan]_Final_1.0

it still read as:

[yyyymmdd]_[Project Name]_[Project Plan]_Draft_0.4

You’re probably thinking I’m joking.  I wish.  We actually failed the stage gate for this.  You can use the comment section at the bottom of the page to mock me, if you still think I deserve it.

What had happened was the programme board was delayed, and it’s postponed date was very close to the stage gate milestone.  The board had approved the document, which in this organisation meant it was baselined as “Final 1.0” and the project manager, in his hurry to meet the submission deadline, had not remembered to update it before submitting for the portfolio’s stage gate reviewer.  Usually I would have checked before making the submission myself, but I’d been diverted to, ironically, help draw up the standards for stage gate management.

A mistake?  Yes.  A critical one?  Not really.  Could it be fixed with a phone call?  Sure. But the reviewer thought that this was his moment to shine and to demonstrate to the watching world that he was adding great value.  A rule introduced a few months previously to embed the new naming convention stated that projects could not pass gates without proper naming.  But where our pedantic reviewer had got his wires crossed was that this rule was to intended to prevent archives from becoming unmanageable due to varied naming styles, not to slow down the delivery of projects.

A hard lesson in the PMO is learning when we should and shouldn’t compromise.  PMO’s and Assurance must always be cleaner than clean – if we are to enforce policy and standards elsewhere we have to follow the rules ourselves.  So do we blindly follow process and let a project run into trouble to reveal to the world that they have a problem (or just a glitch like a misnamed file)?  It would teach them a lesson wouldn’t it?  Or do we note the problem and then spend a couple of minutes helping them out and look out for repeat errors/failures/bad behaviours?  Depending on the nature of the project manager involved, you could potentially spend the rest of your career cleaning up small mistakes after them.

I’m sure you can see that this relates to more than just a single argument at a stage gate.  It applies to nearly every aspect of how we engage with the change community.  I’ve learned that the most effective way to manage this dilemma is ask myself “what is the greater good?”  I remember that the PMO is here to serve the change community, that Assurance is here to protect the business, so the best way I can help achieve those objectives is to help out and take a pragmatic approach.  It’s in the business’s interest for the project to progress, so I wouldn’t block it for something minor.  I don’t feel like I’ve conceded or looked like a pushover in doing so.

Would I have failed the project at the gate for a naming convention failure on a single document?  No.  I’d just be on the phone saying “Hey, are you going to resubmit that plan with the right name, or shall I fail you tomorrow?”  What would you do?  You can use the comment section at the bottom of the page to tell me – if you’re not too busy mocking me.

2 replies »

Leave a Reply