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.

Throughput accounting

Throughput accounting is a form of earned value measurement and it is closely aligned with the Theory of Constraints [TOC]. Throughput accounting can be summarized this way

Throughput accounting measures the value added to the business, process, or entity by virtue of project accomplishments

Value added is only measurable as an accomplishment, presumably an operational difference in the business, process, or entity that makes a meaningful difference.  In effect, what is being measured is how much more valuable is the entity now than before. If expenses are lower, than the business is a more valuable transformer of revenue into profit. If a public sector mission is more effectively accomplished, then the entity is a more valuable contributor to public "welfare".

Value added is a "difference calculation"; in EVM terms, it's a variance. The absolute values of each factor in the difference are less important that the difference itself.

So, what's not accounted for in this variance calculation? Answer: operating expenses [OE] of the project...expenses traditionally called 'actual cost' [AC]. Why exclude AC? The idea is that PMO's and project shops, particularly IT shops, have more or less fixed operating costs. If not this project, then some other will absorb resources. Also, most IT projects involve contributions from non-IT sales and operations staff that are 'fixed costs'. Unless there is some direct incremental expense, like a special tool or facility, or a direct contract for services...like a consultant...then the day-to-day OE of the project is not included in the value difference. If there are such direct and incremental expenses, then they are included as part of the value variance.

The figure below gives a pictorial of this idea. "A", "B", and "C" refer to different projects

What's the tie-in with the TOC? TOC is about managing limitations to throughput, where throughput is defined as something a customer or stakeholder would find valuable. Insofar as a constraint can be minimized or mitigated, throughput increases. Thus, the need for throughput accounting.

Some AGILE practitioners have adoped this idea also. In fact, there is a pretty good book on the subject: David J. Anderson's 2004 text "Agile Management for software engineering -- apply the theory of constraints for business results"

 Bookmark this on Delicious

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

Quality and value

I've been reading some of Michel Thiry's thoughts about quality and value.  Thiry is a expert in value management, with skills and experience from his London-based consulting practice.

About quality, he says: "Quality ...is defined as the ratio of what is offered versus what is expected; if the offered exceeds [in some sense] the expected, quality responds to the need" From the project side, resources required to deliver quality must also be in balance: to wit: the resources needed must balance the resources available.

Here's a diagram to help make the point:

About value, he posits four definitions:

• Use value: the amount we are willing to pay for a deliverable that serves our functional need.  
• Esteem value: the amount we are willing to pay for the pleasure of owing or possessing the deliverable
• Cost value: the cost to achieve a functional deliverable; 
• Exchange value: the amount of current resources required to trade for an equivalent function

Here are some of my musings about this:

• Quality certainly has many dimensions.  You can catch up on my thoughts about quality with this blog.
• Use value and esteem value are really the benefit streams to the business from the customer: sum up the risk weighted present value (PV) of all the benefits--what customers are willing to pay for the need or want--and you have a good way to compare the economic benefits of this project to any other that might be competitive
• Cost value is really the project budget; in EVM terms its the earnable value because it should be only the cost that investors want to pay, not the cost value they have to pay to get done. 
• Exchange value: if we ever get to barter, this one may be a good one!  But on a serious note, if there is competition for resources--and when isn't there?--then the exchange of resources between one project and another certainly makes the case for which is the more valuable.

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

 Bookmark this on Delicious

Agile for Business Analysts

I'll be speaking to the Orlando chapter of IIBA later this month. The topic is Agile for Business Analysts. I've posted the charts on slideshare.net

 Bookmark this on Delicious

The near future and the far future

Here's a quote from Mr. Bill Gates that we should bear in mind as we practice situational awareness:

"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten.  Don't let yourself be lulled into inaction"

I think of this as the 'cone of uncertainty'. Risk attitudes change over time; the near future is always more ominous because we can see more clearly and imagine more vividly everything that can go wrong. On the other hand, the far future is the time of optimism: we can imagine everything going right and we discount any view to the contrary!

Bookmark this on Delicious

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

Creative Thinking

Michel Thiry has a compact list of things to consider when thinking creatively.  He defines creative thinking as "lateral thinking".  Lateral thinks means "...exploring new paths rather than pursuing a given path.." 

From his book on "Value Management Practice" comes this list of ten:


1. Write all ideas and comments
2. Target quantity rather than quality
3. Exclude criticsm
4. Hold judgment until evaluation
5. Eliminate "impossible" from your vocabulary
6. Let your imagination roam
7. Use piggybacking
8. Cross-fertilize ideas

9. Let everybody talk

10. Build a friendly  but competitive environment

Bookmark this on Delicious

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

Quotations worth a moment

I've always enjoyed wit and humor. Here are some favorites:

Instead of trying to make the trains run on time, it might be better to do away with the trains!

Anonymous

There is no undo button for our oceans of time

Tom Pike

"Rethink*Retool*Results", 1999

I'm sitting in the shade today because someone planted a tree a long time ago

Warren Buffett

Institutions vs. collaboration

Clay Shirky has an interesting talk on TED about institutions vs. collaboration, which, more or less, is the subject of his follow-on 2008 book: "Here comes everybody: the power of organizing with organizations".  


This talk is a variation on the general theme: 'organizing without organizations'.  His proposition is that there is value going untapped because, as he calls it, the "economic framework" of collaboration--that is, the cost of coordination and contribution--exceeds the value of coordinating the contribution of the Nth contributor.

He makes a distinction between "institutions" and ad hoc groups. Institutions are any type of formal organization  with economic, legal, and process structure that has the ability and imperative to shape the contribution of its members; groups are unstructured associations and efforts of people with some common affinity but are otherwise uncoordinated

His idea is that since the cost of coordination has fallen through the floor, the talent and contribution of groups can be tapped economically. He posits that the tools of coordination--he mentions specifically meta data tools like tagging--can be provided easily to participants as a by-product of infrastructure. In doing so,  the work--and the cost--of coordination is borne by the participants themselves.  Think: linux developers and wikipedia.  Thus, Shirky says, we now mine the value of the Nth contributor that heretofore was uneconomic.

Perhaps Shirky has a point, but he steps around a lot of issues in his talk.  Shirky doesn't address assembling or satisfying requirements, assuring the quality of the Nth contributor, nor the security, validation, and integration costs of the Nth contribution.  In fact, wikipedia is not free: there is a large formal institution that governs content, and as the number of contributors has increased, so has the cost of quality.

Shirky does make one interesting point to ponder: institutions operate on the most economic portion of the 80-20 rule.  If 20% of people make 80% of the valuable contributions, then hire those 20% and forego the 20% of contributions by the other 80% of potential contributors. Thus, the 80% constitute the group for which the cost of coordination is institutionally uneconomical. But not no so for coordination afforded by coordination infrastructure and volunteer participants.

This idea, of course, is the so-called "power rule": the Nth contributor makes 1/Nth the contribution of the most prolific contributor.  This means as the number of contributors increases, the peak of the curve gets sharper and the tail gets longer, as we see in the figure below.

 However, that necessitates setting up exclusionary boundaries--now pretty much required because of security--and a "professional class" that is somewhat less agile (there's that word!) than their non-institutionalized compatriots.

 Bookmark this on Delicious

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

A note about cost risk analysis

Dave Hulett has a whitepaper on his web site that covers an introduction to cost risk analysis.  If this is a new subject for you, this whitepaper goes through a number of quantitative considerations, including correlation risks among cost elements, that will give you a good feel for this territory.

You might also take a look at a more thorough treatment by reading through the cost estimating guide from the General Accounting Office (GAO), an arm of Congress.  One thing about this guide is that is well illustrated with a lot of diagrams that point the way.

Of course, NASA has a readable manual on parametric cost estimating.  Take a look at it if you really want to dig deeper into the subject.

 Bookmark this on Delicious