Discovering the Personal Program
In Search for a Missing Piece in Contemporary Productivity Jargon
In the first post of this series, I left you on a cliff-hanger. I put forward the idea that tasks are small replicas of projects. Then I asked: what are projects small replicas of? In this second installment, I’ll attempt an answer.
The limits of my language mean the limits of my world.
– Ludwig Wittgenstein, Tractatus logigo-philosphicus (1922)
If we take the concept of a project one level up, we end up with some kind of major working theme. One that spans many projects instead of tasks.
Due to a lack of terminology for this, I started browsing through corporate project management literature and found: managed sets of projects are called "programs".1
So, for now, I will stick to the term and state that a personal program is a collection of related projects to reach a big outcome.
Of course, the "real" definition is another one. It's that a program is a zoomed-out version of a project. A project is a zoomed-out version of a task.
This implies that by looking at how we manage tasks (and projects) we can learn a great deal about how we can manage programs.
So, let’s put it to the test.
Can we extrapolate from tasks & projects to programs?
Recall the seven best practices from the first article:
Name them precisely
Assign a time constraint
Set Priorities & limit the WIP
Make them appropriately small
Determine the execution context
Rephrase lingering items early
Beware of pseudo-manifestations
This is how I think they apply to programs:
Name them precisely — Tasks benefit from clear physical actions ("Outline article"). Projects from tangible outcomes ("Publish first article on blog"). So a program should probably be named after a whole portfolio of related results ("Kick-off fractal productivity series"). On higher levels naming gets more fuzzy and open for interpretation, making it more important to deliberately think about properly naming it. The program example given here may include projects like "Setup new blog", "research fractals", "publish first post", "get ten first subscribers". In a way, projects define the outcome of the program. But just as with projects functioning as a "target" for related tasks, we should name programs after our intended target, keeping the actual projects needed to get there open for modification.
Assign a time constraint — On the task level, it is "good to have" do/due date sometimes; the effects of single slip-ups are marginal. Rescheduling, repurposing, or reframing a single task is easy. On the project level, it’s arguably more important since over-due projects quickly add up in rescheduling and reframing. Other modifications require more maintenance, which can result in stress and overwhelm. Carrying that forward to programs, it is crucial to limit the timeframe on this level since the effect of keeping such big endeavors alive for too long could disrupt our whole life. During a program, we purposefully neglect many other parts of our lives and want to avoid dragging on too long.
Set Priorities & limit the WIP — WIP limits also seem stricter on higher levels. Let's say we were to cap ourselves for 12 tasks a day; then probably only a handful of active should go in any week, and in turn, we should program limit to one - but max. 2 - with most of the time being zero in the count! This is an important point. Just because there are programs doesn't mean that you always need one. You rarely do. I think 2-3 programs a year is all that most people will be comfortable handling.
Make them appropriately small — With the above, programs are already limited in scope, time frame, and number. But we also want to constrain the "size." A "small" program refers to the number of projects it requires to reach the outcome of the program. Just as with tasks & projects: the smaller, the less procrastination we succumb to and the more momentum we gain by actually completing them. The limit here I believe is quite constant across all three levels, as the bottleneck is always the same: our mental capacity for thinking about multiple things at once. So is the limit on average somewhere between 3-7.
Determine the execution context — While many of the practices seem to get more important as we zoom out, this one seems to go the opposite direction: meta-information is very useful on a task level (time & energy available, exact location, access to a computer or only phone,...), only somewhat interesting on a project level (work/personal/on-the-road setup), but hardly necessary for a program. This is probably because in order to even start a program, we need to rearrange our lives slightly, and by doing so, we essentially eliminate a lot of the context switching.
Rephrase lingering items early — A program that survives the battlefield for more than a few months will probably not be sustainable and cause havoc in some form or another. It will either burn you out or bore you to death by lack of variation in your work. So, just as for tasks and projects, we should regularly ask ourselves if we violated any of the other practices.
Beware of pseudo-manifestations — The likelihood of encountering pseudo manifestations also gets weaker from tasks to projects and I assume it's not that hard to avoid it on the program level altogether since there is only a decisive point - the program kick-off - where you can go wrong.
Note that I make a lot of inferences here. I haven’t completed enough of these "programs" to speak from practical experience. Writing a Master's thesis, building an iOS app, and my first marathon would qualify. But I did not call these programs. I wasn't aware of the concept. So there was no way for me to treat them as such. Instead, I winged them. It always worked out, but it often was stressful and came with feelings of high uncertainty.
Now, as I became more project-oriented, the need for such higher-order projects arose more often. So I wanted a way to systemize and principle them.
And that’s when I discovered personal programs.
I believe, that if we stop maintaining projects that span many orders of magnitude, we can enrich our suite of mental models. We can make it easier to reason about different units of work. We can bridge the gap in reaching big goals while working on small projects. And at the same time, we can hope to reduce confusion in communication, making it valuable to also experiment with programs on an interpersonal level.
In exploring this topic I found many good reasons to coin a new term.
So far, all of this is just an intellectual exploration.
So in the third part of this series, I will lay out crystal clear before you, what the practical benefits of programs are.
I’d be happy to hear from you in the comments.
oldie but a goodie