by jurvetson via Flickr

Craig over at Better Projects proposed a meme on modeling for his fellow bloggers.  (link)

I’m keen to see what you guys put up – what models are we using and how?

Ishikawa Diagram

The first one I remember using was not as a project manager, but very relevant.  It was a form of an Ishikawa diagram I would use when I was a lead technician and trainer at Gateway computers.  I often used this method and multiple “whys” going back to determine the root cause of an issue or help uncover the real needs of trainees.  After receiving sample hardware or software (probably on a Friday when I was scheduled to start training on Monday, that was typical) I spent some time on the weekend trying my best to break it.

Invariably, I found a finite set of “end states” or errors that would be produced.  Many of these had multiple possible causes, and many of those causes had root causes of their own.  After a little while, I would construct a fish bone diagram with the data I had collected thus far, and then used it as a means of finding more root causes.  Experience with other similar products would lead me to test for potential causes that I had seen before.

Even though I used this modeling technique for troubleshooting hardware or software, it can just as easily be used in project management for determining potential root causes of any kind of project failure.

Relationship Diagram

I don’t really know if this is the proper term, perhaps you can leave a comment and let me know.  The last analysis tool I used this week was a simple diagram displaying entities on my project, functional groups.  I’ve just recently switched to an acting role as the lead project manager for my contract and project, so this is the first time I’ve been extremely concerned about the big picture and how the various teams on this project work together.  We have a rather complex structure, with multiple project managers leading their teams, multiple contracts from the government agency we work for, and multiple government agencies involved.

The important thing for me was better understanding 1) the exchanges between functional groups and 2) the pain points that exist so that I can help resolve them.  It’s still a work in progress, but modeling the situation this way has taken it from an intuitive exercise plagued with a lack of focus to something concrete that can be used to guide day-to-day activity and progress.