Quote of the day: Oscar Wilde

I am so clever that sometimes I don’t understand a single word of what I am saying.
— Oscar Wilde

Top 10 (Bad) Incentive Assumptions

This post from @IncentIntel is timely as we head into silly season: performance and rewards time. I especially liked the two below; communications about incentives are too often treated as a “once and done” event:

3. If the award is valuable enough you don’t need to communicate and remind them of the award opportunity.
…
5. Top performers don’t need to be reminded of where they stand in the program.

Own your project’s story (HT @MelanieDuzyj and @mkrigsman)

We all should know how critical project communication is to project success.   A compelling story can build strong sponsorship and sustain stakeholder commitment, even in the most challenging of circumstances (also see Michael Krigsman’s project success checklist) .  However, many project managers assume that their audiences — or even worse, key influencers and “re-communicators” — understand the story as well as they do.

The group blog at BlissPR has a useful post by Julie Johnson on “Getting the Details Right“.  I’ve often suggested that project managers leverage what their PR professionals more.  IMO, the ability to influence is an essential behavior for an initiative leader.  Why not listen and learn from people who know?

In this case, the lessons for driving accurate press coverage apply well to any project that needs to own and drive its story.  Simply substitute “project” for “company” or “industry”, and “stakeholders” for “media”. 

• It’s more important than ever for a company to take control of its reputation – after all, you either control your reputation or someone else will
• Educating media about a company or an industry can be even more important than garnering coverage
• The story you tell must be simple – especially when the truth is complicated

Stakeholder management matrix in pictures

Sometimes it’s useful to see how we’re seen… (HT DamnLOL.com via @ahorvet link).

More best and worst project names

My post on best and worst project names remains one of my most popular.  As a follow up, here’s a few more good and not-so-good names:

Sunrise was the name of the project that separated our IT systems and infrastructure from our former corporate parent.  IMO it was an excellent name because a sunrise is the tangible start of a “new day”, which the projected provided for our company.

[Company Name] 2001 was a common turn of the millenium project name, but one that didn’t wear well.   For example, many of these projects didn’t finish in 2001, as global rollouts continued on for several years.  Many colleagues felt silly trying to wrap up “2001” in “2004”.  If you’re going to “date” a project, then make sure your plan doesn’t run past that date.

Phoenix sounds cool, but it should be used carefully.  It isn’t just a myth of renewal, but a

The cost of control

I saw a great post by Ron Ashkenas on how controls create complexity.  We’ve been struggling with this issue in our transformation program.  We have put stronger controls and more frequent communications in place.  However, these controls and communications shouldn’t create double or triple work.

Askkenas captures what drives these issues in his opening paragraph:

Have you ever noticed that organizations are great at creating controls and policies to prevent incidents that have already happened? Once the proverbial cow escapes the barn, they adeptly make sure it won’t happen again by, say, authorizing only certain people to man the exit and constructing barn-door status reports. 

Sometimes this needs to happen and usually it is straightforward to figure out what a “new normal” approach should look like.  But the rest of the program or business can get left behind and needs to be brought along to the new reports.  There is nothing more frustrating than reconciling “old program” status reports to the “new project” control paradigm.

Sound and fury, signifying nothing

Pay no attention to the project behind the curtain...

Communications practices are a gold mine for the troubled project prospector.

Another sign that a project is headed for trouble is another communication quirk: discussions aren’t reflected in any documented issue, action, risk, deliverable, etc.  The most familiar example is a colleague who can always “fill in the details” on a topic during the discussion, but never seems to have the details at hand.

You might as well tell me: “Dig here… plenty of goodies buried in this team, project, etc!”

Best and Worst Project Names

The name of an initiative is an oft-overlooked aspect of communications.  You’ll get a decent name if you work with an experienced OCM crew.  However, the most effective names I’ve seen weren’t focus-group tested so to speak.  Here they are:

• Everest: Used for a SAP project that was challenging with a tight time line; however, the customer expected good returns from the initiative.  This name conveyed these attributes well: Everest is dangerous, has a short climbing window, and signifies the ultimate achievement.
• OASIS: This was an acronym used to describe a SAP upgrade for a customer that had had a troubled initial implementation.  The name conveyed danger and privation.  More importantly, it reflected the key goal of the project: to provide a stable and modern ERP platform (the customer had waited years to upgrade).

Finally, I have a soft spot in my heart for Project BOHICA, a name we used on a project simulation team.  I’ve always wanted to use that one “for real”.

Any other best or worst names?

Portents of Impending Doom

...and another thing: I told everyone that we needed daily meetings!

How do you know if a project or program is going off the rails?  IMO, the first signs show up where you might expect, in communications.  Remember that the core of project communications consists of presenting the progress, status, and forecast for the various elements the project is supposed to deliver.

Perhaps that is the first sign: project communications don’t substantively cover at least one of those three elements.  For example, I get worried when issue reviews only contain the issues’ current condition (status) with giving a sense of what was done (progress) or what remains to be done (forecast). 

Neglecting or ignoring an issue’s “bigger” picture — e.g., a timeline of what was done and what comes next — has been a warning sign that there isn’t much of a plan behind those issues.  Without putting the issues into context, the review can devolve into an “Airing of Grievances” that has nothing to do with moving the project forward.