How we run our projects at Azuki

We thought it would be helpful run through how we run our projects here at Azuki. We try and keep it lightweight in order to stay agile but also have pretty clear method for successfully delivering our projects.

Scoping

We start off with a couple of emails, phone calls or meetings. This tends to be enough to get a reasonable understanding of what the project is. From this, the client or we will produce a brief.

Brief

The brief will describe the solution at a high level and how it’ll be used. We may start covering some technical tools that could be used. Depending on the project, Azuki can provide the client with a ballpark estimate. Whether we can give one really depends on how many unknowns there are left such as which technologies are right for the project and how some of the bigger features will be implemented. If we’re unable to give a ballpark estimate, we’ll find a way to get to that point; either through a couple more conversations or, in unusual cases, with some paid-for scoping effort.

Assuming the ballpark estimate is acceptable to the client, we’ll move on to analysing what we’re actually going to build and look into the how.

Statement of Work

Azuki will generate a statement of work. The statement of work is a document which gives clarity around the project scope, what will be delivered in unambigious terms and timescales for those. It also describes how the project will be run and how payment is expected to be made. The statement of work and associated user stories will describe what will be built and how the project will run.

At Azuki, we’ve tried to take some of the positive ideas from the Agile methodology such as fast iterations and user-focused development.

User Stories

We like using user stories because they keep the focus on the person using the solution. This is something that Azuki will generate. They should provide a user readable list of functionality. Any technical undertaking that doesn’t appear as a user story is covered in the statement of work.

Milestones

The user stories will be grouped into milestones. These milestones will be used to generate a schedule for delivery. Sign-off will be required at each milestone, at which point, invoices will be sent.

Development

Once the functionality is agreed, we can start developing the solution. At Azuki, we want the client to be part of the project and have strong visibility of progress. The user stories & milestones will be put into a project management solution such as Trello to which the client will have access.

We like to get feedback often so at the end of each milestone a testable version of the solution will be shared with the client. It’s the client’s responsibility to take a look at it and feedback. This allows us to identify problems early and make changes accordingly. This can save lots of time (and money).

If we come across a major unanticipated issue or we start to expect delays, we will raise it with the client. There’s no getting around it – this happens sometimes and, in our experience, talking about it early is always better.

We try and stay really flexible, so if the scope changes, we can normally reassign budgets around within the project if needed.

Delivery & Beyond

As we reach the final development milestone (and probably earlier), we’ll be getting ready to go live. This could mean deploying to the App Store or deploying a production hosting environment with the relevant domain names. This is a process that we can do ourselves or can assist the client with.

We take pride in what we build so once the solution is live, we’ll be around for an agreed period of time to help with any major issues.

After the initialy live period is up, we’ll enter into a support & maintenance contract which will cover unexpected issues and general updates.

We’re in it for the long term and we’ll be around for future development on the project.