VisibleThread

The strange case of the missing ’serf-serve’ option

I had a reminder last week of one of those quirky little rules in life that have no logical justification.

I was travelling with a colleague in New Jersey and we were running slightly late for an appointment with a customer, feeling a little anxious as the clock ticked. We stopped to fill up on gas as the yellow ‘low’ gas indicator light appeared on the dash. I instinctively made to get out of the car and start filling up.

Well, you can imagine my surprise when my colleague gently restrained me, explaining that it’s against New Jersey state law to pump your own gas.

To quote a certain Mr. McEnroe ‘you cannot be serious’. The incident was borderline comical, or at least to me at any rate, as we idled in the car awaiting the visitation of the gas attendant before we could proceed.

The incident prompted me to reflect on some of the more interesting aspects of what we do in software. We tend to apply the same laws and process to projects universally, often putting a block on proceedings for no other reason than that ‘the process says so’.

So, in many companies, differing styles of projects can often have identical process gates and approaches, where there is a patent difference in risk factors. A 3 month, 2 person effort for an internal audience is a dramatically different proposition than a multi-year mission critical project. Yet in many cases, the Best Practice for each style of project is not considered, nor indeed does common sense intervene, in fact in many cases the same process gates and phases apply to both. This either makes the small project exceedingly bureaucratic or conversely allows the larger project to be too loose.

So, this brings me to VisibleThread. One of the interesting benefits we see as we work with corporate users is the products ability to tailor specific Structural Best Practices for the different types of documents. For instance you frequently see a specific BP (Best Practice) for ‘Business Justification’, a BP for Functional Requirements, one for Non-functional etc.

What has become more interesting however in some recent examples is the ability to slice along style of project. As James and Suzanne Robertson (http://www.volere.co.uk/index.htm) refer to them; the rabbit projects (small), the horse projects (bigger, more mission critical) and the elephant projects (decades of engineering years, expected lifetime of the live system approaching a decade or more). So, in essence we begin to see structure Best Practices for:

• ‘Rabbit - Functional Template’
• ‘Horse - Functional Template’
• ‘Elephant - Functional Template’ etc.

Now, I guess if we could only get a Best Practice for ‘Person in New Jersey, late for a customer appointment, who needs to work the self-serve gas facility’ we’ll truly be in business

Background: If you want to find out a little more about the background on this ‘interesting’ law, check out: http://ask.yahoo.com/20040715.html As it turns out, this law was put in place in 1949. The purpose of it was to protect consumers and gas station owners from costly, and possibly deadly, accidents. All perfectly sensible when you think about it, back in 1949! But 60 years later, it’s an anachronism.