Here's Part I. And here's Part II.
By way of disclosure, I have a fetish with game theory for project management; it's Chapter 12 of my new book, Maximizing Project Value: A project manager’s guide, to be published this month.
Game theory is all about strategic reasoning; it pits your ideas against those of your competition, your nemesis, or other project strategies. What it helps you do is forecast a likely outcome -- not necessarily a certain outcome. That is, if you do a series of moves and your counterparty does their own moves -- which may be similar or the same or none-of-the-above -- then where are you and your counterparty likely to come to?
Now naturally there are "games" -- scenarios really -- that are win-lose; but in project management situations we're more often interested in win-win, especially those that make the pie bigger as even the share of the pie changes a bit.
Especially we are interested in win-win when negotiating a competitive procurement. We want to win -- to be sure -- but we should also want the customer to win by selecting us over the competion. Indeed, in our proposal we have touted such an advantage: our win theme, the customer's view of our win strategy... select us because...
Strategy and counterstrategy
Haven't we all done something like this.... We want to minimize errors and maximize quality in the final project deliverables. Strategy: place incentives on the discovery and fix of errors. Counterstrategy (by the counter party, not necessarily ethical, but it happens): deliberately -- or sloppily -- cause an error and then 'discover' it, thereby earning an incentive.
Unfortunately, this happens all too often in the software business. With this incentive plan the original code can be done so quickly that there's no incentive to get it right the first time, even if not deliberate, since the developer will be paid an incentive to clean it up... something that should have been part of the development ethic in the first place. Thus, we have abetted the moral hazard of paying for risk that should not really be ours to pay for. (yes, I know I keep ending sentences in a preposition!)
The counter-counter strategy is to push the incentive downstream so that the incentive is on the quality of the final deliverable and not upstream on some piece or part. Then you are incentivizing the end and not the means. (Of course, there may be a counter-counter-counter strategy... this has a tendency to go on)
Dr Baez develops some of the basic ideas in Part II with a description of several game ideas we're familiar with. Two of interest to project managers are "Chicken" and "Rock-scissors-paper"
It's anticipated, of course, that one party or the other will step aside or change course before the collision (or, in the popular vernacular: before going over the cliff).
Baez develops the game theory forecast for Chicken, a game that comes too often in politics and projects.
Project managers may also be expert. The game is one of competing outcomes, each independently random as viewed by the counterparty. The outcome possibilites -- there are nine in a 3x3 matrix -- are individually scored as win-lose, lose-win, or a no-harm-no-foul tie among parties, respectively.
For example: in the outcome set of one party selecting paper and the other simultaneously and independently selecting rock, "paper covers rock", so paper wins and rock looses for that particular outcome.
This has some of the elements of Chicken without the calamitous collision possibility. The no-harm-no-foul tie outcome -- like paper - paper -- could be a win - win in some situations, but more often it's a suboptimum equilibrium wherein neither party is motivated to change, each party can live with the outcome, and the project can move on.
Needless to say: I'll say there's a lot more to game theory. You may also be interested in this very informative series on YouTube: Game Theory 101.
Bookmark this on Delicious
Are you on LinkedIn? Share this article with your network by clicking on the link.