small project

In the July 2007 edition of PM Network magazine, the cover story is entitled “Small Projects, Big Results”. What a great edition of this magazine, especially the Point/Counter-Point Article featuring yours truly. Anyway, back to the small projects piece. It speaks to the importance of doing sufficient planning even on small projects. I personally use a 4 tier category framework in which I apply various levels of rigor, which I wrote about here.

My only point of contention is regarding communication. Communication management seems to be taken as an implicit assumption by both Olivares and Toledo in their described approaches. Personally, I made a breakthrough on my small projects when I stopped taking communications for granted. That happened after I listened to The PM Podcast Episode 64 with Margaret Meloni as the interview guest. (That is an awesome episode, I recommend it highly) Since then, I have included a short communications plan in my small project plan template. It is a short, simple table that has fields for ‘communication activity’, ‘timing/frequency’, ‘responsible’, and ‘stakeholders’. It normally has 2 lines on it, one for a weekly status report, and a project closure report distribution where ‘timing/frequency’ = upon project completion.

Basically what this does for me is provide a reminder to communicate proactively and hold myself accountable for it. Since I’ve been doing this the major benefits have been less rework and making stakeholders more at ease. They know when to expect regular communications from me, so they feel more in the loop and I’ve found they reciprocate by communicating better with me regarding scope and limitations in the project.

There were several references in the article to regularly scheduled meetings taking 1-3 hours in length, sometimes on multiple days during the week. I disagree with this approach to communications on small projects. From my personal experience, this approach tends to yield a waste of time, fruitless pontification, and inattentive participants especially over a conference call. I have an alternative suggestion.

I have started using SCRUM at work along with my team, and I think the communications guidelines in the SCRUM methodology match my personal preferences for small projects. During the project, you have daily meetings limited to 15 minutes or less, and each team member talks in turn about 3 things:

1. Things I’ve done since yesterday’s meeting
2. Things I’m going to get done today
3. Obstacles in my way

Now, this technique in SCRUM is geared towards communication between developers on the project team. I want to suggest an adaptation for stakeholder communications on small projects.

First, meetings might be weekly or bi-weekly instead of daily. Instead of everyone providing the 3 points of information, the project manager uses these 3 points as a framework for the discussion. I suggest keeping the meeting to the 15 minute limit. Here’s the new set of points:

1. Progress since the last status meeting
2. Plans from now until the next status meeting
3. Status of risks and issues, and is there anything new?

Here is the catch. Don’t try to solve problems in the status meeting. This meeting is only for the 3 things above. Speak in terms of identification and status only. To actually address risks and issues, have a separate discussion with only those people who can contribute.

Of course, most of this can be applied to larger projects too. Communication should be like a laser; focused, efficient, and consisting of only necessary wavelengths (people and content). Instead, it usually turns out to be more like a floodlight; scattered, wasteful (of time), and involving many unnecessary parties.

The moral: Value communication on small projects. Make it explicit, planned, focused, and the best use of people’s time.

{ 7 comments }