Projects, sub-projects, support material, future actions

[StuGib]

I'm hoping someone may be able to help clarify this in my mind before I drive myself mad going back and forth.

My work involves website requirements and design. As part of this I'll have things I need to do (write the specification, design the page flow, design individual page layouts), issues that still need resolving (what should be listed in the options, what should happen when users abandon registration), design ideas to consider (add a button to do X to this page), decisions to write up (agreed that users will get credits on registration), and problems raised (what happens when the user does this?). All these things will either come from my own head as I'm working on things, or from others.

I also write documentation, which has similar types of work - documents to write, changes to existing documents, things I need to research, information from developers to include, etc.

My problem is that, because I think I have a general tendency to organise and systemise everything, I always see everything in terms of relating to everything else, so I never know whether something appearing in my inbox is a new project, a new sub-project, some action I need to do as part of another (sub-)project, or just keep it filed separately in different types of support material lists (e.g. issues to resolve). I try to work bottom-up but then see everything top-down and try to organise it that way.

For example, I need to design a new feature for the site. That's a project. I can define it's purpose, visualise the outcome, and think of planning it. I can add in new sub-projects to create the page flow, design each page etc. Each of these gets added to my projects list.

That's fine until I get back to the real world with problems, ideas and issues pinging at me all day. I'm fine getting them into my inbox. It's where to put them then?

Example: I get an e-mail from a developer asking 'What items should we display in this list?'. I can't answer immediately, I need to think about it, maybe ask the project sponsor, add it to the specification. So, it's a project. But is it a sub-project of the project defining the page that this list of items is on? That's when I start to re-plan again - well maybe I shouldn't list this in itself, maybe it should go on some list of future actions to do as part of the bigger project (to define that page, or even as part of defining that feature). Maybe it should go on a separate support materials list of problems and issues with that page? But then how do I know it needs to be done - it needs to go on my main list again - is it a project, or an action? Is it a sub-project,..... and round and round in circles I go.

I've just re-read the book and am trying to simplify again, but get drawn back into a world of sub-projects and nested lists. One of the key things I got when I re-read the book was to separate the vertical and horizontal, and maybe I'm trying to have project plans mixed in with my project lists? I've tried, but in the end I see that things on my project plan needs to get done so needs to be transferred to my project and action lists.

Any thoughts, if that made sense?

Stuart

 

[Brent]

It might be helpful to think of it this way:

There are no sub-projects. There are only projects, large or small.

Does that help?

 

[StuGib]

There are no sub-projects. There are only projects, large or small.

Hmmm, interesting. That does make sense. The 'do I trust my brain?' side of me says 'how do I know if the big project is complete if I can't see a list of the sub-projects it depends on' but I guess that's where regular project reviews come in?

e.g. if I get a small project (e.g. a developer question) where the the action steps are 1.design, 2. review with boss, 3.change spec, then this doesn't need to link into the 'Write spec' big project?

I'll take another look at my project list and keep repeating that mantra! Thanks for the idea!

 

[kewms]

At some level of granularity, everything is a sub-project, because everything is part of your life. So your tendency to connect everything to everything else is understandable.

The problem arises when you spend all your time worrying about how to file things, rather than actually doing them. It might help to remember that you can't do a project, but only Next Actions. If you've captured all the NAs, the project categorization is helpful but ultimately not terribly important.

It also might help to have an organizing tool that can deal with multiple levels of subprojects. Your brain clearly wants to create them, so it may be better to accommodate that than to try to fight it. My system, MindManager with the ResultManager add-in, uses linked mindmaps to stack projects as many levels deep as you want. Icons placed in the maps tell the system which items are projects and which are actions. It uses this information to pull out action lists, project lists, or whatever view of the data you need.

My deepest nesting is currently seven levels:
Life Goals -> Business Goals -> Key Client -> Big Project -> Major milestones -> sub-projects within milestones -> Actions
But I could go deeper if I needed to. (Note that independent projects exist at each of these levels. That is, my fitness project is on the Life Goals map, smaller client projects are on the Business Goals map, and so forth. Not everything is seven levels deep.)

Katherine

 

[luisr]

Or standardize your "methodology"/project list

It sounds like many of your projects would have similarities. So instead of continually trying to identify sub-projects you could standardize the ones you use based on the methodology.

I've done this with a few projects.
So, if for example, your work requires certain stages the use THOSE as the sub-projects. I used to be a role somewhat similar to yours ... my version used to include:

a) Project Goals, Objectives, Ideas

the place to collect all sorts of screenshots, things the client likes, etc.)​

b) Project Definition

determine specs, document it, etc.)​

c) Product Development

for work in progress notes, programmers questions, issues, etc.​

d) Accessories/Future Features

where to put all those things you'd like to add in the next version!​

I used to think of it like building a building:
a) Design the building (finishes when we hand off blueprint > contractor)
b) Build it
c) Decorate & Accessorize

Breaking your projects into standardized subprojects on the basis of stages or methodology takes the guess work (and stress) out of deciding where to place things.

Luis

 

[wordsofwonder]

I always see everything in terms of relating to everything else, so I never know whether something appearing in my inbox is a new project, a new sub-project, some action I need to do as part of another (sub-)project, or just keep it filed separately in different types of support material lists (e.g. issues to resolve).

As others have pointed out on this thread, at the end of the day there are only projects and Next Actions. I've experimented with all sorts of categorization and nesting using a variety of tools, and I've found what it sounds like you're finding: namely, that the effort of managing and organizing your Trusted System isn't justified by an increase in productivity. When you've reached that point, perhaps it's time to simplify your system.

My organizational tool (Agendus) allows tasks (Next Actions) to be nested to more-or-less arbitrary depth. I've found, though, that the supposed benefit of being able to see what's related to what is totally eclipsed by the amount of time I spend organizing and re-organizing the list. (Outlining applications like ShadowPlan have worked less-than-well for me for the same reason.)

One principle I apply to my Trusted System is borrowed from the lingo of eXtreme Programming: Do the simplest thing that could possibly work. If your system is creating friction for you, it's time to simplify.

-- Tammy

 

[StuGib]

Thanks for the replies and ideas. In reverse order,

Tammy
I deliberately left out tools in my post, but I've also mostly been outline based (Bonsai) and did the 'traditional' breakdown of Area of Focus>Deliverable>Project>Action but I started to re-evaluate for the same reason as you, namely that it was too much work to process my inbox and find where to put each one. I'm still sticking with Bonsai for now, just because I can use it quickly and I have more filter/display options than the todo list, but am now just using it for sub-lists (trying to keep in mind GTD is 'just lists').

Projects
-ProjectA
-ProjectB
Next Actions
-NA1
-NA2
Waiting For
Agendas
Someday/Maybe
Inbox

I'm hoping then it's just a case of processing items in the inbox and plonking them in the correct sub-list.

So, I'm comfortable with the tool and that I need to simplify, but it's just that mental hurdle of knowing which bucket to put each item in and trying not to think too much! Unfortunately at the moment everything that comes in is a mini-project. Maybe an outliner is giving me the temptation to organise and sub-divide :-?

luisr
Good point about standardising to remove decision making, and I'll think what applies to my situation. Just started reading 'Managing Multiple Projects' which has been recommended on this board, and they seem to say similar about standardising processes.

Your example I think is a pretty close match for my big projects, but my problem comes when I get a mini-project, e.g. programmers question in your example. What did you do when you got a question that needed more than one step to answer? If I understand correctly, you have a 'product development' sub-project? Where did you put that question? I'm torn between adding it to the support material (e.g. note) of that sub-project, or creating a new sub-project of the sub-project.

Katherine
Well summarised! I'm trying to move away from nesting all my sub-projects as I find it takes too long, though as you say maybe that's fighting a losing battle! As well as just a flat project structure as Brent suggested, I'm considering just nesting my projects on my project list, and not nesting actions underneath. It wouldn't matter if I didn't structure my projects until the next weekly review as long as they were there within the project list and being progressed.

More experimentation needed I think

 

[luisr]

StuGib:
As to the specific question you noted about my post:
Yes, I structure each project with 3 subprojects; over the years my terminology has changed but it's essentially:

• 
  subproejct 1: design stage
  subproject 2: build stage
  subproject 3: accessorize stage

Everything goes into one of those 3.

More experimentation needed I think

I too got overly analytical at one point, and spent way too much time redesigning the building when I should just have been building it!

I would encourage you, like some other posts have suggested to just stop experimenting and "pick a horse and ride it". In other words, pick a system and get on with using it.

In the system I used, it came down to picking 3 or 4 categories that I could fit *most* project actions into. If you do something like that -- then when you're tempted to create another category or another subproject of a subproject ... STOP! and put it into one the categories you thought was good enough last week!

One of the messages you hear consistently on this board is that ultimately, you will be more productive if you apply an imperfect system consistently than if you keep spending time experimenting.

 

[treelike]

I find it's helpful to get an A4 sheet of paper for a complicated project and scribble the plan on it. It's quick, easy to change and you can see all the sub-parts that need be done illustrated together on one place. There's also something about stuff you've drawn freehand that stores more information than kilobytes of text.

The disadvantage I find is that it's so easy to lose that piece of paper!

 

[TesTeq]

Use mobile phone camera backup.

The disadvantage I find is that it's so easy to lose that piece of paper!

If you have a mobile phone with 1 megapixel camera you can always take a picture of your A4 paper project plan or notes. At this resolution it is perfectly readable. Of course it is not very convenient to read it on the phone's small screen.

 

[StuGib]

Been thinking more about this overnight, especially based on luisr's suggestion that there is a place for little items in the bigger projects, and having read some more definitions from the Managing Multiple Projects book.

I think I may be over-'projectising' which is giving me the problems of
1. wanting to structure things (because as Katherine says, everything is part of something),
2. giving me too many concurrent threads (in the MMP book terms) which need managing when I only actually need to do one of those things at a time.

Sure, every change/suggestion/idea will need some thought and will need some write-up, but I'm starting to think "'do' suggestion X" is enough of a description stored with part of the project that it affects (whether it's a specific component, or a larger activity like 'design product'). After all, if I need to 'do suggestion X' and 'suggestion Y' to achieve a project, then I might as well pick one to do next rather than have both on my action lists, then see what the next action is for the one I'm doing.

I need better definition/classification of my work into what are the true outcomes I'm working towards, and what are just actions that will get me towards that outcome. At the moment I'm making just about everything a mini-outcome needing its own planning and actions.

The clouds are slowly clearing

p.s. there's some interesting relevant points about nesting and outlining in this coaches corner article.

 

[sonia_simone]

One thing that may help from a GTD pespective is to remember that although every project (in the GTD sense) needs an NA, not every NA needs to have a project associated with it. Even if that NA is in fact part of one of your projects, there is not much gained by identifying what that is.

The only thing you need to determine when you add an NA to a list is what context it falls in. Do you need to be at your computer, do you need to be at your desk at work, etc. The only thing you need to know is that this is the next action that moves you toward fulfilling the commitment that you made when you accepted the project.

If you will need some kind of reminder that "build widgit component" is part of the "create megawidgit site" project, you can add a small mnemonic, but for most NAs one tends to know off the top of one's head which project they go to. You only need to know this because as you do your weekly review and scan your project list, you need to check to see that you have at least one NA defined for that project.

 

[sonia_simone]

Some great points in the "coach's corner" article

I clipped this quote as being highly relevant to our conversation:

"the idea is to create top-level headings for your @contexts, projects, someday/maybes, etc. -- and then populate the sub-level items with the actual actions or projects. Go no further. The temptation to endlessly nest list items as a way of "organizing" your ideas or projects almost always ends in confusion, frustration, and an aversion to looking at those lists. Unless you want to start losing faith in your system, steer clear of nesting and numeric prioritizing. These are almost always surefire signs that you are slipping -- perhaps because you don't have a complete inventory or haven't stuck with the process long enough or diligently enough to trust you are on top of your game yet."

 

[treelike]

I don't have a megapixel camera on my phone but I do have my dad's old scanner as a hand-me-down so I guess I can stack the papers up next to that and scan them in to the PC as a backup (although of course I need to get into the habit of backing up the PC regularly....)

 

[kewms]

For what it's worth, I find that I create complex outlines of subprojects, milestones, and so forth at the beginning of a project...and then rarely look at them again. Once the project is rolling, all I need to know "in the moment" is the next action for the current subproject.

Therefore, it doesn't really matter how well my brainstorming and planning tools integrate with my day-to-day productivity tools. I can sketch out a plan with markers on a newsprint pad, then stick that sheet in my project support materials while I work from my electronic action list. I think a lot of the endless search for tools that people go through may be because people try to find the Perfect Tool for Everything, which may not actually exist.

Katherine

 

[Steve Wynn]

Take a look at MyLife Organized.

Take a look at My Life Organized it is a great piece of software for addressing Projects/Sub Projects etc. For handling complex Projects with lots of Sub Projects I don't think you can beat an Outlining Tool just to get everything in perspective. I would suggest you take a look at MyLife Organized specifically to address your problem.

MyLife Organized gives you the ability to have the Main Project as a Root Node, then your Sub Projects underneath in an Outline view. But you can actually define each Sub Project as an actual Project. It then has a 'Project View' which lists all of your Projects in their various states, Started, Not Started, Suspended and Complete. This view does not distinguish between the main Root Project and the Sub Projects it just treats them all as Projects. Which from a GTD perspective is great and certainly helps on the weekly review. You can easily switch between the Project view and the Outline view, plus there is the functionality to 'Zoom In' on a Project within the Outline for focussed attention. You can also view things within Context on your Next Action list and it has the ability to tag your Next Actions with the Project Name.

But the main thing is anything can be defined as a Project regardless of where is sits within the Outline. It may look like a Sub Project within the Outline because it sits under or as part of the main Project. But as far as the software is concerned it is still defined as a Project in its own right. Then, as mentioned, with the Project view you can easily see all of the defined Projects.

Regards

Steve

 

[TesTeq]

Phone camera backup instant availability advantage.

I don't have a megapixel camera on my phone but I do have my dad's old scanner as a hand-me-down so I guess I can stack the papers up next to that and scan them in to the PC as a backup (although of course I need to get into the habit of backing up the PC regularly....)

The beauty of the phone camera backup solution consists in instant availability - I have my Nokia 6670 phone always with me so I do not have to go anywhere to do a backup (scan the papers) or to do anything more than to take out the phone from my pocket and take a picture.

 

[wordsofwonder]

For handling complex Projects with lots of Sub Projects I don't think you can beat an Outlining Tool just to get everything in perspective.

Based on my own experience, I have to question how much value there actually is in getting "everything in perspective". I've tried implementing GTD with outlining tools -- and I've played with the demo of MLO -- but I find, as others have said in this thread, that the overhead of maintaining those project/subproject/action relationships is more than the amount of added productivity I get from doing it.

I know some people use MLO for their Trusted System and do well with it. But for me, the more complex my system is, the more time I spend messing with the system instead of actually getting productive work done. I've implemented the "Project as Contact" method with Agendus, as a way of viewing the status of projects, and even that has produced minimal return for me in terms of productivity.

For me, at least, the less effort I have to expend adding something to my list, the more I can expend getting it done. For me, "simple" wins out over "powerful".

-- Tammy