PM Stories

These are stories I have collected over the years. i hope people enjoy.


Project Managers In Practice (PIMP…sorry, PMIP)


Our first story involves a young PM, new to the project and not very technical

Ok, so I (senior consultant guy) have a project and there are 3 changes requested by the team:

1. Change a label (minor)
2. Allow a user to save their selections made on dropdowns (these select what displays in a grid)
3. Allow a user to change a grid and submit the values to another program

That’s all fine and good. I bid 44 hours to make the changes.

Team now wants a user to not only make the grid changes (#3) but save those changes as well. So PM says change 2 & 3 are now merged. We need to save selections and grid entries.

I said, OK, slight increase in scope, 50 hours total.

PM says, wait, we merged 2 & 3 together so now we only have 2 changes not 3 so it should be a decrease in hours.

PM survival tip #1: Reduce scope by merging letters on the plan and hope no one notices.

Story 2 involves 4 experienced PMs

Project is in a major crisis. High-demanding customer, a lot of screaming, no time to deliver on time. Save team is called in to try and pull it out. Atmosphere is very tense.

Some of the project members (developer/consultants) have to work on all 4 segments of the overall project simultaneously. Each segment is given a PM. Customer wants to know what is happening all of the time so PMs demand status reports at least twice a day. For consultants working on all segments that is 8 status reports per day. When complaints are lodged, developers are told that it has to be that way and why aren’t we getting the work done.

Revolt of developers / consultants ensues after months of this activity.

PM survival tip #2: if you flood your customer with progress reports they will think you are doing your job. See tip #4 below.

Story 3 involves a fixed bid contract and some super savvy consultants

Two senior consultants figure out a clever way around a major stumbling block on a late project. They can change the process agreed upon slightly and save time, money, effort, AND bring in a late project on time. The customer also wants it done since the new process has a lot of compelling advantages.

Guess who says no? That’s right, our friendly neighborhood PM. It seems that the PM has decided that the original project, as scoped and laid out, is immutable for all time. No changes are allowed from the project plan WHATSOEVER.

PM Survival Tip #3: Minimize risk by making no changes. No changes, no new plans to build. Voila!


Story 4 involves a PM with a dangerous weapon…Outlook

A project, as usual, is in crisis. The PM decides that their main role is to send out emails…lots and lots of emails. On the day of ‘the incident’, the PM has sent close to 50 emails since 8am.

Then it happens…just before lunch. The PM sends an email saying that people are sending way too many emails.

Consultants laugh and break for lunch.

PM sends 10 more before they get back….

PM survival tip #4: Forward everything, comment on everything, make up stuff. The success of a PM is ultimately measured by the suffering of others.

Story 5 involves a PM with no sense what a PM does

So, the PM contacts the lead on a project and tells the lead that there are too many emails about the project and could the lead please summarize all of the open issues and assign priorities…

…isn’t this what a PM does?

Story 6 involves a PM…again…

The developer has been waiting on getting access to the client’s machine for almost a week. Technical issues, blah, blah, blah.

After the week is up, the PM wants to know timelines (this is good, they are doing their job). Developer says the development has been pushed by 3 days. The PM, who has been copied on every email between the client and the developer, says that they don’t understand why the project is delayed because of a lack of access…

Rule #1 in computers: it is hard to use them if you can’t access them.

Story 7 Guess who…

This story involves, SURPRISE, a PM who we will affectionately call Rum. Now Rum is a great PM because Rum thinks that EVERY piece of email and/or communication must flow through him. Rum insists that no direct communication happen between the technical people or the customer and that he will just forward on what is relevant.

I…AM…IRON MAN…DO, DO, DO DUH DO…

Story 8 Who wants it early?

So, the consultant finishes the application early (1 week) but they can’t test it because it isn’t scheduled to be deployed until the following week. They are told to wait until the project scheduled date so they meet the schedule.

Story 9 This is a loving one that I just title ‘Make the Sh*& up’

Well, the customer wants a project plan. Enter our superhero ‘The PM’. Rather than getting requirements or design done first, the PM decides ‘hey, let me have fun with little chain icons and links and just create a project plan! Oh boy!’.

So a project plan is created, with no document saying what needs to be done and no involvement from the programmers. Developers finally start working on the project and are told you must meet this date for this functionality. Programmers say WTF!?!? Where did this come from.

Well, it is in the project plan that we designed w/o any involvement from the people who do the work…

PM Survival Tip #5: When in doubt, just SWAG the dates and blame the developers.