Grading scheme

I've recently run into a discussion with an accommodation provider on the gradings used in the review form provided by an Internet booking service.

A guest is invited to complete a few questions about aspects of the property: its condition, comfort, kitchen facilities, cleanliness, heating/cooling equipment, bathroom facilities and 'value for money'.

Such lists need to be calibrated so all parties are clear.

I use this set of criteria:

5 - exceeds expectations OR exceptional

4 - meets expectations OR completely satisfactory

3 - does not quite meet expectations OR largely satisfactory

2 - largely fails to meet expectations OR unsatisfactory

1 - does not meet expectations at all OR unacceptable

So, an operator would seek to have mostly 4s, with some 5s from guests who found the property to be superlative in that aspect. If there are too many 5s, over time this might indicate you can increase prices if you are operating at or near capacity.

A few 3s from time to time would be acceptable as people's tastes vary. If critical criteria get a 3 follow up and offer an inducement for a future booking as a gesture to make up for the disappointment. Perhaps a night at a 75% rate.

Once would expect almost no 2s. The operator should follow up guests who made 2 scores to obtain the detail, and perhaps offer an inducement to re-book, depending on the reason and if it gives helpful  information.

Any 1s should also be followed up, with no inducement offered as they are probably very unhappy.

In any follow up avoid recriminations or justifications. The customer is giving you valuable feedback which properly used can produce business benefits for the operator.

Manage the 'inner' stakeholders

Stakeholder management, like most things in popular literature, is often reduced to a set of rules of thumb. Often good as far as it goes, but there are some stakeholders that need extra care.

I call them the inner stakeholders.

Who are they, and how do you find them?

Easy.

First, find the project sponsor. That's probably easy, but not always. The real sponsor.

Next find who the sponsor has dependency or supply relationships with.

That's them, then. These are the 'inner' stakeholders.

Because of their relationship with the sponsor, they have a stake in the project in some way. Maybe even a way they don't see or fully appreciate.

It's your job as the PM to find out what their stake is and how they conceive it.

You need to meet them and ask about the links to the project, and the links to the things and people, functions and customers, the project is linked to. The relationship of the 'stake' to the 'holder' can be a second or third-order relationship, and those relationships might then have similar links to other inner stakeholders. They all need to be found, named, and analyzed.

This is the group you need to get in a room and identify the interconnections and how their influence can be useful to the project (and therefore to them). A 'rich picture' can help do this.

Then keep them updated. Maybe weekly sometimes, maybe monthly or quarterly at others.

But keep them updated somehow, and keep your sponsor in the loop as an ally, a facilitator and a power and information broker.

No matter what. Do it.

The very big project

Familiar project structures typically include a PCG: project control group (or Project Board, in Prince2)

In large projects I've conducted I find a couple of other formal groups useful:

1. An Operational Management Group (OMG, or OMCommittee), and
2. A Stakeholder Reference Group (SRG)

Operational Management Group
On complex projects, the sole manager, even with staff is not adequate to the complexity of the operational activity. The OMG is composed of the decision-makers from essential contributing disciplines or departments. It usually runs to 5 or 6 people.

The OMG role is to advise the PM/PD on critical issues of coordination, operational strategy and the details of performance, again, particularly where coordination is required.

In smaller projects, the PCG can reach into this area, but in larger projects, it concentrates on policy and strategic matters, and authorizations of critical decisions related to scope, expenditure, and policy.

Stakeholder Reference Group
Large projects can have many conflicting stakeholders, stakeholders that the project genuinely seeks to serve in some way. The representatives of these groups meet every 6 to 8 weeks to consider progress, the relation of the project scope and performance requirements to evolving stakeholder concerns and needs and to advise the OMG of stakeholder interests. The OMG may refer these concerns to the Sponsor for further consideration, with any project effects being referred to the PCG/Board.

Just don't do it

Don't do what?

Why, use PowerPoint of course.

This evening I was at a formal inauguration of an academic scholarship in honour of a deceased professor of the school (professor means head of department, not just lecturer, as in the USA).

We had PowerPoint for some images related to him and his work...about three I think. During a speech the computer decided time was up and switched itself off. The image projectors declared that there was 'no signal' and joined the sleep circus.

The technical man ran down, woke up the computer, that woke up the projectors, and of course, he had to restart PowerPoint in edit mode, switch to show mode and flick through to the right slide. Pathetic.

Lessons  (or 'learnings', as we like to say today)?

1. turn off the power saving features of computers before the presentation
2. make sure the projectors don't go to sleep
3. save the  PowerPoint in 'show' mode so you don't look like a dork when you start or re-start it, frigging around with the mouse to turn to a slide show (F5 does it better, by the way)
4. convert the PowerPoint to a video (Quicktime?) and just run it in a loop.

This was at a university with 'technology' in its name...unbelievable!

Guiding Principles 8: Time management

Encourage project managers (PMs) to value time—both stakeholders’ and their own—when making project execution decisions and managing meetings.

Worth mentioning, but I’ve not come across any competent project manager who doesn’t move at an intense pace: tightly run meetings, concise communications, and clear advice.

This topic is often discussed as 'time management', but do we manage time? No. Time passes. What we manage is delivery or project performance (distinct from technical performance, or how the project object does its job).

Good delivery management comes from good information management. And if there is a primary element of project management, it is managing the flow of information to keep abreast of the state of the project, its dependencies and interfaces.

The communication system that moves information through the project team and documents the movement of information makes time management efficient and effective. Without it information is unreliable and its value to the project drops, imperiling the project outturn value.

Using word like a typewriter.

Part of using Word to communicate is to give a document clarity of layout. Some of the message is thus sent by design.

I had a document from one of my team leaders that needed some content edits, and it was quicker for me to get into it and do them myself. Nothing dramatic, so no real coaching opportunity in it.

The document opened I couldn't quite see how it was constructed so I turned on markings--and what a mess!

Instead of using Word's tools like tabs, tables and cell positioning, paragraph layout, my colleage had used the spacebar...for everything. Move one piece of text and the whole line is thrown out, move another and the vertical order is wreaked.

A real step back in efficiency.

Check the e-mail

How many times have you received an e-mail, read it, then acted, only to find that the real message was in the 'trail' of e-mails below the one you read; below the 'fold' in web design parlance.

I usually browse through the trail to see if there's anything there for me, but last week, I didn't. The request seemed to be self-explanatory and self-contained. The trail below it also seemed to be giving various positions, so the author I read had assumed that a reader would work out from the complex trail what they were asked to do.

Not so, too many choices, too many assumptions would have to be made.

To convert this melange to communication, if you must send an e-mail trail, copy, paste and edit to make sure you send the message you want action on. Projects are too complex to think that a reader can work out what you mean from a long trail of e-mails from different authors full of discussion, fact, and inquiry.

One page

Since the publication of the One-page Project Manager, there has been a bit of Internet effort to do the job. The idea of a 'dashboard' is similar, and I use such myself, but I don't know if the 'one-page' nut has been cracked yet.
Based on articles by Edward Tufte, I've had a go:

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.

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: