The auteur model of innovation

Goodness!  Yet another model to learn about.  Now we hear about the auteur model of innovation, an idea coined by John Kao, an innovation guru.  


Auteur: an innovator that has a distinctly personal style and maintains artistic control over all design and production aspects of his/her work [a definition adapted for projects from the film industry where the auteur model has been practiced for many years].  


Sounds a bit autocratic!  Whatever happened to the empowered team and even more broadly: the wisdom of the crowds?  What happened to the embedded customer model--think: SCRUM--and other customer-intimacy models like the market leader ideas of Treacy and Wiersema?  


Indeed! where is system engineering in this model?


In our world, the project world, and especially the technology project world where anyone can have an idea, the auteur model is a rare occurrence; a successful implementation, sustained over time, is even more rare.


But take a look at the poster child for the auteur model:  today that is Apple.  Without its innovative leader, the company foundered; with its bold visionary, the company prospers. And, in a decidedly not-agile way of doing things, it is said Apple never asks its customers anything.  They sure did not ask about a name for the iPad!  


Obviously, the dependency on one personality is Risk 1 for this model--both an upside opportunity and a downside risk.  For the successful, it's evident opportunity triumphs!.


But it's evident that Apple, and others with this model, go a step or two further.  

• Step 1: make  your own market where one didn't exist;
• Step 2: exploit that market with the simplest possible product that has the highest possible wow! factor. 
• And, step 3: guard the gate!  Be selective about letting others ride the coattails of your own auteurist [is that a word?]

Mr Kao writes: "Mr. Jobs is undeniably a gifted marketer and showman, but he is also a skilled listener to the technology. He calls this “tracking vectors in technology over time,” to judge when an intriguing innovation is ready for the marketplace


Skilled listener?  Perhaps so.  One of the mantra's of the agile movement today is to be value on simplicity.  Apple has certainly gotten that.   Jobs told us that the floppy was dead 18mos before it was indeed dead; same for the FireWire [although Apple reinstated the Firewire].   And what is Apple?  The best possible example of the wisdom of simplicity.  Not that things Apple builds are simple; they are simply minimally complex!

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

Cost-Risk Analysis, Tips and Traps

I was chasing some links the other day and came upon this one, a presentation given in 2004 to the Society of Cost Estimating and Analysis by Stephen A. Book.  His presentation, entitled "How to Make Your Point Estimate Look Like a Cost-Risk Analysis (so It Can be Used for Decisionmaking) is eye-catching to begin with, in spite of misspelling decision making throughout.


His main theme is single point estimates for cost [and presumably all else] are bad practice from the git-go, and almost always lead to bad conclusions by decision makers.  Ever since Booz-Allen invented PERT for the Navy in the '50's we've been hearing this message--and it's still as true today as it was then.


Book makes three big points that I have taken from his slides:
1. Sum of WBS-Element Most Likely Costs is NOT Most Likely Total Cost


2. “Point” Estimate Not Useful for Decision making, Because No Success Probability Can be Associated with It


3. Only Percentiles Are Meaningful to Decision Makers for Budgeting and Program-Control Purposes


You can't really argue with point #1 because 'most likely costs' are either the "mode" of the distribution or a calculated "moment" of the distribution.  Either way, addition between distributions is not just a matter of arithmetic; addition has to take into account probability and is therefore handled with a mathematical process called 'convolution'.


You shouldn't argue with point #2 because any decider worth [their] pay considers success when making a decision; if not, fire them and get someone who knows how to make decisions.


You might argue with point #3 because 'only' is a pretty strong word.  Many decision makers can work with statistical information that is not reduced to percentiles.


No matter how you make the argument, Book's presentation is worth a read!

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

Four big ideas that drive quality

On slideshare, you can check out a paper I wrote on four big ideas that drive quality, particularly in agile methods.  Here are the points, summarized for the blog:

The Focus should be on Customers: Perhaps this is an obvious idea that is on everybody's list, but actually it is the Deming v Juran debate.  Deming was a product guy--make it right, make it the right way.  Juran was a customer guy--make it fit customer need.  Of course, there really shouldn't be a debate; Deming and Juran were both right, but in the end, customers, in the broad sense of the word, pay all the bills!  Customers can only be the ultimate focus because without customer buy-in to the quality of the outcomes, all is for naught.

Continuous improvement is a project imperative: There can be no substitute for a learning organization, and that includes project, even short ones.  Every team, group, and enterprise should be a unit in transformation, continually improving performance, capability, and capacity. Plan-do-check-act is nearly sixty years old, but actually it's still relevant, especially the check-act thing.  Take a moment to reflect on what you've done or are going--that's check; and then act to apply learning for improvement.

Total participation involves everyone: There is a place for the loner, the eccentric, and the individual contributor, but in general, the best outcomes involve the synergy of everyone contributing.  This may be a little harder with virtual settings, but it borrows a page from the wisdom of the crowds as well as recognizing that every individual can make a contribution, so every individual should make a contribution toward improvement.

Societal networking is flattening: Social networking may sound like a new idea, but it's been around since the onset of human groups; just the technology has changed.  What is new, or at least revisited, is the way social networking has flattened the hierarchy.  Now, there's no excuse for misunderstanding the spirit and the letter of the customer's needs: just ask!

Wav 4 four big ideas that drive agile quality

View more documents from John Goodpasture.

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

Indecision Making

We here so much about decision making, it's a bit of a stunner to run across an essay about indecisions and indecision making. In any event, the Sunday Book Review on April 18th had such an essay. Something that caught my eye was this bit of insight: "Just because people happily comply with the choices of an intimate — or, for that matter, an authority they’ve selected themselves — does not mean they want bureaucratic strangers making their decisions."

To be clear, the author, Sheena Iyengar, was describing an experiment with children, but my experience is that adults often as not behave the same way.  What does this mean for projects and project management?


The first thought that comes to mind is think about the organization model for your project: how much power projection is there from 'strangers' to the work package teams?  How much energy goes into this power projection just because of the friction it creates?


Another thought that jumps to mind is the hazard of virtual teams: strangers [read: people who've never met each other] don't trust, and strangers in positions of authority are not only not trusted but are often resisted. 


And what about the autonomy pushed down to project teams  [read: the principle of subsidiarity]: team members are more likely to 'happily comply' with a team leader they know and trust, and even more so if they've had a hand in the process of empowering the leader.


Of course, life is not fair, and the fact is that many times senior leadership is remote and sometimes a stranger, even though they are known and recognizable.  On projects of large scale, not everyone is going to sit at the head table.  This reality simply means that extra effort communicating and removing unnecessary mystic will pay dividends in removing non-value friction.

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

Words of Wisdom -- Methodology

Here are a few words of wisdom we might all think about from time to time:

"Problem 1: The people on the projects were not interested in learning our system.
Problem 2: They were successfully able to ignore us, and were still delivering software anyway!"


Alistair Cockburn, noted Agile thought leader.

I've got a few more ditties in my book: "Project Management the Agile Way: Making it Work in the Enterprise", published in January 2010.

What we know about requirements

Here's the two universal things we know about requirements

1st requirements paradox:

• Requirements must be stable for reliable results
• However, the requirements always change

And 2nd requirements paradox:

• We don't want requirements to change
• We know requirements are going to change so we should provoke change as soon as possible

So writes Niels Malotaux in an interesting paper you can access at his website.

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

Seven values to manage by

Here's my list of the top seven values to manage by.

Leading the way is TRUST: A willingness to be vulnerable to, and accepting of, the performance and commitment of others as they act in your joint interests

Next comes COMMITMENT:A pledge to apply all possible effort, energy, and ingenuity to the successful completion of the goal.

Third is ACCOUNTABILITY: A willingness to be judged by others and an acceptance of a personal responsibility for the completion of tasks assigned.

Fourth, and this some might find odd, is to promote CONTINUITY: A confidence that things remain the same until they are changed for reasonable and justifiable reasons, subordinating change to the completion of the team goal.

Fifth is to value SIMPLICITY: Simplicity is not necessarily simple; some very complex things may be maximally simple. Simplicity is the absence of unnecessary complexity

And of course, number six: CLARITY: The absence of confusion

Last, but as important as any--CERTAINTY: The absence of unmitigated risk

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

Probabilistic Risk Analysis at NASA

I came across this statement recently while going through NASA's guide on probabilistic risk assessment. I was really stunned to learn that until 15 years ago there was no formal acceptance of probabilistic risk analysis at NASA, but then I guess I'm just not a NASA guy:

But, NASA having done a bit of a mea culpa in the guide, the guide goes on to give a nice process diagram for the standard triplet:

1. What can go wrong?

2. How often does it happen, and

3. What are the consequences

Actually, although lengthy, the guide is pretty easy to read; we should all take comfort that it is the result of lessons learned. Failure is a much better teacher than success!

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

Ever notice EVM is linear equations?

The earned value management system, aka EVMS, is built out of linear equations! OMG! When did this happen? One answer is more than 50 years ago, but another answer is that it happened during the same age that other models came into vogue that purport to represent reality with linear relationships.

Don't get me wrong--I am in the corner with every advocate of earned value...how else can you measure progress toward outcomes? Certainly not by measuring the consumption of input. Consumption only tells you that something is absorbing input as planned; it gives not a clue whether input is being properly transformed into value producing outcomes for the project beneficiaries. Only some form of EVMS will do that.

My rub is that project managers too often fall in the trap of believing the forecasts beget by linear equations.  They seem unaware that linearity represents only the rational part of our actions; and whereas rationality is what we all say we want because rational also implies predictablilty, in point of fact [or, at least as supported by field observation and analysis by neuroscience] humans are incapable of true rationality.  We require, or better to say our brain processes require, a dose of emotion [read: dopamine] to cause our rational brain to stop cycling through alternatives.

But, that is not to say the calculated EVMS trend lines are incorrect: to do the same and expect different is a fool's game.  Thus, this discussion arrives at the most important mission vis a vis EVMS:

"The mission of project management is to defeat an unfavorable forecast [more often than not wrought by the testy linearity of equations] and produce outcomes of reasonable value that do not exceed the expected investment."

Those with IMS/IMP experience will find these words a bit too informal, but nevertheless, they pretty well represent the bottom line.

By the way, take a look at my blog item "Beware the people model" at to get another idea about linear models and human behavior.

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

Anyone can say NO!

Ever notice that as the environment gets larger and less flat, the "NO" thing gets pushed further down? It was certainly the case for me when I worked as a program manager in DoD. Responsibility flows downward easily, but not authority. It seems to get stuck at the top. Authority is where "YES" is; responsibility is where "NO" is. Way downward, almost anyone can say NO, and the thing stops there. Hardly anyone can say YES, and they are all out of reach much of the time working in the upper reaches of the organization.

What if you're project is being held up by the NO people? How do you move it along to the YES crowd? Carefully! is one answer. Afterall, you probably have to live with the NO set, or at least, they will be back for a second bite at the apple some other time.

Workflow may be another answer, although the NO set seem to have a way to stand at the nodes of workflow and stop things dead in the tracks.

But the fact is, many times, there is no way but to march up the top and make your case. And, most of the time, you will earn the respect of the YES types, put a bit of fear in the NO set, and be known as a person who can get things done!

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