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]

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]

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.