A Tale of a Rigid PMO and How We Prevailed

Never under-estimate the ability of people to find ways around the waterfall project, command-and-control structure. Here’s a real, personal story.

We’re working on a project to make several upgrades to a large database. It’s about a two-month effort. The PMO (Project Management Office) forces us to follow a rigid waterfall process despite my complaints and suggested alternatives. (I know from prior experiences with PMOs that arguing with them is often futile but I had to try.)

The PMO has published guidelines that allow a modified waterfall approach using overlapped phases. They even have guidelines for Scrum projects though they have corrupted Scrum so badly that it’s barely recognizable. Regardless, they refuse to compromise.

We quickly realize that the sequence of events demanded by the PMO simply cannot be done on this project. Specifically, they require that UAT (User Acceptance Testing) be done prior to production deployment.

In order to conduct a non-production UAT on a large and complex system, you need what I would call a staging environment. That is, you need a system environnment, physical or virtual, that mirrors production so that the end users can login and run some tests.

We had no such environment or anything even close to it. Creating one would have easily doubled the length and cost of the project. That wasn’t going to fly.

What could we do?

We met with the engineering and business managers. Everyone agreed that we would simply release the software into production when SQA was complete and UAT was scheduled to begin.

Of course, we didn’t tell the PMO that. Luckily, the PMO was not sophisticated enough to catch this type of “work-around”. They were happy. The users were happy. The engineers were happy. Everyone won.

Except …

This “work-around” was clearly not the right thing to do. However, imposing a rigid set of project management rules on everyone was not the right thing to do either. Two wrongs.

You have to recognize that resourceful people (and engineers are very resourceful) will find a way to get things done no matter the obstacles — technical, logistical or administrative.

Go ahead and lock down your software development process. If you do, here’s my advice. Implement plenty of checks, gates and audit trails all along the process timeline to catch those who would circumvent the process.

Resourceful people will get their jobs done even if they have to “work-around” obstacles. On the other hand…you could simply be more flexible (dare I say, agile?) and accommodate special requests.

Updated: June 9, 2011 — 9:53 pm