In general I believe brakes let you go faster. But what if the brakes are locked on? Suddenly you’re not going anywhere. And that is what happens when a project comes under excessive corporate control. The project screeches to a halt.

Brakes in a car are a form of control. If it starts getting unsafe you can hit the brakes and slow down to a more appropriate speed.

Corporations impose controls on their projects. These controls slow the project (take time) in the interest of safety. Status Reports are an example. They take time to prepare but are there to ensure everything is okay. Actually I like the process of writing a short status report. It encourages me “kick the tires”. That helps me and ensures the programme/project is safe.

Some controls exist to offer safety to the organisation not necessarily for the programme/project. Status Reports are often like this. Although I like the process of writing a status report, and that helps my programmes, I am not audience for these reports. The organisation, or its representatives, are the audience. This is a way for the organisation to ensure my programme/project is okay and, by implication, that it is safe.

When these organisational controls become onerous then the brakes go on an productivity declines. The irony is that this excessive level of control is intended to provide safety but is actually hampering progress and introducing risk. Given my role, most of this impacts me and my time. Organisational policy says they have to be done but I while I was doing this I’m not with the team. Even worse some of this directly impacted my development team.

Here are a few examples:

Long status reports: I like a one page status report. But in the past I have been asked to fill in 15 page reports every month.

Different status report format every month: To top it off the format of the 15 page report changed every month so I could never get efficient about producing it. Did my head in.

Multiple status reports: For one programme I had to write status reports for four different management groups and two Programme Management Offices (PMO). All of these groups expected different report formats and were interested in different periods of time so I couldn’t really cheat and use one report for all of them. And to top it off most of them needed a face-to-face meeting where I presented the report as well.

Change control board: Traditional change management has a board that approves changes to scope, schedule or budget. A board that approves scope changes is going to kill the programme/project because change happens all the time. Luckily I can dodge that issue with Agile Change Management.

Gantt Chart: Sigh. People like a good picture and a Gantt chart is pretty and management types love ’em. But maintaining a detailed gantt chart for even a small software project is a full time job. And a complete waste of time. Luckily I’ve only lost one week of life to this futile endeavour. I won’t do it again.

Metrics: Programme/Project Management Offices (PMO) often want reports on programme/project metrics. Commonly productivity and fault measures (e.g. bugs found/fixed per week), sometime financial. These metrics look like hard data but are often spurious. What, for example, is the point of comparing my team’s productivity with another team?

Architectural approval group: The corporation wanted to ensure my product was architecturally sound so mandated an Architectural approval group. If this group had done what they’d been set up to do then my programme would have stalled as we waited for approval to proceed in any new area of work. Luckily the group were pragmatic and were content with an after-the-fact update and retrospective approval.

Documentation: Some corporations equate paper weight with safety. So I have been asked to produce technical documentation. Actually this has happened more than once. My team’s haven’t needed this stuff but it took time from them to produce. While they were doing that they weren’t writing code. I did manage to cheat once and satisfy a client with a Class Relationship Diagram automatically generated from the database with a free tool. But that was a one off. On another occasion I had to take a bunch of people out of coding for a couple of weeks to write an architectural documentation suite.