Plans are worthless, but planning is everything.
There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of ’emergency’ is that it is unexpected, therefore it is not going to happen the way you are planning. – Dwight D. Eisenhower

Swap in “project” for “emergency” and Eisenhower’s statement is equally as true. Yes, projects are as unexpected as emergencies. If all the variable of a project were known ahead of time – processes, timeframes, resources – the project would already be complete. Projects are in fact the process for answering these questions.

When I was working for a WiFi startup a couple years back, my product manager spent a good chunk of his days in Microsoft Project. Every day, he would tweak the Gantt charts to reflect the current state of the project, and print out the revised plan.

Then as the plan came off the printer, some new information would arrive making the new plan obsolete.

Lately, I’ve been involved in a number of enterprise software projects all at the early planning stages. Project 1 is starting with a Gantt chart. Like all Gantt charts, it depicts a tiered, linear, hand-off process. This is inherently ineffective.

A more effective, collaborative, and true-to-life model is a weave [WorkingPathways_ProjectWeave.pdf]. The pdf illustrates the weave model I helped a design agency work towards.

Another effective planning model comes from Frank Patrick and has traction in the Agile Software development community: the Hurricane model for predicting uncertain futures. The crux – we know where the project is now and some notion of time it takes to get in any direction, but we don’t know exactly where the project will be at that time. That’s the classic quantum mechanics trade-off: you can measure velocity or precision. Not both.

The most effectively run projects I’ve observed are based 2 principles;

• Slack:Project schedules should have 2 forms of slack built in – 1 day per week and 1 week per month. Only schedule work for 80% of the available time. That’ll keep the schedule flexible enough to adjust for all the unknowns you’ll discover along the way.
  Read more on slack in the excellent book Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency
• Keep a loose association between work and resources:
  Define the pile of work and define the members of the team. Don’t define it in any more detail than that.

I think Steve Pavlina sums it up nicely:

“No plan survives contact with the real world.”