The Five Phases of Project Planning - Principles

I intend to discuss in a later post how I use Things, but I wanted to take a quick moment to discuss how I manage my projects.

When I create a project, I follow the five phases of project planning. In particular, I like to document the purpose and principles for every project I put into Things. In the beginning, my purposes were pretty lame. It’s very easy to fall into the trap of restating the project’s outcome in other words. However, with a bit of practice, it becomes second nature to put why I’m doing a particular project. I find it a valuable reminder, and if I can’t even do that, I should ask myself whether the project is well enough defined. However, I have struggled with writing good principles for a while. They often seemed self-evident.

The way David Allen portrays principles in Getting Things Done is as constraints on the outcome. He writes in the second edition, “A great way to think about what your principles are is to complete this sentence: ‘I would give others totally free rein to do this as long as they …‘ As long as they what? Whath policies, stated or unstated, will apply to your group’s activities? ‘As long as they stayed within budget‘? ‘satisfied the client’? ‘ensured a healthy team’? ‘promoted a positive image’?” I don’t find this advice particularly helpful.

At work, I recently started reading a book on writing user stories: User Stories Applied: For Agile Software Development by Mike Cohn. I’m going to be pushing my team and our developers to more fully embrace Agile development and writing good user stories, so I wanted to do a bit of reading. While there are differences between the two methods, particularly since they have different purposes, there are similarities between Agile and GTD. One the things I learned from that book was that part of writing a good user story includes the acceptance criteria, often writing it before the project begins. For those who aren’t familiar with software development, acceptance criteria are the things the software needs to do before the user or customer will accept it. Hmm, this is familiar: acceptance criteria is to a user story as principles are to a project (in GTD).

Before this realization, my principles tended to be very vague. I wasn’t getting everything out and documented that needed to be. It would be like writing “Pizza” when I should have meant to write “Call Hound Dogs to order a pizza for the gaming group on Saturday”. Now that I’m writing my principles like they were acceptance criteria, I feel much more comfortable with the idea that I could (theoretically) hand my projects off to someone else and still get a good outcome. Even if I don’t plan on doing that regularly, it shall serve a reminder of what I am actually trying to accomplish, and it’s in my trusted system rather than in my head creating distractions.