Running a risk

Written 50+ years ago:

You're running a risk.
That's the good part .... when you've nothing to lose, you can run any risk you want.

Ray Bradbury, author

"Fahrenheit 451"

This attitude may not work very often in the project business. But it points up one important idea:

The first question to ask when faced with an opportunity or a threat is: "Can I afford the downside?"

You may well have more than "nothing to lose", but if the loss is affordable, then perhaps the upside opportunity is more attractive than evident at first blush; and perhaps the threat is less ominous than first thought.

My advice: don't insure for risks you can afford.

And, that's not only about insurance, it's about investing in expensive mitigation the project may not need. In other words, some reasonable consideration of affordability as applied to the risk register may your 'new best friend'

 Bookmark this on Delicious    

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

Agile certification at PMI

Mike Griffiths has a posting that provideds a some insight to the PMI Agile Certification program unveiled at PMI this week. As Mike points out: it sounds like an oxymoron, but perhaps it isn't.

In any event, PMI expects to use the rest of 2011 in a pilot program leading to any initial class of certificate holders by the Q4 of 2011.  They've set up a FAQ, and of course there is a PMI Agile Community of Practice.

Why now?  Why from PMI.  From their literature, PMI says their marketing research of the project management community shows the growing importance of Agile methods to the software development project management community, and they feel this community can benefit from the certification process and from the networking and power of the community that they can establish.

  Bookmark this on Delicious  

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

Beware of formulas

From the novel "Our Man in Havana"

Beware of formulas. If there's a God, he's not a God of formulas

As written by novelist Graham Greene

Classic spy novels are not the usual place I look for guidance on project management, but this passage struck a note with me.

The message is: protocols have their place; so also methodologies. But situational awareness, adaption to circumstances, and innovation to fit the need--coupled with the will to lead--distinguish the enlightened from the mundane, perhaps even the successful from the failed.

 Bookmark this on Delicious    

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

So much for the customer

This is probably not newsworthy, but it's nevertheless telling:

"[A journalist recently] ...  asked what consumer and market research Apple had done to guide the development of the new products."

“None, it isn’t the consumers’ job to know what they want.”

Steve Jobs
As reported by Steve Lohr

Actually, this behavior is not unique to Apple. Sony has been similarly credited, the Walkman being a most prominent example.

Is this good guidance for project managers?

Some thoughts:

• It's hard to argue with success
• There are not many like Steve Jobs!
• Prima facia: You don't need the customer embedded in the team to build great products

My opinion:

• Go for it! Ask the customer
• If you're bidding competitively, you'd better ask the customer!
• Pay attention, and learn whom you can trust
• If the situation allows, ask after a prototype exists ... Facebook, GroupOn anyone?
• But don't ask too many, in less you are prepared to handle the "wisdom of the crowds"! [And this applies in the competitive environment also]

 Bookmark this on Delicious    

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

Teams of Strangers

It didn't really hit me until I read a recent article about entrepreneurs that many [most?] virtual teams these days are teams of strangers.

And, my own experience mirrors much of what I read: my recent team-based projects have been virtual, asynchronous, and with strangers. Not only strangers, but in some cases I have not even talked with them on the phone--not that the phone call is particularly in vogue right now when there are convenient information sharing systems.

So, what does team of strangers mean?  Can you actually form a team with strangers, or is it just a group>  Is it important to know?

I actually don't know.  My collaborations were successful, but the teams were small, fewer than a half-dozen people.  Could this scale?  Perhaps.

We certainly did not develop a team culture, or inherit a work ethic from each other, other than we were perfunctory: we got the job done, each to their own.  Maybe that's a culture in and of itself.

What if these virtual teams are 'permanent' employees of a company?--putting aside that permanence is an obsolescing idea.  How do you create a company of strangers with shared values and commitments?  Well, it's doable and being done, more often than some might think.  There's no brick and mortar anchor in most cases, just a logo, a product, and a paycheck!

What's the career path in a situation like this?  Is there a human resources component to such a company?  In the article I cited, the company executive said of 24 employees, she had never met 15 of the them! 

Can you aspire to the virtual corner office?  Maybe, but more likely the entrepreneurs will spin off and the work-day folks don't really have that aspiration anyway.

So, more questions than answers.  Perhaps answers will develop as we go along.

 Bookmark this on Delicious    

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

Engagement: Learning from games

Lynda Bourne had a posting last month that peeked my interest. Entitled "Engagement--Learning from Games", it is a summary of the seven main points made by Tom Chatfield in a presentation you can find on TED entitled "7 ways games engage the brain"

 

Lynda's summary, which is good interpretation of Chatfield's remarks, are:

1. Recognize individual engagement is easier if there is a sense of collective engagement.
2. Appeal to the emotions of both individuals and the group, encourage collaboration.
3. ShowClearly a players progress through ‘experience bars’ and similar.
4. Provide multiple long and short term aims.
5. Reward effort; provide graduated and scaled rewards.
6. Provide rapid, frequent and clear feedback with windows of enhanced learning.
7. Create an element of uncertainty, the occasional exceptional reward

 Watch the video: there's something to learn:

 

  Bookmark this on Delicious  

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

The achievement test

There's a lot of angst in the PM community about project management and management governance as being 'large' vis a vis  'small', or perhaps better said as: project management as plan-centric  vis a vis  'agile'. Even hierarchical vs relational enters the conversation.

And rightly so.  Means matter. 

One reason they matter is that most of us are not artifacts of 'Taylorism', the business theory of  "people as interchangeable parts" insertable into an [almost mindless] process.  But for most, the governance culture of the project intersects with our personal and political ideas of governance.  That intersection may be harmonious, but sometimes it's not.  Where not: move on; otherwise: let's get to work.

I've quoted Alistair Cockburn before, but it's worth remembering:

Almost any methodology can be made to work on some project

Any methodology can fail on some project

To repeat: means matter. 

But of course, the 'ends' matter most. That's where 'achievement' comes into play.

Achievement should take up more of our energy--more, but not all, to be sure--than that which we put into debates over governance and methodology.

A similar theme was struck in an article I read this past month, from which I borrowed the title for this post.  The idea there, and the idea here, is that what matters most is throughput: results--enabled by an effective governance scheme--that are consequential for the people and enterprises affected.

An achievement test for projects is not high science; here are the five big points:

• The project produces the objects of greatest value, most importance, and most urgency as judged by the stakeholders
• The project beneficiaries are better off for having the benefit of the project outputs.
• The project team earns their just rewards for a job done well according to the performance measurement baseline [PMB]
• Project outputs beget business outcomes that  increase the value of the enterprise, and
• The sponsor-investors who underwrite the project receive a reasonable value as a return on their investment

.

 Bookmark this on Delicious    

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

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.