The five P's

With a new fiscal year looming, it is Planning Season at work. Not that we have much to plan with. No money to do anything but essential operations, and big organisational changes being concocted largely behind closed doors at the executive level that will probably derail anything we might consider doing.

But we must try, if for no other reason than to get our unit into the best possible shape to take whatever merde drops on us over the next few months.

So we are building next year's operational plan using a framework to capture goals for different aspects of our work. Under the "process" heading, my director chose to use "the five P's" as guiding principles for building branch-wide processes.

Many years ago, I developed "the five P's" as a yardstick to help me decide when something could truly call itself a standard. I've used this for software development standards, but I guess the same principles could apply anywhere where people are trying to regulate their own or other people's activities.

These are what I am looking for in a standard ...

It should be ...

Purposeful

This is a biggie for me. And helps explain a contradiction in me. I hate over-regulation, and yet I am an avid fan of professional standards. My maxim is "no rules without reasons".

Trouble is, once you start down on the standards road it is difficult to know where to stop. Ever-increasing control takes over and becomes an end in itself. I've seen standards manuals where everything is rigidly set out in minute detail, and everybody sweats blood to conform, but nobody can begin to explain why.

And for all you conformity nazis out there, "consistency" is not a valid purpose, not in itself, even though it is often cited as a reason for setting standards. Ask yourself why consistency is a good thing in this instance. For example, layout standards might help you quickly orient yourself in an unfamiliar piece of code, or variable naming standards might allow you to make some safe assumptions about a variable's characteristics when you see it, without having to track down every reference to it first. Those are perfectly good purposes, but make sure they exist and that you understand them.

If everyone out there understands why a standard is there, and can see benefits in it, then they are more likely to apply it.

And, finally, understanding the purpose allows you to recognise when it is out of date, or when it is in need of updating and how to do so safely without losing sight of the original purpose.

Practical

Should really need no explanation. If it is not practical to use, then it won't happen!

And, remember, standards are supposed to be there to serve you, not the other way around. The best ones are those that make life easier rather than harder.

And the very best are those that are an integral part of your working methods rather than an add-on. For example, if your standard is to use a source code repository and a change process that specifies how & when code should be booked out and in, then what better than to integrate that into your development desktop so that the correct standards are applied automatically as you go about your work?

Published

So, the first two points were probably fairly obvious, if not always practised. Now we are getting into more subtle areas.

To me, a standard cannot call itself a standard until it is documented. Until then, it is simply a convention or a common working practice.

If it isn't recorded, then how can it be communicated? How do you know everyone has the same understanding of it? How can you be sure that it is being applied correctly and consistently?

But simply writing it down somewhere is not quite enough. By "published" I mean documented somewhere accessible so that everyone can get at it.

Promoted

It's one thing to write down a standard, even somewhere accessible, but what good is that if no-one knows it's there? The next step is to make sure the right people know about it, and understand it, and remember it.

In other words, you need to promote it.

And, most importantly, people need to know that you are serious about this, which leads nicely into the home straight ...

Policed

OK, you've got a good standard, it has purpose and it's practical. You've written it down somewhere public, and everyone knows about it.

Are we there yet?

Not quite. It is still no good unless people actually use it. And the only way to determine that is to police it. Somehow.

Now, I don't necessarily mean that you literally need to have someone watching over people to make sure they do the right thing, and to pick up on infractions. You can do, of course, and in some cases that may be the right thing to do, but not always.

What you should do is decide how to make sure your standard is properly applied rather than just leaving it to chance.

Often, simple peer pressure is enough, especially if the working environment is collaborative. And if you've done a good job of making sensible and practical standards that the whole team buys in to and can see the benefits of, they will soon spot and correct problems.

Or you can take the more formal approach, for example by explicitly including standards checks into your QA process.

But, as with practicality, the "gold standard" to look for are those standards that are an integral part of normal working practice. In other words, you do it the right way because that is also the easiest way.

So many people see standards as constraints, as obstacles. I think that is usually because they've had a bad experience with the standards zealots.