Intelligence as Requirement

Let's suppose an organization suffers from a number of the symptoms of organizational stupidity and decides to do something about it. (Not an easy decision, but let's start from there.) How do we determine the detailed requirements for organizational and technical systems change?

Many brownfield requirements analysis projects start with negative requirements - we want to eliminate this bottleneck, reduce this wastage or variation, take out this cost and risk. This involves a combination of factual observation (some bottleneck exists in the target system, with such-and-such consequences) and a value judgement (the bottleneck and its consequences are undesirable relative to some value system).

These negative requirements then need to be converted into positive requirements - we want to improve certain whole-system properties (such as organizational intelligence), and we think we can achieve that by making certain changes to the whole enterprise (regarded as a sociotechnical system). These changes may include engineering new or improved mechanisms, as well as improved use of the existing mechanisms.

Typically, there are many different things we could consider doing to improve these whole-system properties, so we produce a wishlist of potential requirements. But such wishlists create all kinds of difficulties. It may not be feasible to do all of the items on the wishlist, firstly because of limited resources and secondly because some of the items may be mutually incompatible or redundant. So we try to create a meaningful subset of the wishlist, to produce a set of real requirements that is both feasible and affordable.

If the items on the wishlist were all completely independent of one another, then we could categorize each item into subjective categories (say "essential" and "desirable"). Or perhaps we could perform a cost-benefit analysis on each item, calculating a risk-weighted accounting value of the item in terms of its ROI or NPV. This would allow us to rank the wishlist with the most important, valuable or critical requirements at the top; the final set of "requirements" is then defined as that subset of the possible requirements above some arbitrary cut-off line.

Of course both the subjective sorting of requirements ("essential" versus "desirable") and the estimation of costs, benefits and risks are evaluated differently from different stakeholder positions, so the final list is typically fought over between stakeholders. Furthermore, things change over the duration of an engineering project, for various reasons, so the cut-off line comes under pressure.

But a more fundamental problem with this way of defining requirements is that the items on the wishlist are usually mutually dependent, at least to some extent. The costs, benefits and risks of each item may vary according to which other items are chosen, and the number of possible permutations is astronomically large. Therefore the challenge of defining a meaningful and feasible subset of the original wishlist becomes an architectural one - finding some underlying deep structure within the wishlist that permits stakeholders to make intelligent and informed choices.