Breakdown of email in my GTD system

[kingfu]

To start off my current GTD set up is this. A pocket moleskine where I keep all my contexts, inbox and master project list + someday maybe. Google calendar and gmail with GTDinbox.

For my personal life this is working pretty well. Alas I also run a business and theres a big breakdown going on. 90% of what I do work wise is via email. I'm finding GTDInbox great at managing and labeling my email in a gtd way and clearing my inbox. However I'm finding my email system has become a separate entity to my moleskine system.

For instance I have alot of potential projects hidden in these emails. For example "interview new candidate bob". There might be 30-50 candidates I need to process at any one time. Should I make each of these a project in my moleskine? I know I just can't do "process all applicants" project in my moleskine because that is a never ending project. I'm always getting new applicants.

Is it good enough just to process these emails and not have projects attatched to them? Maybe im worried to completely GTD'ise my business life because I could end up with 200+ projects....

Guidance would be appreciated!!!

[jknecht]

Maybe im worried to completely GTD'ise my business life because I could end up with 200+ projects....

Umm. Bad news, Kingfu... you have 200+ projects whether you GTDise them or not.

Now, given that you have a constant stream of input, you may not want to write each of them down; and perhaps that is your real question.

I suggest setting aside a little time each day to process emails from candidates. Treat them as a separate "in box". With each one, you can do an initial triage to decide whether they are worth pursuing (you can probably eliminate 90% of them just by looking at their email: Can they spell? Can they write a decent sentence? Etc). If they are worth pursuing, then create a project for each candidate. Use a checklist to manage the interview/application/hiring process from that point.

[Brent]

Well, I have to disagree somewhat with jknecht here.

I think you certainly can manage this as one single Project. List all the candidates' information in your project support materials for that Project.

Conversely, you could keep separate Projects for each specific candidate that you've committed to interviewing. In that case, I'd still suggest you have one ongoing Project, Candidate Interviews, with project support materials containing resumes and information for each candidate.

It all depends on how much work you have to do for each candidate. If it's mostly a matter of dumping their resume in a folder and scheduling an interview, you should be able to cleanly handle all of them in one Project. If it's more complicated than that, you may need separate Projects for each candidate.

[kingfu]

Now, given that you have a constant stream of input, you may not want to write each of them down; and perhaps that is your real question.

Thanks for the response jknecht. There is reluctance on my part to forgo writing them all down in my projects list, but as you say whether I like it or not I have 200+ projects.

Brent, thanks for advice. It is sadly more complicated than just setting up a interview. Theres alot of emails flying back and forth, calls to multiple people and other work that needs doing relating to each candidate (website to be updated etc). Im also reluctant to have too much seperate project support material than is in the emails themselves, as this would lead to alot of duplication. If i need information I just use gmails search function or my own notes added to the email conversation.

In this case do you think its looking more like a seperate project is required for each candidate?

[AdamMiller81]

The one or many projects question doesn't have to be an either/or type of question. Maybe the answer is both.

You say that you think one project wouldn't cover all the various details you have for each candidate.

Now, my question is, do you have to do this work for every candidate you interview or only the successful ones? Because that then leads us to the "both" answer.

Basically, it might be one general project for the interview stage, and then if it's successful, then that applicant gets a setup project all of their own.

[ellobogrande]

Thanks for the response jknecht. There is reluctance on my part to forgo writing them all down in my projects list, but as you say whether I like it or not I have 200+ projects.

Brent, thanks for advice. It is sadly more complicated than just setting up a interview. Theres alot of emails flying back and forth, calls to multiple people and other work that needs doing relating to each candidate (website to be updated etc). Im also reluctant to have too much seperate project support material than is in the emails themselves, as this would lead to alot of duplication. If i need information I just use gmails search function or my own notes added to the email conversation.

In this case do you think its looking more like a seperate project is required for each candidate?

Is interviewing a candidate the primary outcome, or is it filling one or more particular job positions in your company? It sounds like the latter to me. I think that your projects in these cases would be "Hire a new receptionist" or perhaps "Hire three Java developers for logistics dept". Conducting interviews could be considered sub-projects, but I would't track those as individual projects; it's too cumbersome.

You can efficiently and effectively use the e-mails as project support material to remind you of your work at hand and the progress that you've made on them if you manage them within the e-mail system the right way. I'd use a hierarchy of folders and sub-folders within my e-mail system to do this, but I'm not sure how to do it with gmail, which, if I'm not mistaken, doesn't allow the creation of file folders. Perhaps another gmail user could help you with the "how" on this one.

Best of luck.

[kingfu]

Thanks for replies

The email side of things are fine with a full GTD implementation.

I actually find work for the decent candidates, so the outcome would be on processing each application to see if they are up to par. The problem would be of making one big project to cover it all would be it would never end. This is a area of responsibility for me.

Sadly for each candidate im able to only dimiss around 1/4 very early on which I do via email. Now the others require more emails, calls and so on between me, the applicant and other staff over time.

Im thinking im just gonna have to bite the bullet on this one and create a project per applicant as a way of tracking orphaned next actions I have floating in my context lists....

[Barb]

I've had positions in the past where I had to do a ton of recruiting involving multi-step processes. If it were me, I'd make "hire successful candidate for Job A" the project. The successful outcome isn't processing the candidate, but filling the position.

Your mileage may vary.

Thanks for replies

The email side of things are fine with a full GTD implementation.

I actually find work for the decent candidates, so the outcome would be on processing each application to see if they are up to par. The problem would be of making one big project to cover it all would be it would never end. This is a area of responsibility for me.

Sadly for each candidate im able to only dimiss around 1/4 very early on which I do via email. Now the others require more emails, calls and so on between me, the applicant and other staff over time.

Im thinking im just gonna have to bite the bullet on this one and create a project per applicant as a way of tracking orphaned next actions I have floating in my context lists....