The traditional way of designing then costing a new piece of software is broken. All too often a someone spends months refining what they want, talking to everyone involved and throwing any feature ideas that they think they might need into the melting pot. Until eventually, they think they’ve covered everything.Then; they ask someone how much it will cost. The first problem is that software feels like it should be cheaper than it is. People outside of IT see software as being an advanced version of a spreadsheet. And Terry over there in the corner knocked up a really useful spreadsheet in something like two weeks, so surely a bit of new software shouldn’t take any more than 4 weeks to build! Another problem is that the list of feature requirements that they ask the potential development team to quote on contains way more than they really need. The vast majority of the value of the new system will be contained in a very small proportion of the features. But people rarely ask development teams to help them decided what they need. Probably because those unscrupulous software developers would use that as an opportunity to sell them stuff they didn’t need. Finally, potential customers don’t understand the non-linear way that extra features effect the price of a development project. When they see a quote saying it’ll cost $500,000 to build the 20 features they need they (quite reasonably) think that each feature costs $25,000 and that even the 5 features they really cannot live without would cost $125,000 which is still way too much. Sometimes, they simply walk away at that point convinced that the price is so far from what they can afford there’s no possibility of a deal. There are two ways of fixing this. The good way and the bad way. The bad way would be to be recklessly optimistic when estimating. You quote the customer a ridiculously low ball offer, they accept, you then fail to deliver but the customer is locked in, you then try to claw back some sort of profit through the change control process. In other words, how a lot of software development companies work. In fact it’s interesting to wonder whether this is the reason why this industry has a chronic underestimation problem, perhaps it’s because the business model depends on it! The good way would be to be get involved earlier in the process and to give the potential customer instant feedback on how their decisions affect the price. One way to do this would be through a menu of software modules. Such a menu would have things like “Business Entity”, “Audit features (per entity)”, “Content Management (per page type)”, “Workflow features (per entity)”, “Custom Reports (per report)”, “Backend API”, “Document Management” and so on. Each item would have a price there in black and white and you sit with the customer, explaining how they can combine some of the items on the menu to achieve the effect they need, all the while showing them what that does to the bottom line. Imagine what it would be like to work with a potential customer who’d bought into this process and was starting thinking creatively about how to solve their business problems with the minimum number of software components, now that’s what I call fun!