Let's start with hire a good team of the right professionals for your project. In a typical business app you would need to hire a database developer and a dba, a QA person, a system admin, a business analysts,application developers, a UI specialist and team leads at a minimum. DBA, System Admin, business analysts and QA should be in a separate reporting chain from the development team. The development database specialist should report to the same technical lead as the application developers and UI specialist.
Set up the office space. Private offices are great if you can get them (I wish you lots of luck with this), but at a minumum you needs desks, phones, computers, whiteboards and a couple of dedicated conference rooms. Make sure there is a place for lunch breaks, a refrigerator, soft drinks, snacks, and coffee available. Free soft drinks and coffee even better.
Set up dev/qa/staging and prod servers for both the application and the databases. Databases should not ever be on the same server as the applications. Depending on the size and scope of the project, you may need multiple servers or SANs, etc for each environment.
As soon as servers are set up, schedule backups of the file sytem, the database and the database transaction logs. Do this the very first day things are set-up. Hire a firm like Iron Mountain to take backups off-site weekly.
Set up a source control system and create a document describing how it will be used. Do not forget to insist that ALL database structural changes and data inserts for lookup type tables be in scripts in source control. This will make deployment easier.
Buy commercial software or download open source software for the toolset you decided to use with licenses for all the pertinent users.
Buy developer machines that are screaming fast and have two monitors. Buy at least one test user machine that is moaning slow and typical of what the users will have on their desktops.
Train your new developers in how you want things done. If you have a large enough team to have some junior developers, then schedule extra training for them and include the time in your project planning. Monitor juniors very closely for at least three months. Monitor all new employees closely for the first month. Get rid of deadwood and rogue developers as soon as possible.
Determine what needs to be done in what order (the critical path). Do not assign tasks at the end of the critical path until the tasks they depend on are complete.
Create test plans and requirements.
Set up regularly scheduled progress meetings with the clients. They deserve to know what you are doing and what the roadblocks are. Do not fail to tell them when things will be late. If you are three weeks away from a deadline and you already know you will miss it, that deficit will not magically disappear before you have to tell the client. Make sure that the client knows that added requirements means added costs and time and that every added requirement will either have to have other tasks dropped or the deadline will change by the amount of hours in the new tasks. Making this clear from the start will save lots of pain and overtime hours and cost overruns absorbed by your group and not the client.
Set up an environment to performance test, not just the speed of one user, but one where you can test the expected number of simultaneous users. Do not wait to do this testing until the day before you go live.
In project planning, assume QA will find bugs and that they will take time to fix. Do not schedule QA for only one day at the end.
Create test data that is roughly the size you think the database will be. Make all developers test their code against the database of this size. Do not allow developers to only develop against a small database on their personal machines. This is a frequent cause of code that works fine until it hits production.
Plan rewards into the budget. It demotivates people when they work their butts off for months and only managers get bonuses. Also say thank you frequently and in writing.
You may need a project management system or at least set up spreadsheets to track what you need to track. When doing the project planning, assume no more than six hours a day person in your plan. This helps account for the time that will be spent not on the project, such as vacation, sick time, holidays, HR meetings, performance reviews, etc. If you know the project is in a period of high unavailability (say a project that runs form Nov1 - Jan 1 in the US), you may need to make extra allowances for more leave and holiday time. It is not fair to expect that developers will give up their leave and holidays and no one can predict when things such as sick time, jury duty , bereavement time etc will happen. Assume they will happen to your team on this project.