Innovation and the accidental nemesis

If you're not a regular reader of BusinessWeek you may have missed the January 14th missive in their regular Innovations column. Here we have one that is close to the heart of many project managers: the accidental nemesis to a really new-to-the-world idea, or as the authors put it: the 'accidental enemy'

In their column, entitled "Innovation's Accidental Enemies", authors Roger L. Martin and Jennifer Riel , academics at the Rotman School of Management at the University of Toronto , posit that too many executives manage when they should lead: to wit, they rely too often on inductive and deductive reasoning.  They fail to embrace abductive reasoning when confronted with a never-done-before idea for project excecution.  In doing so, they become the accidental enemy of a radically new idea.

What, say you, is abductive reasoning?  It's the third leg of inductive, deductive, and abductive reasoning.  One only needs to search a bit in Wikipedia to get the ideas.

Inductive and deductive reasoning aligns rules and data--either one or the other begets the other--a traditional manager's view of putting the enterprise's rules with the situational facts.  Nothing wrong with that---some of my best friends are inductive or deductive reasoners--but even though one or the other works well in many situations, they don't always work when innovation is the order of the day.

Innovative ideas many times do not comport with established rules.  That lets out deductive reasoning.  Innovative concepts are often free of facts and seemingly lack cohesion and coherence among the available data.  That lets out inductive reasoning.

Abduction is reasoning through, or postulating, or hypothesizing that seeming unrelated facts or ideas indeed do connect.  Haven't we heard endlessly about connecting the dots?  Well, having a skill, and a tolerance, for the emergence of a new idea by abductive reasoning is key to having visionary foresight.

The genius of innovators is not to let their management impulses overwhelm their instincts to inspire, motivate, and empower.

Recall this witicism from Rear Admiral Grace Hopper [esteemed software leader who, among other things, invented the 'bug']: "Things are managed; people are led"

Are you on LinkedIn? Share this article with your network by clicking on the link.

Agile and the DoD

Does agile and the DoD belong in the same paragraph?  Some would say no, but in the whitepaper I posted at slideshare.net, I make the case that DoD has more flexibility than it might appear on first examination.

In point of fact, a search of the Air Force Software Technology Support Center's much respected and widely circulated publication, "Crosstalk",  with keywords like 'agile' and 'SCRUM', reveals well more than a hundred articles going back some years about projects across the DoD using agile methods in one form or another.

So where does this come from?  Isn't the DoD the poster child for the BDUF--the big design up front?

Yes and no.  For large mission critical weapons programs, yes.  But DoD is not a monolith.  In fact, the top-level guidance from the manual "Introduction to Defense Acquisition Management" as taught by the Defense Acquisition University has these words:

The primary objective of Defense acquisition is to acquire quality products that satisfy user needs with measurable improvements to mission capability and operational support, in a timely manner, and at a fair and reasonable price.

Not too shaby, and pretty agile when you think about it.

And, there's more:  Consider what the very top level instruction to all DoD components says about doing things in evolutionary style, with rapid, incremental delivery [sound familiar?]

In point of fact, agile is an available method set for DoD programs.  However, there are cautions:  consider the points made in this presentation by Kristen Baldwin, then a senior DoD official in the software engineering and systems assurance office entitled "Agile in the DoD Environment" in 2006.  On her page 17/20, she cites 'system of system' issues, scale, security, and a far-flung and somewhat independent customer base in the military departments as the main challenges. Any program manager that has worked on large scale programs can appreciate those challenges!

Are you on LinkedIn? Share this article with your network by clicking on the link.

Leave me some comments

Hey folks, if you want to comment, leave a comment here. Or, you can click the comment link on any individual blog entry.

Love to hear from you!

Todd's Tech Bites - 2 Best Value

Well, the second round of Todd's Tech Bites is available on slideshare.net, and also the audio track is on podbean.com.

In this segment, Todd interviews me about my number 2 point about agile methods: agile is a methodology that delivers best value.

The main points are these:

The sponsor/investor controls the purse stings and the major milestones, setting the investment goals for the project.

The customer gets to vote how to spread the investment resource over the functions and features that are most valuable and most important to the customer community.

The project manager and the performance teams control the mechanics of executing on the investment, respecting the value judgments of the customer, and creating a match between the sequencing constraints, the sponsor milestone needs, and the customer's sense of urgency.

If you want to hear and see more, check out the Tech Bite 2 slidecast at slideshare.net.

Are you on LinkedIn? Share this article with your network by clicking on the link.

Simple checklists and the B-17 moment

In a recent TV interview, physician Dr. Atul Gawande told this short story that he calls the "B-17 moment:": The B-17 was commissioned by the Army as a new strategic bomber in the mid-1930's. In its day, it was a hugh breakthrough in operational capability, but it was enormously more complex to fly than any previous airplane.

Early on, an accident in a test vehicle led Boeing, the plane's developer, to implement pre-flight checklists. [Imagine that!] Millions of miles were subsequently flown without incident due to pre-flight pilot error.

Dr. Atul Gawande has given new insight to this decades-old idea--checklists--in his book The Checklist Manifesto: how to get things right.  Gawande cites many examples where really complex procedures with relatively high error rates were made more error-free by the simple expediency of a checklist.  And not a very complicated checklist. In fact, the good doctor argues that only the mission critical itrems really need to be on the checklist.

That is certainly an idea that resonates with quality project management.  In an earlier blog, I have discussed extreme risk management, and specifically the Apollo 13 incident.  Anyone who seen the movie or read about what went on knows that checklists played a lifesaving role. 

And the more stressful the situation, the more the checklist is needed.  In his 2009 book "What the Dog Saw", Malcom Gladwell has collected a number of short stories, among them a story about how choking is different from panic. 

In Gladwell's description, a choke happens when an expert falls back from a semi-automatic plane to a place where they have to think through the steps--and in doing so, they miss the natural rhythm that made them expert.  Panic, on the other hand, is where fully trained individuals, under duress, lose touch with reality and thereby lose touch with their training.  In both cases, a checklist might help if available.  It certainly prevented panic on Apollo 13--they hung to their training!

As project managers, we understand rhythm--if you're agile, think time boxes!  A check list here and there is a pretty good thing.  Don't object if your governance council asks you about yours.

Are you on LinkedIn? Share this article with your network by clicking on the link.

Photo credit for Malcom Gladwell:

http://www.flickr.com/photos/eschipul/ / CC BY-SA 2.0

Todd's Tech Bites -1

Recently, I had the opportunity to be a guest on Todd's Tech Bites, a podcast-slideshow about various technical topics.

Our first get together was on agile methods, and specifically my thoughts on the top five ideas I put together in my new book, just released this month, "Project Management the Agile Way--Making it work in the enterprise".

Todd Ruopp, a co-founder at Unleashing Performance, Inc, is an inquisitive interviewer, and I had a good time talking with him.

In this first interview, we touched on my five points for agile, and then we got more into Point # 1: Leadership and Management in the agile space.  In a word: leadership drives innovation; management coaches for successful outcomes!

Check out our slidecast on slideshare.net

Are you on LinkedIn? Share this article with your network by clicking on the link.