Software Processes Are Good; Procedures Are Not

Many of us follow procedures. Not because we like them or find them useful but simply because that’s what we are told to do. Regrettably, many procedures take on a life of their own and become powerful impediments.

For purposes of this post, I’m defining a process as a systematic sequence of actions towards a goal. A procedure is a defined series of actions, carried out in a prescribed order. The distinction is subtle and important. Processes may be composed of other processes and procedures. However, procedures are at the bottom of the hierarchy. They may invoke other procedures but may not invoke processes.

It’s common to find many procedures being enforced in large organizations. IT departments routinely enforce complex procedures as a way to “control workflow and reduce risk”, or so they would have us believe. In reality, many procedures are designed solely to protect a workgroup. The procedures add no value to the company or its products and services.

Here’s a true story.

Years ago, I was a manager at a large minicomputer company (who shall remain nameless). I worked in research and development. One day we got word that everyone in R&D would need to fill out paper timesheets every week. We were told that the company wanted to track capitalized projects versus non-capitalized ones.

This was a tax reporting issue. I won’t get into the details of how projects were treated for tax purposes back then. The explanation we were given seemed plausible. We grumbled a lot but agreed to comply.

For most people, the new procedure was simple because they were assigned to a single project and they merely entered 40-hours per week on that project. For senior people and managers, it was more complex. We had to track hours spent on every project that crossed our desks. It was similar to how consultants track time across multiple clients.

This time-tracking procedure went on for a few years. One day, the management team in our group decided to gather some statistics on how many hours we had spent on projects. We believed that armed with this data, we could provide better estimates for new projects.

We thought that all the timesheets we had submitted would provide a wealth of historical data. Someone must have compiled those into a database, spreadsheet, or tracking system of some kind, right?

Wrong? When we inquired about the timesheets, we were told that they were stuffed into a folder and no one ever looked at them. Furthermore, we were told that we were one of very few groups in R&D that submitted the forms. Most groups had abandoned the timesheet directive though it was never formally withdrawn.

Amazing, isn’t it?

I have no idea how many hours were wasted filling out and collecting timesheets simply because it was mandated by someone trying to do the right thing but in the wrong way. That person’s focus was his department, not the company as a whole, and certainly not the R&D group.

You can’t be agile if you’re forced to follow rigid procedures. Being agile requires the ability to make adjustments as conditions change and new information becomes available. When it comes to software engineering, process is good; procedures are not.

How many procedures are you forced to follow in your job? Do you know why? Do the procedures benefit the company, its customers, and/or it’s investors? Or, do they simply benefit the group that enforces them? Let me know.