The database design process

The million-dollar question...

Will you give me a fixed price for the database?

The short answer to that is that yes, we can give you a fixed price.

But you might not like it.

You see, building a database is a bit like climbing a mountain. You can stand at the foot of it, having climbed many other mountains, and gain a reasonable idea of what’s involved. But there’s just no way of seeing every snag, every problem and every challenge that you’ll encounter. That’s just a fact of building databases, no matter how good and experienced the developers.

So that raises a question. What do you do when you hit an unexpected issue?

If we’re working as we’d like to, that would mean that you’re simply paying for our time. We’ve given you an initial estimate, and we’ve given you refined estimates after the design phase, but you’re paying for our time to turn those designs into reality. So, if we hit a problem that means it’s going to take longer than anticipated, you’ll end up paying more than anticipated… for that element of the work.

But in the fixed price scenario, here’s what happens. We know, just as you do, that we’ll hit these issues along the way, no matter how careful the planning. And we know that our developers have to be paid for their time, whether that time was foreseen or not. So when we produce our fixed price quote for you, we have to build into that quote, the time to fix things we don’t yet know about.

There are two laws of time management. Law 1 says that everything takes longer than you think. Law 2 says that everything still takes longer than you think – even if you take Law 1 into account.

And so we have to include a margin for issues for every screen, and every piece of code. Yes, that means that you won’t pay more than you thought you would. But it also means that you’re likely to be paying more than you could, and perhaps should, have paid. We assume all the risk, and to continue to operate as a business, it’s evident that we must mitigate against that risk.

How much is the margin? The most common figure I’ve heard from developers is that they will charge at least double on a fixed price contract. We typically charge rather less than that, but we also wouldn’t be able to produce the fixed price until we’ve got to the end of the design stage, and so have a clearer view of what’s involved.

Some clients don’t mind paying that extra for the security of a fixed price, and if that’s you, then fine. But many prefer to pay what it takes to build the database, and share that risk as well as the rewards.

Finally, I’d mention what Armen Stein, of US developers “J Street technology” says on the issue. If you’re paying for our time by the hour, and we hit a problem, we’re all on the same side – trying to fix it as quickly as possible. But if you’ve paid a fixed price, we’re immediately on opposite sides of the table, trying to work out whether the issue is foreseeable, and “our” problem, or a change of scope for the database, and so “your” problem. He says – and I agree – it’s usually better to avoid these “Us versus them” scenarios right from the start.

Our database design process

First, we’ll say hello…. and we won’t charge for that!

The initial step is always a free consultation. We’ll arrange a time to meet up, and we’ll find out all about you, who you are, what you do, and your expectations of your database.

You can tell us what you want your database to do for you and outline your budget and your timescales. Then we’ll evaluate whether we think we can help meet all your requirements.

It’s surprising how quickly you get an impression of people too – so this is also a great chance to see whether we all think we’ll be a good fit and want to work together.

Phase 2: Detailed research

This is when we really get to know you, your organisation and your processes. We’ll look at what you’re doing, and how you’re currently doing it. We’ll talk to key people who will have a direct input into the design, and to people who’ll be using the database.

Together, we’ll build a picture of the processes which your organisation follows, and at how the database should fit into those processes. We’ll document what currently works and should be incorporated into your new database, what needs to be improved, and what’s no longer relevant. We’ll also look at the systems and software currently in use, to see how your new database will fit into this picture, and to ensure that any connections you envisage to other software or databases are actually feasible.

Phase 3: Plan of work, and estimate

Putting to use all the information we’ve gleaned in phase 2, we’ll come up with a plan of the work to be completed. This documents all the functions that your database will perform, so that everyone involved knows what’s “in scope” and what’s “out of scope”.

Although we will include some information about key screens that will be needed, the details of exactly what’s required are left for phase 3; here we’re just gathering enough information to give you an estimate of likely costs, which we’ll let you have in writing.

Phase 4: Detailed design

Now we get to the nitty-gritty. Every screen, textbox, button and tick-box is planned here. We will produce a description of each screen, describing its functions and its relationship to other screens. We’ll also describe in detail any output required, such as Excel files or PDFs, and any connectivity to other systems, such as generating emails, creating appointments or linking to external databases.

Through the course of this phase, we’ll be getting much clearer pictures of any likely bumps in the road, or areas which are likely to take longer than envisaged to code, and so we’ll be able to give  you a much more refined estimate of likely costs. That way, if things are looking more complex and costly than initially envisaged, you can decide whether there are elements which should be postponed for future builds or dropped altogether.

Phase 5: Begin to build

Once we’ve got the details of the design complete, we’ll discuss with you whether there are particular functions which would make sense to complete first, from both our perspectives. That way, we can begin rolling out early versions of your database for people to test before the whole project is complete. You’ll get a feel for the design, and can bring feedback which may shape later work.

Phase 6: UAT and continued development

As we roll out features, building towards the complete database, you and your colleagues can start to test, and then use, the work that’s already been done. Initially, you’ll have sandbox models with data that’s not live, allowing you to test functionality and generate feedback. Then, as we move to a stable release, real data can be added, and the database begins to become part of your business.

Phase 7: Go-live

On go-live day, we give your staff access to the system, along with real data. Then, typically, we all go to the nearest pub and celebrate a job well done. Or, rather, stay around and resolve questions, provide on-the-spot training and support, and generally fix any issues which may become apparent.

Phase 8: Additional features and support

Almost without exception, the day after we implement a new database, our clients start to create a “wish list” of things they’d like to see in the next release. New reports, a great bit of automation that would save HOURS, a screen that would let users see…. whatever it might be. So, together we prioritise these requests, and when you’re ready, we start designing and building again.