Bulldozer00's Blog

Part IV is a continuation of our discussion regarding the often misunderstood and ill-defined process of “functional allocation”. In this part we’ll, explore the nature of the “shallocation” task, some daunting organizational obstacles to its successful completion, and the dependency of quality of output on the specific persons assigned (or allocated?) to the task.

If you can find one, the process description of functional allocation starts out assuming that a human allocator is given a linear text list, which maybe quite large, of “shalls” supplied by an external customer or internal customer advocate. Of course, these “shalls” are also assumed to be unambiguous, consistent, non-contradictory, complete, and intelligently organized (yeah, right).

My personal experience has been that the “shalls” are usually strewn all over the place and the artifact that holds them is severely lacking in what Fred Brooks called “conceptual integrity”. Sometimes, the “shalls” seem to randomly jump back and forth from high level abstractions down to physical properties – a mixed mess hacked together by a group of individuals with different agendas. In addition, some customers (especially government bureaucracies) often impose some overconstraining “shalls” on the structure of the development team and the processes that the team is required to use during the development of the solution to their problem (control freaks). Even worse, in order to project a false image of “we know what we’re doing” infallibility and the fact that they don’t have to do the hard value-creation work themselves, helpful managers of developer orgs often discourage, or downright prevent, clarification questions from being asked of the customer by development team members. All communciations must be filtered through the “proper” chain of command, regardless of how long it takes or whether technical questions get filtered and distorted to incomprehensibilty through non-technical wonks with a fancy title. Bummer.

Because we want to move forward with this discussion, assume the unassume-able; the customer “shall” list is perfectly complete and understood by the developer org’s system engineers. What’s next? The figure below shows the “initialization” state. The perfect list of “shalls” must be shallocated to a set of non-existent product functions. Someone, somehow, has got to conceive of and define the set of functions and the logical inter-function connectivity that will satisfy the perfectly clear and complete “shalls” list.

Piece of cake, right? The task of shallocation is so easy and well described by many others (yeah, right), that I won’t even waste any e-space giving the step by step recipe for it. The figure below shows the logical functional structure of the product after the trivial shallocation process is completed by a robot or an expensive automated software tool.

Realistically, in today’s world the shallocation process can’t be automated away, and it’s highly person-specific. As the example in the figure below shows, given the same set of “shalls”, two different people will, “after a miracle occurs”, likely conjure up a different set of functions in an attempt to meet the customer’s product requirements. Not only can the number of functions, and the internal nature of each function be different, the allocation of shalls-to-functions may be different. Expecting a pristine, one-to-one shall-to-function mapping is unrealistically utopian.

What the example below doesn’t show is the person-specific creation of the inter-function logical connectivity (see the right portion of the previous figure) that is required for the product system to “work”. After all, a set of unconnected functions, much like a heap of car parts, doesn’t do anything but sit there looking sophisticated. It’s the interactions between the functions during operation that give a product it’s power to maybe, just maybe, solve a customer’s problem.

The purpose of part IV in this seemingly endless series of blarticles on “functional allocation” was to basically point out the person-specific nature of the first step in a multi-level nested allocation process. It also hinted at some obstacles that conspire to thwart the effective performance of the task of shallocation.