Your business needs mean that you need to build something that lies outside the realms of simple websites or e-commerce solutions.

You want data-rich applications, need to expose information for analysis, or need a business specific data dashboard. The list here is long and varied.

We're available to support whatever you need, whether that's just some advice or full design, build and management. With 20 years experience building applications to support any business need, you're in good hands. You bring the requirements, we deliver the results.

Our process, based on industry best practices, follows a simple formula, but at the heart of it is communication with you, your business, and the people who will be using the application.

From the first point of contact, you will have direct access to the people who will be completing the work, no account manager, handler or sales and marketing people. You've come to us for technical expertise, not to be sold more than you require.

How we work with you to build your application

Software used to be pre-specified all up front and then handed off to a software team to build, then after not hearing anything for months or years, something was delivered. Invariably, in the intervening timeframe, requirements changed, parts were left to interpretation, or just missed and the returned product was wrong.

We don’t work that way.

Our process, based on the Agile Manifesto, follows industry best practices and aims to provide constant and consistent communication with you, the client and your business to make sure that everything is on track.

From a high level our process is as follows:

Arrow icons made by Lyolya from www.flaticon.com

More detail on each stage is provided below.

We also use the ShipIt Journal Workbook journal designed by Seth Godin as a general guide and source of inspiration.

Interaction, information and outcomes of all stages will be fully documented.

Kick-off meeting

This initial meeting is where your team meets ours - this will be full of awkward intros and the obligatory presentations. We’ll use this time to discuss the high-level project aims and outcomes, and discover or storyboard out any sticky technical issues.

The meeting can be as formal (or informal) as you like, but outcome of this initial meeting is primarily to open up channels of communication, not to come up with a finalised and signed-off design.

Requirements Gathering & Planning

Sometimes called the ‘consultants invasion’, this part of our process involves our team talking to people involved in the outcomes of the project. This doesn’t mean just the decision makers; we’ll want to talk to the people who actually do the work, those that will ultimately be affected by the implementation of the project. Sometimes this will involve building basic prototypes in order for our team to full understand the internal business processes.

The aim here is to ensure that the project proposals will provide benefit, that they meet expectations to all that will be using the work and finally that we fully understand the criteria for success. Not everyone in a business has the same view, requirements or understanding of outcomes.

Once our team has gathered and confirmed all the requirements, we’ll be able to provide an initial plan and outcomes document that feeds into the initial design stage.

Initial Design

With all the requirements and outcomes collected and an understanding of the technical constraints, we will produce an initial design.

This will be a living document for the length of the project.

As with all things, project elements can, or rather will, change; there’s a new requirement, or the focus of the business changes, or some new technical constraint comes to light, so the contents of this document will also change to match.

The initial design document will cover some or all of the following elements:

• designs:
  • application
    • user interface
    • elements and experience
  • infrastructure/hosting
  • architectural
  • API outline
• work breakdown
• element build sequence
• technology breakdown

This document will also cover the final delivery arrangements.

The contents of this document are shared across all stakeholders to check and approve. Once this is complete, we’ll move onto development.

Development

The real work starts here. We should have everything that we need to get started.

From here the dynamic changes somewhat: we’ll build something, present it to your business, high-five..., rinse and repeat until we’re done.

Sprint 0

This is the initial project set up stage. We set up the development and staging environments, make sure that we’ve got all the frameworks and libraries we think we’re going to need.

Initial iteration length and outcome is set here and the first Show and Tell meeting is booked.

We also use Sprint 0 to double check the element build sequence given in the initial design, to ensure that everything will run smoothly.

Iterations

Our software build process is basically: build a little bit, check, build a bit more, check and change stuff, etc, until complete.

The length of each iteration is typically 2 weeks.

Build

Software development happens here. It’s that simple.

Show and Tells

We use the Show and Tell to demonstrate what has been achieved since the last get-together. All relevant stakeholders are invited to see how things are shaping up.

This meeting is the point where changes to the following parts of the of the process can be discussed and made:

• any part of the initial design
• iteration length
• show and tell frequency

We’ll also agree what the next set of deliverables are for the next Show and Tell and when that’s going to happen.

These meetings form part of the design document, so that changes are minuted and approved.

Delivery

After the final Show and Tell and everything is delivered as required, we’ll package or deploy the project code as specified in the design document.

As delivery is highly individual to any organisation, this needs to be determined ahead of time so that everything runs smoothly.

Sign off meeting

We’ll ask for this meeting a couple of weeks after delivery. This gives all stakeholders the chance to use the application and determine if there are any issues that need addressing or changes required.

Post-delivery support

We usually offer 4 weeks of remedial support and bug fixing for any project that we deliver. Any work outside of this time will be by negotiation only.

Our support contracts can be tailored to your exact requirements.