Friday
Oct312008
Simple project planning for individuals: A round-up
Friday, October 31, 2008 at 8:07AM
This is my one of my favorite kinds of posts:
And as you know, I love pulling these kinds of things together. (Side note: What if every action you took during the day accomplished multiple objectives like this? We need a name different from "killing two birds..." Anything pithy [1] come to mind?)
I'll do two things. First, I'll present the common elements of (i.e., my take on) the approaches I looked at. Second, I'll provide my lightly-edited notes from the sources, for those who are interested. There are some good ideas there.
Questions I'd love to hear your answers to:
Enjoy!
Here's my quick take on what they all have in common:
(Gosh, seems anti-climatic after hours of research. Actually, that's probably a good sign.)
Here are the books (and one site) I looked at:
David Allen's Getting Things Done has a widely-covered planning model. His description of how our minds naturally do this is crisp:
Here are the steps:
As usual, Mind Tools has a solid section on Project Management Techniques, Scheduling simple projects in our case. Simple projects (those involving a few people over a short time with few inter-dependent tasks) often require only timetables and action plans to coordinate and implement them. They suggest creating a workback schedule, starting from the project's completion date and listing all tasks in reverse order with due dates. Use these control points (with deliveries) to monitor the project's progress and take appropriate remedial action. The action plan is a project-specific list of all of tasks (in order) needed to achieve the objective. They have a related section on time estimates, something common to other methods.
The "Managing projects effectively" chapter of Organize Your Work Day In No Time defines a project as "a planned undertaking," with the key being effective planning. Steps:
She has you use a simple form to track projects. For the project itself list: name, due date, and purpose. For its tasks list: name, due date, approximate time, budget, person assigned, resources, and news/updates. For sub-tasks list: name and due date.
Not unsurprisingly, Stephanie Winston has detailed advice in her The Organized Executive: A Program for Productivity, esp. from her chapter, "Project Mangement." The three case studies in particular are helpful in understanding how to apply the ideas to differently scoped projects.
Winston says project design and management requires seven steps, regardless of the task:
(Interestingly she mentions these rules apply to any project and originate from the PERT/CPM Navy Polaris project - see here, for example.)
In The Personal Efficiency Program (I've written about it elsewhere) Gleeson provides criteria for whether you need project planning (vs. back of the napkin):
The book has you plan using a mind map to:
The plan itself is a list of tasks with: estimated number of hours, people involved, target date, and actual completion date.
His process from chapter 6, "Planning," is what "turns goals into activities." He points out planning is generally pretty simple, but it's not easy. His process:
The "Making project completion easy" chapter of To Do Doing Done sketches out Snead's VPIC model:
Complex goals require planning backward. The problem with planning forward is that it focuses on actions. Planning backward focuses on results and provides structure to get the thing done in the right order and at the right time. It helps you keep momentum, even when you're not in the mood. Here are the four steps on how to plan backward:
- I've been asked for help by a client,
- I really want to know the answer, and
- I need to write a blog post!
And as you know, I love pulling these kinds of things together. (Side note: What if every action you took during the day accomplished multiple objectives like this? We need a name different from "killing two birds..." Anything pithy [1] come to mind?)
I'll do two things. First, I'll present the common elements of (i.e., my take on) the approaches I looked at. Second, I'll provide my lightly-edited notes from the sources, for those who are interested. There are some good ideas there.
Questions I'd love to hear your answers to:
- What's omitted here?
- What's superfluous?
- What approach do you use?
- How is it different from these?
- What's the largest project you've planned out?
- How much planning do most of your projects take?
- How do you guarantee learning from projects?
- How does your work integrate with others, including sophisticated project management software?
- Has anyone read Managing Multiple Projects? It's at the top of my Candidates Library, but I haven't read it yet. Thoughts?
Enjoy!
Common elements
Here's my quick take on what they all have in common:
- Decide purpose/objective: Write a list of specific goals and deadlines. What are we trying to accomplish, and why.
- Brainstorm all activities needed to accomplish the objectives, factoring in constraints, obstacles, etc.
- Organize and break down into categories, tasks, and subtasks. Who will do what specifically by when?
- Estimate task durations [2] and work backward from deadlines to create a progression (sequential or parallel) and timetable, including check-points/milestones.
- Execute the project using individual tasks and calendar, monitor using tracking sheets/software, and adjust as you learn!
(Gosh, seems anti-climatic after hours of research. Actually, that's probably a good sign.)
Sources
Here are the books (and one site) I looked at:
- Getting Things Done
- Mind Tools' Project Management Techniques
- Organize your work day in no time
- The organized executive
- The personal efficiency program
- Seize the Day!
- To do doing done!
- The 25 Best Time Management Tools & Techniques
From "Getting Things Done"
David Allen's Getting Things Done has a widely-covered planning model. His description of how our minds naturally do this is crisp:
These five phases of project planning occur naturally for everything you accomplish during the day. You have an urge to make something happen; you image the outcome; you generate ideas that might be relevant; you sort those into a structure; and you define a physical activity that would begin to make it a reality. And you do all of that naturally, without giving it much thought.
Here are the steps:
- Defining purpose and principles (principles: boundaries of your plan) - "Why"
- Outcome visioning - "What"
- Brainstorming - start of "How"
- Organizing (components/subprojects, priorities, and/or sequences of events) - more "How"
- Identifying next actions - final "How"
From Mind Tools' "Project Management Techniques"
As usual, Mind Tools has a solid section on Project Management Techniques, Scheduling simple projects in our case. Simple projects (those involving a few people over a short time with few inter-dependent tasks) often require only timetables and action plans to coordinate and implement them. They suggest creating a workback schedule, starting from the project's completion date and listing all tasks in reverse order with due dates. Use these control points (with deliveries) to monitor the project's progress and take appropriate remedial action. The action plan is a project-specific list of all of tasks (in order) needed to achieve the objective. They have a related section on time estimates, something common to other methods.
From "Organize your work day in no time"
The "Managing projects effectively" chapter of Organize Your Work Day In No Time defines a project as "a planned undertaking," with the key being effective planning. Steps:
- Determine objective and purpose
- Create a consolidated bulleted list of goals
- List all action steps. McCorry lists many ways to accomplish this, ones both informal and formal.
- Don't omit the final steps, e.g., write final reports, send thank you notes, process bills/invoices, etc.
- If necessary, sub-divide major components so that each task takes less than 4 hours (say) to complete.
- estimate time and due dates for each action step to establish a sequence.
- Determine exact/optimal due date for entire project.
- Estimate approximate/optimal deadline date for each action item within the overall project time-frame (backward planning)
- Calculate a total time needed each week to get the project completed on time, and build in "margin" time.
- Determine exact/optimal due date for entire project.
She has you use a simple form to track projects. For the project itself list: name, due date, and purpose. For its tasks list: name, due date, approximate time, budget, person assigned, resources, and news/updates. For sub-tasks list: name and due date.
From "The organized executive"
Not unsurprisingly, Stephanie Winston has detailed advice in her The Organized Executive: A Program for Productivity, esp. from her chapter, "Project Mangement." The three case studies in particular are helpful in understanding how to apply the ideas to differently scoped projects.
Winston says project design and management requires seven steps, regardless of the task:
- Set a specific goal. What is your purpose? Make it a concrete (e.g., numerical) objective.
- Set a final deadline.
- Break project down into subtasks, and group related subtasks into working blocks.
- Organize subtasks into an appropriate progression, either a sequential line of development (tasks handled one at a time) or a parallel line of development (tasks handled simultaneously). For the latter, begin the project by selecting two or three core tasks from each block.
- Set subdeadlines for individual tasks and steps. Establish periodic benchmarks for the evaluation of overall progress.
- Delegate specific tasks or groups to subordinates and/or outside consultants. Add your own tasks to your Master List [3], feeding them into your Daily List as appropriate.
- Monitor less complex tasks with calendar, tickler files, and referral folders. For more intricate projects, use a task sheet or tasks-by-levels analysis.
(Interestingly she mentions these rules apply to any project and originate from the PERT/CPM Navy Polaris project - see here, for example.)
From "The personal efficiency program"
In The Personal Efficiency Program (I've written about it elsewhere) Gleeson provides criteria for whether you need project planning (vs. back of the napkin):
- It is complex.
- It seems difficult.
- It involves several staff.
- It is a new activity.
- There are critical deadlines.
- You are coping with changes.
The book has you plan using a mind map to:
- Brainstorm about all elements of the task,
- Identify the critical elements to success,
- Group ideas into categories,
- Incorporate these into an implementation plan.
The plan itself is a list of tasks with: estimated number of hours, people involved, target date, and actual completion date.
From "Seize the Day!"
His process from chapter 6, "Planning," is what "turns goals into activities." He points out planning is generally pretty simple, but it's not easy. His process:
- Write out the goal, as clearly and specifically as you can.
- Brainstorm to come up with the required activities to achieve it. Write as many as you can think of that bring you closer to the goal. Don't worry about the quality or possibility of each one; write as many as possible in the shortest time.
- Break down activities into sub-activities if large, then eliminate unimportant or redundant ones.
- Break down activities as much as possible into months, weeks and days. Sometimes hours and minutes. He says to be flexible in how much detail you plan out. "Use only enough structure to get the job done."
- Finally, come up with a daily schedule of prioritized activities (your to-do list).
From "To do doing done!"
The "Making project completion easy" chapter of To Do Doing Done sketches out Snead's VPIC model:
- Visualize (create a project vision statement). What does it look like when it's done? Why are we doing it? Output: overall objective. SMART (Specific, Measurable, Achievable, Relevant, Time-dimensioned)
- Plan (break project into manageable pieces). How will we achieve the objective? Who will do what tasks? When and where will they do them? How much will the project cost? Output: manageable pieces. Here seven-step planning model:
- Constraints. Universal ones: quality, schedule, resources.
- Hot spots.
- Hunks (major pieces), chunks (minor pieces), and bites (tasks - verbs).
- Forms (enter sequenced tasks onto forms - parallel and dependent tasks).
- Who.
- When (can plan forward if no deadline is set, or backward o/w).
- Cost.
- Constraints. Universal ones: quality, schedule, resources.
- Implement (monitor and control - communicate, delegate, document). Communication, coordination, monitoring, and controlling needed to keep the project on track toward successful completion. includes adjustments
- Close (evaluate the project). Tie up loose ends, compare outcome with intended results, celebrate/honor/reward. I like that she highlights it's an important learning opportunity. As she puts it, "Projects are almost always a learning experience."
From "The 25 Best Time Management Tools & Techniques"
Complex goals require planning backward. The problem with planning forward is that it focuses on actions. Planning backward focuses on results and provides structure to get the thing done in the right order and at the right time. It helps you keep momentum, even when you're not in the mood. Here are the four steps on how to plan backward:
- Pick one goal. If it's big, subdivide it into smaller goals. Pick the first one you need to achieve.
- List the mini goals or milestones you need to accomplish to achieve your goal by the deadline you've set.
- Draw a time line from left to right. Put the current date on the far left and your deadline on the far right. Insert each milestone with a date, starting from your deadline and working backward
- Once your milestones are in the right places, list underneath each one the actions you'll need to take to achieve them. Keep your plan handy and do what you planned.
References
- [1] I've been collecting great quotes and possibly-useful phrases for a while. I've also started trying to come up with my own pithy quotes, with my models being Benjamin Franklin, Dorothy Parker, and Mark Twain - a very high bar. So far the results are rather pithiless.
- [2] Are you often underestimating how long something will take? Me too. In fact, a client pointed out that apparently all of us have trouble. See Planning fallacy, esp. the paper "Exploring the planning fallacy: why people underestimate their task completion times":
This study tested 3 main hypotheses concerning people's predictions of task completion times: (a) People underestimate their own but not others' completion times, (b) people focus on plan-based scenarios rather than on relevant past experiences while generating their predictions, and (c) people's attributions diminish the relevance of past experiences.
Now why would that be, as a species, beneficial?
- [3] Her "Time and task management" chapter is interesting from a productivity implementation perspective. She has a single "Master List" notebook which acts as: capture, s/m, tasks, and projects. You review it daily, dividing projects into components, eliminating and delegating tasks, entering deferred tasks on calendar, immediate tasks on Daily List. Compile tomorrow's Daily List the night before - choose 10 tasks. Rank each 1/2/3 depending on priority and level of demand on you. <- ideamattblog: Many thoughts here - the mixture of uses, having to review, not separating projects and actions, etc. Fun! Related: Extreme GTD: How Low Can You Go (or: Can We 80-20 GTD?)
Reader Comments (16)
I'm a GTD man, but I have to say that the statement, "Complex goals require planning backward," is an extremely profound insight. I've found that the tasks on task lists have a tendency to break free of goals and outcomes and assert themselves as goals in and of themselves, and that's a tendency that requires mindful vigilance to prevent. I believe David Allen suggests asking the question, "what is the next action I have to take to move myself closer to the outcome I desire?" as a way of organizing specific tasks and general endeavors. If productivity is a measure of how much work one gets done, finding the most direct path toward an outcome has to be a central organizing principle. (An aside: when I first read this statement, I asked myself how different our task list in Iraq might have been if we had planned backwards from the goal of effectively implementing democracy and mediating the interests of competing groups.)
In my position, I concentrate on the tasks in a project so GTD is my tool. I have a Project Management Office with Project Managers that do the heavy lifting, but my task lists are still long.
For the big projects (50+ tasks) assigned to me over months of time, working backward from goal is essential. I do this right in my GTD, by assigning a due date for completion of the tasks needing completion by a certain milestone.
I've written several posts that provide details about my experiences with GTD and the applications I use on my blog at http://johnkendrick.wordpress.com/how-to-gtd/ John
Good points re: disconnect between action and objective. And you Iraq question made me thing. Much appreciated.
Pulling the tasks from a more sophisticated system is something I didn't address. It's in the "GTD-big-tool-integration" category, along with ticket and bug tracking systems. Thanks for your comment, and congrats on the recent GTD traffic success. Well done.
[jp in maryland again]
Hello Matt/co. : Good to talk to you all again. I'd like to contribute more to the GTD discussion (perhaps you could do a post on top ten Time Wasting activities e.g paperwork, meetings, lunch, etc.) but for the moment, Ive got a request for you:
1) I need help;
2) I need to know the answer; and
3) I need you to write a post in a forum.
It's a modest request to be sure, but I dont downplay the significance of sitting down and thinking about something especially from a non paying client.
I am arguing w/ my wargaming friends on a wargame forum, about planetary nebula and whether they could produce planets, and well yellow dwarf stars and such. They are a pretty intelligent group and my only knowledge is from wikipedia but what the hey.They say I am crazy, but I think I can make a case. (it's a well run forum, most members actually use real names, but not necessary)
ANyhow, I thought you might have some knowledge of physics in your background but I dont know if modern day astronauts are more scientific or more jet pilot types. Anyhow here is the page where it begins...
http://talk.consimworld.com/WebX?7@154.69GBeFQ4whO.14@.1dd127e1/3442
it's post 3417 but you only have to scroll down a little.
I realize this is a pain, but if you have a moment, give it a try.
Thanks. jp
I looked at the thread, but didn't see where a comment would help. I'm glad you asked, though.
I'd also recommend reviewing [ Scott Berkun`s project management book. | http://www.scottberkun.com/the-book-the-art-of-project-management/ ]
I found both his old book ( [ The Art of Project Management (Theory in Practice (O`Reilly)) | http://www.amazon.com/gp/product/0596007868?ie=UTF8&tag=masidbl-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596007868 ] ) plus the new one ( [ Making Things Happen: Mastering Project Management (Theory in Practice (O`Reilly)) | http://www.amazon.com/gp/product/0596517718?ie=UTF8&tag=masidbl-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596517718 ] ). Thanks for the pointer.
Brian Tracy has good stuff too, for example the books
"Goals" (tip: rewrite your goals daily so it magnetizes your mind with what you want to achieve) and
"Eat that frog" (tip: start your day with the few most critical activities)
I'll review his works ( see [ Some Thoughts On "Eat That Frog!" By Brian Tracy | http://matthewcornell.org/blog/2006/10/some-thoughts-on-eat-that-frog-by.html ] ).
I hope that your book related to mind map will really get some response. And let me tell you frankly that this post is really a very nice piece of writing.
Much appreciated.
Dear Matt,
Since you asked for feedback, here's how I stumbled onto your page. I have an assignment for college for Software Project Planning, and I need to complete a project plan complete with Gantt and PERT charts, etc.
My basic problem is how my professor defines 'abstract' and 'concrete', 'basic', and 'detailed'. I'll be using an old web design project as my theoretical example, but I have major difficulty in finding the correct level of abstractedness, and "granularity".
i.e. I don't know whether to type "review process implementation details with a series of client meetings", to type "Review Site design with client", "Agree on design", "redo pages until client is happy". One certainly seems to take longer than the others, and therefore could be written down as taking a couple of weeks - and you must remember that a significant amount of people are writing these plans for their boss/lecturer/customer, and need to show that not only is work is being undertaken, but that it's also OBVIOUS in the plan that such work will be done. i.e. Good Software does takes time, but it can be difficult to defend the actual time it takes.
So, that's my 2 cents. Thanks for the page, you've done a ton of work!
Cheers,
Emmet
Hi, Emmet.
Your s/w project sounds like fun. Regarding granularity, I'm not sure I completely understand the question. It sounds like you're asking how to decompose project elements into actionable steps. I generally recommend a hierarchical approach where you start with your top-level objectives then break them down. You'll know when you're at the bottom when someone familiar with the project can look at a task's description and understand it in 10 seconds. Also, they should then be able to perform the task in one sitting, say in an hour or less. Specifying these and attaching estimated time to do them should give you a sense of how your schedule will look. Again, there are two ways to handle deadlines. Either "casting forward" by adding times and seeing when you expect to finish, or by working backward from a fixed deadline and trying to fit it all in. Of course http://matthewcornell.org/search/node/parkinson">Parkinson's Law comes into play here :-)
Thanks for your comment.
Emmet,
I have recently published an article that will probably help you decomposing your tasks, [ decomposing the wbs into work packages | http://www.pmhut.com/decomposing-the-wbs-into-work-packages ], the article explains what is the maximum level of granularity you should be looking at.
I hope you'll find it helpful.
I had to lookup the WBS definition - "Work Breakdown Structure!" Sad that it's about work breaking down ;-) From [ Five Key Project Planning Tools | http://www.pmhut.com/five-key-project-planning-tools ]: