Why do we need a projects list?

P

Paul@Pittsburgh

0
I have been thinking on this for a while now - but I was wondering how others see this.

If we have identified our next actions for each project and arranged them by context - then why do we need to keep a list of open projects? Surely the sum of our context lists would be a complete list of open projects anyway.

I have been wondering on this because I am essentially one person running a North American office for our business - I do sales, customer care, support etc.

Frequently I can have an on-going issue with a customer either be it sales or support related.

In my Outlook set up, I have a folder for each customer (identified by a unique short name) so I can archive their email and see a history for handy reference.

But what I also started to do as I implemented GTD was set up an @actions folder and an @waiting folder. I would then drag emails to be actioned in to @actions first, then when I dealt with it, I put it in @waiting if it needed a response.

However after a while, my @actions have too many separate projects and emails going on. E.g. customer A has emails interspersed by many other emails that all need actioning. And before I can close the action or project for customer A I may need to refer back to some of the other emails that I may have just corresponded with them - hope this makes sense.

The problem ended up that I had emails relevant to say Customer A, in their own archive folder, in @actions and maybe even @waiting as well as Sent! Messy.

So my solution is to now just maintain one folder for each customer. As an actionable email comes in - I still put the message in that folder, but I also note on my @computer list that I have to deal with this query. I am also copying all my relevant sent messages into this folder too. So there is a total history available.

My issue then becomes - I am storing up next actions and on-going projects in what is essentially reference material rather than a project support file. So is there a downside I have not spotted yet.

And if this is OK. Then why can't we do this with paper too? It seems to me that as long as our lists are kept up to date, nothing should fall through the cracks and I didn't think that was the idea of the project support files anyway.

Any thoughts from others?

Paul
 
My thoughts are that we need the project lists to help us keep a project moving forward. When I do my weekly review I look at my Next Actions sorted by project. I can easily see any projects that don't have a next action. This is important. If all you have is a list of next actions by context (without any link to a project), how will you know that a project is not moving forward?
 
Hi Mike

Usually my projects all have next actions defined (by context) unless they are on my someday/maybe list. So I wouldn't end up in a scenario where I had a live project without a next action. I have set up a category in fact just this evening called @Decision where I may need to think on an issue before deciding the next action - I will be using this sparingly, but an example of this is deciding whether to respond to a journal to run a set of ads - I don't need a computer, phone and can do it anywhere... but I just need some quiet time and I don't have an @anywhere context (maybe I should).

In a case where I complete one action and the project is not complete, I would define the next action by context to keep it going forward.

For some more complex projects where there are multiple actions that can be defined (and maybe even actioned at the same time) I would set up a support file for that project to list the actions for the future that are not currently on my next action lists) - OK so maybe they should be on a project list - is that what you are saying. Nonetheless - unless they are on my next action lists, these actions are still someday/maybe's aren't they. I just need to review these as part of my weekly review.

Maybe I am not getting something, so I will try and use a couple of examples.

In the first case - I may have a prospect. My outcome is to secure a sale. My first next action could be issue quote. I will then transfer this project to @waiting. Once I get a reply, I could call the prospect to discuss @phone, or issue another email @computer. When the order comes in I need to process it. So this is switching from one context to another. Sure I could have on a project list - Outcome = secure sale for XYZ, but it would seem self evident anyway. This is one case where I could see some benefit in having a project list.

In another case - I get a support query from a customer. The issue is can I help them with their problem. Usually there are only one or two steps in this case. Solve problem and report back to customer. Or maybe a first step is to clarify the problem with the customer. Again, it seems overkill to put this on one project list and then put the action(s) on another list.

What am I missing?

Thanks

Paul
 
I think the big reason to have the projects list is that it prevents you, at least once per week, from NOT having a next action for that project.

Sure, you could remember to always define the next action as soon as you complete one. But what if, for some reason, you didn't? What if, right as you complete one next action, someone calls with an emergency? Your mind is now totally unfocused on the project you just did a next action for - you may well remember that the project is missing a next action. But if you have 100 projects, can you trust yourself to always remember that?

I think of the projects list as a safety net. I will only look at it a couple of times during the week, and even if I don't, I know I will be looking at it during the weekly review. Even though it has no "real time" usefulness, it affords greater peace of mind because you know that no project can grow stale for more than a week (unless you choose to relegate it to someday/maybe).
 
While I agree with Murt's observation, I think that there is also a bit of psychology at work here. If the method is that you always write the next action as soon as you leave off a project, then knowing that you don't have a separate projects list may force consistent use of the method. Of course, if the method includes immediate deletion of the NA when done, there is no safety net to avoid losing the project. Marking things done and keeping them around until the next NA is written, whether that's done immediately or at the next weekly review, is my preference.

Andrew
 
I agree 100% with Murt. While we *THINK* we won't forget a project, if we don't have a project list, forgetting the project becomes an option while having a project list makes it NOT an option. By having a project list, it can be reviewed and it can easily be seen that there are no next actions under that project, thereby causing us to add a next action and get that project moving again. By avoiding a project list I think we are keeping the projects on our mind rather than in a list so we can get them OUT OF our mind (which is the goal of GTD). If you don't have a project list how are you going to be 100% certain that you didn't forget something?
 
While I agree totally with what everyone has said about needing a stake in the ground to remind you that you have an open loop, there is also another reason. Once you see a good list of all your projects you will find that you are much more selective about the new projects that you take on. You'll find yourself adding more things on your someday/maybe list and you will find yourself saying "no" much more often. Without a complete list of your projects you will continue to take on more than you can handle because you don't realize you full you already are.
 
Thanks for the feedback everyone.

Although I don't think anyone specifically mentioned this - the act of discussing this with others has made me realize that not all actions have to be listed as a corresponding project. In other words if I just have a one-action activity, then this can go directly to the corresponding next action list. It's only the bigger projects that need to be listed on the project list.

The other point that this has made me reflect on much more, is that my projects tend to be defined right now in the list I have made pretty much by their actions rather than their ultimate outcome. This is something that I will change for sure - think ahead about the actual outcome and purpose of the project in the first place. This ties in nicely then with the RPM system that I also use from Tony Robbins.

Cheers

Paul
 
Any action that has more than one action qualifies for a project. Not only the bigger projects.

I strongly suggest that one should actually go through the process of creating a project list and defining at least one next action for each project. In the process we will come across projects that can be accomplished very easily and projects that will seem daunting. I tried this process and it took me a whole 20 hours to set up this seemingly simple list. But the fact that I have a complete inventory of my projects gives me a top-of-the-world feeling.

Defining the next action for many projects is only a small step. But we would have to do a partial to complete informal project planning for some of the projects. That is 1. Defining purpose & principles 2. Outcome visioning 3. Brainstorming 4. Organizing & 5. Identifying next actions.

Some of the projects will be heavily loaded towards some of the steps. Not all steps are equally weighted for all projects.

For each of the heavy projects you may have to set apart upto 3 hrs and start the informal planning and that may help you get a clear picture and help define multiple next action steps.

Another problem I had was with (now with that I am giving away how absent minded I am) relating next actions to specific projects. What I have done is (based on someone's suggestion in the GTD forum) to assign a number to each project (say 1001-Finalize trip to Tokyo) and the number always goes with any NA associated with the project. With this, apart from knowing which project this action relates to, I also know at any time what are the actions that are pending related to this project (by doing a numeric search for '1001' in my Treo 600).

I think making a comprehensive projects list is as important as the Weekly Review, 2 minute rule, Next Action list, etc; if our objective is to have 'mind-like-water'.

Ashok
 
Re my earlier post, I don't want to leave the impression that I agree that there shouldn't be a projects list. I was assuming that the poster had a system for handling current projects that was already working for him and I was making an observation about consistency. I think there is a problem with hybrid approaches where you can easily fall between two stools and not be consistent with one method or the other. But from a planning perspective, I favor having a full inventory of projects - current and future.

Andrew
 
You must log in or register to reply here.
Top