Project Lifestyle

I am going to wrap up this initial series of posts on Global Single Instances with some thoughts on the number of test environments you’ll need to support your project(s). It may not give you instant happiness, but it will give you:

Many project or program managers have no firm idea on this subject and delegate the decision making to the technical lead/solution architect/chief propeller head.

This is OK if you accept that having no firm idea = having no clue. Alternatively (waxing lyrical here):

If you don’t stand for something you’ll fall for anything.

So what do I recommend PM’s need to know? It depends on the size of the rollout and the solution footprint.

In one of my latest MIT newsletters (free subscription of course!) a great piece on testing assumptions.The Importance of Testing Assumptions

Behavioral economist Dan Ariely's talk from the TED conference last month was recently posted online. In his talk, Ariely (who wrote the best-selling Predictably Irrational) addresses, through his own experience, a topic that is also quite relevant for innovators in an uncertain environment: the importance of testing assumptions through experiments.

He also makes some great comments on cheating (of all things).

• Everyone cheats, a little. But only to a point where it does not challenge their self image of being a “good” person
• People start cheating (more) when a member of their in-group blatantly cheats
• People stop cheating when a member of an out-group blatantly cheats 
• People cheat less when confronted with moral standards (people lie less about remembering the 10 commandments, for example)

In our project lifestyles we come across this phenomenon all the time. No so much cheating as social behaviors like groupthink that we as project managers need to find ways of combating.

A good start is to be aware from the outset that people are sometimes “predictably irrational” and may not be sensitive to your rational, evidence-based arguments…

Sometimes little things can make a big difference, and sometimes those little things are right there in front of you, waiting for you to notice them.

Take project issue lists for example

As a key project document I first started getting interested in them about 10 years go when I was doing a lot of Critical Accounts & remediation work. It was impossible to go into a project and have an agreed issue list waiting there, ready for you to work on.

Nothing has changed. Getting agreement on what the key issues are and their status still feels like getting blood out of a stone.

Recently I decided to have another look at issue lists in projects in the light of some of the latest thinking in the fields of personal productivity and sociology. I wanted to see if that led to any new insights on how those concepts could be applied in the context of project teams.

Obviously the underlying question is "If we manage issues better, will that improve our project outcomes?”

I was pleasantly surprised with the results. 

[Update 22-Apr-2009 Links to the mind map file, free Mind Manager Viewer and same in pdf format added. Apparently IE can’t render the embedded viewer either. Kudos to Hans Henrik Krohn for pointing this out.]

This is the second part of a discussion on the secret life of issue lists in our project lifestyles.

In Part 1 I opened the discussion by looking at why issues are such slippery things to manage. I then got perspectives on managing issues from various colleagues who know a thing or two about them.

In this post I’ll see how some of the latest thinking in personal productivity intersects with issue management in projects.

Issue Management and GTD

I compared my colleagues’ perspectives on issue lists and issue management to some of the concepts outlined in the action management method "Getting Things Done” (GTD) developed by David Allen.

Basically this method rests on the principle that a person needs to move tasks out of their mind by recording them somewhere.

That way, the mind is freed from the job of remembering everything that needs to be done, and can concentrate on actually performing those tasks.  Hmmm…sounds like the projects lifestyle to me…

Two things distinguish GTD from other time- or action-management systems.

GTD is not about prioritizing up front.  It is about dealing with things as the come using a standard workflow.

Secondly GTD the idea of grouping tasks by the context (defined as a place or set of available resources) in which they are to be performed.

Really I wanted to see what would happen by applying GTD workflow to the project context and the issue process in particular. 

Here is a MindMap I built to document the steps in the workflow. You can grab this file directly from the link and view using the free MindManager Viewer.

You will need to view this in IE or install the excellent IE Tab plugin for Firefox to view this embedded MindMap Viewer.

For the truly afflicted you can grab the mind map as a pdf file.

Built by Mindjet LLC

The biggest thing really is the concept of collecting issues out of the minds of project team members and users and getting them recorded.

Issues running around in the wild are the dangerous ones.

Once you capture them, you can tame and manage them.

So doing, you exercise a lot more control over the unknowns in your project.

In the next and final post I will examine how better management of issues may have an overall impact on project outcomes by referring to Tipping Point theory.