Our Approach to Django Projects

We start with the people doing the work

Not with the specification and not with management's description. With whoever actually does the job, watching them do it, asking why at each step.

The process as documented and the process as performed differ in almost every business we work with. Building for the documented version produces a system nobody uses.

Then the data model

Before any screen, we work out what the entities are and how they relate. That decision shapes everything after it and it is the expensive one to change later.

It also usually surfaces the questions nobody had asked — what happens to a job that is split, what a customer means when they have several sites.

One workflow in production early

1. The core workflow built and reviewed by week five
2. In front of real users by week six
3. Extended from what they actually do
4. Rather than designed completely and delivered in month four

If something is wrong, we find out in week six rather than after everything has been built on top of it.

Four things we insist on

• Your repository, your credentials, without exception
• Tests around the business rules and the permissions
• A deployment process and a staging environment
• A named owner in your business

How we communicate

A weekly note on the same day: what moved, what did not, what we need from you, and whether the date has changed. Short and honest.

If something is going wrong you hear it that week rather than at the deadline. That is the whole of our project management philosophy.

Frequently asked questions