In part 1 I covered how to find a freelancer. In this part, I’ll talk a bit about how we run our projects smoothly.

I’d suggest that the number 1 reason why most projects have problems is due to communication. Do any of these sound familiar? You thought you made the brief clear but it turns out it wasn’t precisely what you meant. That crucial business workflow that is obvious to you has been misunderstood by the developer. The developer is telling you it’s all on schedule and then you find out at the very last minute that it’s not. You get the picture. I’ll try and give you some tips on how to minimise these.

Before kicking off the project

Now you’ve found the developer you want to work with you need to make sure that you’re on the same page. Communication is key to a successful project.

• Good brief

  Write a brief which contains enough information about what you need. This usually requires a face-to-face meeting. If it's detailed enough, this can be used to sign features off. For our projects here at Azuki, we produce a brief and a set of low-level user stories. We find this is usually enough to have clarity about what's needed.

• Milestones

  Group the user stories and/or features into logical groups and turn them into deliverables. This means that the developer will be able to deliver something to you early on. Set a delivery date for the first milestone.
  The developer will also be able to give you an ETA for the other milestones but be aware these could change if there's a lot of feedback.

During the project

So you have a schedule and the developer has started to work. Definitely leave them to get on with things but you also need to see something.

• Preview

  You'll want to get early previews of the developed application. This puts everyone on the same page about where things are. It should be hosted on a staging environment in order for you to play with it and to put in test data.

• Communication

  As the developer is thinking about how to build the next feature, they will sometimes require more information from you. This can sometimes block development so make sure you're available to deal with questions.

  We find that asynchronous communication works best for us because we can ask questions and leave answers when it's a good time for us.
  Sometimes we make ourselves available via instant messenger (using Slack for example), but with the expectation that we won't always be available.

• Project management tool

  It's a good idea to store the information centrally because no one wants to deal with long threaded email chains discussing features. We use a few different tools depending on the project like Basecamp, Pivotal Tracker. Trello is one of our favourites. It's simple, free, it can store all the user stories, it tracks conversations about them, and allows you to see progress at a glance.

On completion

Now that the job is done, you’ll want to make sure that you have an ongoing relationship with the developer for support/maintenance and possibly managing the hosting.

• Support & maintenance

  Again communication is key. Be sure that you are all clear on what is expected from the developer. What is covered? What turnaround time will there be on handling issues? How much time can be spent on support? Should the developer be monitoring the system?

I hope these posts have been useful and do get in touch if you want to chat about anything from project management to running a successful project.