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.