How granular are your projects?

Ben S

Registered
The title basically says it all. I'm a software engineer, and sometimes some of my projects read "develop xyz app", which technically is a thing I plan to do which takes more than one action, but really I'm not sure whether tracking that as a project adds any practical value to my system. A project like that might have 10-15 possible next actions, which could be grouped up into smaller projects. I'm not sure whether "develop app" should be an area of focus (level 2) instead; sometimes its large enough scope that it does become an area of focus, but often projects like this feel like they live in a middle ground.

My question is: At what level of granularity should a project live? Do you use nested projects ever? Should I even be tracking a project like this, or just swap it out for 3-5 smaller projects that are more specific?

Thanks!
 

PeterByrom

Registered
I think you have the right intuition about it being an area of focus. After all, if you’re supposed to be continually developing the app and releasing updates - and never stopping - then indeed it is an area of focus.

So the question is, can you identify anything with a clear end point? How do you know when you’ve crossed the finish line? Eg “launch new app”? “Release upgrade X”?

the question will then be whether you have sub projects which are means to an end of reaching those finish lines. Eg do you have to fix a number of bugs, redesign a number of pages, and update an amount of copy before you can release the upgrade? If so, you can track all of those as sub projects, tasks, or milestones. Anything which clearly records the fact that “I need to finish X,Y,Z”. All of those will trigger questions about next actions, and rightly so.
 
Last edited:

Ben S

Registered
I think you have the right intuition about it being an area of focus. After all, if you’re supposed to be continually developing the app and releasing updates - and never stopping - then indeed it is an area of focus.

So the question is, can you identify anything with a clear end point? How do you know when you’ve crossed the finish line? Eg “launch new app”? “Release upgrade X”?

the question will then be whether you have sub projects which are means to an end of reaching those finish lines. Eg do you have to fix a number of bugs, redesign a number of pages, and update an amount of copy before you can release the upgrade? If so, you can track all of those as sub projects, tasks, or milestones. Anything which clearly records the fact that “I need to finish X,Y,Z”. All of those will trigger questions about next actions, and rightly so.

Thats great, I love the heuristic of "is it finish-able". Definitely going to start thinking about my projects with that in mind.
 

Cpu_Modern

Registered
What kind of app can be developed in 10-15 action steps?

To the question in the OP, for the NA lists it is the same wether you have one project that generates a bunch of NAs or a few projects that generate the exact same NAs.

The difference comes in on the projects list(s), how many entries do you want to have there?

One goal should be "mind like water", what puts your mind at ease? One entry, or several of them?

Another place where it makes a difference is project support material. Would it be better to have one project plan for each project, that is, if you have several of them?
 

PeterByrom

Registered
Good point about the use of project support material. It's important to decide what you're most comfortable with. E.g. do you have one project called "release update X", and then have 20 sub-projects listed in the project support material for it? Or, are those worth listing as 20 outcomes in their own right, on the projects list?

One way I've come to think about this question is, "would this sub-project be worth completing if the rest of the project stopped?". For example, a friend of mine has a big project called "Put on Conference". He has dozens of sub projects for it, one of which is "Conference advert broadcasting on radio". It would clearly be a complete waste to complete the "advert" sub-project, but then abandon the rest of the "conference" project! After all, if the event isn’t going to happen, there’s nothing to advertise! So, in that scenario, the advert sub-project is best listed within the project support material, which gets reviewed in the weekly review and triggers questions about next actions.

if you are working on upgrades or improvements to an app which all have independent value in themselves, then it may be worth treating them as separate projects. If they’re closely related (eg they are all updates worth making, but they’re supposed to get packaged into a single iteration of a new release) then you could have them as independent projects but with a shared prefix so that they sort together. Eg “UPDATEX-bug fixed”, “UPDATEX-night mode added”, “UPDATEX-new sync feature integrated”, “UPDATEX-homepage restructured” etc.

Ultimately, it’s whatever gets these desired outcomes off your mind, and you get them off your mind by recording them in whatever way works best for you to be able to trust that they will trigger you to ask the necessary “next action” questions required for keeping them moving.
 
Last edited:

Oogiem

Registered
'm not sure whether "develop app" should be an area of focus (level 2) instead; sometimes its large enough scope that it does become an area of focus, but often projects like this feel like they live in a middle ground.
For me my programming project LambTracker is a clear area of focus. I have over 200 open issues and some of them are months worth of programming with multiple projects.

Example:
One open issue is documented on my post-it note kanban system as " Handle recipients and donors for embryo transfer" That's going to end up being multiple projects: "Implement data collection for embryo class, freezing method, storage locations etc", "Implement pedigree tracking for stored embryos", Verify how USDA wants imported embryos tracked and documented", "Ensure NSIP/LambPlan/Bvest etc can handle EBV calculations on embryos and their recipients as a contemporary group when sires and dams are dead" just to mention a few off the top of my head. I think when I am actually tackling that task (probably not untiI have lambs produced by embryos to register) I will end up with 20-30 projects to complete it.

My question is: At what level of granularity should a project live? Do you use nested projects ever? Should I even be tracking a project like this, or just swap it out for 3-5 smaller projects that are more specific?
Personally I make things very granular and no I do not use nested or sub projects. I find many more projects easier to handle that tracking things in a nested structure but YMMV.
 
Top