The first rule of story writing is that you mustn't simply place a series of actions after each other. The story is good if the reader can empathize with the struggle of the hero. The hero of the preparation process of a business decision doesn't have to be the decision maker. A case study is never written by the hero, but by someone else who saw it from close. Othello didn't write his story, but Shakespeare did. These two case studies were not written by the decision makers but by the person next to them. A case study only makes sense if the penny drops for the reader “hey, it can happen (or have happened) to me!” For someone who has never been jealous like Othello, the penny will never drop. For someone, who has never been a business decision maker, a case study on the preparation of business decisions will not mean much.

The case of the “Young Director of Development” and the “Procurement”

Ten years ago intelligent portals came into fashion. The Young Director of Development couldn't miss this train either. He wasn't asked, but was expected to get an intelligent portal for his company that producing and distributing high-end technology. The market of portal frameworks was dominated by the offers of “Plumtree” and “BEA” (at that time, separately), but there were four not as good products as well.  The Young Director of Development wanted to make a satisfactory decision, and at all costs, the decision preparation process transparent. He invited the Knowledge Engineer, whom he considered the master of decision preparations. They agreed that they will be working on this decision for two months every Monday, all day.

The first Monday the Knowledge Engineer noticed right away that in their meeting room on one side of the table was sitting the Director of Development and three of his men from Development, and on the other side four people unknown to him. It soon turned out that they were from “Procurement”. It was apparent that the two mentality, different by nature, couldn't get along in the same room. In the progress, everybody brought up their own expectations. From one side of the table they said things like

“trust in the project management of the vendor”, “the upgradeability of the framework” or “the speed of data mining”

The other side said things like “references of the vendor in our industry”, “references of the product” or “cost of operations of the portal”.

The number of expectations (attributes) was 49.  An impressive number. Colorful attributes. What else is needed to confirm a decision? Nobody could say that the Director of Development was making a rushed and unjustified decision. The Knowledge Engineer rather suspected this number to be bigger than it should be as there were some “bookish” expectations that the decision preparation team thought to be “proper to expect”.

Next Monday the team defined the “if...then” rules between the values of the expectations. One example:

If its operability is good, and if the features of the database engine are acceptable, and if its upgradeability is excellent, then the features of the framework are satisfactory or excellent.”

Magnificent debates sprung up from the rules. The team went through 1170 rules, so the database needed for the decision was formed finally. The Knowledge Engineer was happy as a rule-set of more than one thousand rules was a proof of the thorough consideration of the decision preparation. The only thing left was to examine four other vendors apart from “Plumtree” and “BEA”. It soon turned out that none of these vendors could meet the expectations. Based on his experience the Knowledge Engineer suggested that they shouldn't continue the search, as there is little chance that lesser-known companies could satisfy a customer of such high expectations. The Young Director of Development asked for a week to think the decision over. Finally he suggested building the portal framework by combining the components of a few different vendors. He found a solution that meets the expectations. Although he himself suspected that the strongest framework vendor will make a more reliable framework than the one put together from different components.

Business decisions don't tolerate functional organizational charts. The decision is not getting any better from everybody stating their expectations, but will be satisfactory if relevant criteria of a few competent people are included in the decision preparation. The expectations of the “Procurement” make the decision preparation difficult. At the end of the work The Young Director of Development had a lunch with the Knowledge Engineer, and said only one thing: DoctuS KBS was useful, it made the process of decision preparation transparent, and also showed how consistent “if...then” rules everyone had.

The case of the „Experienced Director of Development” with the „Young Applicants For Director of Development”

There are companies, where great amounts of money are put into developments, but there isn't one where there is enough money for every idea. The Experienced Director of Development was about to reach retirement age. He had lots of experience in distributing money for company development, and he wanted to pass on this experience. Somehow he felt that Kahneman formulated the essence in an excellent way: „An algorithm written on the back of an envelope is often good enough to compete with a perfectly weighted formula, and is probably good enough to exceed expert judgments.” The explicit simple algorithm was missing – this was a part of his silent (tacit) knowledge.

On the first occasion, the Knowledge Engineer was investigating what is seen as the success of a development. By the end of the day the Experienced Director of Development and the Young Applicants For Director of Development defined the following values:

  • “the income from the innovation is visible”
  • “this is going to bring money”
  • “I can't see yet”
  • “failure”
  • “didn't even start”

The Knowledge Engineer had the Young Applicants For Director of Development say the expectations. 25 expectations were collected all together. They were like, for example:

“The project leader's experience in coordination”, “What were the predecessors of the project?” or “The composition of the developers' team”

Later they examined 40 past development projects of the company, among which there were “successes” of all five kinds. The team was waiting for the result of the Case-based reasoning doubtfully. The result was shocking and sobering. 13 complex rules were revealed, such as:


If the idea source was external, then it always failed.

If the idea came from the development engineers, and if there was a strong divisional support, then the income from the innovation was visible.

The penny dropped for one of the Young Applicants For Director of Development: from the good descriptive explanations it is worth choosing the one that is simpler. This is called „lex parsimoniae” (principle of parsimony or economy). For the skeptics, the Knowledge Engineer examined all 40 cases in DoctuS KBS, and verified that using only the five expectations and 13 complex rules gave the same result as using the 25 expectations and the several thousand rules between them.

– Is this my forty-year experience? - asked the Experienced Director of Development aloud.

– It can be written on the back of an envelope – added the Young Applicant For Director of Development.