Comments are closed.
What not to do
March 17th, 2005
There’s any amount of advice out there on what you SHOULD do as part of the project management process, so it makes a refreshing change to come across some ideas about things you SHOULDN’T do.
Stephen Seay’s blog provides just such a list, some of which are listed below:
Don’t believe everything you are told about a potential project’s benefits. Investigate for yourself and plan accordingly. Don’t take on a project that doesn’t have a strong sponsor that is committed to seeing the project succeed.
These are interesting ones, because the role of the project manager is often synonymous (or confused) with project cheerleader. To an extent that’s natural - after all, it’s not good for the soul to be running too many projects you’re not enthused about; but there are fine lines between enthusiasm, optimism and over-confidence. One of the most important roles a PM can perform is acting as a questioner of assumptions when it comes to the project’s benefits. If those benefits aren’t delivered, you can bet that it won’t be the sponsor who’s criticised for over-selling the potential - it’ll be the PM who picks up the blame for under-delivery, even if the benefits were unachievable in the first place.
Don’t forget that most project assumptions should also be risks.
This definitely falls into the category of “obvious, but ignored”. The clue is in the word - “assumption” is simply a more business-friendly alternative to the word “guess” - so if you were in any doubt as to why this was important, just try rewriting your project initiation documents substituting the two words, and see how it looks. Ideally, the initial risk log would be the mirror-image of the assumptions, with contingencies set accordingly.
Don’t set project expectations that are higher than reality can deliver. Don’t forget to manage customer expectations.
These two are linked in my opinion, and can be summed up as “under-promise, over-deliver”. Unless over-delivery itself is likely to cause problems - projects don’t exist in a vacuum, so cranking up the volume out of yours isn’t necessarily a good thing for someone else downstream.
All in, the list is a useful mental checklist to have at the back of your mind - the full posting is here.
Filed under Project Management |One Response to “What not to do”
Finding stakeholders for a project was amazingly difficult in my last dot-com company. A project team of 8 to 15 people would be rounded up and given a target, but we had a devil of a time getting someone to “own” the project at a VP or Senior Director level.
Since our projects were often intra-divisional, it was absolutely necessary to have high-level air cover when trying to get cooperation across divisional lines.
As a result, we would run a project for months on the promise that our requests were being evaluated, while senior executives backed carefully away so they wouldn’t get splattered if the project stepped on somebody’s toes or exposed an organizational problem that was being carefully obscured.
If the project managed to make some visible headway and the team reports were politically correct, some upper level manager would always seem to surface as the project stakeholder, just in time to claim credit for the final release.
Part of the problem was that most of these projects were created to reconcile different product designations and prices coming from separate profit centers after they were all rolled into one madly struggling amalgam of formerly competitive business units.
Most of these projects were suicide missions, but they had to be done if the company was to survive. Although management took the credit, it was the incredibly hard-working project teams that welded the company back into a working whole with the distant support of some far-seeing Senior Vice Presidents.
To support one of your main points: All of our project assumptions were risks.