Project Management

Managing projects with multiple requirements, technologies and team members is like herding cats*. The success of every project comes down to controlling requirements, timescales, resources and changes. To this end, we put a lot of emphasis on managing the project both at our end and between us & the client.

The exact project management methodology we use is appropriate to a number of key factors:

  • The size of the project – two or three web forms or a multi-month program of work?
  • The complexity of the project – multiple technologies or many users?
  • The impact of the project – is it mission critical?
  • How new you are as a client of ours
  • The situation with your end users – is this part of a big project &/or for your client
  • Timescales

We aim to de-risk as much of the project so that we can ensure that we can deliver what you need, when you need it. So we write stuff down. At worst, we can go ultra-formal, using the UK standard called PRINCE2, for which we hold accreditation. Or reference the NASA recommended approach to software engineering. At the least, a Google Docs spreadsheet may suffice. Usually it is somewhere in between.

Start with something small

The first piece of work we do with any new client is a small project – something tangible but only a few hours work – because we both need to see how we get on, do we communicate well, how do we handle the change requests, support issues, deployment and so forth.

However we recognise that quite often new clients come to us with a larger project in mind. In this instance we look to make the project a proof-of-concept or prototype. We can talk about the larger project, but we won’t allow ourselves to get sucked in to the excitement of a big piece of work until we know we can deliver.

No fixed prices – sorry, just not realistic

Everyone wants a fixed price quotation, guaranteed timescales and promises no substantial changes to the requirements. This only works if we pad the price with so much extra cash you’ll need to win the lottery to afford us.

What we do instead is take the brief and produce a budget guide with indicative costs and timescales against each requirement. You can then add & remove items and change the running order to fit the projects requirements.

For each development cycle (a two week period generally), we can firm up the costs as the requirements become more clear, so you will know what you are getting in to. If there is an obvious gap in understanding we’ll come back to you immediately to discuss the issue. Most R&D we will subsume in to our portfolio but if we need to use our Google Fu or prototype to figure out how to do something a bit more esoteric, that’s billable time.


We don’t produce finished work straight out the box. The first data entry form may have little or no validation – or not all the fields – or not pick up live data from the database. Because until we’ve got a basic system in place, we may not be travelling down the right road for you. Experience tells us that until there is something in front of the end-user for them to give feedback on, it’s all a bit academic. Once they can see something vaguely working they can then crystallise their requirements and be more definitive. We think of this as a variation of Heisenberg’s Uncertainty Principle


We work on a two-week (aka fortnight) cycle of plan, code, test, release, review. So any active development work will normally be two weeks out from request.

Two members of the team have the breadth of knowledge and experience to make changes to all parts of the things we produce, so minor urgent changes are possible – things like changing validation, adding/removing a field, a tweak to the processing code, a change of colour in the CSS, an image update and so forth.

If we are not ‘in-project’, then support requests are evaluated and work scheduled pretty much as above, unless it’s apparent that the request is in fact a project in it’s own right.

System critical issues that arise are dealt with as a matter of priority. This has some boundaries and caveats on it – as long as the systems are on appropriate servers with trained users & sys admins we really don’t see such things coming up very often. But if they should, we will drop what we are doing to get things sorted out.


Everything the team principal, Nick, knows about flying (gliders/sailplanes, power, aerobatics) is that you aviate, navigate and then, only then, do you communicate.

Conversely, everything he knows about leading a software engineering project is that you communicate what you are doing, how you are doing, when it’s going to be ready, what the challenges are and so much more, in parallel to, and in preference to, actual development.

In short, we will keep you in the loop.

We ask you do the same for us.

That way there are no surprises for either party.

If you have a concern, a worry or a niggle, talk to us early please so we can work together to resolve issues before they escalate.


Our role is software engineering which needs some peace and quiet – so email only gets checked a couple of times a day. At worst, we’ll acknowledge the email and tell you when to expect a detailed reply. See our contact page for a timezone planner.


* Team principal, Nick, has six cats so he is very very good at this. The two chickens are equally challenging!