« Oh No, My Dad Is a Project Manager!
Taking Over As a Project Manager of a New Project? »

Project Management for Dummies

July 22, 2010 | Author: PM Hut | Filed under: Project Management Musings

Project Management for Dummies
By Gina Loubser

After more than a decade of working with Project Managers I have mastered their evil art. Based on my observations over the years I have come up with what must surely be the ultimate guide to Project Management:

  • Identify people to blame.

    People always say that the Project Manager is to blame for a badly delivered project…this is a fallacy. It is a Project Managers key performance indicator to ensure that there are at least 2 or 3 people to take the fall.

  • More is less: Create Cool Reports

    The more impressive your reports look, the more people will be amazed by your skills. Make the reports as long winded as possible. No one reads them anyway. The longer your report is the less likely anyone will use it. Make sure you have a section that has Red Green and Orange in it that highlights people to blame for your projects failure. Never ever put your own failings into the report.

    You should also put in as much jargon as possible. Jargon makes reading the report even more difficult. Add in some ”codenames’ that only the core team really know. This will confuse the hell out of everyone else who needs to read the report.

    A project plan and project server and an automated SharePoint project site with obscure information will further impress and confuse everyone. Remember no one really reads documents. They all assume someone else has.

    Further content can be generated by splitting the entire project into phases and reams of paragraphs about scope creep.

    Draw processes in UML, I have recently learnt that most corporate business analysts have no idea how to use UML. That’s quite sad but useful in your efforts to slow things down on the project.

  • Getting Approval

    If you need something for your project, master the art of creative purchasing. The more technical and impressive it sounds, the likelier it is management will sign it off. If your request for a new digital camera is turned down (because someone figured out you just wanted it for your holiday at the beach), request a Replacement Single Lens Reflex Digital Image Capturing Interface Device. Adding the word ‘Replacement’ on the form will make management believe you already had one. Since you obviously had one, they must have approved it previously. This will make it easier for them to ‘re’approve and make them ask less questions.

    In the motivation section, instead of writing ‘for taking photographs of some of the project team’, you can write: ‘Single lens reflex digital image capturing interface device will be used to record & evidence data in a user friendly graphical user interface’.

  • Framing the scapegoats.

    Even if some of the red issues are fixed, you should ‘forget’ to update them and email the report to senior management. In the project management meeting you will apologise for your oversight in forgetting to update the report. Senior management will rarely attend a project management meeting, instead they will open the report and flip straight to your green and red highlights… where they will start formulating opinions about your preselected scapegoats.

  • Death by PowerPoint: Wasting valuable time in meetings.

    10% of your weekly project meeting should be devoted to tediously covering meeting attendance and scheduling the next meeting.

    20% of your meeting should be devoted to the most mundane issue on the issues list. You know you have been successful if everyone leaving the meeting is left dazed and confused about the issue and even more confused about who should be fixing the issue.

    10% of your meeting can be filled with projector issues, Microsoft PowerPoint or Project Manager error messages or Windows issues on your laptop.

    10% of your meeting will cover scope creep. You will moan and moan and moan about scope creep and insist that everything useful suggested in the project is out of scope or moved to Phase 2. For fun you can keep moving deliverables up and down between the phases.

    20% of your meeting is best used discussing the project methodology. Discussing the merits of SCRUM versus Rapid Application Development will ensure that your project team has no idea whether you are following the companies official software development life cycle.

    10% of your meeting can easily cover role definitions. If people are confused about who should do what, it makes blaming them far easier. Discuss their roles but interrupt, repeat the same thing and keep attributing the same role to different people.

    10% of your meeting can be switched between eating the snacks you stole from the adjacent meeting room or discussing something completely unrelated with the person you invited to the meeting who has absolutely no part to play in your actual project.

    10% If you are a vendor who is supplying services to a corporate, you can use 10% of the meetings to discuss why all deliverables are out of scope and further explaining that these will be billed separately.

  • Highlighting your performance.

    Schedule all the emails you need to send for the early hours of the morning. Nothing says ‘I am a great employee’ than emails sent bwn 02h00 and 04h00.

    Make sure you spend at least 10 to 12 hours at your desk ‘working’. The value of an employee isn’t measured by their innovative cost saving ideas, their problem solving or meeting their KPAs. All managers know that the sign of a productive employee is a person who is diligently at their desk all day, punctual, working late while sending tons of emails. In this respect, management and hr are generally idiots.

  • Bullet Dodging

    The intelligent people working on your project might figure out your techniques. If they start to challenge you on your efforts and performance, act dumb. You can also pretend you have a really bad memory.

    Muffins & food at bullet dodging meetings are a great distraction. They also ensure the meeting time is swallowed up by coffee making and eating. Stealing catering from other meetings is a great way to keep your project budget down.

  • Passing the buck

    The final rule of thumb is to ensure you are no longer working on the project when it ends up failing. Apply for jobs in other departments or have your project cancelled do to cost savings, budget issues or technical dependencies. Pointing out that the project outcome no longer matches the problem it was supposed to originally fulfill is always a guaranteed success because power hungry insecure and unqualified middle management always try and feel self important by making a project seem bigger or more important by screwing with the scope and intent.

  • Don’t blame me

    If you follow the steps above and still manage to take the fall for your project, don’t blame me.

Less is more!

Personally I believe the most efficient approach to a project is face to face collaboration, prototyping and dedicated focus. I get frustrated by the slow moving cogs in multinationals that cause more administrative work than practical value. I am tired of the BS most developers get away with. I detest the belief that the more expensive it is and the more complex it is, the better it will be. I cringe when people cannot see the bigger picture or understand the need for a long term strategy. I loathe the project prioritize processes that only serve to make the CEO or the Marketing Executive happy at the expense of the small very necessary projects that help staff do their jobs better.

But most of all I am disheartened by the way simple and effective ideas that solve business process issues, save costs and improve customer service are lost in a sea of red tape and stupidity.

I wish I could find and work with cutting edge companies that understand and apply these. If you know of somewhere you think I really belong, feel free to share it because right now I really need my second chance. Until then I will just be a rather bruised and broken square peg in an endless round loophole.

Gina Loubser has worked as a Project Manager for top multinational software development companies, banks & mobile network providers.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Thursday, July 22nd, 2010 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

5 people have left comments

The part on the scapegoating was quite funny, and I can easily relate to.

Gary Marcinkoski wrote on July 22, 2010 - 11:50 am | Visit Link

Not really a good article on PM practices for reading.

Shashank wrote on July 23, 2010 - 6:28 am | Visit Link

Hi Sashank,

The article was meant to examine the funny side of project management…

PM Hut wrote on July 23, 2010 - 10:00 am | Visit Link

Very funny :)

Athif wrote on July 24, 2010 - 7:45 am | Visit Link

@Shashank I am the author, it is completely satirical. Clearly it is not best practice reading, but it does touch on points of failure & frustration that I have felt when dealing with Project Managers over the years.
I think I should write a follow up article that explores the benefits of having a sense of humor in the IT sector. Don’t take everything so seriously!

Gina Loubser (ïnnov8ive) wrote on July 26, 2010 - 5:59 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories