Guest Lecture on Project Risk Management

I was invited earlier this year to deliver a guest lecture to the MBA and MEng combined Project Risk Management class at the Haskayne School of Business at the University of Calgary.

This guest lecture was a bit of a trial run for me to see if I could take the written word from blogging and make it useful and usable for a broader audience.

The slideshare is here:



Advice for Junior PMs – #6 – Starting your own Project Management Knowledge Book

One of the Project Management RSS feeds which I read had an interesting article in it (it looks like a recycled link, but was new to me).  The article stated that in order to continue growing in your project management career, you should start keeping a binder of your best practices.

Given that I’m not particularly into dead tree and lugging a binder about, I fired up Google Docs and started a new file.  I spent 30 minutes hammering out everything I could think of as a best practice.

My first line item, which came from a fortune cookie that I have taped to a photo frame, was Promise Only What You Can Deliver. Read more of this post

Quotes for the Self Actualized Project Manager

One of my favorite frameworks for looking at how one is doing in life is through Maslow’s Hierarchy of Needs.  I’m not certain if it is the oversimplification of how we approach life, or the fact that I can broadly apply it to many of life’s circumstances, but I do think that it is the most succinct framework out there.

Thinking about the top of the triangle, I often ponder what true self actualization would feel like.   I think that being truly self actualized is the meaning of life.  I know many of my friends and colleagues have found their niche (pronounced “nee-sh”, not “nit-ch”) and say that they are self-actualizing in their career.  Personally, I think that most people stumble at the Self Actualization level due to the need to be displaying and constantly seeking their full potential.  So, that being said, I would offer this advice for those Project Managers who desire mastery of their art. Read more of this post

A better feedback model

This is just a quick plug for a tool that I have found to be super effective.   Special thanks to Manager Tools ( for the podcast and indirect coaching.  I highly recommend that you listen to their “Manager Tools Basics” series (even though it can be kind of rambly at points).

Typically, when giving feedback to someone, you give them the shit sandwich – “this was good, that was bad, the other thing was good; overall, keep up the good work but don’t forget about the thing that was bad.”  This model is a bad model, and should be very ashamed of itself.  It’s a bad model because it lets both good and bad behavior sit unattended until feedback review time.

The better way is to be proactive; however being proactive when using the above model can be hard to implement.  How do you walk up to someone and tell them that something that they did was good and/or bad without it happening in a formal review setting? Read more of this post

What if you are your project’s biggest risk?

“A little knowledge is a dangerous thing” – Alexander Pope

While I was studying to become a project manager, I believed what the PMBOK and my professors had to say as the gospel truth: a project is a project is a project.  It didn’t matter that I had no experience building a bridge, planning a wedding, or configuring a database server… I was going to be a professional project manager, and that meant that I could manage anything (so long as I followed the 5 phases of the PMBOK and did everything that the 11 knowledge areas told me to do)!

For a while, that was the case.  I made sure that all of my projects had strong technical people that were good communicators so as to provide good estimates, identify risks early and often, and manage the details of the deliverables.  I was able to focus on managing at the executive level, facilitating problem resolution, and provide project administration support.

But then it happened – I was assigned a project where I had a little bit of technical knowledge, but not much, and was paired with some intermediate resources.   Read more of this post