It sounds to me like you may have an unnecessarily, or even counterproductively, tight linkage between your files and other support material, and your GTD system. Your GTD project and next action lists are not normally stored with your project support material. And your project support material doesn't have to be organized in the same way that your GTD project and next action lists are.Originally Posted by suzanne1
Of course, you _can_ have a folder specifically for a project, but you don't necessarily have to, and you don't have to have all of that project's "stuff" in that folder. You may just have a pointer to various materials that may be stored in various places. And even if you have a project folder, that project's Next Action is in your GTD lists, not hidden in that folder.
For example, when I get an email that causes the creation of an action or project, I don't store that email with the action or project - I just store a quick note that tells me where to find it. ("Project: Resolve Widget bug report. Details in email from John Smith, 12/10/09") Then I archive the email with the gazillion other "handled" emails, where "handled" means that I've inserted any needed projects or actions into my system. I'll go back to the email, but I never have to scan through my emails - my GTD system will tell me when to go look for a specific item.
If the "resolve Widget bug report" project got big and ugly, I might make a folder for it and plug relevant materials out of my usual storage locations, but that folder still wouldn't contain my action list. It would contain the bug reports, code tests, and so on.
> * For colleagues I have to regularly talk about some items, I
> have 'project' folders by name (for notes of things I want to
> talk to with then) + a list in my notebook. But I wonder if that
> are projects according to GTD. Because usually a project, you can
> finish it in about a year. But talking to my colleagues never
> ends.
It sounds like these folders would be more tightly linked to a Context than to a Project. The colleague is a resource that you may need for many different projects, which makes a conversation with the colleague into a context. Or an Agenda, which is a type of context.
However, again, the folder is just support material, and it doesn't need to be tightly linked to either a context or a project. It's information that you're choosing to file based on who you got the information from or who you're giving it to, rather than based on the subject of the information. You could choose to chop it up and file it by topic, or you might be perfectly happy sorting it the way you do now.
> * Also I have a lot of other projects that are never finished,
> such as meetings where we come toghether on a regular basis. I
> have a 'project' folder for each meeting (things to discuss) and
> a reference folder for things to keep but don't need to do
> actions on it. But this also isn't a project, is it?
It seems to me that the meeting could be a context, could be involved in one or more projects, or both. When the meeting serves as a source of information and decisionmaking, the meeting is a resource, therefore a context. So, "Submit image editing software purchase request to Board for approval." is a Next Action that has the Board meeting as its context.
When you have to prepare for that meeting, those preparation tasks are a project. So I'd say that "Prepare image editing software purchase request for January Board meeting" is either a project or an action (depending on how quick and straightforward it is to do) that does have an end date. Or it might be part of a "Prepare for January Board meeting" project, that has an end date.
In either case, you can have a "Board support material" folder, to store the stuff for the board meeting. Having the folder doesn't make the Board a project, it's just your chosen filing category. Alternatively, you may have an "Image editing software acquisition" folder to keep the support material in.
> For example, now I have projects like: 'drugs' (= working about
> drugs in the institution in which I work), 'Frank' (things to
> discuss with Frank), 'strengts-based' (working more
> strengts-based), 'formation' (formation of the empoyees), the
> year planning of the institution, 'office' (learning more about
> office), motivation (working with employees about motivational
> theories),... But when these are just goals, what to do then with
> all the notes about these things? Now it is well organised in
> project folders, but some of the things are not a project yet.
> Where to keep all that stuff then?
> I don't feel like having another alphabetical system for that
> stuff.
I'd say that all those folders are just your files, and if you can find the stuff, they're sorted just fine - they don't need to line up with the projects. The GTD part is recording and tracking the projects and tasks in lists, separate from the folders.
And I'd say that, yes, all of those are either areas of focus (drugs, strengths-based, formation, office, etc.) or contexts (Frank). A project should be something that you can state as a definite goal that can be completed, such as "Project: Design a format for motivational meetings with employees" or "Project: Obtain certification in the use of MS Office." The area of focus will go on, possibly forever, but these specific projects will be completed.
Not all of my projects are neatly defined bodies of work with a completion date, but I try hard to make them that way.
> What is the advice about the project list: do you better split it
> into 'projects for later', 'active projects',...? But I like
> having all the project folders together in one alphabetical
> system, and not splitting then by active or not. How do you do
> that? What seems the best practice about all this.
Again, there's no need to split your support material to match the split of your GTD system. The piece of paper that lists your project names may be split into "Later", "Active", and so on, but your file cabinet doesn't need to care.
Gardener
Reply With Quote
Bookmarks