Project Management: Why Stupid Procedures Should Be Followed (Most of the Time) – Part 1/2

On Friday I talked about the fine Professional Development Conference sponsored by CIPS Vancouver and hosted at BCIT.

I had a chance to dialogue with session speaker, DJ Dunkerley, and invited DJ to share his thoughts here.

DJ is a Business Analyst and Project Manager with more than 10 years experience working in the hi-tech industry in Vancouver, starting at Laser's Edge in 1994 and continuing with Creo (now Kodak Graphics) as project and product manager. DJ currently lends his expertise with Annex Consulting working on a host of projects.

DJ has an engaging two-part blog about Project Management. Look for Part 2, later this week.
Part One of Two: The Arrogance of Youth

Advice for young PMs: Imagine you and I are having a beer. You have just been promoted to management from the technical ranks. No more whining and complaining about the dumb suits putting unnecessary obstacles in the way. Because now you are the du-- er suit.

Remember we are just sharing a beer here, this is not a public discussion. You and I only. And because we need to drink our beer and have time to get up from the table to order another one, we will break the discussion into two parts:
- So if you work at a small company, you generally don't have the problem of stupid procedures sucking up your valuable time and draining the morale of your team members. Instead, your big problem is resources, or lack thereof. Like maybe you have one person doing coding, documentation, quality control and marketing. And that person is you.
- At big companies, if you're lucky, the problem of resources constraints is not as insurmountable. Instead, dealing with bureaucracy is oftentimes your number one problem.

What this means is that for you to access the coding/documentation/quality control/marketing resource, you need to follow procedures. Or crack the secret code. To clarify: Lots of time nobody tells you the proper procedure but they just expect you to follow it. I can't remember the number of times I would locate somebody in the Creo organization who had a resource I needed, and when I made contact, I would first receive a lecture on the importance of following procedures and why the blank didn't I do that first instead of bothering them? Then, they would show me the secret web site on the company intranet that had the form I needed to fill out in order for the system to process my request.

And this is not to dump on Creo (probably one of the most successful Canadian hi-tech companies of the 1990s). From what I understand every organization over four hundred people, whether public or private, tends to do this. You can protest all you want, but you might as complain about excessive moisture on your socks after um, spitting, against the wind.

Of course, by no means do you have to follow procedures. Sometimes you can get what you want by screaming loud enough. This approach tends to be especially attractive if you are a young and frisky project manager and you've had a couple of frustrating work-days. You can even get away with this approach if your project is An Important Matter and also if you report to somebody Really Senior. For a few years at Creo I reported to an executive VP (at least that's how it showed on the hierarchy chart) which is better than reporting to a regular VP or even a mere director. It was great for two reasons: One, I could safely antagonize anybody and everybody up to the level of director without my boss feeling threatened. Two, executive VPs at Creo were really, really busy people so they wouldn't even take the time to discipline you unless you were running around the building wearing a clown suit with the pants missing. Well, actually one time Stan chewed me out but that was because I totally upset the prez with a total flamemail to about 30 people. But that doesn't disprove my theory.

However, even with the awesome discretionary power of being able to whiz on the shoes of anybody in the org excluding the senior management team, I soon learned to restrain myself and work within the system. There were many reasons for me making the transition from crap-disturber to team player. One reason was early in my career I worked under a guy who was a great leader but a not-so-good manager. Any tiny bit of red tape would drive him crazy to the point were everybody in the bureaucracy rebelled against his screaming and went totally passive-aggressive. And he couldn't get a damn thing accomplished. I realized that if I continued down the path I was going, I would end up like him. And what is a project manager that can't push anything through the system? Absolutely useless.

So I started to fake interest and listen to people and ask questions as to why this procedure was put in place. And more times than not (but not always), there was an understandable (but not always good) reason as to why that procedure was put in place. A good rule to remember is: No procedure is stupid at the moment of inception. That is to say, it always seems like a good idea at the time to put the extra step in. Why is it sometimes important to know the origin of a procedure? Because it helps you to come up with an alternative that is satisfactory to all parties if following the procedure as it stands is just too painful.

End of part one, for our beer glasses are empty. Time for a bathroom break, or a smoke, or both...


DJ, I can't wait for "Part 2: The Secret List."

IT managers and pros: we encourage you to share your comments and experiences.

Thank you,
Stephen Ibaraki

Comments (0)

Skip to main content