You don’t know what you want, and we don’t know how to build it. Yet.

You don’t know what you want, and we don’t know how to build it. Yet.

This is not a criticism of our current (or prospective) customers, or an admission of our incompetence, but more a statement of the realities of the early stages of most software development projects we encounter.

You have your idea and have been thinking about it a lot. You may have documented your thoughts and perhaps started thinking about and designing what the user interface might look like and other systems you need to interact with. You then take the next step and start talking to software developers.

Early in the conversation, of course, the question of costs and timescales come up. Quite rightly you want to know whether your idea makes financial sense to pursue, whether you have sufficient resources and whether it can be delivered within a suitable timeframe. This is where things can get awkward, and honestly, we are not deliberately trying to be evasive when we say, “it depends”. Therefore, at this point, it is likely all we can give you is a ‘ballpark’ estimate consisting of a range, which is based on our past experience and our current, high level understanding of the project scope.

Bespoke software projects are complex beasts with many (often competing) requirements which then expand to many finer details. Some of which you haven’t thought about... yet. Thinking about these may well bring up other ideas and things that you haven’t thought about... yet. And so, it continues. At this stage, you may not even fully understand what is technically possible or feasible. You get the picture, but crucially these finer details are very key when creating a software solution and determining what actually needs to be done.

Of course, costs and timescales are inextricably linked to what needs to be done, so we need to start making sense of, cataloguing, and prioritising, all these details. At this stage it is very easy to get bogged down with the ‘functional’ requirements of the what the system should do and how it should work. However, as undoubtedly you were doing when you started forming and articulating your ideas, it’s important to keep in mind the “big picture”, why you came up with it in the first place and what are the big problems you were trying to solve.

There are some very good tools/processes/approaches that can assist in this. A great example is ‘Impact Mapping’ ( It’s a high-level process to help planning and prioritisation with a focus on stakeholders needs and organisational goals. There are many others, and we won’t go into detail here, but another useful technique is to create ‘user stories’ which are a way of describing requirements from the perspective of the different stakeholders.

It is also important early on to think about the value of the proposed system to you, your organisation and your stakeholders. Try to be empirical and assign actual values/scores even to the ‘intangibles’ like customer and staff satisfaction, ease of use, brand enhancement etc. ‘Intangible’ does not have to mean ‘immeasurable’. The book ‘How to Measure Anything’ has some useful techniques for this. Only by doing this can you truly know whether your system is a worthwhile investment and measure your subsequent return on investment. This also helps you to prioritise and focus your investment on what is important to the various parties.

This leads us to another aspect of the “You don’t know what you want…” problem. In all but the smallest, simplest systems it is difficult, and in fact unrealistic and usually unwise, to try to think of and document everything up front. As a result, ‘agile’ processes have been developed to break up larger projects into smaller chunks that are delivered in iterations: work out the value, detail the requirements and prioritise based on delivering that value, design, build and deliver a subset of the overall project. Rinse and repeat. This feedback loop ensures that we can focus on delivering what is actually needed rather than what was assumed was needed at the outset of the project. We’ve previously discussed how, when planning financing, a good approach can be to not think of software projects as solely an up-front capital investment, but to allocate an ongoing operational budget, that enables this process.

And finally, the “We don’t know how to build it” bit. We know how to create software - it is what we do every day. However, until we know what we are going to build, we can’t know how we’re going to build it. It is premature to start designing a system and deciding the best technologies to use before we understand what it is. As we have spoken about before, bespoke software development is most often a research and development process rather than a construction exercise.

Hopefully the above illustrates how difficult it is to specify the requirements for a software project up-front and consequently provide a realistic up-front costing for the project. This could go some way to explaining the high-profile software project ‘failures’ with large cost ‘overruns’ we often hear about in the media.

Did the project really go over budget or was it that the budget was unrealistic in the first place because it was essentially ‘guessed’ before the full project requirements were known?

Did the software fail to work and deliver the required benefits or did it function as specified up-front but the up-front specification was wrong for the reasons mentioned above?

Now we’ve illustrated the problems, and some of the solutions in terms of carrying out a software development project, what are the approaches to costing the project and getting over the concern of needing to know all of the costs up-front. Well unfortunately, there is no simple answer, but we will explore some of the approaches in an upcoming blog post.