When I worked at ISS, my bosses forced me to try to do documentation project planning with Microsoft Project. Imagine the following problem:
- You have a giant pitcher of beer and 11 glasses of different sizes.
- There are 20 people in the other room expecting to get different amounts of beer at different, specific times.
- You will need to use the 11 glasses for all 20 people, some expecting their beer first, some expecting their beer last, and some expecting their beer sporadically; and some people are dependent on others for their beer.
- I could add more, but you get the point.
You would be about as successful in using Project to plan the on-time beer delivery as I was in using it to plan our doc team’s resource allocation and doc delivery. Project is not made to work the way we worked at ISS. It’s certainly not made for cross-project planning where everything is fluid: resources, project priority, units of work, etc. After trying to make it work for a few days, I called the best project manager I know: my sister. She works for a consulting company that specializes in IT project management on the Enterprise scale (so she really knows her shit!). She listened to my problem for about 90 seconds, and then told me, “You don’t have a project management problem. You have a MATH problem. You use Excel for math problems, not Project.” I told her my boss insisted on Project, and she said, “Well, then you’re screwed.” And of course I was, so I’ve moved on to nicer things.
Since then, Mike Hughes started working over at ISS/IBM and has evidently convinced them that Excel is the way to go, probably because he has a really cool method for tracking projects with it. You should check it out, if you haven’t already.
Project certainly has its place; I think it works best when you have a projectized organization and a well-defined Work Breakdown Structure. Otherwise, I think Mike’s method is a better bet. I’d love to hear about methods that work for others!
July 23, 2008 at 9:30 pm |
Nice writing style. I look forward to reading more in the future.
July 24, 2008 at 11:27 am |
Thanks for the shout out. Obviously, not everyone will agree and I already have one comment on the column taking me to task. I’ve just always felt that the resultant project plan became the end in itself, and having produced it we all admired it as if we actually had a plan. It reminds me of the quatrain from Carroll’s The Hunting of the Snark:
He had bought a large map representing the sea,
Without the least vestige of land:
And the crew were much pleased when they found it to be
A map they could all understand.
July 24, 2008 at 1:00 pm |
Thanks, Martha! I will say that when it comes to illustrating dependencies in a way that can cover your team’s exposure (i.e. “we didn’t make our deliverable because we never got the code from the QA team”) , MS Project is the PMO communication tool of choice. For managing programs, we use MS Project with high level “tasks” that are place holders for subprojects, to show dependencies between them, and then a more analytical tool, such as excel to actually manage the work. I enjoyed reading Dr. Hughes link, thanks for posting that.
July 24, 2008 at 1:23 pm |
Barbara, I should have asked permission to paraphrase you like mad in this post. Thanks for reading this and adding more dimension in your comment. I think you should have a blog on PM!
Mike, I remember that the Chief Architect at ISS didn’t like artifacts that didn’t survive the project (and I agree), and the old-fashioned Word doc plans would fall in that category. However, they did serve as CYA in their static form, basically enabling you to say, “This is what I told you I was going to do 3 months ago. You can’t bitch about it now.” That is in no way a useful tool for managing a project to its completion, of course. Sad that CYA was (is?) needed.