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.

4 Comments Continue reading

Many processes are cross-functional. The same is true of projects. This point is about dissolving the “us versus them” scenario that so often exists in one form or another within organizations. In most projects that I work on, there are individuals from departments such as operations, central services and other support functions, MIS, IT, Service Engineering, etc. The “us versus them” attitude comes about when project managers and project team members look at their own interests at the exclusion of others, and instead of working towards a common goal, work towards their own separate and distinct goals.

Although I have much respect for PMI and am a member of the organization, there is a statement in the PMBOK to the effect that a project is successful if the written requirements are met, regardless of whether or not the actual customer needs are fulfilled. To me, this is lunacy and reality avoidance. Project management within any organization can not be successful in the long-term if the only goal is to meet the written requirements. The goal should be to help the stakeholders and sponsor flesh out their true requirements fully, and then meet those needs. The objective of any project is to add value to the organization, period. I have been a team member on projects where the ‘requirements’ were met, and yet the end user was thoroughly dissatisfied with the results. This is not a successful project, regardless of what PMI says.

I have begun using SCRUM at my company recently, and although I was at first frightened because of the paradigm shift required of such a technique, I am beginning to like it. The general premise is that stakeholders really don’t know what they want until they can see it and work with it. SCRUM (a light version of Agile) is a way for the stakeholders to actually use incremental versions of a working prototype software, and I have already seen it’s power in fleshing out true requirements. I completely understand and realize now the hardship that stakeholders bear when trying to visualize a future state and properly articulate the requirements to get there. So far it appears SCRUM is specific to software development, but I am starting to have ideas that elements of it can be applied elsewhere to better understand the true stakeholder needs in an iterative manner.

I encourage everyone who is a project manager to not take the CYA route of “well, if they don’t put it in the requirements, it’s their fault” and instead be proactive and engage the stakeholders. If any doubts exist, do not throw responsibility over the fence, take it on yourself. A truly great project manager holds themselves accountable for stakeholder satisfaction.

0 Comments Continue reading