Audit, control, and the harsh light of day

There’s nothing as exciting as working on the first version of a product that you hope will one day become a best-seller for your company. I’ve been in this lucky situation a few times in my career, but one such experience was much more enjoyable than all the others because the company I worked for – still do, in fact – had a much more mature process than the others. Most often you get to work on “one-oh” projects (that is, version 1.0) when you belong to a small startup, where it gets pretty chaotic heading down the stretch toward product release. If you can take away some of the chaos then you might even enjoy working late and ordering pizza from memory because you’ve done it so many times.

Of course every project is different. Every team has its share of characters. The number of new technologies being introduced – which is an imporant measure of risk for the project – varies, though usually there are at least one or two things with which nobody on the team is intimately familiar. And then there are the three main constraints for project management: Time, scope and budget. Unfortunately, time is usually the only one you get extras of – and that’s not a good thing, believe me.

Quite appropriately, the TV show from the 1960′s called Get Smart pitted the good guys – CONTROL – against the bad guys – KAOS. The irony of the show was that in most episodes the CONTROL folks, especially the hapless protagonist Agent 86, were the epitome of chaos. I was too young to truly appreciate the show but I really liked the theme music and the opening sequence where Don Adams would walk down a long corridor and doors would open in front of him and close behind him as he went. Now “control” seems like such an awfully oppressive term, and late-night comedians never seem to use the word “process” in their stand-up routines, but you can actually have an enjoyable experience working on a project with a reasonable amount of control and process.

The trick is to make the process work for the participants, not just the boss. That means, for instance, you have a list of things to do and you can pick the items off the list in the order you feel is most appropriate. It means breaking down the project in sufficient detail at the beginning that you have a good sense of the features you absolutely must have, and which ones are nice to have if there is enough time. It also means that there is a way to track backwards from the work that was done to the reasons for doing the work, so when you come across something that seems odd you can find out why it is the way it is. The ability to track back from the work to the justification turns out to be extremely important for a number of reasons. First, it means your boss doesn’t have to watch what you’re doing so closely. If you are working on a feature and you do work that is unrelated to your feature, and this fact is plainly visible to everyone who cares to look for it, then you are much less likely to do that unrelated work. Is this a bad thing? Not at all! Yes, it constrains you, but it also constrains everyone else who is working on the project. It is comforting to know that, assuming there are regular audits, nobody is going to get side-tracked too far by working on something that ultimately will not show up in the project. It is comforting to have that level of trust within your project team, and valuable because it is self-imposed trust.

Second, the ability to track backwards from the work done to its justification, which is usually a set of requirements, helps your test team stay focussed on constructing the right tests. A test that is consistent with the design but inconsistent with the requirements once again may signal that unnecessary work was done. It may also indicate a breakdown in communication. Either one is pure project management gold. If you catch these situations soon enough you might shave weeks off your schedule.

Third, if you can’t track some work back to a feature request or a defect, and the documentation folks start from feature requests or defects, then even if you manage to slip in a really neat feature you won’t have anything written about it anyway – your customers will never know. This is fine for an Easter egg but rather disappointing for cowboys who think they can get away with this type of shenanigan.

It is important to realize that being able to trace backwards is not good enough – you also need a process that ensures that at least occasionally somebody will do it. The trick here is to make it part of what they would be doing anyway.

Imposition of controls has many facets but in this article I’ve chosen to show how audit performs a valuable control mechanism. As in government and financial regulations, the harsh light of day tends to keep people honest, and frankly happier for it. There are a number of loose ends that arise from this article – I will address other interesting aspects of control in a future article.