With the current economical climate, everyone is keeping a keen eye on their wallet, to make sure they are not spending more than is absolutely necessary. And when it comes to cost of IT, the newspapers remind us time and time again how those big projects keep breaking their budgets, so it’s buyer beware.
What is the logical reaction: Make sure beforehand that you know the exact price you are going to pay, and make damn sure that everything you want is nailed down in a contract.
The unfortunate result however is that, well, your IT provider doesn’t want to pay for your mistakes should you change your mind halfway through the project, so they will help you in nailing down everything in a contract.
Until you end up with a product that doesn’t do what you want, has features that just don’t work (because you never properly specified them when you entered the contract), and if you want to get the product to function properly you’ll have to start a new project which is going to cost you almost as much as you payed the first time… with similarly nailed down contracts.

As much as it is understandable that as a buyer you want to have a guarantee of functionality for the amount of money that you spend, people often forget that we are talking about -custom- software development. Sure, if I buy a TV, I know exactly how much functionality I will get, and for which price, if I do my research on brands, models and point of sale, and am willing to compromise on features for the right price.
However, custom software is not a ready product. I don’t know a single customer who buys SharePoint, installs it on a computer, and then says: done. Usually, there is a vision about which goals the new product should achieve, and of course we know how large our budget is. But we don’t know exactly what functionality we are going to need to reach that goal, let alone the way that functionality would need to be implemented in a product as, say, SharePoint.
And that’s where the flaw in the first scenario comes out. Because the contract was for a set amount of work, usually already specified down to the details so the contractor doesn’t get too much leeway, but the necessary knowledge to specify that functionality wasn’t even there, we end up with a contract that neither buyer nor seller is happy with. And another project makes the newspapers.

So how about a different approach? Sure, we don’t know the exact functionality we need, but that overall goal, our vision, is still there. And of course, we know the amount of money we have. And there’s a reason we want to work with certain contractors, since we think they deliver good work, and are not explicitly trying to rip us off.
So how about going into a time- or budgetbox with them? A timebox means that you and your contractor agree on a fixed time in which they will develop your solution. At the end of that timebox, you will have had several iterations with working software and in the end a production ready application is available. Say, three months. A budgetbox is more or less the same, except that you specify the total amount of money that you allow the contractor to charge.
You know exactly the amount of money you have and will spend, the contractor can tell you exactly when the project will be finished at the latest (because that’s when the budget runs out), and during that time, everything will be aimed at reaching that business goal.
Your contractor works with you every step of the way, helping you specify what you want and building it, allowing you to change your mind if things don’t completely fit, or the market has been changing, to find the optimal solution within the time/budget box. And perhaps halfway through the project, you already find that you have reached your goal, so you don’t have to spend that other half of your budget and can go to production as it is.

In a way, you’d be doing as most companies have been doing it for a long time: with a budget. Only in this case, the budget isn’t the hidden amount that you try to shield from the contractors eye, but it’s used to steer the development process that is being done in your name.
The weird thing is, of course, that you don’t get a hard guarantee of the amount of functionality, or lines of code, or kilobytes of software you are going to get. But then, how good software is performing was never measured by the kilobyte, and not even by the functionality, but only by the functionality that you actually use because it helps you to do what you want.
It is a leap of faith, because you only know you will be getting ‘software that will help you reach your business goal’ instead of a pre-specced Opel Astra Z18XE (Ecotec). Then again, might turn out that all you were looking for was a minivan anyway.