: : << I N D U S >> : : May-June 2006

Six Sigma is a data driven measure of quality used to eliminate defects. Processes can be applied to Technical Documentation for achieving Six Sigma level. In this article we shall use the Econometric approach of Game Theory to achieve Six Sigma level in Technical Documentation. To begin with, I will give a brief description of Six Sigma and Game Theory.

Six Sigma (Six Standard Deviation) limit states that a process should not have more than 3.4 defects per million opportunities. Different measures of quality, such as SEI CMM Level 5 and ISO 9000:2005 are used to measure the number of defects. This is based on the statistical measure known as Statistical Quality Control (SQC) and Hypothesis Testing. The number of defects should lie between the ±3s limit. In Technical Documentation we can apply this same technique to produce a document of 4s level. A 4s level document is easy to read and understand.

Game Theory is a branch of applied Mathematics. It was propounded by John Von Neumann and Oskar Morgenstern in 1944. During the Cold War of 1970s, Game Theory saw a substantial growth, used for the application of military strategy to ensure mutual destruction

The basic assumption of Game Theory is rationality. Rationality is defined by market conditions. Market conditions include specific systems of institution, rewards, and competition. The outcome of a Game depends on the interaction of rational groups of decision-makers to maximize their pay-off.

Application of Game Theory in Technical Documentation

Applying Game Theory to Technical Documentation, we see that there are multiple players, like the User, Writer, Programmer, and others. Every player is assumed to be a rational human being who tries to maximize their pay-off. Maximization of pay-off can be achieved only when the quality of work is good. Quality of work is defined by less re-work and shorter time to market - measured in terms of the number of defects. This results in reduction of cost and better ROI (Return on Investment).

Let us use the principles of Game Theory in Technical Documentation to achieve Six Sigma level. To begin with, we take the classic example of Prisoner’s Dilemma. Two burglars, Bob and Al, are captured near the scene of burglary and kept in separate cells to get a confession. Each has to choose between two options: to confess or not to confess. If each confesses and implicates the other, then each will get a minimum sentence of 1 year. If neither confesses they will go scot-free. However, if one burglar confesses and implicates the other and the other burglar does not confess, then the burglar who has confessed will go scot-free and the other will get a maximum sentence of 5 years. The strategies in this case are ‘Confess’ or ‘Don’t Confess’. The pay-offs are depicted in the Table below.

Prisoner’s Dilemma		AL
Prisoner’s Dilemma		Confess	Don’t Confess
Bob	Confess	1,1	0,5
Bob	Don’t Confess	5,0	0,0

Table 1: Mea culpa!

So as rational persons, both Bob and Al would try to minimize their prison time. The best case here is to confess and implicate the other so that the pay-off is maximized for the individual. Thus, both will confess and reach to the equilibrium pay-off of 1 year in prison.

The role of dominant strategy is implicit in this decision as both decide their strategy separately and choose their own strategies to maximize their individual pay-off. If in a Game, each player has a dominant strategy and each player plays the dominant strategy, then the combination of dominant strategies and the corresponding pay-off constitute the dominant strategy equilibrium for the game.

In the Prisoners' Dilemma game, to confess is a dominant strategy, and when both prisoners confess they reach dominant strategy equilibrium. This is called the ‘Nash Equilibrium’.

Prisoner’s Dilemma is a non cooperative game whereas Technical Documentation is a cooperative game. The Writers, Users and other members of the Project have formed a coalition in game theory terms. The first decision then would be to join the coalition or not. In this scenario, that’s a pretty easy decision. By not joining the coalition all the players, that is, the writer, project team members and user can be sure of a pay-off of zero. By joining the coalition and playing their dominant strategies they can get a total pay-off of 100 between them. The next question is how will the players divide the total pay-off of 100 between them? How much will the User pay for documentation? The gross pay-off to the User is negative since the production of documentation is a cost item to the User.

Firstly, the net benefits to all the players in the coalition cannot add up to more than 100, since that is the largest net benefit they can produce by working together. Secondly, each participant can break even by not entering the coalition. Neither will accept a net less than zero. The pay-off matrix is as shown in the Table below.

User Documentation		User
User Documentation		Alliance	Non-Alliance
Writer	Alliance	50,50	100,-50
Writer	Non-Alliance	-50,100	0,0

The ‘pay-off set’ for the writer and the user is depicted in the figure below.

The figure above shows the net pay-off of the User on the vertical axis and the net pay-off of the Writer on the horizontal axis. Since the User, as well as the Writer does not agree to a pay-off less than zero, the pay-off set will lie between (50, 50). But, any point on the line between (50, 50) can be a possible pay-off set. In that sense, all the points on the line are possible solutions to the cooperative game. Together, they can be called a Solution Set as coined by Von Neumann and Morgenstern.

This is an ideal scenario where all the players play a dominant-strategy cooperative game. But this Solution Set covers a multitude of scenes. To narrow down on the range of possible payments we have to consider the following factors:

Trust and Perceived Fairness are the two most important parameters to narrow down on the range of the pay-off set. At the start of the documentation project, the Writer has to interact with the SMEs (Subject Matter Experts). The SMEs give domain specific information and the flow of the program. The writer has to map the information given by the SMEs correctly. Young entry level Writers are scared to interact with the SMEs. Mutual trust has to grow between them to form a congenial work atmosphere. The writer should place their complete trust on the design of the application, data-flow diagram, functional specification and the requirements given out by the SMEs. This will help the writer to plan and design the storyboard. There should be transparency in the phase-by-phase process to be followed by the writer.

Regular and timely communication should happen between all the players in the coalition. In other words, fair practice should be followed by all the players in documentation phase. The dominant strategy should be exercised by all the players to usher in an environment of trust and fairness to achieve a better level of quality.

Timelines are another important parameter for the pay-off set. Timelines affect both quality and cost of the project In a multi-player coalition game, it is assumed that all the players will be exercising their dominant strategies. But, in a documentation project the writer is assigned a delivery date. Hence the Writer has to play a sub-dominant strategy Game depending on market conditions, which includes specific system of institution, rewards and competition. This leads to a skewed pay-off towards the User matrix and a Non-Nash Equilibrium. The result is hasty documentation with no designed layout of the storyboard. To add to these last minute changes are incorporated in the document due to ever changing requirement of the User. The produce is a document with less than 4s. The ROI is affected.

The document scores 4s if it easy to read and understand. We can use Controlled English to ensure a document, which is easy to read and understand. The key principle of Controlled English is: ONE WORD – ONE MEANING. The main objective is to remove ambiguity in language and create Six Sigma technical English

Controlled English is a subset of technical English. Controlled English has been designed for important procedures and instructions. Controlled English uses 1% of the complex and growing English language. [For a related discussion, see the guest article, Fonseca: “How Simple is Simplified Technical English?” reprinted courtesy Intercomm.]

Cost is measured in terms of ROI. According to Peter Drucker, “Profit is not the explanation, cause or rationale of business behavior and business decisions, but the test of their validity”. Dominant strategy Game by all the players in the coalition can lead to better quality and reduced cost. Customer satisfaction and improved bottom-line can be achieved only with better timelines and better quality.

For implementing newer processes and tools of documentation, the writer has to have sufficient freedom for exercising the dominant strategy. The basic premise of Game Theory for the application of dominant strategy is that it can only be exercised in a free and fair market condition. This can only lead to Nash equilibrium. The pay-off set as defined by Game Theory would then be equally distributed for all the players in the coalition. Therefore, with better timelines and non-skewed pay-off set the documents produced would be of better quality. Thus we can achieve the Six Sigma level and delight our Users.

Note: While writing this article Plain English has been used and the document has been checked by Bull Fighter to remove ‘Bull Words’.

Disclaimer: The views expressed are totally personal views of the author based on the experience gathered from the Technical Writing industry of Indian Information Technology sector.

Contributed by Pradipto Das who works with Infosys Technologies Ltd., Pune as a Senior Technical Communicator.

Applying Game Theory in Technical Documentation to
Achieve Six Sigma

Overview

Application of Game Theory in Technical Documentation

Applying Game Theory in Technical Documentation to Achieve Six Sigma

Overview

Application of Game Theory in Technical Documentation

Applying Game Theory in Technical Documentation to
Achieve Six Sigma