Comments on: Dynamic Planning

By: Axodys » Dynamic Planning

Axodys » Dynamic Planning — Sun, 14 Aug 2005 15:19:00 +0000

[...] I just came upon a nice article by Steve Pavlina about Dynamic Planning that I wanted to mention because it has a couple points about working on projects that I found very useful. The following part really rang true for me: My preference is to focus on a single project for as long as possible, doing a variety of actions in a row. Once I’ve loaded a project into my brain’s active RAM, I don’t like to unload it. Much efficiency is lost in the process of rebuilding awareness of a project. If I haven’t worked on a project for a while, it can take me anywhere from 15 minutes to several hours to fully reload the project into my brain — this is especially true for technical work or very large and complex projects. [...]

By: Steve Pavlina

Steve Pavlina — Fri, 17 Jun 2005 17:50:04 +0000

I’m familiar with Robbins’ Time of Your Life and OPA/RPM systems. I agree that it’s higher level than GTD, but IMO it neither starts high enough nor goes deep enough.

By: Alek

Alek — Fri, 17 Jun 2005 09:57:21 +0000

Steve, I highly recommend Anthony Robbins’ Time of your Life program. It makes GTD and Covey programs seem so generic in comparison. It mostly deal with the highest level, and the it goes down to the lower levels. It’s totally different than any other time-management systems.

By: Greg

Greg — Sat, 04 Jun 2005 16:28:15 +0000

One other comment on this is that I think it also depends greatly on the type of work you are doing as to how effective the GTD contexts are. A perfect example is someone in a sales environment vs. a software development environment. Where you are developing software and working a few major projects, it may be better working as you suggest in looking at project based NA’s to keep things moving along rather than jumping around different contexts. However, in a sales role (or something similar) you are often working on a large number of smaller efforts which require ongoing attention, so you may have a block of time when you are calling 10 different clients on 10-15 different projects, or sending out 5 emails all on different opportunities. So in the sales case, you aren’t doing serial project tasks so much as do a follow-up, then wait on something (a call back, and email, etc.), then another follow-up. There will of course always be large projects sprinkled in the middle, such as a large proposal to write, but I think you can see the differences.

By: Nathan Gabrish

Nathan Gabrish — Fri, 06 May 2005 15:52:37 +0000

The idea of dynamic planning as reffered to in this article seems similar to the concept of rolling-wave planning. Rolling wave planning is a schedule development technique where task detail is fleshed out as it enters a closer time horizon. I have read about different hard and fast rules for level of detail vs time horizon (for example phase level detail for work more than 3 months out) as well as detailing driven by project lifecycle (task level detail and phase level detail for the current and next phase and no detail for other phases. However like most PM techniques and tools you must know when and how to adapt the rules to your situation. It’s worth noting that schedule development may not be a neccesary component of smaller projects but I think the techinque is still relevant even if there isn’t a formal schedule.

By: Steve Pavlina

Steve Pavlina — Fri, 06 May 2005 12:58:41 +0000

The usefulness of dynamic planning for projects depends on the difficulty of accurately planning out the finished project in advance. For some projects the later planning work is much easier if earlier steps are already done. Sometimes your vision of the finished project will evolve based on how the earlier steps turn out. This is especially true for creative projects like designing a computer game. An iterative plan-do-evaluate cycle will usually produce better results than a waterfall lifecycle model where everything is planned in detail in advance.

I haven’t written any books yet, but I do have one in the works. I am working on it every day, but it is still months from completion.

By: Prosper

Prosper — Fri, 06 May 2005 12:47:50 +0000

Well I used to do this dynamic planning style though not entirely as described untill i met a friend and started working in teams. We often planned the whole project out down to the classes and the functions in them and then assign each class to each member of the team. This was very effective and we only had cause to go back when the was a better algorithm created in a function. Things are pretty straight and fast. I’m not very sure but i think i prefer a complete planning than dnamic. And I really don’t think i can cope with the ramdom action sytem described earlier.

One more thing Steve,
I enjoy your articles and they’ve been real real helpfull I read them from Dexterity.com and i really wan’t to take time out to let you know you are doing a very very good Job on personal Developemtn writings. Have you written any book?

Cheers.

By: Steve Pavlina

Steve Pavlina — Mon, 02 May 2005 23:39:21 +0000

I see what you’re saying, Christopher. It depends on what kind of web site you’re building. For the web consulting work my wife does, building a web site is often just a one-time project that has a clear beginning and ending, not a whole new area of responsibility. In this case of this web site, however, it would be an area of responsibility (or a subset of one) instead of a project because the work is always ongoing.

By: Christopher

Christopher — Mon, 02 May 2005 22:05:24 +0000

mh, larger projects, like ‘building a website’? Im my model this would not be a project. As I see it in this example, the ‘website’ is a plant (or unit/entity whatever). You then have a goal like for example ‘decent interface for my website’, that leads then to a project ‘build CSS-files for website”.
You have ‘units’ (like home, website, car, relationship, library and so on). The planets in your universe. Then you have wishes for how you want to change the status of these. Your goals. And finally (here we arrive in GTD) we assign projects to our goals. We act on the things to alter.

By: Scopulus

Scopulus — Sat, 30 Apr 2005 22:06:17 +0000

Good post!

GTD is not neccessarily a method for productivity as it is a methodology. What you describe is an adaptation to suit your needs.

I like GTD but , like you, have adapted it for my specific needs.

My projects usually require concentration and can be fairly complicated. I get my best, most thorough, and quickest work done when I am “on a roll”. This mental state requires concentration to achieve. However, I have people who have no problem whatsover interrupting me and dumping more stuff in my lap. It was often very frustrating when I’d get interruptions 3 tasks deep and totally lose what I was working on. (Call it ’stack overflow’)

My style of GTD works around this to allow me to make progress constantly.

For intents and purposes, at work, I have one Next-Actions List [context]. Some items on the list are created when I plan my day; some are created during the day as a response of actions; and, some are added in there as a result of everyday not-so-urgent emergencies my co-workers thow at me. I log these uninvited tasks to the list when I am interrupted and handle the issue quickly but usually not instantly. These tasks, I acknowledge that I’ll handle the issue shortly and then proceed to finish what I was working on..or at least get to a good stopping point. I make it a point to follow through with the person to make sure the issue has been handled or is being handled. In addition, when I am away from my desk, I carry something to collect new issues. (Being in I.S. always means people know what you do, never bother to learn your name {even when its printed on your hardhat, yes I’ve been called other people names}, and have no problems hijacking you for their purpose)

My Next-Actions List is ALWAYS visible at my desk at all times. (This communicates to passers-by that I am getting lots of things done and it might slightly discourage trivial interruptions - hopefully). I review it whenever I get or need a mental context switch. If I’m tired, I’ll know off the easy ones and be done with them. I keep this list to two pages (an open binder) and often signify related tasks so I can get “on a roll” as needed.

I also keep a Waiting-On and a To-Figure-Out list visible. As I have co-workers who often leave a request incomplete and don’t bother to communicate

Projects are not usually visible but are viewed at the beginning of the day or when a non-trivial task falls in my lap. I clean this list at the end of the week.

My Agendas list is occasionally used (but always private) as it is more or less a ’scratchpad’ for issues I transform into a Next-Action. I review this weekly.

I usually maintain the “To-Aquire” list for home projects only. (not for work)

Of course, my adaptation has developed as a direct result of my work-place demands and idiosyncrocies.

Cheers….