Managing yourself: Planning a project

I'm starting a series called "Managing yourself". I'll be posting bite-sized techniques for a productive solo indie life.

Specs document

When I did contracting, the client cared about two things only: Time and money. First, they wanted to know when the project is going to be completed, and second they wanted to know how much it was going to cost.

Answering these questions involves preparing a specs document. It's an in-depth overview of all that we're going to build for the client.

One of my Excel plans for first version of FocusList.

Indie planning

Specs are not only for contractors. It's the opposite. For indie developers they are even more important. We tend to work on things as they come, not really thinking about overall picture - and often times it's a good enough approach, but...

It makes you tired. It means you are doing two jobs at the same time: Engineer and manager.

When you plan ahead, you first do your manager work, and then when you switch back to engineer. As enginner, you pick the next task, write some code, pick the next task... It's easy life.

I don't start a project without knowing what work is involved, how much time and money it will cost and when it will be finished. This is my manager homework and I always do it before jumping into coding.

Create the wireframe

Start drawing all the screens you'll want to see in your product. Think about possible variations. Don't try to get the UX perfect. You're doing this to figure out all the features.

I typically draw this on a big piece of paper and write a structured Markdown on my computer.

Plan diligently

I try to go into as much detail as possible, making sure that everything is clear. Imagine you're building a todo list and come up with this "Feature 1: Manage tasks"

What does that mean? Adding? Editing? Copying? Reordering? Checking off? Pasting from another program? As you go into detail, you might discover some things are going to be much harder than you thought.

In my favorite book, Astronaut's Guide to Life on Earth, I read about what astronauts do when preparing for some operation - they go through their lists over, and over and over again, until they're absolutely sure they didn't forget about anything.

I try to do the same thing in my planning stage. Just thinking over and over: What feature I could've forgotten about? I draw more wireframes and imagine more interactions, and many times I discover I forgot something important.

This part is hard and it takes a lot of concentration, at least it does for me. But if you're diligent in this part, you'll have much easier time later on.

Write the stories

As I draw the wireframe, I write down all the things user wants to do, all the features the app will have.

It's quite easy when you have the wireframes. You just imagine using the app and write down everything you want user to do. Nested lists are a great way to build a nice, structured document for these specs.

The goal is to have a complete idea of what the product will do. Go over it a few times, like the astronauts do, to make sure you didn't forget about anything.

Making estimates

Now I have a Markdown document with complete, well thought-through list of feautures. It's time to decide how much time will each of these tasks take.

I used to estimate tasks by hour, or by number of Pomodoros. I would just write down "4 hours" to certain task, and then I'd sum them up, divide by 8 hours in the day, and I would get a number of days needed.

Since then I've moved to the point system and Pivotal Tracker, but I'll describe that and how I'm using it in the next article.

Further reading