Is your Sponsor interested?

“If sponsors are too busy (…), I recommend project managers camp out – take their laptop and work in the lobby outside the sponsor’s office, if need be, until they can get an audience.” – Corinna Martinez
Source: PM Network, May 2012

For projects managed on the customer’s side, where there’s typically more need for an active Sponsor, setting up a recurring update is a useful practice (e.g. weekly or biweekly – depending on the project’s length, among others).

When problems occur, we shouldn’t expect our executive to become engaged, if we haven’t kept him or her interested in the initiative while there were none whatsoever.

Is knowledge a project deliverable?

Knowledge Management is a beautiful concept. And a poor practice.

It comes naturally with a fixed team or an operational setting, thanks to employee networking. Even here conscious knowledge transfer is a rare thing (i.e. knowledge transfer standards, knowledge maps, sound databases, menthoring and the like).

Knowledge Management is particularly useful for temporary organizations. Typically known as projects. Here the organization is often disbanded upon closure. Deliverables remain (hopefully). And so does knowledge. Why not store it?

Why isn’t knowledge treated as a project deliverable by itself?

Transferring knowledge requires standards or even better — habits. Best if the PMO or the Sponsor are keeping score. As a Project Manager, we’d do best to obtain early buy-in from them, agree with the team, and make sure we codify the knowledge according to the PMOs requirements (e.g. information needed, categorization by process groups, standard project phases or governance rules etc.).

Here’s an important thing… We talk about lessons learned at the end of a project usually. Why not make it a regular practice during weekly updates or daily stand-ups (in Scrum we perform a retrospective for every sprint.), i.e. adding the following questions when synchronizing with the team:

  • What went well?
  • What could we improve?
  • What have I learned?

We could then make use of our dust-covered lessons logs (described e.g. in PRINCE2) and make sure we have something to share with the organization upon the project’s completion.

Do you make it visible enough?

How would you build a habit?
You wouldn’t put your tools in a closet, would you? Better trip over them than forget.

How would you make sure you’re heard?
You’d use vocal variety, pitch, tempo, and vivid images, appealing to logic and emotions.

How would you make sure everyone’s on the same page?
Among others, you’d make it… visible.

Explicit works best — boards (e.g. as in Kanban, Scrum), printed, large dashboards, avoiding attachments in correspondence, but rather embedding additional content as thumbnails-teasers (with links).

The threshold to build momentum is substantial with electronic tools. That’s why Lean practitioners prefer analogue.