Changing the anchor

Sometimes it seems too often there's one stakeholder who is a nemesis who  holds up the whole project for their own agenda or pet requirement.  Sometimes it amounts to blackmail; either put in the resources to mollify them, or have them stand in the way; maybe even risk having the project cancelled.

It may not appear so at first, but such a stakeholder has put down an anchor.  By that I mean it's a point of reference for all others to refer to.  Instead of the PM estimate as the anchor, from which the nemesis' position is seen as an unfavorable variance, the nemisis has actually changed the anchoring point.

Now, everyone seem to measure the variance from the place where the stakeholder is standing.

Is there lemonade here?

Actually, as matter of risk management strategy, by changing your charts to show that your project is a positive variance away from the "new normal", you've  changed the "anchor" from 'adjusting upward to' to adjusting 'downward' in one stroke. Usually, going downhill is easier.  That is, if the stakeholder is so persuasive as to carry the day, setting a revised and upward benchmark, and  you have a way to do better, changing the anchor may well work to your advantage.

Be careful not look a gift horse in the mouth; you may be able to benefit from the gift!

To read more about anchoring, check out a 1974 paper by Tversky and Kahneman that explains the concept.

Photo credit:  kyekye4 on photobucket.com

 Bookmark this on Delicious    

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

The systems approach

A quotation of note:

...management should be directed at the interaction of the parts and not the actions of the parts taken separately

Russell L. Ackoff

In trying to explain this idea, Vincent Barabba, formerly of General Motors, says this:

"In this systems approach, the parts by themselves are meaningless – indeed, they cannot provide value –- outside their interaction with all the others.

In a systems approach .... decision support systems that pump a free flow of contextual knowledge and understanding – not just data – into a series of networked dialogues that take place continuously across the functions within the firm, as well as between the enterprise and its extended alliances which includes the ultimate consumers of its products and services."

 Bookmark this on Delicious    

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

The riddle of memory and experience

Daniel Kahneman, with his collaborator Amos Tversky, are researchers this blog has pointed to many times for their work in decision analysis and other human factor influences in risk considerations.

Kahneman is a psychologist, and Nobel laureate in economics, who appeared last year at TED to talk about the "riddle of memory and experience". He took as his context 'happiness'

You might ask: "what does happiness have to do with musings on project management?". Happiness, per se, not much. But Kahneman simply uses the context to explain the dichotomy of memory and experience.

Why, as project people, should we care?

Memory and experience enter into every decision we make, every estimate we make, every issue and risk assessment we make.

Kahneman makes a few points that really captured my attention:
--Experience is objective; memory is rarely objective, and to the extent that it comports with facts depends greatly on the way the experience plays out over time. That is: our memory of an experience is highly influenced by what happened near the end of the experience.

--Without a factual repository for experience, we can't really depend on memory as a recall of what happened.

--Memory recalls the narrative of the experience, but the timeliness of the experience is not accurately represented in memory, nor are the priorities and relative emphasis within the experience.

I have often talked about the narrative of the project, in effect the vision of the sponsor translated into 'verbs'--to wit: the schedule--and the nouns, aka the WBS.  It's obvious that our memory of our experiences will highly influence the way the schedule is architected and the way risk is represented in each Control Account on the WBS.

To mitigate the points Kahneman makes immediately brings to mind 'project closure' and  the need to have a responsitory of history to upon which to base the facts of the project.  These are the facts that will inform the narrative on an objective history of the past experience of relevant projects, whether successful or unsuccessful.

Take a look and listen to Daniel Kahneman with your own project experience in mind.

 Bookmark this on Delicious    

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

Business Rules Manifesto

The folks at businessrulesgroup.org have written a manifesto, entitled, conveniently enough, the "Business Rules Manifesto"

Who knew!?

Seems like everyone has a manifesto these days.

In any event, it makes interesting reading. There are ten 'articles' that more or less lay out the 'rules about "rules"'. Perhaps the articles should be called meta-rules.

Article 2 and 3 are my favorite:

Article 2. Separate From Processes, Not Contained In Them
2.1.
Rules are explicit constraints on behavior and/or provide support to behavior.
2.2.
Rules are not process and not procedure. They should not be contained in either of these.
2.3.
Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1.
Rules build on facts, and facts build on concepts as expressed by terms.
3.2.
Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.
3.3.
Rules must be explicit. No rule is ever assumed about any concept or fact.
3.4.
Rules are basic to what the business knows about itself -- that is, to basic business knowledge.
3.5.
Rules need to be nurtured, protected, and managed.

So let me put this in my words.

Business rules are actionable specifications of behavior that explicitly implement a policy.  The policy could address legality, ethics, responsibility, authority, or custom.

The specification has three [at least] arguments: ~condition, activity or behavior, constraint or boundary~.  Of course, there could be others: ~'date applicable', 'applies to', 'exceptions', 'inclusions', 'extensions', 'authorized by', 'appeal to'~ are examples. Constraints or boundaries are enforceable, either by system functionality or administrative procedures.  Behavior can be animate or inanimate on the part of 'actors'.

Sometimes, the arguments are arranged in an 'if-then-else' logic:

IF ~condition~, 

THEN ~activity or behavior~~boundary, constraint~, 

ELSE ~activity or behavior~~boundary, constraint~.

Too much structure?

How about this example: "No receipts are required for business expense items < $25"

Now, I use the term business to explain all this, and it probably connotes a front office or back office organization, but in fact, 'business' is the enterprise, and enterprise could include everything from a commerce activity to a weapons platform in a military context.

In this regard, project managers should engage business analysis to construct business rules as a part of any requirements definition and specification process.

 Bookmark this on Delicious  

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

The mantle of responsibility

On leadership:

When the mantle of responsibility comes along, put it on, step up, and step out

Tony Blair

Prime Minister of Great Britain

 Bookmark this on Delicious

Agile ideas for the business analyst

It happens:

Better Software magazine--in the January 2010 edition--has published an article I wrote entitled "Enterprise Agile and the Business Analyst ".

Here's the promo:

Summary: Agile is making its way into the enterprise as a project methodology for industrial-strength projects. Why the popularity? The answer lies in the requirements paradox: "We want requirements to be stable, but requirements are never stable." Discover some key agile concepts as they affect business analysts.

 Bookmark this on Delicious  

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

Hope v Analysis

As said during a recent interview*, about times of great stress and dire consequence, regarding risk analysis:

... the most dangerous thing [analysts] can do is to confuse [their] hopes with [their] analysis

Tom Friedman

Author and Commentator

In other words, hope is not analysis, a play on the more popular construction: "Hope is not a plan"

It's almost axiomatic that great stress and possibly dire consequences have the potential to color and filter analytic results, so much so that analysis of the possible outcomes could be compromised into error and miscalculation.

Such analysis confusion is a form of Framing Error, a phenomenon explained by Amos Tversky and David Kahneman as a tendency to weigh or interpret facts differently depending on the frame of reference.  That is, if a circumstance is described in terms of potential harm, analysts have a darker outlook than if the same circumstance is described in terms of the potential of harm avoided. 

You could also say the coloration of analysis with hoped for results is a form of Availability Error, also described in another paper by Tversky and Kahneman, in which we attach the closest [retrievable, imaginable, familiar] similar historical situation to the facts at hand and announce that the present is a representative of the past. 

[*Tom Friedman on "Meet the Press", 30 January 2011]



 Bookmark this on Delicious  

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