DRMacIver's Notebook
Anytime Projects
Anytime Projects
Something I’ve found over and over again is that there is a particular way of structuring projects that, when you can manage it, works very well. I call them Anytime Projects.Named after anytime algorithms, which are algorithsm which you can interrupt at any point prior to completion and they will tell you their current best answer. I’ve written about it a bit before but never really fully articulated what Anytime Projects are and why they work so well.
The distinguishing feature of an Anytime Project is that can stop at any point, and little of your time will have been wasted.
You make an anytime project as follows:
- You make a minimum viable version of the solution as quickly as possible. This might just be the status quo, or it might be some initial basic implementation of the thing you’re aiming at.
- You proceed in a series of individually relatively small steps, each of which leaves the project better off on completion.
Optional features:
- The project may not even be possible to finish. Many projects are amenable to constant improvement over time.
- It can be helpful to prioritise, so that you get a lot of the high reward to effort tasks done first.
For example, the way I clean the kitchen structures it as an anytime project. There is a well-defined end state, but it’s done in a series of stages, where each stage is fairly completable in its own right, and each stage being completed is an improvement.
In contrast, I recently converted my office in our house into a spare bedroomThe office moved into the “box room” which is basically a wide corridor joining the landing to the bedroom, and that I used as a slightly awkard storage and study room before, so this is no great hardship, except for the actual process of doing the rearrangement. I actually like my new desk position better than my old one., and the priority was getting the new room usable in time for someone to use it, so my first step was rapidly extracting everything from the office, much of which got dumped in my bedroom.
This was not an anytime project, because although I made clear progress on getting the office ready to become a guest room, I did not leave the system in a state where it was interruptible if I wanted to be able to sleep that night.
This is, I think, one of the key feature sof an anytime project: At any given point, you are a relatively small amount of work from just being able to stop.
Why didn’t I do it that part as an anytime project? Too many moving parts, too many dependency chains. I probably could have if I’d put in a bit more forethought, but it would have been more work and taken longer on the most important metric, which was getting the room ready.
This is true in general I think: Unless something is very naturally an anytime project, it’s usually going to be more work to do it as one, and there will often be a faster route to any particular point than doing it that way.
So why do things as anytime projects?
One reason is just the definition: Whenever you end up abandoing the project, you’ll still have ended up with something usable and worth doing.
But secondly, it’s actually been my experience that anytime projects are much more motivating, and the result is that you’re less likely to abandon the project! When there’s a huge amount of work in front of you before you see any results, it can be quite daunting. If in contrast you are presented with a constant stream of easy ways to improve the situation, it’s easy to keep going until you’re done - it always feels worth it to do one more thing.
It’s also possible to have many anytime projects on the go and pick them up and put them down as and when you’re motivated to do a bit of work on them. A blog is an anytime project, as is most software once it’s in a releasable state - you can sit down, do something to it, and make it better by publishing an article or adding a feature or fixing a bug or something. This makes anytime projects a more natural part of your life than many larger more monolithic options.
Some things you end up wanting to structure them partially as anytime projects. e.g. right now in the room move, dealing with the fallout of it is an anytime project. After I tidied up the worst of the stuff I’d moved into my bedroom, my bedroom and new office are usable, but there’s still a lot to do, but I can just do it in small life-improving chunks each day.Sometimes I even do that.
I think there’s often a very natural split of a project into two phases: An initial prototyping or drafting phase where you do whatever is needed to get some usable first version, and then an Anytime Project of finishing it off. e.g. I’ve often used “writing a book” as an example of something that isn’t an anytime project, but I think this is only sortof true. Writing a first draft is not, but after that draft is written there’s a long process of editing and improvement which does mostly naturally fit the anytime pattern of project design.
I’ve thought of myself as bad at completing projects in the past, but I think perhaps what I need to get better at is completing drafts. In Completing Completable Projects I identified the idea of a mode shift in projects where the sort of activity you need to perform changes as the projet nears completion. I think at the time I didn’t notice the transition to anytime as a mode shift because the project I was talking about didn’t have an editing phase, but I think this is notion of mode shift is perhaps a good way of thinking about project planing: The first stage of a project is to get it into anytime mode, as quickly and easily as possible, and then after that you mode shift it into an anytime project.