WebPaperwork.com

Leisa Reichelt at Disambiguiy asks Where’s The Gantt Gone?

In the article, Leisa explains why she finds Gantt charts useful:

At a simplistic level – nothing focusses attention like a Gantt Chart with lots of red on it – indicating that you’re way behind schedule.

On a more practical level – when constructing project plans, I’ve come to realise how much I did actually rely on the Gantt Chart to help eliminate errors in my scheduling, and to quickly see the implications of alternate scheduling, risks and delays.

When reviewing a complex project plan to see if I’d made errors in scheduling, or understanding project relationships, or if I’d just missed lots of stuff out – it was the Gantt Chart that would most quickly let me know if I’d stuffed up. Breaks in the flow, a critical path that just stops (before the end of the project), tasks that just look too long or too short compared to the tasks around them – all rapid visual indicators that something’s not right.

It get’s really hard and boring to read through a long list of tasks, and even more difficult to understand the relationships between tasks in this format. This is where the Gantt Chart comes into it’s own. Relationships between tasks and groups of tasks are immediately apparent. Tasks that are on the critical path are obvious.

This really struck a chord with me. I manage projects with Basecamp, a system that doesn’t provide Gantt charts. Leisa has made me realise how much I am missing out on.

Footnote:

After reading Leisa’s article I signed up to GoPlan, a Basecamp alternative. I’ll post a review here soon.

I highly recommend this article over at Dave Pollard’s How To Save The World blog: I Don’t Think You Get My Point: The 5 Hurdles to Effective Communication

37 Signals have just posted an interesting article about having confidence in People, Process and Purpose

There is much that I agree with in this post, but some things that I am not so sure about.

Some companies try to manufacture confidence. They use specs, documents, and process as things to lean on. These crutches give them a false confidence that nothing will go terribly wrong.

The problem is when you build confidence with documents and all that, you are nailing yourself down to assumptions that are probably wrong (assumptions always seem to fall by the wayside once things get real). Yeah, you may feel better that you have a recipe written down. But if it’s a recipe for failure, what’s the point?

While it is certainly possible for documentation to provide a crutch that provides only false confidence, I don’t think that this is sufficient reason to abandon documentation entirely.

I think that there is a great deal of merit in doing the right documentation and then using the documents properly.

My philosophy is simple:

• At the start of a project, do the right amount of documentation. No more, no less. (It is entirely up to you what you think the “right amount” is – it is your project).

• Use this documentation as a starting point, not as a cast-in-stone blueprint that must always be obeyed.

Always try to remember the desired end-result of your project. If deviating from what is written in the documentation will produce a better website / application / whatever, go ahead and deviate from the documentation.

If you think that you can do things faster and better by abandoning documentation altogether, by all means go ahead and do that. This approach does not usually work for me, but it works for 37 Signals.