The audience is never at fault!

In the days before Powerpoint there were transparencies and overhead projectors. The technology has changed but one thing has not: the audience is never wrong!

Something that has stuck with me over a lot of briefings from Generals to janitors is that if I as the briefer can not make the audience understand, it's not their fault. I recall being called on this point at an executive session when I responded to one of the seniors in the audience--who said my points were not clear--that "it's right there on the charts". Well, it was to me, but not to the executive. He made it clear: "Don't ever argue with the audience; it's not my fault that you are not persuasive; find another way to get you point across!". And, thankfully, I took the advice and I did make my point.

Afterall, the audience is the customer and they are the only ones who can make the value judgment on what you are saying. If the audience checks out, you may put it down to boredom, but often it is confusion.

Confusion--that is, a lack of understanding--is the quickest way to drive away a listener and completely defeat the value proposition of your presentation.

Even the guys at SesameStreet figured out the difference between confusion and boredom!

So, I say again: it's never the audience's fault!

Bookmark this on Delicious

Share this article with your network by clicking on the link.

The Tipping Point for PM

In his popular book, "The Tipping Point", Malcom Gladwell describes three personalities that affect communications and the spread of information.

Since most acknowledge the central role that communications play in effective project management, it's worth a moment to consider these personality types in the context of projects:

The maven: The absorber and distributer of facts and information.  Mavens have an encyclopediac memory and an ability to easily absorb and organize all manner of data bits.  Mavens are eager to inform and teach, but equally eager to learn, and often combine informing and learning in the same encounter.  Every project team should have mavens who can cross-pollinate between project information sources.  Mavens are sort of a human index of all the project's information, absorbing and processing changes--they are a human "select (*)" for whatever query is needed.  They are also the project coach for conveying an understanding the information base of the project, teaching team members what things mean.

The connector: The connector collects relationships.  The connector knows everyone and is known by everyone.  The connector is the transport layer for the project.  The connector knows how to launch the message into their network and get the message around, although the maven may have to forumlate the message.  The connector is trusted among his/her network, and trust adds weight to the "word".  The connector adds agility to project communications because of  the efficiency with which information is spread and impact the connector can bring to the task.  If connector and maven are joined in the same person, then the project has not only an effective means to spread the word, but also has the means to convey depth and understanding as well.

The salesman: The salesman is the persuader, the person that helps with diffusing new ideas in such manner that adoption is efficient.  Every project has a need for the salesman: initially to get the project sold through the process of the business case or charter, and then to keep it sold when the inevitable problems arise.  There will always be stakeholders who have perception-reality alignment issues, seeing challenges as either insurmountable or unaffordable.  When you have the salesman and the connector in the same person, the project not only has the person to get the word around, but the "word" will be persuasive.

.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Another post on Kano Method

I gave a recent presentation on the Kano Model as applied to the business case for new product development.  I put the charts on slideshare.net.  You can also find my Kano presentation for agile practitioners there also.

If you are interested in more detail, here is a good presentation by a different author of the model with a lot of narrative on definitions.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

The Risk Library

Seems like everybody has a book list of their favorites on risk and risk management.  Many project managers start with the "PMBOK Guide--4th Edition", Chapter 11.  However, there is also a PMI "Practice Standard for Project Risk Management", and there are industry specific "extensions" to the PMBOK Guide that tailor Chapter 11 to industry practices. 

Not available on the pmi.org site, but available free from DoD is the DoD Extension to the PMBOK Guide that has a Chapter 11 that in some respects differs from the PMBOK Guide and the companion practice standard.  For instance, in the DoD guide, qualitative and quantitative assessments are not handled separately: they are just considered different flavors of risk assessment. 

And, the DoD standard takes some effort to explain the hazards of multiplying risk probability times risk impact if the values are "uncalibrated". [Uncalibrated means guess or hunch or unsubstantiated estimate] The DoD's advice [as given in the PMI extension in Chapter 11], echoed elsewhere, is that if such values can not be properly calibrated so that the values have real project meaning, multiplication should not be used; it's better to form ranks of qualitative values.  If a numerical ranking is required, then apply a utility factor to transform the qualitative to a quantitative value.

I have just finished reading three books I would like to throw in the mix:

First, the well known "The Black Swan--2nd Edition" by Nassim Taleb.  The thesis of this book is that there are events that are so rare that conventional risk probability-impact assessments are not meaningful, but although rare, they can have dramatic impacts.  So the author spends most of the book discussing his observations and interpretations of how people react to very rare but important events.  For project managers, the insights to human behavior are where the value is.  [A book with a political variant on this same theme is Suskind's "One Percent Doctrine"]

Second, an interesting book for those doing product development: "How We Decide" by Jonah Lehrer.  This book is again qualitative; its main  focus is on decision making, especially decision making under the stress of time or information deserts, and the risks of those decisions.  I've always thought of decision making and risk management as unseperable.  The book covers what we know about how the brain works in decision making, and is very informative on not only the physiology of the brain but the interaction of physiology with thought processes.  There is a lot of discussion about how we get fooled by circumstances, a theme of Mike Clayton's blog back in Feburary.

And, third, "The Irrational Economist--Making Decisions in a Dangerous World", edited by E. Michel-Kerwin and P. Slovic.  This is five collections of essays, with each collection addressing a different theme.  Project managers will be especially interested in the first two collections because they address the concept of utility in many forms. The application to projects is fairly obvious because every project manager is faced with the difference between perception and reality [a utility concept] and the need to transform qualitative [high, medium, low] to something numeric [1, 2, 4], also a utility concept.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

IIBA and BABOK

I spoke to the Orlando IIBA chapter this week about Agile for Business Analysts.  What is a business analyst you might ask?  The definition is found in the Business Analysis Body of Knowledge, V 2.0, available free [and legal] for viewing  on Google books. There is a 16 page summary of this document that can be downloaded

The BABOK on BA
Paraphrased from the BABOK, business analysis is the tasks, supported by techniques, that provide liaison among stakeholders for the purpose of understanding and recommending solutions [improvements] for structure, policies, and operations of an organization. 

So, it's not about projects per se, but it's been my experience that BA's can be essential and important members of a project team, particularly at the outset when the business case is being put together, and then interviewing for use cases and user stories, evaluating test cases, and also at roll-out time as ambassadors to the business [or to the customer community] for the changes coming from the project.

What I said:

A few notes from my talk: my slides concentrated on requirements management because that is a strong emphasis in the BABOK. 

There was a great Q&A session. The questions were mostly around risk: what risks are mitigated by agile and what risks are caused by agile practices? What is the balance between risks mitigated and risks caused, and how should BA's convey the risk conversation to project stakeholders.

A lot of questions about cost-schedule-scope-quality trades. Most specifically, how and what to communicate to stakeholders about how much an agile project is going to cost, how long it will take, and what scope will be delivered, as compared to a conventional command-and-control project methodology that may be more familiar.

There were also a number of questions around throughput accounting, and whether such a practice is useful. 

Overall, a pretty good session; I'm appreciative of the effort the Orlando chapter invested to have me come by.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Time centric Earned Value

Some years ago, actually 13 years ago, Jim Sumara and myself gave a talk at the 1997 PMI Symposium in Chicago. The topic was "time-centric earned value", a practice we introduced at a commercial backoffice IT shop when we found the conditions for conventional earned value did not exist.

Jim and I both came from DoD backgrounds and had managed programs with EVM for years. But, of course, IT shops rarely embarace DoD practices. In particular, the portfolio of IT projects we were managing had a lot of participation from the functional side of the business for which there was no time accounting. People were simply assigned to projects 'for the duration'. And, the chart of accounts did not support project portfolios.

So, working with what he had, we came up with "time centric earned value". A relatively simple idea of assigning value to task starts and finishes, and then measuring the value earning of those events. The focus is on accomplishment, not effort.  The idea is to give credit only for a meaningful contribution to completing the project.  As given in the presentation, the key to success is defining the value--that is, establishing the criteria--that is the basis for sustaining a claim of accomplishment by the team.

The presentation is posted on slideshare.net.

Of course, there are other approaches to earned value that are unconventional by the ANSI definition.  Among others are 'throughput accounting' and 'work unit accounting'.  Some agile practices include a form of work unit accounting in their 'earn-burn' practice.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Defining creativity

Every project manager is challenged with finding 'creative solutions' to project requirements.  Certainly over the last generation, practitioners have been admonished to 'think outside the box'; manager's have been warned to value the new and unique.

[The 'establishment' always resists a challenge to conventional orthodoxy.  See Einstein, A. for the year 1905]

In a recent article in a national publication, and on a follow-up panel show on PBS, creativity was defined [again, since there are many definitions].

Creativity is production of something original and useful, ..... To be creative requires divergent thinking (generating many unique ideas) and then convergent thinking (combining those ideas into the best result).

As discussed by the panelists, creativity arises from synthesis of known facts or ideas in ways heretofore not known. As such, creative people must be aware of, or have knowledge of,  facts and ideas in order to create a new synthesis. Obviously, project managers can have a big affect here: assembling facts, or providing access to ideas, to drive creativity within the project scope [and budget, etc] is something we managers can do, even if we ourselves are challenged for right-brain function.

As project managers, we face these questions:
1. Can creative people be reliably identified?
2. Can creativity be taught, and therefore, learned as a means to develop project resources?
3. Is there a project protocol to evaluate a new and unique narrative to connect a known set of dots?
4. How do you fit innovation, the practical implementation of creativity, into budget estimates?

The general conclusion from the cited references is yes to 1 and 2: there are nationally recognized and accepted tests for creativity aptitude, and there are ways to influence and stimulate creative solutions.  [Step 1: move away from rote recitation of 'how we did it before']

Beware the timeline, however. Some research shows that constant immersion in creative activity actually changes brain physiology. So that would suggest that consistently creative people started young, but that also means that physiology once developed may be a life-long capability [there's a place for senior citizens over 40!]. It also suggests [at least to me] that many creative people have there best years when they are young and the brain is most pliable. [See Gates, W. III for 1980's]

As for 3 and 4, protocols that anticipate innovative solutions from creative ideas that are practical and proven by experience are more problematic.

• Spiral methods provide allowance for creativity. 
• Deming's PDCA cycle anticipates an opportunity to think creatively--that is, to synthesize a new narrative from the facts--as part of  'Check-Act'.  
• To provide innovation is one of the motivations for agile methods.  

But regardless of methodology, projects of necessity have limited windows for creativity when the scope-resource-quality-time dependencies are open for debate and for shaping.  Of course, agile methods protocols to stretch the window openings, but in the end "someone has to pay for this stuff", so even agilists must limit creativity.

Photo credit: Newsweek on-line, July 10, 2010

 Bookmark this on Delicious

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