Game theory revisited

---

John Baez, mathematician and blogger, has started a free course online about basic game theory. He's decided to post some of his class notes on his blog, Azimuth.

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
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)

Game examples
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"

Chicken:

In the game of Chicken two managers (or strategies, plans, events) are on a collision course. Each are driven on this course with the idea of overcoming the on-coming alternative. (Some view this as mindlessly stupid)  If there is a collision then it's possible that there is a loss for both and no one wins: lose - lose. And, the loss may be calamitous.. you could lose the company or the project.

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.

Rock-scissors-paper

Most parents are experts at this game, which is handy for enteraining children while waiting for the pizza to be delivered to the table.

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.

There's more
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.

 

Ask a SME?

---

In my various classes, it's often asked and discussed: what's your practice for obtaining cost and schedule estimates?

There are lot's of answers given, but invariably "ask a SME" (subject matter expert) is included in the answer set.

Some recents posts have been up and down on this approach, so I submit: it matters what you ask, as well as who you ask.

Afterall, an expert is stipulated to have expertise, so it's wasteful not draw them into the discussion. They certainly get the big bucks. On the other hand, opinion -- as a general matter, and like eye witnesses to history -- is not very reliable, and if that's all the SME has to offer, then I suggest you look elsewhere for information.

What the SME should bring is an expert interpretation of benchmark data that is to be adjusted and applied to the current situation.

There are tools for helping: usually we call them configurable models. To assist with the interpretation, these models have 'knobs' and 'switches' to tune the configuration and impact of one or more parameters on the current project.

Who knows how to set the knob or the switch? By and large we look to the SME for an expert opinion about the properties and parameters of the model that are under our control. However...

Without benchmark data to guide the model adjustments, the model is "uncalibrated" and thus hardly better than a guess.

If you really are going to guess, and not use calibrated estimating parameters, it's best to adopt a Bayesian methodology. That's what Bayes is all about: working with uncalibrated a priori guesses with an eye towards developing the calibration.

---

Bookmark this on Delicious

Design thinking -- agile for not-software?

---

"Design Thinking" is a term of art. Many are accredited with its coinage: early on Herbert Simon writing in The Sciences of the Artificial in 1969, but probably most prominently by David Kelley -- founder of product design firm IDEO.

A really good comparison of 'design thinking' and traditional management thinking is given in the slideshare presentation embedded below. Some really good insight is given on pages

However, you might also want to hear it directly from it's most articulate spokesman, David Kelley: here he is in a recent 60 Minutes interview making these key points: (and, take note of the agile-like envisioning, story-like requirements, and user feedback shown in the interview)

• Design thinking incorporates human behavior into design
• Diversity of talent and experience is required on teams... arts, engineering, science
• Teamers have to be good at building on other's ideas
• Requirements are developed by observation of user behavior/actions
• Emphasis on prototyping; focus on what's intuitive for human utility
• Empathy for the human need is key to everything
• Applicable to tangible products, environment experience, processes, and other

Steve Jobs was IDEO's early client that really drove the company to excel. The mouse was on of the prominent early products in the Apple-IDEO collaboration.

In the slideshare below, we learn that abduction, a logical complement to induction and deduction, is what really makes design thinking go.

When you put all this all together, it's pretty obviously agile for non-software!

Design Thinking - Presentation from Jan Schmiedgen

---

Bookmark this on Delicious

Storyboards

---

A great technique for writing proposals, papers, or books -- as I do a lot -- is to storyboard the ideas.

My favorite expression: "If you can't draw it, you can't write it!"

Here's Einstein on the same idea:

I rarely think in words at all. A thought comes and I may try to express it in words afterwards

If you're not a storyboard person, check out this website for insight...

---

Bookmark this on Delicious

Making group decisions

---

"My idea of a group decision is to look in the mirror"
Warren Buffet

Nothing like a little bit of confidence; nothing like long term success to bolster confidence!

And, by the way who is the investor in your project? Every project has one because every project is a bet on success, with risk of failure... thus the mix of investment, reward, and risk are all there.

Typically, the business is the investor: the project begins life as a liability on the balance sheet. What you want -- and your investors -- is for that liability to be transformed by project activity into some form of an asset, thus actually building the balance sheet, even as resources (assets) are consumed.

The idea of asset transformation is probably one of the most fundamental about projects as a business tool. Value is added to the asset in the transformation, and the business is all the more valuable thereby.

---

Bookmark this on Delicious

Earned value references

---

Are you looking for a handy reference of Earned Value articles?

I wasn't, but I fell onto this website by accident: Earned Value Bibliograpy. It's maintained by  David S. Christensen, Ph.D, CCEA, CMA who teaches in the business school at Southern Utah University.

In this bibliography you will find (at today's count) 514 articles/references, many with clickable links.
514 is a big enough number to keep anyone going....

Although I didn't know it til I looked, even one of my EV papers is among those listed.  How nice!

---

Bookmark this on Delicious

Defending requirements

---

From one of my agile students, I got this about the differences between agile and more traditional methods. I thought it was well said, so I repeat it here.

It seems ... that the principle difference between "traditional" and "agile" project management is that the former relies on careful elaboration of the business requirements (project scope) and strict defense of that scope via change management

- this generally results in a long lead time between customer sign-off on requirements and delivery of the requested product - often met with customer comments "that's not exactly what I had in mind" or words to that effect.

[Agile] depends much less on a rigorous and well defended set of requirements (e.g. stories) and much more on delivery of product that can be reviewed by the customer much sooner and expectation of changes to those requirements based on customer feedback on the solutions as they are developed and delivered at end of sprint.

---

Bookmark this on Delicious

Defense AT&L and Agile

---

The cover article in the January-Febuary 2013 (free online) issue of Defense AT&L is about agile in the DoD as a consequence of the 2010 U.S. Defense authorization mandating agile.

The article's theme is "terra incognita": "... new territory, full of unfamiliar processes, lacking clear alignment to existing expectations..."

Unfortunately, this article is long on issues and short on actionable practices for the contracting officer, acquisition officials, and contractors.

This figure more or less captures the essence of the author's points, which is a relocation of requirements in the traditional alignment. The article is somewhat based on Leffingwell's well received book: Scaling Software Agilility.

Striking contrast
What really caught my attention was another article in the same issue  (Good contacts start with good requirements by Eesley) about fixing requirements early and firmly, the very thing eschewed in the cover article.  Of course, to be fair, all DoD programs are not software intensive, and so all DoD programs can't take full advantage of agile methods.

Nevertheless, a search of 'Good contracts' on the word 'agile' returned no hits; thus this article didn't seem to acknowledge the requirements paradox, which in part drives agile:

• We always want requirements to be stable to drive design and development; but user requirements are never stable enough to drive design and development.

And, 'Good contracts' didn't acknowledge the move from 'shall' and 'will' to the conversational mode of agile, where the capture mechanism for the conversation is a test script and not a requirements statement per se.

At some point, the dots will connect better than they do, but there's a long way to go. For more on my ideas, see:

Agile and the DoD from John Goodpasture

 

---

Bookmark this on Delicious

Cyber security journal debut

---

In October 2012 the inaugural issue of the Cyber Security and Information Journal made it's debut. Online, it came out mid-December.

The opening article describes the U.S. Air Force's Cyber Security and Information Systems Information Analysis Center - CSIAC

We learn that "CSIAC is chartered to leverage best practices and expertise from government, industry, and academia on cyber security and information technology. Operating in an agile manner, the CSIAC will monitor and utilize emerging technologies of information assurance, software technology, software and systems engineering, modeling and simulation, knowledge management and information sharing."

You can't miss the word "agile" that, if anything, is a loaded idea, especially in the DoD. But since this quote came from a contracting officer, Paul M. Engelhart, one can only hope that general approach of agile in the U.S. government is in play.

There's an interesting article on software reliability, something that has wide interest and application all across the apps industry, whether mobile or traditional web. We're told:
 

Software reliability is defined as

the ability of a program to perform a required function under stated conditions for a stated period of time. Quantitatively, this may be considered as “the probability that software will not cause the failure of a system for a specified time under specified conditions.

An unreliable software-based system may be unavailable, incorrect, vulnerable, or possibly even unsafe. This variety of inadequacies and failure modes includes both “sins of omission” (not behaving as intended) and also “sins of commission” (behaving in unintended ways).

And, in a bit of inside-the-beltway infomation, who knew there is a Department of Defense (DoD) Electronic Biometric Transmission Specification (EBTS), and even more curious, who knew there is a Biometrics Identity Management Agency (BIMA). You can't make this stuff up; and where else can you read about it?

 

 

 

---

Bookmark this on Delicious

3 leadership ideas (and more)

---

Samad Aidane wrote a post last month on "essential leadership". He's got three ideas about how to define it:

• A deep appreciation for diversity: No two brains are alike. A deep respect for the value that each person brings to a global project is mandatory and it can’t be faked.
• A diagnosis mindset:  A diagnostic mindset will help you look at situations from a “researcher” lens to try to determine the factors at play so you can experiment with different solutions or interventions. 
• Mindfulness:  Being present and aware and in the moment is a must to be able to observe how you are thinking, feeling, and behaving and to do the same about the other people’s mental states.

These are good ideas, but I think the bible for leadership for project managers is Ronald Heifetz's "Leadership without easy answers" (this links to an excerpt). The whole book is a favorite.

Here's Heifetz's concept

1. Leadership is an activity, less so a thing, with a take action orientation: Set direction, establish cultural values, resolve conflicts, bestow protection and security, and restore/maintain order.
2. Values and effective activity are separable: This is the "Hitler was a great leader" school.
3. Leadership can be very technocratic, bordering on--gasp!--management; in effect, leading with the solution (I've got the answer right here; follow me! model).
4. Leadership is often most innovative when driving adaptive participation, leading with the problem rather than the solution ("it takes a village" model); and
5. Authority is neither necessary nor sufficient (you know you're a leader when .....), but if you got it (authority of position) you still may not be a leader

---

Bookmark this on Delicious

Requirements feasibity and risk assessment guide

---

A posting from Matthew Squair put me onto a nice one page template for requirements feasibility and risk assessment. The chart links compliance, achievability, and technical consequences. You could, with just a little effort, build an an interlinking matrix, something like a QFD (quality function deployment) house of quality :

One note: if you don't recognize the shorthand scientific notation for numbers, like 1.0E-3, this is read as 10 with an exponent, in this case -3, meaning 0.001. Similarly, 1.0E+3 is read as 1000.  Frankly, I would ignore the number rankings. You can make up your own, or have none.

The important content is in the categories and the category definition.

---

Bookmark this on Delicious

ASL-STEM

---

I don't recall a project on which there were practitioners that communicated with ASL -- American Sign Language. Perhaps they were there and I missed them because they were mainstream and not really handicapped.

In the U.S., we hear a lot about STEM -- Science, technology, engineering, and mathematics . This is an important curriculum for any project team doing technology of any sort.

Now we learn that there is a join of ASL and STEM, ASL-STEM, because you can imagine it's not easy to sign scientific terms.  For instance, “Often times, it would involve a lot of finger-spelling and a lot of improvisation,” said Matthew Schwerin, a physicist with the Food and Drug Administration who is deaf, of his years in school, and was interviewed for the underlying article.

We are given this news: This year .... the Scottish Sensory Centre’s British Sign Language Glossary Project, added 116 new signs for physics and engineering terms, including signs for “light-year,” (hold one hand up and spread the fingers downward for “light,” then bring both hands together in front of your chest and slowly move them apart for “year”), “mass” and “X-ray” (form an X with your index fingers, then, with the index finger on the right hand, point outward). 

This has to be all good news: we can now fully enfranchise those who would and can contribute to our STEM projects.

---

Bookmark this on Delicious

The message and the messenger -- a quotation

---

He mobilized the language and sent it to war

Edward R. Murrow

speaking about Winston S. Churchill

Of course, his message was poetry; his delivery compelling; and his presence mesmerizing

In the pre-television age -- to say nothing of pre-cable or pre-internet -- words were even more powerful than they are today... and Sir Winston was a master communicator.

So, when we in this business are beseeched daily to communicate, to collaborate, and to lead, we could have a lot worse than Churchill as the poet-messenger model. 

Admittedly, there's not a lot of room for poetry amongst powerpoint bullets, and certainly not in the latest style of requirements: the conversational user story (...as a user I want .... ).

(Not to digress too far, my once-teen daughter used to begin her communications with ...I want...!)

And, the Chicago Book of Style is probably not required reading by the project team.  Nevertheless, there are good technology writers out there that provide a worthy model -- Leffingwell is one that comes to mind when reading about Agile.

Word smithing is not the only way: Jurgen Apello is an agilist that communicates with humor and images.

Thus I beseech you: communicate, collaborate, and lead!

---

Bookmark this on Delicious

2012 Books -- and more

---

It seems everyone has their book lists of favorite reads for 2012. Here is one, and here is another

And, of course, I've got mine.
I want to lead off with this one that gives great insight into decision and discovery under conditions of uncertainty (the title says it all):
"The theory that would not die: how bayes’ rule cracked the enigma code, hunted down russian submarines, and emerged triumphant from two centuries of controversy" by Sharon Bertsch Mcgrayne

Here's another one from Kahneman about cognitive skills, thinking processes, and cognitive bias: "Thinking, fast and slow" by Daniel Kahneman

This may be the one best book on change management: "Leading Change" by John P. Kotter

For the agile manager and practitioner, this is a thorough treatment of the subject matter. It gives good advice for bost tester and test manager: "Agile Testing" by Lisa Crispin and Janet Gregory

Leffingwell is one of the two best authors in the agile business (Mike Cohn is the other). Here's Leffingwell waxing on requirements: "Agile Software Requirements Lean Requirements Practices for Teams, Programs, and the Enterprise" by Dean Leffingwell

You don't find this one on too many PM lists, but if you engage in competive bidding and proposal gamesmanship, give this a read: "Game theory 101; the basics" by William Spaniel

And, for a change of pace, but nontheless full of lessons for managers, architects, and system engineers, read: "The revenge of geography" by Robert Kaplan. This is a geopolitical book but replete with many examples of boundary strategies, culture impediments and impacts, and architecture strategies that affect projects.

Some recommended links I fell onto in 2012:
For the agile practitioner going for their PMI ACP: click here for a handy ppt explanation of the whole thing, plus some good test questions

For the top 20 ways to fail at agile and avoid success, check out this handy reference.

If you are a scheduling person looking for guidance, here's a pretty robust list. of scheduling guidebooks.

And, one for the risk experts among us, here's one from Matthew Squair on why everything you know about risk is wrong (or is it?)

Something new
And, one from your favorite author -- yours truly -- click here to see what's coming in 2013.

Something not as new
Click here to see other books I've written

 

---

Bookmark this on Delicious

Big Bang fizzle

---

After a billion dollars, a big bang fizzle in the Air Force

“We started with a Big Bang approach and put every possible requirement into the program, which made it very large and very complex,” says Elizabeth McGrath, the department’s deputy chief management officer.       

This stuff is hard, even with commerical off the shelf (COTS) applications -- they still have to be configured; you still have to move your data.

Grover Dunn, the Air Force director of transformation, [now says he] ... can see just how unrealistic the project was: “We’ve never tried to change all the processes, tools and languages of all 250,000 people in our business at once, and that’s essentially what we’re about to do.” 

After a lot of money and time, the Air Force has pulled the plug on their IT modernization.  

So, what do we have here?

• A huge user community that has both central and local needs/wants/urgencies
• A big scope to change everything all at once
• Off-the-shelf with thousands of customizations and configuration details
• Probably a lot of legacy data (100's million of records, I imagine) to clean and move
• And, big bang 

I've done three ERP projects. I've never done it like the plan I just described. Anyone who would do such a plan is beyond nuts. You can't do much about point 1: the community is the community. But all else is a bad, bad strategy.

With COTS, it's hard to think of conventional agile methods to avoid the big bang, but you certainly can think of ways to do this with rolling waves, partial installs, etc

I've heard all the arguments about not paying for throw-away interfaces when you do partial installs, and I've heard all the arguments about multiple training rollouts and how they affect the organization, but experience shows they are cheaper in the long run.

Let's just hope the next time around is more sane.

---

Bookmark this on Delicious

Happy New Year!

---

Happy New Year!

 

 

---

Bookmark this on Delicious