General Sir David Richards, Britain’s most senior military officer recently published a reading list (of 90 books) for candidates to the UK’s Defence Academy.

I was interested to see books like “Blink” (instinctive decision-making) and “Thinking Fast and Slow” (behavioral decision-making) on the list. Maybe “Nudge” should be there too.

Also of note is General Sir Rupert Smith’s book “The Utility of Force”—Smith is a proponent of confrontation analysis.

However, in general, the list has a bit of an “MBA” feel to it. There’s lots of analysis, but very few original sources. I’d have expected a lot more texts that originate in different (non-Western) cultures. Even if one believes, as suggested in “The Dictator’s Handbook” (another omission), that all leaders are driven by their political survival, arguments are still cloaked in cultural history.

Still, these lists provoke debate. And that’s a good thing.

Another week, another embarrassing spreadsheet error. Two Harvard professors conceded that they made a spreadsheet “coding error” in analysis that formed the basis for their recent book.

James Kwak, in an article where he describes spreadsheet modeling problems at JPMorgan, said (of Excel)

Because it’s so easy to use, the creation of even important spreadsheets is not restricted to people who understand programming and do it in a methodical, well documented way.

For more spreadsheet disasters, have a look at the recent Fortune article titled “Damn Excel! How the ‘most important software application of all time’ is ruining the world”.

We’ve written about this before—and, sadly, probably will again.

Every organisation that’s abusing spreadsheets needs to clean house. Now.

Government open data initiatives, such as the US’ data.gov and the UK’ data.gov.uk are to be applauded, but there are still many challenges to be overcome. I’d like to outline three important ones.

What are the problems?

Open data is a bit like a hammer looking for a nail. There needs to be greater transparency about the problems facing government. Politicians are incentivized to present everything as rosy. This makes it more difficult for citizen developers to focus their resources for the greater good.

So, we need open problems—a list of what governments think is most pressing.

We need the right data

Once we’ve identified the problems, we need the ability to source the data that will help solve them. This isn’t necessarily the data that is already published. There needs to be a feedback loop where governments focus on publishing the data that will have the most impact—not just the data that they feel happy about publishing.

Real-time data feeds are required

Publishing data annually is imposing an archaic model on a new technology. Data could, and should, be published as it is collected. Everyone knows that the rate of change in society is accelerating. Without real-time data we’re, at best, solving last year’s problems.

So, open data is great. Let’s just try and get it right.

I’ve just finished reading Jack Hart’s “Storycraft: The Complete Guide to Writing Narrative Nonfiction”. Now, if you are going to write a book about writing, it’d better be good—and Hart doesn’t disappoint.

The book explains how compelling stories are comprised of structured elements. One thing that struck me is how closely these structures and elements are aligned with confrontation analysis.

Page 93 quotes literary agent Peter Rubie as saying that a good scene will:

• cause a subsequent scene to occur, creating cause and effect
• be driven by the main character’s needs and wants
• explore various ploys by the character to get his own way
• include action that changes a character’s position, relative to the end of the story

This general theme, of a protagonist who must overcome a series of challenges in pursuit of a goal, forms the “arc” of every great narrative.

This is exactly how we tackle problems using confrontation analysis.

Parties (protagonists) have positions (goals) that they attempt to advance by overcoming a series of dilemmas (challenges) through the exchange of (kinetic and non-kinetic) messages (action). Resolutions to one confrontation set the scene for the next as the parties struggle to achieve their goals.

Compelling narrative needs dilemmas.

It appears that confrontation analysis has potential as a design tool for creating compelling narrative. Strategic narratives, used to help us understand real-world issues and organizations, might be enhanced through a confrontation analysis treatment.

Without a formal process, there is a danger that a narrative will fail to draw out the essential elements. And, if the narrative is not compelling, those reading it will not be drawn in, making it difficult for them to extrapolate the story into the future—essential if the narrative is to influence what comes next.

Without a formal process underpinning the development of a narrative there is a danger that it’ll be a hard-nosed, “just the facts, ma’am”, news report—safely unbiased, but hardly absorbing. Strategic narrative, like all narrative nonfiction, needs to draw the reader in.

There is also much the confrontation analysis practitioner can learn from Storycraft—for example, when writing up an analysis in a way that brings it to life. Deft use of verbs and dialogue creates a sense of movement…action…that propels your narrative along. As columnist Jimmy Breslin said

News is a verb

The book also reminds us of the importance of developing character and scene—elements that are important when trying to understand a confrontation, but that are not formally addressed by the confrontation analysis process.

Read Storycraft. I promise you’ll learn something.

The article “Estimation is Evil” discusses the difficulty of accurately costing software projects—a subject of interest to anyone involved in contract software development.

However what struck me most in the article was a discussion of problems with an early, high profile agile project—Chrysler’s C3 payroll project.

The author argues that this project failed because it attempted to develop a comprehensive replacement for Chrysler’s existing system. While this system was perceived to have many problems, there were also many things about it that worked. So, a wholesale replacement was an ambitious undertaking.

What would have been better, it is suggested, would have been to focus on just replacing the parts of the system that were causing the most pain—sort of replacing the entire system one hated piece at a time.

It seems to me that this is very similar to the idea of designing larger systems as ecosystems of simple apps. Processes can be broken down into simpler tasks and each task can be solved using a loosely-coupled, highly focused app (see the article on “Mobile First”, for example).

Each app has relatively clear, well-defined requirements, making it easier to estimate. Granted, it may need to provide a variety of hooks for communicating with other apps in the ecosystem, but these can be added as required. Also, the tight focus of the app makes it easier to provide an outstanding user experience.

And, if the process changes, an app or two can be dropped and the ecosystem reconfigured—the “app swarm” can recover.

The “app swarm” concept is already working. It’s effectively how you use your smartphone—jumping comfortably from app to app as you go about your day.

Maybe it’s time you invited the “app swarm” into your organization…