This is a guest post from Richard Revis who is one-man army standing behind The Plan Is.
Which milestones have to be on your start-up plan?
I’m a project manager, so when I decided to start a new company the first thing I did was to draw up a plan.
Not everyone agrees that this is a good idea. The arguments against planning are numerous, and the biggest one is that in a start up things change so fast that a plan will be out of date before you get to day 2.
My own experience over the last two months has been that change is rapid and continuous, however the time I spent planning was not wasted as I am still working from the original plan with some minor updates. The key was to pick good milestones to aim for.
There are two types of milestones essential to any plan:
– Input milestones; these are things you do that reflect effort on your part, tasks like getting a website up and running, writing articles and technical milestones such as feature availability.
– Result milestones; these are outcomes of your work such as website traffic and beta sign ups. These show you how well the work being done is turning into customers, sales and money.
Only result milestones matter in the long run, however if you don’t hit any input milestones there won’t be any results. This is why both have a place on the plan. Input milestones drive you to get stuff done and keep you working hard. If you aren’t hitting them you have a performance problem that needs to be fixed.
In contrast result milestones are valuable because they tell you if your plan is a good one. If you are missing your result milestones then you need to know as that lets you change your input milestones to ones that will help you get the results you need to stay in business.
How do you pick good milestones?
The right milestones vary a lot by circumstance, however all your result milestones can be reverse engineered from one date – the day that you will run out of money. The most important thing on the plan is that by this ‘out of money day’ your income is larger than your expenses.
My own result milestones, such as customer numbers, sign ups, website hits, and anything else which I can’t control, are a guess based on data about typical conversion rates. For example a 1% website visitor conversion rate is normal for my industry, so my milestone is based around 100 times break even sales. Where data is bad or missing I have taken a guess and will update it when I find out how things really work. The milestone won’t go away, but some of the details might change.
Input milestones are even more variable and will depend on your project, however it helps if they are enablers for results. For example ‘website up and running’ is a good input milestone because it is required for you to be able to achieve your ‘first website visitor’ result milestone.
The input milestones for my company are very high level and look like most normal development road maps. For example you would see entries such as starting open beta and implementing one customer requested feature. These are spaced out about twice per month, so that I always have a goal in close proximity. Knowing I have to tell my advisers which milestones I have reached every month really pushes me to keep working consistently.
The goal is to have a plan to measure yourself against, not an itinerary of the next six to twelve months! By keeping it high level and more adding detail one month in advance you have the advantage of knowing where you are going without boxing yourself into a losing strategy or having to throw the plan away.
This will also help keep your plan more realistic, as you can tailor the exact nature of the milestone to the circumstances at the time. There’s not much point in adding milestones to your plan that can’t be met.
An example of the milestones I have been working to can be seen in the accompanying table. One is still ongoing but I’m pretty happy with how things are progressing so far.
The minor changes to my plan that I mentioned at the start of this article have all been caused by too much detail. The exact features delivered to beta customers were not important so changing one for another didn’t matter, however the overall milestone was critical to the company.
Having a plan is about helping you and the people you work with know where you are and where you are going. Selecting good milestones can make the difference between the plan being useful and a waste of your time.
About the Author:
Richard Revis has run technology development projects involving everything from iPhones up to front line fighter jets. He is currently Project Director at The Plan Is where he is developing web applications that make it easier to plan fixed duration projects. He writes regularly on project management and start ups at http://theplanis.com/blog