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: 15%

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

Modern organizations work in a large horizontal and vertical network comprising of entities who interact [pass information or material or capital] with each other. Optimizing one relationship without considering the effect of the same on the overall system, can lead to lower and sub-optimal business value. One example of such a sub-optimal step includes stocking vast piles of inventory leading to massive increase in storage costs and loss of stored material, where considering this entity from a systems thinking perspective led to growth of Just in Time Inventory Control. “Outsource to cheap vendor” is one such sub-optimal step an organization could take. Cutting costs is a useful goal for an organization to focus on but is probably not the only goal the organization should focus on. Other goals to focus on could generally include quality, faster time to market, responsiveness to change, flexibility, competitive advantage. While deciding to outsource work, an organization would want the business value to be optimized across the value chain rather than just cut costs.

However, optimizing business value across a value chain, a difficult goal even if all work is done in a single organization, is especially difficult when the value chain includes more than one organization [which is the case when you outsource]. Generally, within the organization, each department is trying to maximize its own individual measurements. This gets magnified within an outsourcing environment where each organization is trying to extract the maximum pound of flesh from the deal as possible. The pound of flesh is generally defined and tracked by individual measurements in each organization. For instance, the firm outsourcing the work negotiates on the lowest price possible while the vendor is typically looking to not exceed the price while developing the project. As is obvious, these measurements do not span the value chain and will invariably [particularly if the products are critical, large or in demand] cause sub-optimized business value across the organizations. In the above example, none of the two organizations is actually focusing on “getting the right product to the market in the right time” and the “overall business value” has not been defined specifically. Rather, a contractual document with clauses and clauses to define the “terms of engagement” is generally put in place between two companies. The immediate fall out of contracts is to cause measurements and controls such as cost, schedule and scope. It is also assumed that meeting the contract terms is equivalent to providing business value. This is often misguided thinking. A collaboration is successful if it provides something useful and not because it delivered something thats “within scope, within cost and on time”. Cost and time are important parameters but already considered within “something useful” [something spiraling out of cost or time would rarely be useful]. Hence, cost - schedule - scope triangle does not define business value. Rather, such measurement will mostly get in the way of driving the effort toward true business value. The fundamental focus should be to do away with sub-optimizing points of measurement so as to optimize business value across multiple companies.

If cost, scope and time do not define business value - then it is logical to ask what would. In software, we generally consider value to be defined as function of features, quality, time and cost. Within this paradigm, it has to be noted that true business value would be more dependent on features and quality, and often not on meeting *tight* deadlines and rarely on meeting *tight* cost targets. The distinction between deadlines and costs being “exceeded by a distance” and “not being met” is subtle but important. The most important aspect in the business value as per the parameters above are the features. Features embody “what is being built“, “what is the business case“, “risk associated in not developing” etc. Sometimes, there would be a risk for not “doing by a date” and very often for “not being up to mark on the quality“. The fact that we keep features, quality, time and cost as parameters reflects their dynamic nature. These change because:

• What was thought nice to develop today, might be outdated or too risky tomorrow
• What was the priority today might not be a priority tomorrow
• Some new features might be discovered
• Some new standards of quality might need to be adhered to
• Timelines might be important today but not tomorrow
• We might have cost surplus today but not tomorrow

Based on the above, another dimension needs to be added to define business value in these dynamic times. We can call it “flexibility” or “responsiveness to change“.

Hence, business value at its very least for today’s “terms of engagement” has to focus as a function of features, quality, time, cost and flexibility. Most Scrum teams [and Agile teams as well] pride themselves in delivering business value faster and regularly. Business Value operates at multiple levels through simple means in Scrum. For instance, prioritized backlog allows delivery of high priority features first. Product Owners usually decide the priority by balancing risk and opportunity. Focusing on risk allows early feedback and course correction. This reduces the risk of developing wrong features or wrong product itself. The development people [which could be outsourced offshore] and the business people work as one team on prioritized features. Further, the measurement for business side is on prioritizing the features to be developed and explain business case and acceptance criteria along with evaluating/ providing feedback on developed features. The measurement for development side is to develop highest priority features and incorporate change. In addition, the review of the priorities and work done as per the priorities is held at the end of each iteration, which is usually only a few weeks. Ruthless prioritization of the features to be developed along with a strong inspection and adaptation framework creates a flexible, self correcting and highly transparent mechanism for engagement between both sides.

Popularity: 36%

Posted on December 28th, 2007 by admin
Filed under: Business Alignment, Collaboration, Outsourcing 2.0 | No Comments »