I’m afraid this is yet another one of those philosophical blog entries. J
Consider a web analytics vendor selection process. What a mess that can be! You have some people who genuinely believe that something is the best, and then you have some people whose salary premium merely depends on their ability to (fakely) pull reports out of a hyper-specialized piece of software, you have people who like a particular vendor because of who they know, and then you have everybody else. Worst case scenario: kick-backs or related ‘perks’ – which, just for the record, is one of the absolutely worse bases for making a decision.
It’s hard to be objective when you’re making a decision though – but let’s just take a step back to some theory, and then drill into the issue of “creep” versus “bringing people along” in a decision making process – like around a vendor.
Back in 2004, Dr. Perl introduced me to the Garbage Can. It struck at a very formative time when I was dealing with organizational challenges in a number of online organizations, and most certainly made a lasting impression. (I’m blogging about it, aren’t I?)
March and Olsen (1974) argued that organizations are “organized anarchies” and went onto describe, in pretty good detail, how Universities make decisions. They argued that an organization can be thought of as a giant Garbage Can…there’s a flow of solutions looking for problems getting thrown in there, a flow of problems, a flow of participants, and a flow of energy (what we call in interactive as “bandwidth” or management types call “manpower” or the more polite term: “peoplehours”. I still remember the FORTRAN program they wrote in a very sophisticated way to simulate (or model) the dynamics. Looking back on it from 2008, I recognize that FORTRAN program as one of the earliest attempts to tackle complexity theory in public policy.
The question comes up, whenever you’re trying to solve a specific problem, or achieve something specific, about just how many people are you going to consult, and what the solution is going to entail. How are you going to manage that Garbage Can?
I’ve lived through this a number of times, in a number of settings. There’s this weird thing about organizational decision making that makes it so difficult.
The first is to acknowledge that you rarely have final decision making power. Typically, you’re going to have some sort of, as Avinash puts it, a Hippo. If the Peter Principle is in effect, you might not even have a Hippo that appreciates the complexity of organizational decision making.
The second is to understand that human will accept an unfair outcome if they accept that the process by which the outcome was determined was fair.
Trying to impose a process on chaos – finding order where there is a lack of it – is also really hard. For a vendor selection criteria, it helps to establish the requirements from the outset. It also really helps to have those requirements weighted by the participants in the process as well. Frequently, consulting the participants on which vendor sets are being considered is important. If it’s all there in a spreadsheet, it becomes difficult for a human with any sort of social or personal awareness to continue to push for Awstats as the ultimate solution for a multivariate testing solution. Although, in a previous career, I have seen it.
The requirements selection process helps participants understand just what problems they’re actually trying to solve. It also helps other participants understand what other problems other participants are trying to solve. Having the various vendors enumerated helps the participants see the various solutions. Perhaps (and frequently) the best solution is actually using two vendors, not one.
See how these flows come together? A flow of problems, a flow of solutions, a flow of participants, and a flow of energy – all into the garbage can.
For now, let’s set aside the problem of a flow of problems. In organizations, problems are incredibly numerous. A flow of solutions is typically tainted. A lack of energy completely wrecks timelines and destroys relationships.
It’s the flow of participants that’s vexing me the most.
To a large extent, you need to bring your Hippo’s along with you.
If you scale down the ladder, however, you increase – geometrically, the number of participants. If you’re already dealing with a lack of energy, you can’t really consult everybody. Worse, if reporting lines become blurred midstream, you’ll get participants ejected out of the Garbage Can very quickly, compounding problems.
Now, I’m not saying that there’s an optimal number of participants that’s fixed. I don’t think that it’s a ‘constant’, like, “to be effective, you must have no more than 5 participants, and now fewer than 3”, but, my hunch is that the number of participants ought to scale with energy to retain efficiency. In fact, applying a degree of ‘order’ on the decision making process, be it hierarchical access versus ‘unsegmented access’ has an impact.
But I don’t know what that Golden Ratio is.
How many participants are too many? Well – it’s at the point where you reckon your ability to make a decision, and the timelines therein, vanish to 0? Is there a time component? Want to make a decision quickly and have it fully thought out – constrain the number of participants, and then use that strategic plan to win buy-in after the fact? Watch that strategy – it can (and frequently) burns you. Bring everybody along, and you’ll most certainly fail – and not even necessarily as a result of lack of process. You can have the best process ever and still fail for want of energy. There’s a balance there.
And I’m not suggesting that organizations are all ‘garbage’, though, I must admit, all of us do produce garbage when we match the wrong solutions with the wrong problems.
Things to consider if you’re embarking on any sort of group decision making – be it vendor selection, KPI selection, and so on.