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 hell 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. 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 taking a pee 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 lousy 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, which actually proves 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-agressive. 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. Another good reason to follow procedures is a lot of time they allow people to form abstractions about what you are doing. And in a big organization it’s important to have abstractions that mean the same thing to a wide body of people. This may come as a surprise to you, O great leader, but not everybody in org has the time to read your weekly updates or the energy to expend the effort to understand why your project is so unique and special. If you are following the procedure and not antagonizing (too) many people, then all is well with the world (meaning they won’t block you and even perhaps release some resources to help you out). Don’t underestimate how important it is to have solid abstractions in a large multi-national corporation. Let’s see you have some procedures for rolling out a new product. You don’t like the procedures? Fine, get on the phone to Brussels, Hong Kong, Tel Aviv, and Boston and tell everybody you’re changing what beta means and early production doesn’t include documentation because you think it’s stupid to get stuff written at such an early stage. Let’s see you get everybody to sign off on how you think stuff should be done.

On the other hand, slavish obedience to every darn procedure that is drafted in head office is by no means a guarantee you’ll get the project done. This is where experience comes into play. It can take years, years I tell you, to develop such powers of discernment that enable you to determine which procedures are crucial to follow and which can be safely ignored. Here is a rough guide:

1. All procedures laid out by salespeople should be followed. Salesguys hate procedures, absolutely loathe them. So if the sales office actually comes up with a procedure, you probably should be following it.

2. Procedures by your foreign branches should be followed. Even if the procedures seem really weird. Especially the weird ones.

3. Procedures by the budget team. This is a tricky one. If money for projects is flowing like a river and your company is doubling in size every years, you can oftentimes ignore them. But if money is tight and the rumour of cutbacks is making the rounds, then follow their procedures to the letter. Unless you really did want your budget cut.

4. Any procedure by a business analyst or a consultant can be safely ignored unless it’s given a seal of approval by your boss or by somebody who your boss respects.

5. Customer services procedures can be safely ignored EXCEPT for those procedures recommended by those people who actually deal with directly with customers. I’m not kidding, in every large company there are people in the customer service division who have never ever SEEN a customer. And these people are the worst at making up stuff that is just a pain to follow.

 6. IT procedures. Find the guy who wrote the procedure and confront him. If he can defend it, then honour it. If he got the procedure out of a Dummies textbook, tell him to compromise or you’ll start an insurrection.

7. Procedures by the datacenter people (SAP, Oracle, Peoplesoft): Follow them only if the data people give you resources so you CAN follow them. That is to say, the SAP guys should be given you face time with the database administrators to work the system to get what you need. Ditto with Oracle and Peoplesoft. If all they are doing is sending you e-mail with hyperlinks to undecipherable database GUIs, then you can safely ignore them. Because they are probably doing the same thing to your boss and bosses’ boss, and as a result, everybody in the org hates them.

8. All procedures that release resources that enable a crucial task to be completed should be followed, no matter how stupid. Fight the good fight in the next life, not this one dummy. 9. If it will annoy your boss to not follow the procedure, then follow the procedure. James Dean could be a “Rebel Without a Cause” because he had tons of natural charisma and was incredibly good-looking. However, if you follow Dean’s example, you will just come off as being irritating. In short, you gotta push the paper and kiss the rings of the various bureaucrats to get stuff out the door. Unless you’re the CEO. And even them, I’ve seen at least one CEO slap his forehead when dealing with SAP.