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.

I knew you had more than a passing interest in outsourcing. Maybe you can come up with a solution for the problem outsourcing companies in India are facing. You may know that majority of the income for outsourcing companies comes from engineering of end [...]]]> A former colleague of mine wrote me the other day:

I knew you had more than a passing interest in outsourcing. Maybe you can come up with a solution for the problem outsourcing companies in India are facing. You may know that majority of the income for outsourcing companies comes from engineering of end of life products (products that are deployed and are in sustenance mode). While overall income from these products has grown, margins have been rapidly going down even before the recession. Outsourcing companies are also scared that if and when we come out of recession SaaS [software as a service, or hosted solutions] and cloud computing will have a huge impact on the topline of outsourcing companies in the wrong direction. Your thoughts…

First, I think margins will continue to decrease for multiple reasons:

• Water seeks its own level, so to speak. As the US transfers money to India, for example, by paying for offshore work there, the basic laws of economics dictate that the value of work there will go up relative to here. Workers will get paid more, the Indian economy will do better (the rupee rising against the dollar), and so on. So it will be more expensive to do work in India next year than it was last year.
• As India gets more expensive, and as other countries do a “”hey, we can do what they’re doing,”" India will have more competition, at least in some areas. There are lots of English speakers in the Philippines, for example; I used to outsource work there a decade ago, and they still have a price advantage. India for now has a skills advantage, but given sufficient price differential, and that will vanish. There’s also a “”nexus”" advantage in that groups of workers congregate and are easy to reach, and they share skills. Both can be overcome with money.
• China is entering the market. There are enough people who read English well enough in China to do outstanding technical work from American documents. There’s still a price advantage in China.

There are other difficulties and issues:

• China also has a time-zone advantage. India is half a clock cycle away (actually, 12.5 hours) from the West Coast. It’s super-hard to get a team meeting to happen, because if it’s 9AM here, it’s near-bedtime there, and vice versa. You can get individuals to connect, but it’s hard to get two full teams on line at the same time. China is 8 hours away from here, which gives a lot more overlap. (It’s 11 hours from the East Coast, though.)
• It slows up work when there is an overnight cycle. You can do only one communications cycle a day with India, and it’s pretty much the same with China. We send something at the end of our day, they work on it while we’re with families and asleep, and we get it back as they go to bed. That’s slow.
• Brazil and Argentina are entering the game. Same time zone, give or take, which is an advantage for collaboration.
• The overhead is significant when dealing with India. There are flights, and time lost to travel. There’s the overnight/full-day-cycle issue. There are general communication difficulties; it’s hard enough for two Americans to communicate and transfer full meaning; it’s a lot harder when there are fewer cultural referents. (That said, India is culturally closer to the US than China or Brazil because of the long history of the British in India.)

I had mixed luck with sending work to India. One project went well, but it had an effective leader (the colleague who wrote me the note above). Two others went poorly, with lots of rework; they ended up costing more — and taking longer — than it would have had I sent them to Bozeman or Bangor rather than Bengaloora (Bangalore). The upshot is that if I looked at costs all up, including transactional friction and opportunity costs, I’m n0t sure I’d find India economical for technical work at this time. That can only get worse with SaaS and the cloud, where much of the work will need to be in the same sort of timezone as the customers. Should the US emerge from the recession before India does, there’ll still be some price arbitrage… but I’d bet the recession will end in Manhattan, NY before it does in Manhattan, Kansas, and so there’ll be price arbitrage opportunities to “”offshore”" to the US and Canada. Bozeman and Manhattan (Kansas) are also offshore. They’re not within 200 miles of an ocean.

Also, the perceived — and possibly quite real — need to do rapid turns (revisions) on cloud-based work argues against an India or China solution. There’ll still be work going there, but it may not continue to grow — and it may well be lower-margin work.

There is, however, another area where the price differential remain enormous — the legal world. Legal Process Outsourcing (LPO) will utilize India and other nations for some time to come… but again for low-margin work.

=========================

There is one critical assumption implicit in all this. I’ve avoided it until now.

That assumption is that the US will continue to be the center of both technological advancement and the source of work such as LPO. Given our litigious society, the latter seems reasonable. But I’m not confident the US will remain the unchallenged “”big dog”" of technological innovation.

China is a scary (from a US-centric viewpoint) rival. India is too. Will the next Microsoft or Google emerge from an “”emerging”" nation? Maybe, if you’re talking about a business. However, will the innovations that drive this mythical company come from outside the US? That’s much more likely than it was ten years ago.

Ten years ago, that was unthinkable. Now, it’s very thinkable.

And therein lies the key to the question raised at the start. India will grow stronger to the extent that it become the technology innovator. Same goes for China.

Think I’m smoking something? Consider: There are a handful of very cool phones at the moment. The iPhone is a US idea, but both the Touch and the Google Nexus come from China. (HTC created both.)

Innovation is the high-margin business. Insight, courage, education, a bit of capital. Used to be, the West was a sole-source supplier of the last two. Today, not so much… and with education, seriously not so much. The opportunity is out there….