I. Draft.
First get a good idea of what you want. Future functions may be unclear, but you should have a very good idea on every part of what you want written now. Discuss with managers/designers of your contractor. They often have some very good ideas and a better clue what the customer might want than the customer has. Of course last word belongs to you, but these people often know "what works", "what is doable" "what is way over budget" and "what others tried and it simply didn't work".
II. Good Specs. This is 80% of the success.
You don't have to design everything yourself, but don't expect these people to magically peek into your head and know what you want. They will say what they are missing and you are to fill in. Even if it seems trivial or unimportant to you, just humor them, better to have too much detail than not enough. As you get the complete scope of the project, try to keep that fixed. There are few things more destructive to productivity than constantly changing specifications. Programmers -can- deal with that, but time will rise, price will rise and final product quality will drop. So plan well ahead, completely and competently, as to -what- you want, try to keep later changes to minimum, and all will be quite happy. If you aren't sure about parts of the project, modularize - "this is a feature we will request at a later time.", "currently unknown/undefined" is perfectly okay and better than something half-defined. This allows programmers to leave hooks for extension while not fumbling with code for something they don't completely know how to write. "Just do it somehow, show me how it works and I'll tell you if it's what I wanted" is the worst approach ever.
III. Deadline.
Arrange for a reasonable deadline and keep 2x as much time for reserve. The common joke is writing the first 90% of the app takes 90% of the allotted time. Writing remaining 10% takes second that much. This is true, as support/debug takes up at least as much resources as creation. Expect the deadline to slip, they always slip, don't panic, be forgiving but keep some pressure. And remember to include support contract in the deal.
IV. License.
Pay attention to license. You can commission work on your code, and purchase it all, codebase, copyright and all - which will be more costly but assures better profits and lower long-run costs. Or you can order the app but just purchase license, the software company keeps the copyright and they can sell the app to others.
Nevertheless, arrange for updates and support in contract. This can be skipped with established, reputable software - not with something just-written.
Don't agree to infinite price creep due to slipping deadlines, but also don't punish slipping deadlines too severely. It's better if the project is finished late than if you force deployment of unfinished product.
V. Oversight.
Stay in contact, request test versions, stay up to date with the progress, periodically see test versions of the program, to see if what is being created is what you want. Very few people can write perfect specs. It's very unlikely that you can. Programmers will write to specs but what you wrote may not be quite what you wanted, so better inform them early on if they are going in a wrong direction. Some things may appear to be doable much easier some other way than you intended. Listen, rethink, accept if it makes sense. Some things may appear much harder or impossible, so be ready for sacrificing them or deferring for future versions. And as much as you'd be tempted to add features in places where you feel you'd like them, defer that to next version. Bugs are to be mentioned calmly. They occur and should be fixed, that's normal. Specs violations in finished parts are to be pursued aggressively. This is something that should not be happening. (unless of course given part is "not yet implemented" or "work in progress").
VI. Deployment.
Don't expect 100% productivity jump overnight. Feel lucky if the system even starts working on day one. There will be errors. They are to be fixed. Employees will be slow to pick up on the new system. After some two weeks to a month everything should be ironed out to mostly smooth operation with people skilled enough to make identification of bottlenecks possible. Have them fixed in the first update, along with all the (numerous) bugs you will discover. Expect a fully functional and smoothly working application within half a year since deployment.
