Saturday, March 28, 2015

Document Everything

In investigative work, of which I've been involved in, there's the well known rule of ABC; I've extended it to 'ABCDE'; less snappy but more representative of the work:
  • Assume nothing
  • Believe no one
  • Check everything
  • Document
  • Evidence.
In a project context, we can make that 'document everything.

I sat down with a 'not-senior-not-junior' member of my project team last week to discuss her work. I'd been puzzled over the seeming order in which she was doing it;  with her team leader being away it was time to make inquiries.

I found a disaster unfolding before me.

Her team leader (the away one) had been quite clear on the mission and was seemingly executing it well. It was relatively small, self-contained and low risk, so I left it to her.

In the transfer of information to the 2IC team leader something had gotten lost and the tree being barked up was in the wrong forest!

So: DOCUMENT EVERYTHING.

A brief project plan, or statement of brief would have clarified everyone's perception, so I'm going to knock together a template for just such a thing. It makes good procedural discipline as well, so that a pattern of activity is instilled in the team when undertaking a contributory task, to ensure they know how it advances the overall mission, and so they can see how it achieves what it needs to.

Friday, March 20, 2015

Guiding Principles 4: Shared accountability

Create commitment to a shared vision of project outcomes.

Often this advice is directed to the project team; and yes, ‘commitment to a shared vision’ is important to the project team. It is important that the  PM keeps his/her eye on this and makes sure it produces the results needed.

Where the shared accountability is required is at the company executive level. It is here that projects can be subject to shifting commitments, factional jealousies and even sabotage. If a senior exec is not pulling projects into order and ensuring they are effectively supported at the executive level, even by executives responsible for dependencies and who have an interface to the project, the project has slipped of the road to success.

Thursday, March 19, 2015

To Powerpoint or not...

Some observers have claimed that one of the contributing factors in the space shuttle Challenger disaster was the use of Power Point to communicate complex engineering considerations to decision makers.

It didn't work it is suggested.

This can be attributed, at least in part, to the problem of the medium, reminiscent of Marshall McLuhan's quip "the medium is the message". Powerpoint constrains, guides and
'encultures' communication to the minimal 'points' that can be crammed into a slide. It doesn't suit the complexities of argument and judgement, but only the conclusion, or the way stations of thinking; not the reasoning itself. It lead, in the case cited, to the fatally wrong decision.

There are plenty of good ways to use Powerpoint, and that's to provide graphic information: relevant images, graphs, and so on. But only in context, and not just because you can. So I was pleased to read this in the Fin Review the other day: