Complex projects with deadlines; or, to date or not date your tasks

devon.marie

devon.marie

0
Since this seems to be popping up in a lot of threads (and de-railing some), I thought it might be nice to have one place to discuss the various ways to use or not use dates when managing one's tasks. Forgive me if there's already a thread for this, but a cursory glance over the past few months didn't lead to anything, so I thought I'd start fresh.

It seems we're all in agreement that GTD makes handling general tasks fairly easy and uniform. If it has a due date, it goes on the calendar. If it must be done on a specific date, it goes on the calendar (or a tickler, depending on personal preference). If it is to be done whenever possible, it is to go on a Next Actions list. If it is to be done at some point but isn't a priority now (or cannot be done now), it could (or should, if inactionable) go on a Someday/Maybe list (either as a rule or depending on the length of one's Next Actions list).

So far so good - we mostly seem to be in agreement with this. But I'm curious how we all handle complex projects with many tasks necessary for completion and a due date on the project. According to GTD from what I understand, the only "hard" deadline in this is the project's due date. I am curious how everyone keeps their project (or projects if in a field where we have multiple) on track. There are other methods outside of GTD that companies and teams use, such as Agile, but I'm curious how each of us handles projects like this in a GTD environment.

Thoughts?
 
chirmer : I create actions plans for complex projects. On those projects, I list (or mind map) the many sub-projects and actions that need to be done. I do backwards planning -- starting with the hard due date for the project. I determine how much time approximately different components will take. I add in cushion time if something goes wrong. I end up at the beginning of the project. It is an eye-opening experience. By planning this way, I can now see when I need to block time on my calendar. It can be just a project block, or a block to complete a specific, 1+ hour next action. ALL of this ends up on my calendar. I also block time for the multitude of small actions that by themselves should not be on the calendar -- "doing time" if you will. By doing this level of planning, when new work comes in, I can review my calendar and easily determine if I have the bandwidth to do the new work. If everything was decided in the moment without this level of planning, I would quickly overwhelm myself as I would not be able to clearly discern what I really could do.
 
Re: "It seems we're all in agreement that GTD makes handling general tasks fairly easy and uniform. If it has a due date, it goes on the calendar."

Actually, I don't think that there's agreement on that. I don't put due dates on the calendar--my calendar only has events that will happen AT that day and time--not before, not after. Usually this means meetings and similar events that require my physical or virtual presence.

By "not before" I mean that tasks, as opposed to meetings, can be done early. So if I have a document that's due on the 12th, but I could finish and submit it on the 8th, that due date of the 12th won't be on the calendar. On the other hand, if that document is a paper that I'm presenting to a group of people on the 12th, that will be on my calendar.

This may in part depend on the definition of "the calendar". I have a calendar program, where meetings go, and I have a task manager, which contains due dates, but the fact that a task has a due date doesn't mean, in my terminology, that it's "on the calendar."

So my version of your list of categories is:

- Is a meeting or other event that requires my physical or virtual presence at a specific date and time: Goes in the calendar.
- Is not the above, is a priority that I may work on in the nearish future, and has a due date: Goes in my task system with a due date.
- Same as above but no due date: Goes in my task system without a due date.
- Same as above but it's not quite possible to work it (say, I can't do it until a colleague returns from vacation): Goes in my task system with a future start date, and possibly also a due date.
- I'm not likely to be worked in the nearish future: Goes in my task system in the Someday/Maybe area, or gets dumped to even lower priority lists outside my task system.

Re: "So far so good - we mostly seem to be in agreement with this. But I'm curious how we all handle complex projects with many tasks necessary for completion and a due date on the project."

It depends. If the complexity can be addressed as multiple projects, I would create separate parallel projects for each of them. If I could only work on some of those projects at any given time, I would probably put a future Start Date on the ones that I couldn't work yet. But that's mostly about storing the work, not about scheduling or dating it.

If the project were sufficiently complex, I'd probably create a plan for completing the whole project, and store it as project support material. Then I'd likely create a recurring task for reviewing my progress so far against that plan. If I had usually had one or more of these projects, I'd make that review part of my GTD weekly review.

(Now, if this were a corporate project, somebody else might be creating the project plan for a whole team, but I'm assuming here that it's either a personal or one-person project.)

You mention Agile. I would assume that for Agile, the end date for each sprint would indeed be treated as a hard deadline in each team member's individual GTD system if they have one, even though the team would have some flexibility in adjusting that date.
 
Very good initiative, chirmer I can already see how this line of inquiry can illuminate the background of some of the differences that seem to pop up in other threads.

I think in my case I do not ever have any projects that are complex in that kind of sense. They can be very complex in more nebulous ways, but not easily "plannable" in terms of "time quantities". I work mainly with, and depend heavily on, hitherto unknown people, people I have no way of predicting will be partners. All that exists is a goal of some kind. For example, I and some client of mine may have a vision that we will get a share of particular market or perhaps a government tender, but we are too small to win it ourselves alone. We need partners of all kinds (financial, engineering, marketing, legal ...) and we do not have them yet, but we may have some avenues, people we can ask etc. So an early "subproject" (one of the first steps) might be to identify potential partners of type X (e.g. computer companies) to contact. And potential partners of type Y (e.g. banks). Another initial "subproject" would be to create an initial "vision" presentation (which will be a living document, a moving target, which will need to be modified as we go) for what we are looking for, the initial basis for the discussions we will have with potential partners. And so on. And maybe some isolated steps here and there in the future can also be identified early, but for the most part the plan will evolve as we move ahead, a few steps ("subprojects") at a time. It will all depend on who we meet, who are interested, what kinds of objections and suggestions we encounter, how creative we can be together, and so forth. The whole vision may change. And generally you can trust other people's commitments no more than you can trust your own. You may need to have parallel discussions with other potential partners in case one backs out etc. Very difficult to make a time plan that will really be followed, but I keep drawing these all the time anyway, because they serve as very good illustrations when presenting the project vision to new potential partners or customers. A neat time plan is usually a very useful part of the presentation package. I don't enter them in my personal lists, though; they are just "project support" material, more for show than for actual use as I expect them to change and get clarified many times over. All the planning uncertainty applies even to very small projects, like helping a small client find a distributor or supplier or get a bank loan, or even when just helping some friend sell their apartment or company. You have to just begin with something sensible (a next action or "next subproject" if you will) , then continue, see how it goes, and adapt as you go.

In my private life, too, I depend a lot on family and other people for what matters to me, and cannot really control either my time or theirs. And for my own personal things I simply do not want to plan. I prefer to just have a cup of coffee, look at the sky, have an impulse and just do whatever I feel like at the moment. I do not think I would ever undertake anything big and complicated entirely on my own, like build a house or write a book. And if I did, I probably still would not plan it, but just go all cylinders until it was ready. On the rare occasions that I get a chance to go on a vacation all by myself I do not plan visiting a single monument or beach or bar or museum or concert or lookout point or people I know there or anything at all. The only firm intention is that I will have a good night's sleep and a nice breakfast every day - but I always pick a place with lots of options, because I know I tend to get restless by mid-morning.
 
Priacta.com offers a course ( advanced GTD, TRO or whatever they call it) where they introduce something called " smart dates" . This is for those weak souls (me) who can renegotiate their way out of self imposed deadlines / dates.

Any task can have 4 dates
a deadline date,
a hard date( date before which you must work or disaster looms)
soft date ( the first date you would like to start working on it) and
start dates ( the date it is available to work on- like a tickler).

As you can see there clearly are tasks that don't have deadlines, that are always available and YOU get to choose when you need to work on them. The idea is to approach tasks by deadline dates first ( goal is to not have any), hard dates next ( again should not have any), start dates and lastly the nebulous soft dates which function like a kind of priority.

You could either use actual dates (tracked in a different filter) or vague dates like "this week", " next week" "next year"etc. These tasks are scheduled into the calendar ONLY during the daily review, or weekly review. I use just 2 soft dates -this week and next week

All this is to say, I don't schedule tasks in the calendar until I know that I am absolutely going to do it today.

chacha
 
I agree with Gardener's definition. I disagree with chirmer's initial definition that anything with a due date (deadline) would go on my calendar. No way. If it is even a little bit important I will try to do it much earlier than the deadline. Most likely I will not do it on the due date at all, as it would be too risky to wait so long. In my case, the deadline (kept in my list) is mainly a last catch for unimportant stuff that "expires" on that day (will become impossible the next day) - everything of importance has already been done, so this is usually just the "last chance" for less important stuff.

jenkins I think maybe part of the problem here (I also answered your question in the other thread) is the fact that we use different kinds of tools, and although the methodology as such is supposed to be "tool agnostic" the terminology is not. Yes, you can definitely use a calendar tool as a tickler device. Or you can use a regular list tool as a calendar device. That's just a choice of tools. BUT: The difference between a so-called "calendar action" (regardless of whether you keep it on a calendar or on a list) and a "tickler item" (regardless of where it is kept) is this:

- a calendar action MUST be done on that day (cannot be done before and not after. Example: appointment)
- an action with a due date cannot be done after the due date (Example: a last submission date)
- a tickler item is premature and cannot even be considered before the tickler date. (Example: monthly report). Ticklers typically end up being regular next actions, but can also become Waiting or Trash etc

I think your examples are very good, and your quotes from DA are excellent. I see no contradiction, just that the terminology sometimes gets in the way.
 
chirmer said:
It seems we're all in agreement that GTD makes handling general tasks fairly easy and uniform. If it has a due date, it goes on the calendar. If it must be done on a specific date, it goes on the calendar (or a tickler, depending on personal preference). If it is to be done whenever possible, it is to go on a Next Actions list. If it is to be done at some point but isn't a priority now (or cannot be done now), it could (or should, if inactionable) go on a Someday/Maybe list (either as a rule or depending on the length of one's Next Actions list).
Click to expand...
Nope, for me there are 3 main apps that I use.

One is the calendar. It has 3 functions for me. A running diary of what I actually spent my time on so I have a historical record of what I did and when. This has been critical. I've gone back to my calendars from over 30 years ago to pull out data and information I need now. WIthout this record I'd have a hard time dealing with current issues and projects.

The calendar also has hard dates in the future for things that I must attend or do. Jury duty is a hard date. It also has potential future things that are time critical. So a concert that I might attend is in my calendar with a note ?attend concert X? on the date and time it happens. That way I can see at a glance the critical items that are fixed and the time critical items that are still possibilities. Some recurring projects have critical time dates based on when a particular action gets completed. So for example we have a case now where I had to give all the sheep a dewormer for tapeworms and liver flukes. All sheep need a second dose a minimum of 10 days and a maximum of 12 days after the first dose. So I have blocked out in my calendar ?Give second dewormer" for all the possible days. That way I know I have at least one of them available and won't schedule something else in that time. That action is also in my list manager as a next action with a start date of the first possible date I can do that item.

My primary GTD app is my list manager, Omnifocus. In it I put all current projects. If a project has a due date it is in there. If it can't be started until a certain date I have a start date. I have many recurring projects that can only happen at certain times of the year and I only need to be reminded of them then. I want them in my list app because I don't want to have to deal with a totally different system for checklists. I also don't want to reinvent the wheel so to speak by having to plan them out again and again. And I need a reference so that in the event of an emergency, injury or other problem someone else can pick up my system and keep things running well so it's a backup of my job too. A project like "Decide on the ewes and rams to breed this year" is a recurring project that starts in October and culminates in December when I put the rams in.

chirmer said:
But I'm curious how we all handle complex projects with many tasks necessary for completion and a due date on the project. According to GTD from what I understand, the only "hard" deadline in this is the project's due date. I am curious how everyone keeps their project (or projects if in a field where we have multiple) on track.
Click to expand...
My interpretation is that any critical subproject (which I would create as a separate project) can also have a due date.

My complex projects can span months, years, decades and lifetimes. I keep them in as many separate projects as I can. I don't handle subprojects well at all. I might have 30 projects related to one big complex project. Many will be pending completion of another project and that is often indicated by an action of "waiting for project X to complete" My projects rarely change much if I have done proper planning at the start so it's perfectly reasonable for a complex project that got conceived and planned 40+ years ago, to take this long to get all the various pieces (that I actually create as separate projects) done. I just have them entered as projects either on hold or in my someday/maybe list or with a waiting for action until the prerequisite project is completed. And for me it's perfectly reasonable to create due dates for each of those pieces as required.

My 3rd app is a new twist with DEVONThink notes for the huge list of someday maybe projects that are of a sort that I won't start another one in that category until the current one is either completed or dropped. These are typically crafting projects. So for example I have a single current knitting project and once I've either finished or frogged it I'll look at my DT note of "Knitting Projects To Do" and pick another one to make current and active. I don't need to see all my options because I have decided that I will only do one knitting project at a time. Similarly I have the same sort of list for classes to take, weaving projects to do, sewing projects to do and so on.
 
My rule is simple:

"I can put anything in my calendar if there's a very high probability (>95%) that I will not rewrite (or reschedule) it."

For me this is the main idea of using a calendar in the GTD methodology.

My calendar is not a "someday/maybe" or "as soon as possible" list. It is a "on this day for certain" list. And don't tell me that often there can be something that will change my plans. Not often but very rarely - earthquakes don't happen very often in Poland. ;-)
 
Generally speaking I am with Longstreet here: the shortest path to glory is documented and updated in the project plan.

If the project is big enough to "warrant" such a plan.

In that plan there is also room to state one's guiding principles for working that project, which could very well consist of making a weekly milestone a priority.

(I wrote about this "recently" in another thread.)

I may write reminders of time-sensitive facts into my calendar.

What I find problematic with "artificial deadlines" is that it is often very difficult to assess how much work is to be done in a given week to "know" that you are "on track". In most cases, I guess, it is virtually impossible. Also, what if you get "too much" work done?

It would be nice to have a short list of clear-cut milestones for the week, the month, the season and being able to mark them "done". But I don't know which type of work would be possibly be able to sliced that way. Factory work, maybe. Hundred cans of soda this week, one hundred cans of soda next week.

There is also the factor of "overcommitment" or possible "overcommitment" playing into this. Part of the discussion resolves around how white space in the calendar can deceive us into thinking we have much more time at our disposal than we truly have. This, of course, could be countered with by writing all sorts of signals from the project list engine onto the calendar and thusly get a better picture of how full our weeks already are.

Clearly, priority is to be dealt with on 10,000 ft and above. When we do our Weekly Review and see on our Project List that many projects could not moved forward this week, we have to decide whether we are okay with this. Alternatively we have to change our commitments. A helpful guide can be our notes regarding the "higher levels".

No amount of calendar scribbles will help us, if the underlying problem is an unrealistic view on the projects level.
 
TesTeq said:
My rule is simple:

"I can put anything in my calendar if there's a very high probability (>95%) that I will not rewrite (or reschedule) it."

For me this is the main idea of using a calendar in the GTD methodology.

My calendar is not a "someday/maybe" or "as soon as possible" list. It is a "on this day for certain" list. And don't tell me that often there can be something that will change my plans. Not often but very rarely - earthquakes don't happen very often in Poland. ;-)
Click to expand...

My profession is very crisis driven. I never know what I can do tomorrow until tomorrow comes. I dont need earthquakes to disrupt my plans.
 
Folke said:
I agree with Gardener's definition. I disagree with chirmer's initial definition that anything with a due date (deadline) would go on my calendar. No way. If it is even a little bit important I will try to do it much earlier than the deadline.
Click to expand...

I only say this because it's the vanilla GTD way to handle deadlines. It's David Allen's definition, not mine :) And just because it goes on the calendar, doesn't mean it's inherently forgotten about until the due date. Part of the Weekly Review is to go through both your lists and your calendar. Having a due date in an app is no different than having it on a calendar - it's each person's preference. If you use paper, there's no where else to put it. If your app doesn't support due dates, there's no where else to put it. So my initial post seems to confuse some. I was more talking about what's acceptable to put on the calendar, if the calendar is your primary time-manager. And the 2001 GTD book says things to be done on a date, things to be done by a date, and things relevant to stuff on that date belong on the calendar.
 
Oogiem said:
My interpretation is that any critical subproject (which I would create as a separate project) can also have a due date.

My complex projects can span months, years, decades and lifetimes. I keep them in as many separate projects as I can. I don't handle subprojects well at all. I might have 30 projects related to one big complex project. Many will be pending completion of another project and that is often indicated by an action of "waiting for project X to complete" My projects rarely change much if I have done proper planning at the start so it's perfectly reasonable for a complex project that got conceived and planned 40+ years ago, to take this long to get all the various pieces (that I actually create as separate projects) done. I just have them entered as projects either on hold or in my someday/maybe list or with a waiting for action until the prerequisite project is completed. And for me it's perfectly reasonable to create due dates for each of those pieces as required.
Click to expand...

The bolded sections are essentially what I'm getting at. It has seemed in many threads that those of us who put deadlines for certain project parts on the calendar to keep it on track, despite them not necessarily being "hard" in the sense that the day before and the day after would work just as well, are having these referred to as "arbitrary" or "artificial". I'm curious to hear how those folk do otherwise, because I can't imagine having a project with 400 individual tasks that all must be completed within 6 months and not creating secondary deadlines to keep it flowing smoothly.

Cpu_Modern said:
What I find problematic with "artificial deadlines" is that it is often very difficult to assess how much work is to be done in a given week to "know" that you are "on track". In most cases, I guess, it is virtually impossible. Also, what if you get "too much" work done?
Click to expand...

I would disagree that it's impossible in most cases. I've yet to have a project, no matter how complex, go off-track by incorrectly estimating work. I'll use my upcoming side project as an example of how I do things:

I'm starting a project where I want to complete 28 items of varying complexity in exactly 1 year. It can get completed early, but not too early, as it's a public side project I'll be blogging and wish for it to take close to a year to complete. I sat down to plan the project by creating my list of 28 items and the level of intensity the item will take to complete - High, Medium, or Low. If it takes a lot of time, or requires me to be at the top of my game, it goes as a High. If it requires strong attention but perhaps not as much as High, or it doesn't take quite so long but does still take a fair bit of time, it's a Medium. And if it's quick, or easy, or both, it's a Low. I try to make sure there's not an overabundance of High items, since I know the project will fail otherwise, because it's an unpaid project and I still want to have a life ;) Then I plan each step of the process, from building the website through the wrap-up blog post. And lastly I plan out my "arbitrary" deadlines (though to me they're Hard because without them the project will fail) for having 5 complete, 10 complete, 14 complete (halfway), 20 complete, 25 complete, and 28 complete, while leaving myself enough time at the end of the project to complete the wrap-up tasks.

According to the 2001 GTD book, these are perfectly acceptable items on my calendar according to the first two quotes jenkins shared. So I was curious how others who claimed it wasn't handled situations like this. How would you make sure your 28 items get done on time, in a nicely spaced out manner?
 
Longstreet said:
I also block time for the multitude of small actions that by themselves should not be on the calendar -- "doing time" if you will. By doing this level of planning, when new work comes in, I can review my calendar and easily determine if I have the bandwidth to do the new work.
Click to expand...

I do this, too. Most of my tasks come from my co-workers, and they all tend to hit at once. It's too hard to tell from my task list how much time it takes, because the only apps I've used that map time are a) too expensive, b) unintuitive, or c) don't work on all platforms I need. So I use the calendar, and many times I'll go quite some time before I can work on something that really should be worked on, so I'll start blocking time in my calendar for these shunned tasks. Since my coworkers can see my calendar, it lets them know I'm too busy for that umpteenth project.
 
My perspective -- we might want to work backwards from a 'use model'.

I start my day by opening my calendar in week view. THEN, I look at next actions. So, you can see that the week view of the calendar influences my choice of next actions.

IF you start your day by looking at next actions, you would treat due dates totally differently than if you start with the calendar.

That is, if my calendar says a project is due on Friday, that might influence my choice of next actions every day until then.

It sounds like there are a variety of use models being assumed in this discussion, so I would like to ask -- how do you use your calendar and next action lists?
 
ArcCaster said:
My perspective -- we might want to work backwards from a 'use model'.
Click to expand...

I start each day like this:
  • I check my calendar (for appointments - not much else there). I am careful before promising to have a meeting, but if I do I strongly try to honor it
  • I check my next and waiting actions for red items (critical items) that really would have needed to be well underway. If possible, if I have any, I'll star a couple of those, too (but not any red ones those that seem impossible given my expected whereabouts etc that day).
  • I check my whole next and waiting (red and blue) for any other actions that are hot candidates for today, usually those that match the context of the appointments and starred red actions, and I star those, too.

That leaves me with a tentative "today" list, which I keep grouped by context.

During the day, when I change context, I review the tentatively selected tasks for that context against the rest of what I have in that context - maybe I now have more or less time etc - I like to doublecheck whether the selection is still ideal. At the same time I also always check if any of the unstarred red actions have now become more possible to get done today.
 
chirmer said:
So I was curious how others who claimed it wasn't handled situations like this
Click to expand...

I can perfectly understand (I think) your desire to be in control of time. I would probably want that too - if I thought I could.

If I had a project (or other kind of ongoing effort) that required me to post regular blog posts or newsletters etc I would certainly use dates to pace it. Most definitely. Exactly how would depend on the features of my app and on what it is you need to publish - if it is of a "latest news" type or "timeless" (say a cooking manual). In the latter case I would keep all the writing as a next action to write all the umptieleven episodes (or if it needs more detailed planning I would break it down a bit). And I would set up a repeating tickler to just publish. If I had let people to expect this on a particular day of the month etc I would use a due date, too, on that tickler, otherwise I would just give it either a red or blue color depending on how quickly it must be done from the tickle date (first acceptable date).

If it is a latest new type of thing I would need to hold the product until just before the publishing time. Then I would tickle it for say a week in advance of the approximate (or exact) publishing day. I would also use a deadline if one has been promised or has become the expected standard.

If each article will take a long time to produce, and must be quite fresh, I would probably set up a separate repeating tickler for the production work, and the deadline for this would coincide with the deadline for the publishing, if there is one, or with the tickle date for the publishing.

I would agree with you that these "internal" deadlines as in fact "inherently hard" since they are derived from a "promise" (albeit yet unspoken) to your audience about providing a certain type of content at certain intervals - we cannot appear to be jumpy or inconsistent in our dealings with other people.
 
Folke said:
If I had a project (or other kind of ongoing effort) that required me to post regular blog posts or newsletters etc I would certainly use dates to pace it. Most definitely.
Click to expand...

​I almost fell out of my chair. Good for you, Folke !
 
chirmer said:
The bolded sections are essentially what I'm getting at. It has seemed in many threads that those of us who put deadlines for certain project parts on the calendar to keep it on track, despite them not necessarily being "hard" in the sense that the day before and the day after would work just as well, are having these referred to as "arbitrary" or "artificial". I'm curious to hear how those folk do otherwise, because I can't imagine having a project with 400 individual tasks that all must be completed within 6 months and not creating secondary deadlines to keep it flowing smoothly.
Click to expand...

This is where I wonder if we have different definitions of "calendar". I have deadlines for many items in my list, but most of those items are not also in my calendar. I think that the issues of (1) what goes in the calendar and (2) whether to enter interim not-externally-imposed deadlines, are two different issues. Your argument addresses (2), but IMO not (1).
 
No reason to "argue"....do what works best for you. It all is within the realm of a good GTD practice.
 
You must log in or register to reply here.
Top