There are many different ways to approach planning and executing a complex project. We find that the best way to start is by discussing the client's wishes and goals. From there we can approximate the initial scope of the project - how big it may be, how complex, and what sort of resource will be required. This will give us a baseline to start building the project specification.
Almost every project includes a specification phase near the beginning. The specificaton documents are an organic (meaning that they 'naturally' grow and mature) set of documents that specify the deliverables of a project. One of the final documents in the specification is the Project Plan. It's a plan that accounts for applied resources, time to execute tasks and a detailed task breakdown. Essentially a project plan will tell you how long any part of a project is estimated to take.
There are two extreme ways to develop a project - Waterfall and Agile. Waterfall (in it's extreme) planning dictates that before any code is written, everything must be planned down to the last detail. Agile (in it's extreme) plans only a rough skeleton and details only the tasks that are to be done immediately. We find that most clients are comfortable with a bespoke combination of the two - somewhat high-level specification and project plan along with frequent release cycle to allow the client to steer the project to their vision.
Communication is key with any project. Any liason members should be available for immediate contact via email, phone or chat. The easier it is to communicate, the more likely that communication WILL occur!
The steering is VERY important to Lancetek. Many I.T. projects fail due to artificially-enforced document adherance. We feel that a project BELONGS to the client. The client will be advised by Lancetek in any situation, but any decision is ultimately the client's to make. To assist in utilising this flexibility, we plan to do frequent releases to the client, 2-3 weeks being an ideal timespan. This allows a client to really take ownership of a project and flag any concerns they may have - BEFORE development is too committed.
Of course, if a client doesn't have time, or just wants a turnkey solution, we are happy to make the decisions for them. But the most successful projects succeed due to client involvement.
We have come to use this approach to development as we find that there are often project management problems that precluded the best solutions being delivered. The only people who can *accurately* plan a technical project are those that understand the underlying technology implicitly. For technical projects, a 'generic' project manager won't do. We find that someone who has recently had a role building a similar project is best at doing estimates and plotting potential risks (pitfalls).