I utilised some of the concepts from this article in a recent post here. I’m going to make some connections here between the content of the article and how I used it. Broadly my recent post is about avoiding overwork in ~7 day burst projects.
Quotes are from Overreach Summary.
When you create more new errors than your error correction capabilities can keep up with, you’ll build up a backlog or queue of unsolved problems, and it will grow indefinitely. As the backlog gets large, you’ll be overwhelmed and criticism will become unpleasant, and you’ll start ignoring most errors without addressing them. Criticisms point out errors, but that is only useful if you’ll actually fix the errors. If you have more errors than you can handle, then finding out about more doesn’t help you and exacerbates your negative feelings about the situation.
You mention burnout once later in the article. I don’t know if you have a specific concept of burnout and I don’t think there’s a clear definition of it elsewhere (and certainly not one that I think is very good). I think this paragraph could be a decent explanation of the underlying process of burnout.
Burnout is something I inflict on myself from time to time with overplanning. Part of my recent post was recognising this and trying to come up with a better way of planning.
Theory of Constraints helped with some of my more advanced understanding of budgeting, e.g. by its discussion of buffers – instead of trying to spend all of a resource, you should aim to leave some extra resource as a margin of error to deal with variance. In The Goal, Eli Goldratt explains why a balanced manufacturing plant is a mistake and aiming for extra capacity on most machines is better. In Critical Chain, Goldratt explains leaving buffer time in project schedules and why it’s better to have buffers at a higher rather than lower level (e.g. have a buffer for the whole project instead of adding buffers to individual tasks).
This is a major component of my recent post. In the context of a one week project I’ve decided that leaving a buffer time of 2 days is reasonable to start with. Then I can use this time to complete project goals that take longer than estimated, or if I complete the primary goals on schedule I can use the buffer time to complete secondary goals.
In addition to that, I’m effectively adding buffer time in to my daily project plan too by planning to only work 5 hours a day on my burst projects and to only plan the project goals around this rate of work. This leaves time for personal care (such as exercise and diet), continuing to study and learn, and having freedom to rest as needed while still completing the project. I can spend more time on the burst project if I want to and it isn’t a problem; the point is to plan the project so this isn’t needed.
So the total burst project planning commitment is 25 hours in a week (which seems easy), and the primary goal planning of the project is built around that time frame. This leaves 10 hours (i.e. 2 days) of buffer time to complete the primary goals, and extra time (say another five hours a day) that can be spent if it isn’t problematic. Secondary goals can then be optionally completed if there is time left over in the buffers. As a rough estimate I don’t think I can spend more than 60 hours a week on a burst project without giving up other things I think are important and/or getting a few days of burnout. This is something I’m going to continue paying attention to as I’m not confident of that 60 hour estimate.