From Idea to Plan

We looked at [estimating](/stack-report/shipping-software-on-time-and-on-budget/), and [not doing R&D in production](/stack-report/avoiding-rd-in-production/), which give us a framework for both coming up with a schedule and avoiding one of the main risks that it will face. We looked at [personal productivity](/stack-report/getting-stuff-done/) so that you can predictably move your projects forward day to day. I want to round out the year by talking you through a framework for getting from those first, high-level, ideas to the basics of a plan. Where that’s something with enough grain to it, so that estimating the work involved, and then matching that work to a calendar actually makes sense. With those four pieces in place, you’ve got the foundations of everything you need for solid forecasting. Can you deliver on time and on budget? Yes, you can! There are more complex things you can do, but you have to do the first bits first. That’s why they’re “foundational”. If you’re doing them right, you’re in the top decile of all teams out there. For small teams in particular, you likely don’t need anything more. That’s the plan. Let’s go! ## Ideas are not enough The challenge is getting from a bare idea — something that I just jotted down, one among many — to enough of a plan that I can break it down, estimate the tasks, and consider scheduling. We require an example, so I’m going to take the one I always use for Neapolitan: “A Bookmarking app for URLs, written in Django”. The sentence in quotes there is 8 words. If I’ve brainstorming, I’ve likely got not even that. Along with a list of similar one or two word bullets — maybe three or four that keep bubbling up when I do this kind of thing — I’ve likely got just the single word “Bookmarks”. Thinking about the year to come, I pick this project as one I want to commit to. Wouldn’t it be good to ship that? Dutifully, it goes into my list of goals for Q1 — let’s get it done by March — “Bookmarks”. > The story here is meant to be illustrative: fill in your own examples. I know you have them. In the well-trodden path of _How Software Projects Go Wrong_ — answer: one week at a time — it often happens that we get to the end of March and our “Bookmarks” project is not really any closer to shipping. A lot of — well, at least some? — work has been done, but it was a lot more complex than we thought, and actually… Well… — you know the story. Not to panic though, we’ll put it down for Q2, and get it shipped then! And so it goes. This is again the [failure to estimate](/stack-report/shipping-software-on-time-and-on-budget/) that we’ve talked about before. We didn’t think about the hidden complexity. We didn’t guide ourselves to the crucial things we should be working on, and those distractions that we (crucially) shouldn’t. We didn’t give ourselves an idea of scope, that would help us answer whether this project was even worth taking on at all. And in fairness, how could we, with nothing but “Bookmarks” to go on? At the same time, our bookmarks project wasn’t the only thing we wanted to get done this year. So, we wrote down two or three other bullets next to it. If we’d have been realistic, each of these was a significant commitment, that required a focused stretch of effort if we were (really) going to push it forward. But we weren’t realistic. So, each week we worked hard, and maybe got a bit of time on each of our goals. But not enough to move the needle. Each week we carry forward almost the same few bullets. Each week the mental pressure builds ever so slightly, that we’re not achieving our goals. Eventually, the year takes over, as it always does. Our weeks are consumed by the day to day, and those goals we set in January just get paused. It’s OK. They’ll be there ready for us to write down for next year in December. If we don’t do the planning, we sabotage ourselves. That’s why the framework for fleshing out our ideas is vital. Anything so that we’re not left with (just)“Bookmarks”. § Before, then, you commit to your new year ideas — before you write them down as if you’re going to work on them in Q1 — for each one, create a doc and go through the following questions. We’ll see you at the bottom for what you do after that. ## The Elevator Pitch Step one is telling me the elevator pitch, the _why_. > I see hundreds/thousands of links go past on tech news sites and social media. I can never keep track of them. I want a bookmarking app to let me easily capture links and then **find them again**. That’ll do. There’s a lot in there. I’m sure your mind is already thinking of options and alternatives. Those last three words in bold add a lot. My browser already does bookmarks. It does read-later too. But these are almost append-only, write-only lists. They don’t surface the links I saved in any meaningful way. Maybe I want sharing too? (I didn’t mention that, but now it comes to mind.) ## Define Done What does success look like for your project? What does “done” mean here? We need to know when we’re finished. > - A web app, online, to store bookmarks. > - Filtering by tag, site, when saved. (Others?) > - Easy saving > - Particularly for mobile. > - Possibly, a bookmarklet, web extension, or shortcut so the OS share menu _just works_. That’s a good start. Again it’s enough. A few things begin to pop-out. It’s got to be online, not just on my laptop. I see countless links on my mobile, and saving those for later is part of the point. The filtering is important: I want to be able to find the right links again. Often I’m browsing on a topic, so links saved close in time are often relevant. And the _easy saving_ — that’s a good one. I’ve got to be able to use it from my mobile, and that’s not as simple as you think. What’s the best way forward there? Not sure. ## Clear Points and Highlights We’ve started to find some unknowns. But there are some obvious bits too. > - Django > - We need user auth. > - Uses Neapolitan for the basic CRUD views. > - Django-Filter will power the filtering. > - Query: which tag library to use? > - Detail view needs to show related links > - Capture from mobile as main UI challenge. This is an iteration of what we did before. It clarifies quite a lot, though. All of a sudden, I can start to think in terms of time estimates, and **more importantly**, how risky those feel. I have an excellent idea of how long it would take me to bootstrap a Django application, with Neapolitan and Django-Filter. I can see immediately that the detail view is less clear. What exactly do I want to show there? There’s design work to be done. I can pause and dig into that now, or I can (for now) just note that uncertainty as needing to be addressed. That last item, though, stands out. As it is, I have no real idea at all how hard or easy what I need to do will be. ## Barriers & Mitigations At this point, we list the barriers that we face. What are the problem areas? What are the chief risks? We already spotted those, but call them out. Just doing so gets your brain working on them. > - Capturing links from mobile is the main risk. > - A bookmarklet or shortcut is probably easiest, but does this offer a good enough UI. > - Otherwise, a web extension, or even a mini app would be needed. > - Both of these are an order of magnitude more effort. > - The UI needs to be good enough to want to use. > - Even though this is just a personal app. No point making it if it just sits idle. > - What are my requirements here? By writing these down, it’s clear what I need to focus on. (Note that coding probably isn’t the issue — certainly not for the second point.) Given the requirement to use from my mobile, I could spend a day or two looking into bookmarklets and shortcuts. If I did this, I could see if one of those approaches was going to be **good enough**. If so, I can move to the UI question. Otherwise, I can evaluate whether the project is still viable at all. The worst-case scenario here is that a few days are lost showing that the simpler solutions on mobile don’t work, and I can shelve the project for the now. That’s a bit sad but, what I didn’t do was plough on with all the easy bits, only to find my project blocked later on, with all that time now potentially wasted. Note though how far we’ve come from when we just wrote “Bookmarks” down for Q1. We’re still a long way from a full task-breakdown and schedule but, we’ve got a risk-orientated set of steps that makes sense for our project. That’s better than the median project already, I’d suggest. We **don’t know** whether our initial investigation into bookmarklets and shortcuts on mobile will be successful, but we can time box that, by giving it no more than two or three days. We can probably also eyeball the design and Django implementation phases, to reasonable accuracy. So, we can plot our project against the calendar, and our other commitments, and already speak with some confidence to a potential schedule. Given that this is a small project, that might be all we need. We’re not far off. ## Non-goals The final step is to draw up a list of things you’re not going to do. The non-goals for the project. > - Crawling pages, to index content. > - Recommendations based on content. I’ll add a note field to my bookmark model so that I can add some text, maybe a quote from the page. I’m not, though, going to get into cleaning the HTML and indexing the full-text content **for this version**. All of that sounds great, but it’s not needed for my first pass, and it clearly would take the effort up, probably 2 or 3 times. I’m **explicitly** ruling out paying that price for this now. Writing it down as part of the plan helps us to keep on track. ## Onward to a New Year Following the steps above doesn’t give you a full estimate. You still need to [do the work for that](/stack-report/shipping-software-on-time-and-on-budget/). What it does give you, though, is an outline with enough texture to it, such that the estimating process isn’t spinning in the air — that you can actually do it. Breaking down an idea is a large part of the design work needed to do it. We’re natural avoiders of that work. Having a framework of set steps you can go through at the initial phases overcomes that resistance. It’s a powerful tool. As you’re drawing up your plans this New Year, give it a go. May it help you bring your ideas to fruition it the year that comes. Happy holidays, see you next year! 🎄