Tools & Communications

I had a recent discussion with one of my fellow IT & Telecom SIG board members on a budget item. There was a mis-understanding between us which stemmed from the use of an electronic poll in one of the tools we use to run the SIG. We were using a tool instead of having a conversation, which lead to mis-communications.

I've been working with a couple new clients and the tool topic has come up. My advice is always to get practices down before trying to use any tools to support your practice. One of my clients is using note cards on a white board to manage their stories, and it's working for them. They have a dedicated room for the project, most people are on sight most days, so the technique is working. Inspect and adapt can also mean continue to do things that are working well, don't change just because you can.

As for the SIG, I'm going to change the process for approval of budget items to include a conversation and not just an electronic vote. This will give people the chance to ask questions, clarify assumptions, and make a better decision. It's like user stories - a reminder to have a conversation and not a detailed requirement. Without the conversation, you're going to run into problems.

Tools

There was an interesting article in this month's Wired about David Heinemeier Hanson, the creator of Ruby on Rails and Jason Fried, his co-founder at his current company, 37Signals. They have a philosophy that simple is better. Interesting enough, one of their current applications is a project management tool called Basecamp, which takes this approach to running projects.

Contrast this with a colleague of mine in the middle of a big Planview implementation project. This is a large IT organization with a lot of projects to track.

So how much tool do you need? The folks at 37Signals would say to much complexity is a bad thing, even to the point of being criticized for not growing their tools. On the other hand, some organizations need a big application like Planview to support a complex organization. However, I've also seen companies implementing complex tools in a hope that is will fix a weak, immature process (it won't).

So start simple, get your processes in shape, and then bring in the bigger tools when you need them.

Checklists

The current issue of Fast Company had an interesting article on checklist, see it here. Their argument was that checklists aren't just for the kid at the fast food place making burgers, but can help in all types of situations.

Checklists are often sited as a quality assurance tools, but how many of us really use them? When I'm preparing a customer deliverable (typically a Word document), I have a simple checklist so that I don't forget anything in the last minute rush. The checklist includes conducting a review for grammar, having someone else review the document, incorporating their feedback, checking all diagrams, running spell-check one last time, making sure page layouts/fonts etc are correct and finally checking the document properties.

This might sound pretty simple, but when things get rushed at the end of the project, my checklist keeps me from forgetting anything.