Directing a bottom up design process

As the astute reader might have realised, this book has been written using a bottom up design technique. It wasn't planned: it evolved. As each chapter was written, it was passed on to several groups of review readers to read and comment upon during the time I was writing the following chapter.

In the ensuing discussions, it quite often happened that one or other of the readers would seem to anticipate the content of the next chapter. This chapter is a case in point. When I had just completed writing this chapter and before sending it out, one of the readers, Yvan Caron, a senior systems analyst from Canada, sent in the following post to his group of reviewers. I was quite surprised because in some ways it provided a short, sharp summary of what I had just been writing.

Here is Yvan's post:

One of the things that I have noticed in reading Peter's new book is that he did not address specifically the never-ending project syndrome.

In reading this book the corporate mind will fear that without very specific plans, IT overhauls can easily zoom out of control. When <snip> Insurance Inc wanted to replace a system that collected data from third-party administrators, it was expected that the project would take 3 months to finish. A year later, the project was still far from complete, and the company undertook a major reassessment. The conclusion: It would take another 3 months.

Probably. If you think this is unusual, think again. The never-ending IT project has become a staple of corporate America. 90% of projects exceed their deadlines. Not surprisingly, at least half of all IT projects go over budget, and almost as many are eventually abandoned altogether.

Why does this happen?

There is no single reason why IT projects so often run out of control, but one explanatory phrase has taken on some notoriety in this regard: "scope creep". This is an insidious disease that takes hold when the scope of a project slowly and almost imperceptibly increases in size. There's no deliberate pattern here. The designers simply ask to be given, say, a particular set of tools or technology licenses; after getting them, they ask to add on features. Sometimes, without anyone noticing it, expectations change, goals change, technologies change, and the project keeps stretching to accommodate all these changes.

The corporate mind says poorly defined objectives can also be a serious obstacle to the successful completion of a project. Without a concise and comprehensible set of objectives, the project keeps going and going. There tends to be a lack of structure about what the up-front goals of the project are. There are unclear expectations on all sides.

There are some corporate minds, however, that are willing to do whatever it takes to avoid a never-ending project, including what is called a "ready-aim-fire" approach. First, on any given project, you ascertain user needs and wants and define a set of very specific objectives. Then, you devise a quick solution. Usually deliverable within three or fours days, sometimes even a day. Users then provide immediate feedback, and IT does an almost instant redesign. The project goes back and forth between IT and users, until the users are happy. This is what could be called "fast-paced solution building". In today's technology environment, even the most innovative design will become obsolete in the near future. If the solution becomes obsolete or is inadequate in some other way, it can quickly and efficiently be brought up to snuff.

Yvan Caron

Quebec city, Canada

What particularly appealed to me about this post was that the last paragraph had neatly summed up a strategy that I'd taken this whole chapter to explain. What Yvan calls "ready-aim-fire" and "fast paced solution" approaches, describes in a nut shell the bottom up approach to designing e-commerce businesses. So, if you have any difficulties in understanding this chapter, when green frogs and throwing marbles into a field are being mentioned, just refer back to this last paragraph of Yvan's post.

The most perplexing problem for top down thinkers to grasp about the bottom up approach is the seeming lack of a direction. Many don't see how a process that is allowed to evolve freely can hone in on exactly the right solution without random wanderings. This is another of those paradoxes where the resolution is not easily seen until you click upon the right idea.

The counter intuitive reality is that the bottom up ­ the "ready-aim-fire", or, fast paced solution ­ actually gets to a solution more directly than any carefully planned and controlled approach. It is the top down, procedural approach that is vulnerable to directionless wanderings, or, "scope stretch" as Yvan calls it. In this chapter we shall see why.

In the book "Magical A-Life Avatars" I likened the process of bottom up design to a strategy for finding a small hole in the middle of a large field. The key is to have an observer, or, a means of feeding back results to modify a process. To find a hole in a field, imagine that you use ten marbles. From any place in the field you drop the ten marbles. An observer tells you which of the marbles is closest to the hole. You then pick up all the other marbles and drop them over the marble that has been identified as the nearest.

The observer then indicates which of the newly dropped marbles is now the nearest to the hole, and you pick up all the other marbles and drop them over this new marble that has been identified as being the nearest. Repeating this process over and over again must eventually lead to reaching the hole in the field as the route is continually guided by following the marble that falls closest to the hole at each throw.

At first thoughts, this doesn't make any sense because it implies that you already know where the hole is: the answer to the problem. But, that is the whole point: you do know the answer to an e-commerce solution - the answer is that you want to be profitable. You want to move towards profitability. If there are competitors you want to move to the position where you are more profitable than the others.

This might be less ambiguous if we change the metaphor: using the marbles to find the northern part of the field. If somebody can tell you which of the ten marbles is most northerly you can gradually move the marbles increasingly towards the northern perimeter at each successive drop. This can be more easily associated with moving to a state of profitability.

Now map this across to the scenario of my head shop business in the last chapter. Instead of marbles, think of sales items. The observer, me, identifies those items that point towards the solution I want: profitability for the business. As I keep following in the direction of the items that are proving to be profitable, I am effectively following the marbles that are dropping nearest to that goal.

The paradigm shift is to realise that the designer of the system is not the person dropping the marbles but the observer. The observer does nothing except for noting the results and providing the necessary feedback. In the case of finding the hole in the field, this feedback goes to the person who drops the marbles. Thus the designer, or decision maker, is the one who says which is the nearest marble and the one who drops them is the expert or specialist.

That is the twist. The expert or specialist isn't leading the design. Experts and specialists are providing random suggestions and initiatives. The designer is testing these against some main system criterion and selecting those that seem to be leading to the goal. Mapping this across to the picture creation model in the last chapter: the observer is the decision maker; the marble dropper is the initiator; the marbles are the work of the craft workers.

This can also be related to the "fast-paced solution" described by Yvan Caron. It's analogous to the process he described when he wrote: "Then, you devise a quick solution. Usually deliverable within three or fours days, sometimes even a day. Users then provide immediate feedback, and IT does an almost instant redesign. The project goes back and forth between IT and users, until the users are happy".

Now you can extend this model to have one observer (the system designer) with ten people who are dropping the marbles (the experts or specialists). The observer can give them all feedback - telling them which of their marbles is nearest - and allow them all to converge on the hole. The marble dropper who gets there first will be the most expert, or, the expert that was nearest to the hole (the solution) from the start.

This begins to make sense if you think of all the marble droppers as being somewhat eccentric. Imagine one to have bad eyesight, another to be a bit deaf, another to have a twitch, another not to trust the observer's judgement, another to do the opposite to what the observer indicates. The observer (the designer) won't know these things and will just be aware that there are ten marble droppers (experts) working on the problem and, unless the designer is very unlucky with the choice of experts, can be reasonably confident that one of them will eventually locate the hole in the field (or the northern perimeter fence).

Notice that the observer (the designer in this system) does not have to be involved in the marble dropping activity at all. All the observer does is to make an observation after the action and then communicate. The order of events is: 1) Action; 2) Observe; 3) Communicate.

Relating this back to my head shop business, it can be seen that the business was able to design itself because of the role I was able to play as the observer: the non participating designer. This, as I explained, happened accidentally, so, it may be clearer if I describe another personal experience where I used this technique deliberately as a calculated strategy for design.