One of the games that we played at our internal annual indoor games was Clue 16. The game was played by two players. One player could think of any person or place and the opponent had to guess what did the other person thought of in series of 16 questions which can only be answered in Yes or No fashion. Now lets say you are playing with me. You come up with “Mother Teresa”. And my questions go like this:

1. I could start by asking: Is it Bill Clinton? The answer is obviously no.
2. I could then ask: Is it London? The answer is again no.
3. I could then ask: Is it South Africa? The answer is obviously no again.
   • And so on…

As you would see, I am going to exhaust my options pretty soon and chances of reaching “the solution” are pretty low. A better approach is to ask the question in “a series of sets”. So it could go like this:

1. I could ask: Is it a person? The answer is a Yes and hence, we rule “place” out.
2. I could then ask: Is the person living? The answer is No.
3. I could then ask: Is the dead person a woman? The answer is Yes.
   • As you can see we are at a much better place at the end of third question compared to first round of reasoning.

In a set based theory explanation, this example is provided through a 2-player in a room game where the first player can only guess objects from a room only. If the opponent has 20 [instead of 10 questions] questions to ask and each question eliminates 50% of options, the game is winnable with certainty in a room containing up to 2¹⁹=524,288 objects². Hence, you can see the trick is to ask the right questions at the right time. It would be very risky to ask the question - Is the dead person a woman as the first question. You could get lucky [we could write an essay on risk and luck too :)] but chances of not being lucky and hence, risks are high. Or, you could ask the question if you knew that the other person is only going to think about a dead person. This is a big assumption, but if you can validate it with some degree of certainty, it is probably worth asking this question. Also, asking questions through “sets” or “regions” rather than “specific instances” is more efficient. You will identify the region as “worth looking into” or “not worth looking into“. This is useful either ways.

As discussed in the web page on set based design, recent work provides evidence that commercial success is correlated with set-based thinking. Also, this can enhance an iterative process even further. Traditional iterative processes first hit on a solution and then try and refine it. Set based concurrent engineering methods emphasize the need to first target multiple alternative/ options and then eliminate the options to converge on a given option. It is a bit of an overhead to start with but the later stages more than make up for it. Further, the risk in the later stages is lower using this approach. This is because you have narrowed down the paths you don’t want to go and selected the most relevant space to look for a solution. And the biggest risk is to look in the wrong area. As can be inferred, this has profound implications for new product design. Hence, set based design approach helps us by:

• Helping us defer decisions till the last minute when the best information is available
• Explore many design alternative at the same time
• Converge designs more quickly

Working with a set based concurrent engineering approach could actually enhance the efficiency even further. Concurrent Engineering is a business strategy which replaces the traditional product development process with one in which tasks are done in parallel and there is an early consideration for every aspect of a product’s development process. This strategy focuses on the optimization and distribution of a firm’s assets in the design and development process to ensure effective, efficient and concurrent product development process to minimize duplicate or repeat effort and risk. If we see an example within a web development process, then concurrent engineering would mandate requirements gathering, analysis, graphics design, architecture design, development, testing and deployment at the same time. This in itself is known to improve productivity. In concurrent engineering, collaboration between various design groups/ departments is stressed. In set based concurrent engineering approach, various design groups reason, develop, and communicate about sets of solutions in parallel and relatively independently. However, they are free to talk to people working on the other sets, rather encouraged to. As various design groups ask questions and find answers to them, they narrow down their respective solution sets. The fact that each of the participants choose a different path means that rich information and feedback to lot of scenarios is available. Theoretically speaking, more the design groups working, reasoning and communicating about sets or options or alternatives in parallel, the better is the chance of an optimized solution solution. Optimized systems generally provide greater overall efficiency. Toyota uses SBCE rather well. SBCE can be used in software effectively as well. One of the places where it could be used is to decide between three-four different alternatives for coding language i.e. answering a question like should we use C++, Java, .Net or PHP. This is how we can go about it:

• 4 pairs can pair program to spike on what they feel is most complicated or strong case for their language in the project
• They are free to talk to each other during their work particularly about how would they evaluate their exercise
• They record their findings and experiences and more than likely for a web based application C++ pair would probably give up and Java pair would probably record findings which suggest heavy overhead and the pair suggests use of Java as non-feasible [and on some projects it could actually be very useful]
• PHP and .Net group would benefit from the findings and depending on the project, the decision could swing either ways

The trick in SBCE, is to realize what decisions you can defer and what you must take now as well as how risky or difficult would it be to change a decision later. For instance, the decision to change a programming language later in the project is momentous. However, just changing the search algorithm is comparatively not as difficult. From a risk perspective, wrong choice programming language is potentially a huge risk while wrong choice of search algorithm is comparatively a lesser risk. Through the user of SBCE you would like “risky or difficult to change later” situations and decisions to be minimal. Decisions like programming language are probably irreversible but some others like architecture and algorithms can be taken with a view to maximize alternative approaches. A modular approach [SOA, Layered Architecture, Network Protocols, Machine Independent Language] for instance, is known to improve design alternatives. Many examples of modularity are based around the ideas of abstraction and of an interface: two parts make a commitment to how they will “talk” to each other, but no commitment about what happens beyond the interface. Another approach that can help in not doing something wrong is simply not doing it. The implication is so profound and challenging probably because “not doing it” is not considered as an alternative at all. However, not doing it “now” could allow us to do it better when we really need it or have enough information about it. In case of new product development, where multiple scenarios would probably need to be tested, carrying on with multiple approaches can help. Lets take an example of a “landing page that converts”. Assigning one designer to work on the design is a point based approach. Having 03 designers come up with 03 different designs and each tested/ evolved separately would either yield the best design among the 03 or better still through feedback from each other 01 collaborative design that is better than the best in the 03.

As we can see collaboration, reaching the optimal solution, multiple scenarios, flexibility, minimizing waste and efficiency are the key objectives of set based concurrent engineering approach. This align perfectly with Agile.

Popularity: 25%

Posted on January 10th, 2008 by admin
Filed under: Business Alignment, Collaboration | No Comments »