Yesterday I blogged about hosting a daily status meetings and some of the tricks I use to make it work. One of those that is worth extra attention is the meeting notes – at the end of each meeting I send out notes (not minutes – not that formal) that include:

• Who attended
• Key metrics
• Revised schedule of key events
• Updates from everyone that attended and/or sent me notes since the last meeting, and sometimes this will include quick post-meeting follow up discussion notes as well

I don’t spend a lot of time on formatting, it’s all bullets. If someone isn’t on the call and I think they need to read something I’ll add a note to the end of the note (Ralph – FYI). If it’s important, or I need some informal assistance from above, I’ll call it out in bold. Both of the latter tricks are important – my notes go to a lot of people that are just monitoring progress and they will typically do a very quick scan, it helps all I involved if I make it easy for them to find things that they need to see.

There are plenty of days when things go wrong, and it’s all in the notes. Sometimes we lose a day, sometimes more It’s not fun, but it’s unrealistic to expect perfection either. Showing problems in the notes is honest and powerful – stakeholders worry if they get no news, or only good news.

Think about all the things that impact a project on a daily basis. It’s easy over the course of a week or two to have it all add it up to slipping the schedule by day, or by adding some unexpected incremental cost. Imagine trying to talk about that during a weekly or bi-weekly status meeting and explain how you fell behind and what you’re trying to do to fix it (if such a thing is possible). It’s not easy, even if you have your own notes to refer to,and easy to get second guessed.

By giving a solid update every day they are on the ride with you. They see the failures,they see the causes and the attempts to fix, and if they think something isn’t right, they can engage then. Much easier and much more positive to have a talk about the one thing that went wrong yesterday than then 10 things that went wrong last week.

Transparency is easy when its good news, but it’s important when there is bad news. Rarely does someone want you to fail. Bring up bad news when it happens. Don’t let bad news “debt” build up, get it out in the open. It will make the project healthier, will keep your stress level lower (if not low), and gives the rest of the organization a chance to help you.

Transparency doesn’t have to be notes either, for example I love the concept of the burn down chart in Scrum – you can see in an instant if the team is on track or not. Think about how you might be more transparent and why you’re not doing that right now, it’s time well spent.