Wednesday, April 7, 2010

I want every email, every meeting

Let's say there's some miscommunication on your project - you thought she'd do it and she thought you'd do it. You have emails, she has notes to prove it. There's some urgency with this one because it'll impact schedule.

One reaction I see a lot is that the project lead or program manager now wants to be included on all meetings and emails. There are several problems with this:

This approach doesn't scale well on programs. A person can only process so much information and getting in the full stream of the project will just create more problems. For example, the lead will think they have to respond to more emails, or will have more information to not remember correctly.

If there's a break down in communication, the lead needs to look at the team and figure out who was responsible for the communication and work with that person to plug the hole.

Sometimes there are big battles or a lot of negative energy around the issue. Pick your battles - does this one really matter? Hey, stuff happens - see it as an opportunity to strengthen the team.

I want to be careful with this comment: if you find yourself in a tug of war over who said what and by-god-I-have-emails-to-prove-it, take a step back and assess yourself. Are you reacting because there's a serious project impact or because someone challenged your authority? Almost anything can be whipped up in to a project impact. Anyone's sense of power can also impact a project.


Friday, April 2, 2010

Blogging in the Enterprise

Blogging on projects can be a great way to let folks know status of key tasks. I've used blogs to report progress towards key milestones, results of testing, and completion of key work products. The great thing about blogs is that when reporting progress, folks don't need to figure out who to send emails to and those people who don't want to get notifications any more can opt out of the alerting. Also, blogs provide a chronological history of the project - useful when having independent reviews or audits (or cya). Good use of blogs will also cut down on the number of meetings you'll need.

Here are some recommendations:

* Setup a blog for each project, assuming a project is around 2 months or more.

* Each person on the project sets up an alert on the blog so they'll get a notification when something is posted.

* For each deliverable, peer review, or formal review, make it part of the closure criteria to post.

* Include instructions on when to blog in the projects collaboration playbook. If the blogging tool you use allows for tagging, give some basic guidelines

* Blog postings should be simple - not lots of elaboration. Use links to supporting documentation.