Project Team Principle #8: Undermining Bureaucracy

All organisations develop their own ways of doing business.  Their internal systems, processes, rules and management style can evolve organically or under the direction of the company strategy. But every organisation will eventually end up with a certain amount of process that doesn’t seem to provide value.

Project Team Principle #8: Undermine Bureacracy

Project Team Principle #8: Undermine Bureacracy

Bureaucracy can be defined as when an organisational unit exercises a process for which they are the primary (sometimes only) consumer. Any project team set up inside another organisation will need to deal with bureaucracy at two levels:

  • Internal bureaucracy within your project team.
  • External bureaucracy imposed by the organisation or other organisations (e.g. government).

External bureaucracy can also include processes imposed by organisations outside your immediate project team (e.g. your own organisational PMO, Legal, and Finance).

“You will never understand bureaucracy until you understand that for bureaucrats, procedure is everything and outcomes are nothing.” – Thomas Sowell (American economist, social theorist, political philosopher, and author)

Given that outcomes are the key to project success, any activity which is more about the process than project outcomes is at best an overhead or at worse a block to achieving project objectives.

 “Bureaucracy is shit” – V.I. Lenin (Russian communist revolutionary, politician and political theorist)

Purpose of bureaucracy

Bureaucracy usually begins with a core purpose, perhaps to administer a policy on behalf of an organisation. This could be to ensure compliance with a rule or regulation, control access to an asset, and/or to raise revenue. The objectives are efficient and standardised execution of these corporate processes.

However, without some counter-bureaucratic pressure, these organisations can easily expand their scope and the method of exercising the policy, introducing additional checks and balances, collecting additional information, or refining and expanding the processes.

A large enterprise that I used to work for, had a lot of bureaucracy because it was originally a government department.  At one stage the entire senior executive layer was replaced by the Board, introducing a number of Americans as the CEO and CEO-direct reports.  Their description was that they couldn’t believe how many “checkers who checked the checkers who checked the checkers” the company had, and set about removing the wastage.

In regards to external bureaucracy, you have to work out what you can get away with and feed them the least amount of your team’s resources, as your role as a project manager.

With internal bureaucracy, you have the control to decide how much crap you throw at the project team.

Undermine bureaucracy by pruning it

In dealing with corporate bureaucracy, you need to always ask yourself questions.

  • Where does this information go?
  • What purpose does is this activity achieve?
  • Who benefits from the exercise of this power?

If the answers are obscure, unclear, or the beneficiary of the process is only the organisation itself, then it is likely to be pointless bureaucracy.

If you have control over the processes that you impose on project teams, you can remove wastage by examining and testing it yourself.

For example, ask yourself: do you really need that project status update; do you need that review meeting; and do you even need a weekly team meeting?  Maybe you do and maybe you don’t; but if you do have a weekly meeting, make sure you know why you are having it and the outcomes you want. If the meeting only fills out your weekly report, then perhaps it isn’t needed.  Do you need minutes from those meetings and do you need to prepare for it?

Ruthlessly prune your own project team’s bureaucratic processes! – Adam Russell   

Identify processes that your project team has adopted and ruthlessly test them with the customer who finds their output valuable. If there are none or if that customer cannot influence the outcome of your project, remove them!

Undermine bureaucracy by embracing it

I used to work with a former Army Officer.  Anyone who’s worked in or near Defence organisations will know that the “Green Machine” is the ultimate bureaucracy monster.

When I joined that new organisation, serious bureaucracy was something that I’d never experienced before.  I got easily discouraged and frustrated because of the lack of knowledge and experience, and general distaste for what seemed to be pointless obstacles.

Unless you are a veteran of bureaucratic systems, you’ll never know on first encounter, which form, check off or report is a complete waste of time and which is a fundamental step.

What I learned from my ex-Army buddy is that you need to talk to various “gatekeepers” and information requesters, charm them, challenge them when necessary, and generally work out the lay of the land to get what you want or need. Basically, embrace bureaucracy to make it work for you.

I will provide much more detail on the techniques for undermining bureaucracy in the section found in “Micro-Techniques”. But as individual team members and as a team, you must learn to undermine bureaucracy.

Team Charter Clause #8: Bureacracy is shit! And I will undermine it.

The purpose of clause #8 is to help team members understand that bureaucracy will be there and that they should adjust to deal with it to achieve project outcomes.

This team has been created from within a larger organisation, so it is possible that I will be asked to perform processes that don’t make sense to me, slow down my progress, or perceive as not adding value. 

I understand that it usually takes more time to attempt to bypass or counter these bureaucratic processes than to follow them quickly and correctly. 

I also understand that I may try to introduce my own processes to the project, driven by habit, preference or past professional training.

So I will look carefully at any process that is followed or proposed, and objectively determine whether it adds value or not, when measured against my project goals. 

Processes that do not add value, and where I have a choice, will be eliminated without emotion.  Processes, where I do not have control, will be performed to the necessary minimum, without emotion, ridicule or bitterness. 

I will make it my goal to ensure that such processes do not interfere with or distract my team-mates from the execution of their required tasks to obtain outcomes.

If I join the team, and do not do these things fully and without reservation, then I’m a Project Asshole.

Next Steps

What are your thoughts on the objective of this clause? Do you have any suggestions for modifications to the wording?

What do you think your team’s reaction would be to this Charter if you introduced it to your current project(s)?

We’d love to read your comments and thoughts, so please use the area below the article to provide feedback.

If you like this article, perhaps you’d like to be notified when there are more.

Subscribe to the AdamOnProjects Mailing List!

All the Principles

[pt_view id=”77e66c2y4j”]