Customer Brief

At Cogent Consulting, we want you to get the very best application that you can for the time and money you have available. As a group, we have many years’ experience in software development, and we’ve observed many projects where customers didn’t get what they wanted. In many cases it was simply because time, energy, and money were wasted on things that weren’t important.

We believe that the customer should be the ultimate arbiter of how the development budget is spent. We provide strong advice on how features could be built (technical expertise), but we defer to our customers on what features should be implemented, in what order, and to what level of detail. While we definitely need to have some idea of what we’re building, we don’t want anyone to spend too much time documenting details that turn out to be irrelevant, or writing down things that can be communicated more effectively by phone or face to face. Starting development earlier and with less detail actually gives us a better chance of finishing early. We also work in short iterations and frequently deliver working software to you in an environment that you can access. This is known as agile software development.

The benefits of this approach are:

• more development energy goes into writing software
• working software gives you a better measure of progress than documents do
• you can use the software yourself and decide if it’s right for you
• you have many opportunities to re-prioritise features, or even introduce new features midway through the project
• you get the very best system you can for the available time and money

However, with this power comes some responsibility:

• you need to use the software frequently, particularly when new features are delivered
• you need to be the final arbiter of when something works well enough (we don’t want to waste time gold-plating)
• you need to have a firm idea of what is most valuable to you
• you need to be comfortable with the concept that some things will turn out to be cheaper and easier than expected, and some things will turn out to be harder and more expensive than expected

What you can expect during development

We will have an initial discussion with you about scope, and put together a list of very short stories that describe what you want done, based on our understanding of your problem – think of them as bullet points that describe what you want your application to do. We’ll put some time estimates against these stories, and use these estimates to determine the initial project budget, staffing needs, and timeline. Once we’ve started, we also use these stories and estimates to track our progress.

We’ll set up some infrastructure, and then we’ll start developing the software in iterations that last one to two weeks each. We’ll give you things to look at within the iteration (often on a daily basis) so that we can get immediate feedback, and at the end of each iteration we’ll have a meeting (face to face or online) to check that everyone understands what has and hasn’t been covered in the iteration, and what the priorities will be for the next iteration. After that, we’ll invoice you for the iteration we’ve just completed.

We do our best to implement each story in the way you expect, but there’s a fine balance between doing it cheaply (which we’re sure you want us to do) and getting every detail right. We test and use the software ourselves, but we also rely on you to check what we’ve built and let us know if anything is wrong or missing from your perspective. Some people may want to use a formal software tester to make these checks, but most of our customers do it themselves.

When do I pay?

We’ll invoice you at the end of each iteration. Once you’ve paid for the iteration, everything completed in that iteration belongs to you.

What do I pay for?

You will be invoiced on a time and materials basis for the project. In most cases, that means a daily rate for the people working on the project. Each invoice will list the person that did some work on the project, their daily rate, and how many days they worked on the project.

We may also pass on some material running costs to you for the project. In particular, this will probably include the hosting service we use to get the software running in a staging or production environment. Weʼll pass management of these accounts over to you as the project progresses, but it makes sense for us to set it up first.

How do we know when the project is finished?

In some sense, a software development project is never finished – there will probably always be some things that you wish worked differently, or some new things you could add, or some defects that you trip over occasionally. Two things constrain your project – the amount of money you’ve put aside for development, and the amount of time we’ve allocated. Development stops when one of those things runs out.

We’ll make sure that getting your application into a production environment happens well before the end of the project, so that you can start benefiting from the application as soon as possible, and so that there aren’t any unpleasant surprises when we get to the end of the project.

Of course, you might also decide that we’ve built exactly what you need and you’d like to stop development, even though there’s still time and money left. In that case, we’d appreciate two weeks’ notice, so that we can manage our own time effectively.

What about defects?

We expect that there will always be things that you’d like to change about your software. Some of them you may see as defects which need to be corrected, and some of them may be enhancements or modifications you want to make. Unfortunately, we don’t have an indisputable way of making that distinction, so instead we treat every change as simply that – a change.

Some software companies say that it’s possible to make this distinction if you start with very clear specifications – then, anything that doesn’t work as written in the specification is a defect. However our experience is that it’s time consuming, expensive, and very difficult (if not impossible) to write specifications that are actually explicit enough to be helpful. Even if you do manage it, these detailed specs become outdated very quickly, and are usually too rigid to allow for necessary modifications we may discover along the way. We try to avoid this by writing automated tests to catch regression, by making the working software visible and available to you, and by giving you control of the priorities in each iteration. We acknowledge that’s not a perfect solution to the problem, but it works well for us and our customers.

Supporting the software after release

When we release your new software, we will recommend a hosting environment that we believe is reliable and appropriate. If you encounter problems in the first three months of operation (the run-in period) we’ll classify them as follows:

1. Hosting service problem. We’ll work to rectify this at no cost, since you shouldn’t be penalised for our choice of hosting service.
2. Application configuration problem. We’ll work to correct this at no cost. It should have been uncovered during our initial installation, and you probably couldn’t have detected it yourself before release.
3. Application software problems. These are problems that could have been detected or uncovered during the development project. If the problem is stopping someone from using the application, we’ll endeavour to correct it as quickly as possible; otherwise, it will go onto the list of potential future changes. Application changes will be treated as extensions of development, and will be charged at the last rate we used during the development project.

During the run-in period, we’ll manage your relationship with the hosting service and pass bills on to you (with a small handling charge). After the run-in period, we’ll pass the relationship with the hosting service, including billing, directly to you (unless you’d like to make some other arrangement).

What are your support hours?

During the run-in period we will provide support for hosting, configuration, and serious application problems in your normal business hours (which we’ll agree on in advance). You’ll be provided with a support contact (usually one of the developers on your project), and this person will work on your problem once it’s been reported. If he or she can’t resolve the problem in two hours, we’ll call in other resources as appropriate and advise you as that happens.

And after the run-in period?

After the run-in period, any work that needs to be done will be treated as new development, at our current development rate.

What if things don’t go well?

If you’re not happy, please tell us. Of course, the software we create for you is yours, and you’re entitled to handle problems with it as you see fit. However, we’re committed to the quality of our work, and we want to work with you to fix any problems or issues you might have.

How do I get the source code that Iʼve paid for?

Source code will be hosted on http://github.com/ as a private project under the Cogent account. You should create an account on github, which we will link to the project. That lets you get complete access to the full history of the project at any time.