It was during this period of just scooting around on the FZR that I realised that I needed to do a couple of things differently.
First up, I needed to accept that this restoration project was rapidly turning into a ‘down the rabbit hole’ experience, as I’d heard can happen with restoration projects. A flow-on effect from this was an acceptance that I really needed to do as much work as possible on my own if I was to stop this becoming the mother of all money-pits. The time alone that it was going to take to uncover and fix the things that I suspected needed to be fixed was going to be significant, so I needed to accept that I was now the one responsible for doing as much of it myself as possible, only outsourcing the really tricky or critical stuff to people who actually knew what they were doing.
Secondly, I needed to get better at planning my work.
It’s funny, in my work life I’ve been in and around project work for twenty years, and have a whole bunch of tools and techniques that can be used to run them, and yet in this project (aside from setting a budget) I’d not done much in the way of planning it out.
This had to change.
At work I’d been playing around with Agile product development methods. For those of you who haven’t experienced Agile as a methodology (or arguably a philosophy) before, it originates from the field of software development, and in very basic terms looks at defining and achieving smaller chunks of work on a frequent basis, continually revising the roadmap of works, and making sure that usable products are delivered frequently. There’s a lot more to it than that, but that’s the rough idea. It aims to eat an elephant in much smaller chunks, and without necessarily planning every detail of how you’re going to eat it before you start.
I realised that I had been spending too much time thinking about the end game of recreating my ’89, and not enough on thinking about what the many sub-plots could be along the way, noting that many of those sub-plots I’d not even written yet. Agile as a concept could help with this, as there is a regular focus on resetting plans, reviewing what has worked and not worked, and delivering usable stuff as a result. The problem I had with a highly structured method like this though was the time commitment. Common Agile methods like Scrum assume fixed-length ‘sprints’, which is fine when you’re employed to do stuff within that timeframe, but with this project time would be on an ‘as available’ basis, so running my project as a one-person Scrum team with fixed-length sprints wasn’t really going to work.
A method closely related to Agile principles is Kanban, a simple yet powerful method of organising tasks in a way that tracks everything that needs to be done at some stage (in a list called ‘Backlog’), keeps a focus on what is imminent, and helps estimate and review time needed for tasks. This seemed a much better fit for what I needed.
This led me to using an online tool that I’d been using in the workplace to manage my planning – Trello. Trello quickly became my single source of truth for planning the project. Any idea that I had about a task that I might need to do – dump it into Trello. Working out what to focus on next – check out what’s on the Trello backlog. Need to add reminders for later tasks to not forget an important point – make a note in Trello.
Even just being able to use Trello as the braindump area for the project has reduced my anxiety about the whole process. My greatest fear for this project (well, one of them anyway) was that the bike would end up in a million bits in a box, only to be put up on Gumtree with the typical story of ‘started the project and it got too big, make me an offer, just want it gone’, and knowing that all of my thoughts on what needs to be done and what has already been achieved is pure gold.
Although I’m writing this post a couple of months down the track from when I started using Trello and the Kanban method more generally to manage the project, looking back I think this was probably a significant turning point for me. I had accepted that this project was no longer going to be a couple-of-weeks job, and that many of the things that would need to be done I didn’t understand, or even know about yet, and I had found a good method for keeping all of these things in a format which took a lot of the fear and confusion out of it.
I had worked out that I was trying to eat an elephant, and I’d worked out what seemed to be a good way of going about it.
Up next: Putting lipstick on a pig.