Quantcast
Channel: Planning – Codenutz – all about how to make an app
Viewing all articles
Browse latest Browse all 11

Ensure Your Side Projects are a Success (and being honest with yourself)

$
0
0

Ensure your side projects are a success

Last year I decided to take some time away from writing my blog. The decision was not taken lightly, but was done so to allow me to focus my time on projects that I wanted to deliver.

I’m ashamed to say the blogging hiatus has lasted a lot longer than I expected. I initially planned to just take a few months off to focus on getting my head into Xamarin and delivering an app I was happy with. Unfortunately that didn’t quite go to plan!

I thought I’d start my return to blogging with something I’ve taken from the last couple of years work which I’ve never fully appreciated until now. I have attempted a number of different projects over this time with several highs and lows, but none have really paid off. One thing I’ve taken away is about being honest with yourself and have a little more critical thinking when getting into a new project.

Being honest with yourself

There’s a few things I’ve really grown to appreciate over the last year, one of which is about understanding the project you’re working on, and what capacity you can commit to it. Its important to identify if the project you’re working on is a side project – i.e. a project that is not the primary focus of your time.

For me, my time is mostly spent consulting for larger companies, working on larger projects with larger teams. On the side I’ve undertaken several other projects – I’ve developed apps, created websites, published e-books and so on, but in reality they were completed as side projects.

Its important to understand if you’re working on is a side project, as it can really help avoid some common pitfalls – pitfalls I’ve absolutely fallen down over the last few years. Sure you may want to build the next Snapchat or Angry Birds, and it may turn into your primary focus but in reality, most times it wont start that way. So be honest with yourself when weighing up what the project is, as it could save you some time and help you attack the problem in a more realistic way.

Before I go much further I want to say that side projects are totally legitimate and nothing to be ashamed of! Its almost crazy that I feel the need to say that, but personally I’ve historically avoided labeling things as side projects because I feel it somehow makes them less legitimate. But the truth is that many huge products started as side projects, and knowing that it is a side project will give you a much greater chance of success.

Is it a side project?

For me there’s a simple rule – am I spending more than 60% of my time on it? If not then its a side project.

  • If you’re working on another huge project then its probably a side project
  • If you’re working full-time then its probably a side project
  • If you’re consulting long hours then its probably a side project.

For example, lets say you allow for 8 hours sleep, that leaves you with 112 waking hours per week. Lets attribute 10 hours per day for full-time employment, commute and breaks – that’s 50 hours (given a 5 day work week). That 50 hours accounts for roughly 45% of your waking hours – at that you’re already at less than 60% available before taking into account eating, family time, exercise, downtime etc.

This can also be used when looking at potential projects, i.e. how much time have I got to spend on it – if its only 16 hours per week then in all likelihood you’ve only got the capacity for a side project. And you should only take on projects that can fit into a side project schedule.

How should you approach side projects

Given that you’ve identified your next (or current) project as a side project, here’s some some general purpose guidelines as to how you should approach or plan for it.

1. Limit your deliverables

Its really tempting to try and build a huge all singing all dancing solution, which is designed beautifully and works flawlessly, but in reality you have limited resources, and in my experience the further beyond 1 month a project goes, the less likely it is to be delivered at all.

For this reason its really important to restrict what you plan to deliver into a relatively short period of time, and then deliver it! This means one of 2 things – you either deliver the entire project in 1 month, or you break up your work into shorter ‘sprints’. The important part here is accountability of some kind.

If you’re delivering a project within a month, then accountability is easy. It should be in front of users / customers at the end of the month. This may mean sacrificing certain elements such as features, user experience, artistic merit etc. But you have delivered the project and it is in front of people – that’s a huge deal.

Its not always possible on larger projects, but you can break it into 2 week sprints and then have some form of accountability at the end of each sprint. The key is accountability at the end of each of those sprints – and ideally that accountability should be coming from your customers. So you could be engaging some potential customers and having them use you product after each sprint. But really I’d try very hard to limit the scope of your product to something that can delivered inside a month.

If your project cannot be delivered inside a month, or no part of it can be delivered inside a month I’d question whether its a good idea to take on a side project of that size and scope.

The main reasons for applying this constraint:

  1. Firstly delivering side projects is exhausting – you’ll likely be spending a ton of your spare time dedicated to this project, and having a distant delivery point destroys motivation. Having that delivery date within reach ensures you stay focused, don’t lose interest and don’t burn out.
  2. Secondly projects that lack early accountability tend to stray off path and either end up not getting delivered, or end up inappropriate for the problem they set out to solve.
  3. Finally putting that 1 month limit in there gives a natural break-point where you can rest, recharge and review what you’ve done.

2. Plan you time

I don’t know about you but my first impulse when embarking on a new project is to get straight to work – and ti seems to make sense right? You’ve got limited time and you want to get straight into the interesting stuff.

I can’t stress this enough but you must commit at least a small amount of time to planning your workload. Yes it may be boring, yes it may take up time that could be spent on making the product but t gives you so much more chance of actually delivering what you’re product.

I’m not suggesting you spend all your time planning, but without planning

  • You wont understand the scope of your project
  • You’ll almost certainly underestimate how long things will take
  • You’ll definitely overestimate how much time you’re going to have avilable to spend on the project
  • You probably won’t deliver inside 1 month….or ever

So adopt some form of planning. Personally I’d recommend a simplified Scrum process, where you work out what you individual deliverables are, break the work into tasks and deliver one task at a time. Going into my personal planning process is a little beyond the scope of this article, but the important thing to recognize is that a little planning can save a lot of time.

3. Write down the single, distilling goal of the project

One of the biggest pitfalls I’ve struggle with is losing site of what I’m trying to achieve on projects, and in particular what is most important. So I’d suggest as part of your initial project assessment you write down, in order of importance the goals you intend to deliver in the project. I’d actually suggest that getting it down to a single, distilling goal is one of the most empowering things to have.

Having that single, distilling goal will make coming to decisions so straight forward. It’ll save no end of time and should keep you on the right track. Once you muddy that with several goals, you all of a sudden have competing requirements and different stakeholders – all of which will slow you down, and in general frustrate the process.

For example, I have an upcoming side project delivering a website to buy and sell comics called Madcap Comics (UK). My primary goal:

  • Allow people to find and get in contact with me for casual comic back issue sales and purchases, as a periphery to eBay sales.

This is driving my initial sprint to deliver a really simple website, that looks well designed, and gives ways for people to get in touch with me, plus people need to be able to find it with a simple Google brand name search (i.e. using my eBay username).

Its really easy to visualize this project, really easy to understand how to deliver it and really easy to prioritize things. I could ask should I list all my comics on there – probably not, its beyond the scope of my initial deliverable. Should I do a little SEO work to ensure it can be found in Google – probably yes.

But if I expanded those goals to say:

  • Allow people to find and get in contact with me for casual comic back issue sales and purchases, as a periphery to eBay sales.
  • Accept online payments for comics with PayPal and credit card
  • Make managing my comic stock list easier

I’ve all of a sudden got several factors competing for my time. I’ll end up going in circles by developing a massive e-commerce solution for managing and listing comics, that accepts several payment methods etc, etc. Sure it may one day end up being that, but first out the gates is the really simple important stuff, that will help prove the commercial viability for the rest of my project.

But what if you deliver early? So what?!! Great, you have more time to plan your second sprint, or you can even start your second sprint early. Or maybe spend some time reaching your customers – but thats also for a different day!

I’m probably sounding like a broken record but I cannot stress enough how important having a single, distilling goal can be.

Wrapping up

I’m sure there’s more things and I’d love to hear if you’ve got any suggestions for things that help when completing side projects. I’d also add that the above points aren’t limited to side projects, but in my opinion I think we have a tendency to treat them as less important for side projects, but actually they’re more important – particularly if you want to actually deliver it!

The post Ensure Your Side Projects are a Success (and being honest with yourself) appeared first on Codenutz - all about how to make an app.


Viewing all articles
Browse latest Browse all 11

Latest Images

Trending Articles





Latest Images