The problem with project sponsors is that they have got to where they are by climbing a very dirty greasy pole. They now have a privileged aerial view of the executive landscape…. The slightest hint or whiff [...]]]> I was floored this morning when I came across this post about project sponsors. Some choice excerpts:

The problem with project sponsors is that they have got to where they are by climbing a very dirty greasy pole. They now have a privileged aerial view of the executive landscape…. The slightest hint or whiff of them being on the wrong side of an issue, especially if it is your project that is the issue, then it is odds on that you will lose your project patronage…. If we do report the real project status now, it will only lead to investigation and recrimination which will ultimately delay the project anyway. [emphasis added]

In my decades in the corporate world, I have certainly seen my share of execs who fit this description. I’ve also seen at least as many who try their hardest to do the right thing by their teams, their projects, and their company.

Here are a handful of guidelines for project managers dealing with execs:

• If you bring a problem, also bring a suggested solution and some options to go with it.
• Be prepared for deep probing on any issue, not all of which may make sense to you at the time. (As a leader/manager, I would often pull hard on one particular thread of what I was presented, both for my own edification and to see if you knew your stuff. If that thread held, I was likely to accept the rest of your arguments and cut to the request-for-action section. If it didn’t hold, I deeply discounted everything you were offering.)
• Be prepared for the exec to ignore certain areas you think are important; she may know they’re not important, she may already understand them, or she may know that they’re outside her level of competence and is looking to you for an answer, not a dissertation.
• Take responsibility. Don’t point fingers.
• Execs have less do-this-now power that you think they do. If you must ask for something, ask wisely. The best (and easiest) help an exec may offer is an introduction to someone in a different group with whom you want to make contact.
• Virtually all execs believe they got to the executive suite by being smarter and “better” at their job than most everyone else — which is true more often than you may be willing to admit, though it certainly isn’t always true. (Being smarter than 90% of the other folks may or may not make the exec smarter than you… but don’t assume either way.)
• Don’t ever bring to a scheduled meeting a spreadsheet you haven’t triple-checked or a document (or PPT) with grammatical or spelling errors. (For an on-the-fly review, more leeway is given.) The exec wants to be sure you prepared — and cared enough to do your very best — before he contributes his constrained time.
• Half of what managers do isn’t visible to their direct reports; three-quarters isn’t visible at levels beyond that. Just because you can’t see what they’re busy with doesn’t mean they aren’t buried in work. More often that you might suspect, part of that work is providing “air cover” for their teams and your project, if for no other reason than you looking bad makes them look bad.

Finally, one quick clue for spotting an exec who does fit the description in the quote with which I began this article: An exec willing to burn his team by name to his peers or in public. It’s one thing to share, “The Acme Project is late,” or even “The Acme Project team’s been telling me the project will be late.” It’s quite another to say, “The Acme Project team has screwed up,” or –worst of all — “Joe has screwed up” or “The leader of the team has screwed up.” That’s departmental politics in the extreme, avoiding responsibility.Even for an exec new to a department, there’s a big difference between “I know the Acme Project has been late, and I’m going to find out what’s wrong and fix it” and “My predecessor screwed up the Acme Project.”

Exec, grunt, or in between, take responsibility. That’s leadership.

PMBOK Breaks Project Management

The PMBOK is the grandiosely titled Project Management Book of Knowledge from the Project Management Institute (of which I’m a member).

Wow, I thought, someone else thinks formulaic, by-the-book-only project management can be as much a problem as a [...]]]> I found the following subject line on a mail in my inbox yesterday:

PMBOK Breaks Project Management

The PMBOK is the grandiosely titled Project Management Book of Knowledge from the Project Management Institute (of which I’m a member).

Wow, I thought, someone else thinks formulaic, by-the-book-only project management can be as much a problem as a solution. The mail was from an electronic newsletter called IT Business Edge. It struck me as odd that an IT publication would be railing against the PMBOK.

Of course, what happened is that my inbox shows only the first 30 characters or so of a subject line. The entire subject is “PMBOK Breaks Project Management into Five Lifecycle Phases.” (It links to this slideshow — and it’s not a slow Flash thingy, so kudos to IT Business Edge for that!)

I’m not sure why this is headline-worthy news; did someone in IT just discover project management?

But now that I think about it… five phases? They’ve got it down as Initiate, Plan, Executing, Controlling, and Closing. Aside from the grammatical issue — it’s either “…Plan, Execute…” or “Planning, Executing…” — there must be at least one and perhaps three additional, explicitly called out phases in an IT project.

The unforgivable omission is Rollout. Without a specific Rollout cycle, there is a tendency — I’ve seen it over and over again — to “dump” the new solution on the users, point them to a (functionally useless) training website, and disperse the team after Closing — but long before the solution is embedded in user processes. Sure, you can technically put Rollout in one of the other phases, but it’s really a post-Execution activity, involving a handoff from the execution team to an operations team… and much more.

There also need to be User “Readiness” and Shakeout phases. These can be subsumed into other phases — e.g., part of Rollout. However, because the activities and players are significantly different, I prefer to call out explicitly at least Shakeout. In addition, if you’re using stage-gates (go/no-go decision points), these phases represent transition points where the sponsors and stakeholders need to get together on a go/no-go decision. (What, you think you can’t say “stop” after the project is rolled out to users? Wrong. If it isn’t working for them, you may well need to perform a rollback, and you’d better have all the stakeholder ducks in a row when that happens!)

As for the names of these last two stages — there aren’t universally accepted terms. I don’t like “Readiness” — it means everything and nothing — but it can serve as a catch-all for user documentation and training, adoption planning, helpdesk/support preparation, and so on. Shakeout represents the first few weeks to a month of actual use on live data, where numerous bugs and configuration errors will crop up, and where the original development/project team should remain in place to address them. One reason I prefer to see this particular phase visible at the highest level is that there is great pressure at this point to move the team on to other projects… especially if the project is late… and since we’re talking about software, the likelihood that it will be late is, oh, 100%. If the executive sponsor and the CIO are aware that there is a full project phase that is just getting started, there is less pressure to move the team, and more weapons with which to fight the pressure.

So maybe leaving off these phases from an IT project justifies the headline after all, with a slight emendation:

Misapplied PMBOK Breaks Project Management

Almost all of it applies equally well to non-Legal project management (which isn’t the same thing as illegal project management). The topics are:

I do take issue with one blanket statement, however: “The projects your senior managers worked on were much simpler than the products you’re working on now.” This statement assumes either that the IT [...]]]> Johanna Rothman has an interesting post on why senior managers seem to like waterfall project management, or, as she puts it, serial lifecycles.

I do take issue with one blanket statement, however: “The projects your senior managers worked on were much simpler than the products you’re working on now.” This statement assumes either that the IT and project worlds have gotten more complex in the past 20 years or that senior managers tend to be political hacks who are promoted because they play games rather than because they were smart. The former is untrue, and the latter is untrue often enough to fail as a generalization — though I’m sure we can all point to managers for whom it is true.

But she later hits on a very telling point, I think:

Possibly the most seductive reason of all: Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. [italics in original]

Serial lifecycles have a few aspects — perceived benefits — that I believe drive their appeal:

1. As Rothman notes, they provide the appearance of prediction and control.
2. She also notes that they can succeed on short projects… though pretty much anything can succeed given a short enough or simple enough project.
3. They provide the easy metrics and even red-yellow-green dashboard reporting that less effective execs love.
4. They provide ways for bad managers to blame others for problems and offer “support” for that blamestorming.
5. They work in some industries, especially construction and manufacturing, where the percentage of unknowns and unknowables on a project, along with the variances in estimates, are very small.
6. They’re the easiest methodology against which to apply project management science. Unfortunately, it’s extremely easy to misapply the science to them.

In particular, I believe they’re a very poor tool for reporting up or out on a project or project portfolio, for reasons I’ve detailed in other posts.

However, if used [...]]]> I’m not a huge fan of dashboards, particularly red-yellow-green types of dashboards. Too often, the oversimplify, providing a simplistic, un-nuanced and therefore low-value view of a situation.

In particular, I believe they’re a very poor tool for reporting up or out on a project or project portfolio, for reasons I’ve detailed in other posts.

However, if used in conjunction with rich data, a dashboard can provide an eye-catching way of spotting something going wrong. Sam Huffman presents a very neat way* of including a dashboard within Microsoft Project layouts, as shown in the reduced-size picture below.

It’s a bit tricky to set up, but Huffman walks you through the steps with lots of supporting pictures.

This is most useful to the project manager and sometimes the project team. I strongly recommend you not include it in project plans presented to management. It’s too easy to look at the pretty lights and think you understand more than you really do.

As a department manager, I never wanted to see working dashboards or other symbol-heavy reductions; I knew how easy it was to get caught up in these pseudo-facts. Also, I knew that teams learn to shade their work to ensure that something that’s either-yellow-or-red, for example, always shows up as yellow.

____________

*Updated with link 7:28AM PST January 14.