I found out that asking yourself and your team members the right questions makes a whole lot of difference. It makes things easy once you get in the habit of doing it.
Try some of these:
- in a stressful moment: What next thing makes the most sense at this time given the current situation?
- someone complains, ask: What can we do about this?
- when in doubt: What are the next steps?
- when things surprise you: What are these things telling us?
- after a setback: How can we learn from this?
I got inspired by a post by Steve Pavlina I remembered from long ago, in the recent past I started noticing that my CEO and other senior project managers ask these kind of questions quite a lot.
It’s funny how common sense this is, all you have to do is do it.
Good question, someone asked me a few days ago and it got me thinking about the essentials. So what does a good PM do actually?
Here’s a list of good PM behaviors that I think are important:
- communicate with all the people who are influenced by the project
- monitor and control the scope, budget and planning constrains
- understand the content of the project in enough detail to communicate, monitor and control efficiently
- create situations that allow the team to focus on the project goals
- help people to get the feedback they need to grow (not the same as coaching)
To give you some context on my list, in my company we create teams around a project most of the time, it’s what the Project Management Body of Knowledge would call a projectized organization.
Words have the incredible power to set the trend in a business agreement, nothing new there, but at times differences can get subtle. That’s the case with using “assumptions” vs. using “dependencies”, they can mean the same thing but give a different message in the same context.
There will always be things that are unknown in a projects life cycle. Now, when do you use which word?
- Filling in those particular blanks is critical for the success of the project? Then go for dependencies, reducing ambiguity on showstoppers is always good.
- Need to make one choice over another to keep the story in the document intelligent, then you’re safe with assumptions.
Assumptions tend to take care of the unknown but dependencies imply someone will need to take responsibility for them.
It’s a choice that keeps coming back in project charters, proposal texts and product case descriptions.
edit: The thing is that those terms get used as topic headlines a lot in standard PM templates, and sometimes when arguments arise it’s a lot easier to point to dependencies than to assumptions.
A project charter is the document that provides ownership (and authority) to the PM for a project, after someone hands that to you or when you write it up yourself and get it signed, you are the owner of the project on behalf of your company.
The point is, you start out with it and maintain it during the course of the project. I never get project charters handed to me in my current work situation, I always write them myself. And I like them short.
According to what I understand from the PMBOK there are 3 things that are absolutely essential for a good project charter, and those are:
- a business case
- the projects constraints
- the assumptions (or dependencies)
Looking at only those 3 things that’s not much is it? Some of the things I always add are:
- high level in scope
- high level out of scope
- communication plan, list of major project stakeholders with their coordinates and roles
- general terms and conditions in the mother language of the sponsor, for legal purposes
I made a mindmap exercise in Freemind a long time ago by looking at some example project charters I got my hands on, the combination I came up with looked a bit like this:
But that’s too long to maintain if you have a high number of relatively short projects to manage.
Today my actual essentials look more like this:
Here’s the big mindmap:
project charter comparison PDF download
Freemind source file (.mm)
I want to share the whole exercise with you, so here you go, source and everything in a variety of formats.
One of the most important things you should do in the project closure phase is a retrospective meeting with the team.
The best website about retrospectives on the entire internet ever is retrospectives.com, it just says it all.
I send a link to retrospectives.com together with the invitation to the meeting to set the purpose and the expectations.
What is a retrospective? From the site:
A retrospective is a ritual gathering of a community at the end of a project to review the events and learn from the experience.
No one knows the whole story of the project. Each person has a piece of the story. The retrospective ritual is the collective telling of the story and mining the experience for wisdom.
What you get after the meeting is a nice list of meeting notes and happy people, and if that isn’t enough these are the 3 main reasons why I do it:
- regardless of how the project went, the lessons learned are always valuable for the people on the team, like the definitions says, it’s mining experience for wisdom and will help people grow
- you are creating a valuable project management asset for future risk assessment
- it’s an official point in time that says the project is actually done and that’s cool because everybody likes the feeling of accomplishment (or relief )
When you want to do this, all you need are the 4 questions from retrospectives.com to set the correct mood. Although it’s kind of tempting, I’m not going to copy the entire retrospecitives site, so head over there.
I got this via the unofficial bridge king of the West and delivery manager at Nascom, Tom Tabruyn.
I’ve been reading a lot of blogs on project management, in the sidebar on this site you can find them under links. The ones I absolutely like best and love to read are:
The Struggling Manager has some really cool articles about efficient communication and I bet Rob Redmont – the author – writes just like he talks to people. Good advice, over and over.
PM Hut makes up for it’s ugly design (it’s true) with a high posting rate and a lot of very good authors who probably also have their own blogs somewhere.
My head of project office told me about Project Smart when we where talking about PMI training. It’s a great training resource and the post frequency is just right.
I use Google Reader to keep up to date with the latest and greatest, if you haven’t tried it yet you should, it saves you time and for that it totally rocks.