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).