Like many people I’ve never made it all the way through David Allen’s popular book Getting Things Done. One of the most valuable take-aways I did get from Allen’s system was getting really clear on what the “next step” is for a particular project. In fact I think It’s the most lasting take-away I got from the book.
As simple as it might sound, determining the next step is an extremely useful quest as a project manager. It’s easy for a team or yourself to get overwhelmed by all that there is to do on a project, but the reality is that usually you can only do one thing at a time anyway. So getting clear on what that next thing or things that needs to be done is, and writing it down pays off big time–particularly in today’s world of constant context switching and interruptions.
I’ve never been a fan or user of complicated Microsoft Project schedules or Gantt charts. I managed some of my biggest project at Red Hat using a simple shared text document and maintaining a simple schedule by hand. Ocassionally there were important dependencies to call out and coordinate, but a majority of the time it was weekly project meetings, making sure the “next step” or “steps” from last week’s meeting were done and getting clear on the “next steps” to be completed before the next meeting.
Don’t get me wrong. Scheduling tools can come in handy when you have a lot of dates with hard dependencies. Then by changing one date you can automatically calculate how far out your launch date is. Although that’s often met with mixed results because a lot of projects have to launch by a certain day, no matter what, at which point the hours spent configuring the fancy schedule to calculate dates automatically goes out the window while everyone buckles down to figure it out manually.
I don’t think I’ve ever ended a project wishing I’d spent more time tuning the schedule in a tool. The most successful projects I ran always came down to consistent execution and knowing exactly what we needed to do next.
Leave a Reply