Standards – II

George Dinwiddie has a great response to my previous post on standards. In his post, George says:

Why do people want to choose a standard before they’ve tried something to see how well it works?
… (snip) …
Processes, like software, don’t work well unless they, well, work. So get it working first, and then worry about whether you should standardize on it.

A short while ago I worked tangentially with a team that was implementing a business intelligence tool. The architect of that team was quick to point out that they were really implementing a business intelligence service – a process. In that case, it was important to get the process right. So, once the servers were installed, but before they rolled the software out to a customer, the team had to develop the methodology. They had to define the process to requesting a BI universe, for defining it, for scheduling it, for prioritizing. For each of these sub-processes, the team had to use a standard template. The architect was very clear that the template had to be filled out correctly, and there was some amount of back-and-forth over how to correct describe a methodology component.

They had a template standard. They had a standard standard.

And, eventually, the group threw it all out, choosing to instead actually run a project, then document what they did.

The odd thing that I have seen is that groups that do this often fail in a way that is predictable and repeatable – yet don’t see the problem.

For lack of a better term, I will call this “Paradigm Blindness” – when you see the way you work as “right” and build defenses against it, instead of admitting that experiential evidence should guide the way we work.

With paradigm blindness, when you have documented test scripts and quality stinks, you say “Next time, we need to do a better job documenting our test scripts.”

When the requirements process is a big, painful waste of time and the customer is unhappy with the results, you say “Next time we need to get the requirements right up front, before we ever right a line of code.”

When the company keeps trying to increase the accuracy of it’s estimates and failing, you focus on getting “more accurate estimates” instead of trying to deal with uncertainty as a real thing.

In the mean time, there’s a quality guru named Deming and he came up with an idea called the Plan-Do-Check-Act cycle – where you do a little planning but then conduct an experiment to see if the standard will work, then check results, then move forward – often, you do these in cycles.

There’s another name for this: The Scientific method. And when methodology proponents argue for processes that defy the scientific method as “right”, you’ve probably got a case of paradigm blindness going on.

I’ve been seeing this more often (see the last few posts.) Does anyone have any ideas on how to deal with it? 🙂

POSTSCRIPT: I was a bit worked up when I typed this. I hope it makes some sense.

A google search points out that “Paradigm Blindness” is apparently, a real phrase – not quite real enough to make Wikipedia, though. The best definition I found was “Paradigm blindness is a term used to describe the phenomena that occurs when the dominant paradigm prevents one from seeing viable alternatives.” From this web site in Google Cache.

2 comments on “Standards – II

  1. Hi Matt, I both agree and disagree with your position on standards.

    I think standards are good for guiding new project managers about what to do. Once you get good at a process, you are then in a position to improvise it. So sure, you need to be able to move on from the standard once you understand it.

    I think of process standards as a starting point – some set of guidelines that worked some people. The problem is that many people think of standards as a finishing point – lets standardise on this and thats the end of the process discussion.

    I would say that process standards have their place, but not in the way that they are currently implemented in most organisations.

  2. Hi Matt,

    I guess the proverbial map analogy applies here, where in order to get from point “A” to point “C” you have to go through point “B”. The problem as everyone knows is obstacles and unforeseen circumstances may hinder your process and you will have to adapt in order to get to point “C”. Traditional project management attempts to control this by defining a critical path that when deviated alerts the PM to take action. The illusion is in the control aspect as I have yet to see the “action” make any relevant difference to the project as a whole other then killing the project team.

    Rather than prescribe to a concrete standard where you follow standards project after project only to hear the same rebuttals of why things didn’t work. Embrace the inevitable and work with the challenges. Build a toolbox if you will of disciplines and practices that help solve business, software, and testing issues. Start out with a working skeleton of guidelines to follow and general framework. Attack the issues and discover the solutions. Apply the disciplines and practices as needed in order to facilitate the outcome. Over the past 2 years I have seen a great cultural shift from traditional prescribed practices to more of a lean approach to developing software in my company.

    My two cents,

Leave a Reply

Your email address will not be published.