emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: "Sébastien Gendre" <seb@k-7.ch>
Cc: Tim Cross <theophilusx@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: How do you manage complex project with Org-mode
Date: Sun, 20 Mar 2022 13:06:48 +0800	[thread overview]
Message-ID: <87wngpdxg7.fsf@localhost> (raw)
In-Reply-To: <87czj4t6yc.fsf@k-7.ch>

Sébastien Gendre <seb@k-7.ch> writes:

> So, if you have any suggestion on how to manage, in Org-mode, projects
> with:
> * Lot of work to do (many days)
> * Short deadline (not enough time)
> * High importance (disastrous consequences in my future in case of fail)
> * Many of them in the same time
> * Progression need to be followed to chose where to sacrifice time to
>   limit the damages

I think that your existing system is already a good starting point. I
would not recommend changing it drastically. Every possible time
management workflow must be based on existing workflow habits (like
daily inbox review) and only introduce new habits one by one and slowly.

For your specific situation with many simultaneous important projects,
you are not alone. Every student meets similar issue.

My recommendations for managing multiple projects:

1. Similar to daily inbox review, do weekly/bi-weekly project progress
   review. You are already doing this. However, I am not sure about the

   When doing project review, I find it useful to create a custom agenda
   listing all the ongoing projects.

   Every time I review the project list, I select up to 3 projects I
   plan to work on from now till the next project review. All other
   projects are marked "HOLD" and their tasks will never be listed in
   agenda (unless there is some hard deadline or unskippable meeting).

   Review is the time when you decide which projects to sacrifice if you
   have insufficient time. Coming back to those HOLD projects after the
   review time is a no-no, unless you complete the planned projects and
   still have remaining time.

2. If you cannot complete a project within initially planned time, it
   may be tempting to continue until completion. Do not do this. It is
   better to try finishing the other planned project work first and come
   back to the partially completed projects if time permits.

   In Org, there are several tools you can use to address this:
   - You may dedicate each single day to no more than a single project.
     The project tasks will be scheduled to specific days and you can
     create a custom agenda that does not show tasks scheduled in past
   - You may use effort estimates for projects/tasks shorter than a day
     + non-nil org-clock-sound. If you create a habit to clock-in
     regularly, Emacs will play a sound when you run out of time.
   - You may create a rule to have at least a single easy 2-3 min task
     as "entry" point to a project you plan to switch to. Having a
     simple task really makes it easier to switch from working on
     current and already familiar project to other one.
     *This rule sounds obvious and simple, but I cannot stress more how
      much it changed my workflow once I got to follow this regularly*
The above suggestions are simple to list and somewhat obvious, but
not-so-easy to master. It is important to stick to them as much as
possible until they become a habit. They may take months to master.

> To manage school big work, I think of managing them as projects.
> I want to apply a simple "Project" workflow:
> * Each project is a headline with the status "PROJECT"
> * Each project have the deadline defined by the school work deadline
> * Each project have a complete description with every info needed to work
> * Each project have one or many tasks (as sub headlines with a status)
> * Each task have a importance, time and effort estimation
> * Each task have its own deadline, distributed along the remaining time
> * When I set a task deadline, I look at its estimations and also other projects tasks
> * To create a new project, I use Org-capture with a template

Just one comment. If you tend to have a large number of tasks in your
agenda, you are likely overusing deadlines and scheduling. I would avoid
setting deadlines for every single task. Too long agenda lists are
*counterproductive* in many ways. I recommend scheduling the whole
project (or subproject, it the main project is huge) + 1-2 individual
tasks. When you complete the 1-2 individual tasks, it is more productive
to look inside the project, and select next tasks depending on the new
results from the first tasks.

Hope my comments are useful.


  parent reply	other threads:[~2022-03-20  5:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01  1:43 Sébastien Gendre
2022-03-01  4:03 ` Matt
2022-03-02 19:44   ` Sébastien Gendre
2022-03-01  6:43 ` Dr. Arne Babenhauserheide
2022-03-02 20:00   ` Sébastien Gendre
2022-03-01  7:12 ` Tim Cross
2022-03-02 20:33   ` Sébastien Gendre
2022-03-02 21:55     ` Tim Cross
2022-03-20  5:16       ` Ihor Radchenko
2022-03-20 21:24         ` Tim Cross
2022-03-21  9:25           ` Ihor Radchenko
2022-03-20  5:06     ` Ihor Radchenko [this message]
2022-03-01 19:26 ` Antonio Carlos Padoan Junior
2022-03-02 20:53   ` Sébastien Gendre
2022-03-01 21:06 ` Milan Zamazal
2022-03-02 20:58   ` Sébastien Gendre
2022-03-02 16:29 ` Quiliro Ordóñez
2022-03-02 21:05   ` Sébastien Gendre
2022-03-01  4:38 Eric Abrahamsen
2022-03-02 21:26 ` Sébastien Gendre
2022-03-02 23:35   ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wngpdxg7.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=seb@k-7.ch \
    --cc=theophilusx@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).