After you capture all of the functional business requirements, nail down (with both the management and the technical leads) what architecture you will build upon, and identify the key resources who can create your system, it's time to settle in to some serious project planning.
The general approach to follow for successful planning is:
Gather all the tasks that you can foresee the developers will need to accomplish
Get rough estimates for the time for each task
Become familiar with and enter the tasks into some project management software
Include holidays, vacation, jury duty, and slack time
Tentatively assign employees to accomplish tasks
Add task dependencies
Add task priorities
Level the resources
Reassign resources and tasks until the project plan "feels right."
When possible I like to add a couple days of "slack time" every month. Slack time is not allocated to any particular tasks, but allows a window where the developers can add overlooked items, or where the staff can catch up on tasks that you underbudgeted. Planning to recover from mistakes also make sense if you care about quality. Don't be afraid to allot extra time to tasks where you have the most uncertainty about your estimate of the required effort.
Integrating project planning into the workload of existing employees is quite a bit trickier than having staff dedicated to your own standalone project. You may need to get a percentage commitment from the manager of your shared staff that allows them to still dedicate time to other projects and their ongoing tasks.
Don't be surprised if your first several plans miss their mark: it is quite easy to underestimate the quantity of tasks involved to develop and implement software, as well as the programming time required. It is always best to consider your project plan more as a telescope to organize thoughts and tasks, rather than as a fence that commits and pressures the staff.
