Project Support versus Reference

I noticed that some of my Project Support Files for big ongoing projects that take long time to complete become more like Reference files, and I end up not knowing where to look for what. I need some clear-cut criteria to distinguish those two.:-?
Thanks
 
write up your own or maybe these guidelines might apply

I think it is more of a continuum and you divide it according to your needs and space. You might try to make your divisions explicit but describing your "divisions and domains".

Here are some ideas that sorta work for me. I am always looking to improve so any suggestions and hacks are welcome.

Reference:
reference archives-stuff you keep but dip into or to add to infrequently.

reference "at the ready": you need to add to or take out often for routine work but you won't be done with it ...ever... until.. new tables, editions, reference sheets, etc. are created.

Project Support:
shorterm project and/or small volume of paper, easily fits with other projects in your active area.

longterm project but doesn't take up a lot of space. As above.

longterm project that takes up a lot of space--needs its own cabinet or drawer.

I think the main factors are the nature of your work and responsibilities (do you need to get into your stuff fast) and the "geography" you have to work with and your personal preferences.
 
gery;83031 said:
I noticed that some of my Project Support Files for big ongoing projects that take long time to complete become more like Reference files, and I end up not knowing where to look for what. I need some clear-cut criteria to distinguish those two.:-?
Thanks

Not sure I understand, Do you store Reference Files in a separate location from Project Support Files?

I deal with filing by having only 1 place to go.

The physical folders for reference and all my project support for someday/maybe or on-hold projects are in my one alphabetical filing system, currently comprising three 4 drawer file cabinets and half a 2 drawer file cabinet. So if it's not a current active project file then it's in here.

All physical folders for current active projects I am working on right now are stored in the top drawer of the 2 drawer cabinet along with my tickler file.

When I do my weekly review I put any folders for projects I am not going to work on for a while into the main filing system and I pull any folders for projects I am starting to work on. It's not uncommon for me to move 5-10 folders back or forth each weekly review.

The advantage is that when I am working if it's a current active project it's next to my tickler and if it's not a current active project then it's in the main filing system.

For huge projects that have become too large for single physical folders I will archive into the main system pieces by sorting the file into logical groups. For some it's by date (files older than X years) for example. For some it's by subproject or section.

Often if the Project support gets beyond about 3 inches of paper it's a sign I really have more than one project there. I will then pull that folder and take the time to really evaluate whether I have properly thought out the entire thing and will split the folder once I have split the multiple projects out. I often find that the huge folder really contains project support for 4-5 separate projects and that at least some of them are really actually completed so I can pull that data into reference if I think I will need it eventually.
 
Sorry for not specifying

Maybe I'm wrong, but I thought that the beauty of GTD is about clear edges. And my question is not about physical aspect of files, but rather about the concept. I liked the idea that all my stuff is stored either as (1) Reference which is something that needs to be accessed only when I need it, and should be categorized the way that I can easily find it, (2) Project Support, and (3) Maybe/Some Day which should be set up in the way that will force me to review it at some point in the future.

I like the simplicity of that threefold division of the stuff that is not in an direct use: Reference, Project Support , and Maybe/Some Day.

However, as clear as Reference and Maybe/Some Day distinction is, the criteria to assign something to Project Support gets a little fuzzier, and I would like it to make it clearer, so I don't have to waste my time looking for stuff in two different places instead of just one.

I hope it makes sense,
Thanks for your responses,
Gery
 
Reference support files

Hi,
I also stumbled across that division.

In my opinion reference support material is everything, that is an active project, reference is everything that was a project and might be useful in the future.

To make this more practical: project support is what you would take with you, to work on your projects. Reference is staying at home and waiting until you really need it.

So in my case as a doctor, project support is the patients records and my treatment planning sheets.
After the treatment is done, all goes to reference.

Typical invoicing schemes, lab prices etc are staying in reference.

Hope this explanation is helpful
 
Some Thoughts...

Do your projects have clear outcomes? If so, then what materials do you need to actively support that project? Once the project is completed then you could move the materials you choose to keep to reference. Can you share an example of a project tha's challenging so as a group we can work through ideas?l
 
gery;83038 said:
I like the simplicity of that threefold division of the stuff that is not in an direct use: Reference, Project Support , and Maybe/Some Day.

However, as clear as Reference and Maybe/Some Day distinction is, the criteria to assign something to Project Support gets a little fuzzier, and I would like it to make it clearer, so I don't have to waste my time looking for stuff in two different places instead of just one.

You said it yourself, it's threefold. Project support is whatever additional info and material you may need for current active being worked on projects. The same bits of information or the same folder of papers might and probably will, move back and forth between project support, someday/maybe and reference as the project gets done.

Project support should be everything you need to work on an active project. So Project support is actually in direct use.

Here's an example from my recent lists:

I have a recurring project to plan the sheep matings for the year. Early actions were to decide which ewes to keep and breed vs butcher. This is nearly done I'm down to 61 ewes to breed and I need to cull out a further 4-5. I also had an action to determine which rams I can use for both the AI experiment and live cover. The AI list required some feedback from the gene bank as to the motility, quality and number of doses of semen in storage as we can't deplete the gene bank running the experiment. I have several files of reference material about this, Sheep Breeding EPDs (contains articles on calculating EPDs for various traits), NAGP Semen Inventory (details of all the stored semen, motility reports, number of doses and more technical data), Sheep Pedigrees (5 generation pedigree data on all the ewes and all the rams living or dead we might use). Those files were all in Reference until just recently when I pulled them all as Project Support Material. To that I added a new file Sheep Breeding Experiment 2010. In here I've been collecting some drawings of the ram teaser pen we need to build, a list of all the ewes we will breed and their lambing history and other notes as I make them. I am keeping all these files in the top drawer of my 2 drawer file cabinet where I keep Project Support Material as I am actively working on this now.

When I work on this project I will take all of my project support files out and sit down and do a floor sort of ewes with rams for best genetic results as that is my next action which is documented on my inside by myself context list. I will be creating a list of which ewe will be bred to which ram, whether via frozen semen, fresh cooled or live cover. That data will be sent to the researcher for review and a copy will go into the Sheep Breeding 2010 file.

I'll then move on to the physical actions, build the teaser pen, decide which ram will be the teaser and so on. At some point, soon I hope, I'll have all this prep work done and all those files will move back into my reference/someday maybe filing system as the project will be in wait status until the time is right to do the matings. So my Plan Sheep Matings project will be on hold and all the support and reference material will be back in my file cabinet.

I will be reviewing it as a someday/maybe item each week at review time. In December when the researcher is here we'll set up the semen lab, and start the actual experiment. When I make the project active again I'll pull out all the pedigree files, EPD files, Breeding Plans and so on and have them ready. From experience due to poor motility during collection, weather, which ewes are in heat and more variables I can't control I have to be able to make changes to the plans on the fly each night after that days' experiment results.

In fact just writing this made me realize that I need to pull the file with motility and collection data from last year on the rams I still have so I can make educated guesses about whether we will be successful collecting semen from them this year as that might affect my mating decisions for fresh cooled semen now.

So during the course of this project getting done I will be creating and using files that are reference when not in use, project support when in use and someday/maybe while on hold.

Does that help any?
 
Top