Most software projects follow a similar style, the idea stage for the product, the defining of the requirements, the analysis of the design and elements required to complete the job, the implementation phase, the testing of the solution, and various releases through Alpha/Beta issues, or selected customer trials. We try to marry the Best Practices of the industry with the internal procedures of the customer to give the optimum software development solution.

Many books have been written on the actual engineering of the software itself. One leading book we refer to, and would recommend, is Code Complete by Steve McConnell (Microsoft Press). It has numerous industry studies and describes in clear concise unassuming format the problems found, and by engineers in writing software.

A companion book to this is Rapid Application Development by the same author, who takes a rational view of the myriad of ideas of project management and process engineering. From his industry analysis (and his reading of many industry studies) he concludes which methods can be called Best Practices, and we use some of them inhouse (There are over 20 of them in all, ranging from 'Outsourcing' to 'Inspections', and many others).

Examples of Best Practices we use are

Risks Lists : the client is given weekly reports on the various risks and issues affecting the project, so that both Blue Legend and the customer can see where the biggest risks to on-time implementation are to be found.

Thorough reviews : Reviews of requirements, design and coding. Many times errors are picked up earlier in the design cycle by objective inspection, carried out with no room for developer ego. When there is a document or code listing to be reviewed, the author is always on the receiving end of criticism, and therefore we try to keep criticism positive, and reason-based.

MiniMilestones : All of our projects are internally analysed to a fine grain of detail, so that we have a solid method of tracking progress. Every task to deliver a project is entered into a list where each task takes from 0 to 2 days, where 2 days is an absolute maximum. This enables us to know precisely how much work is to be done, who will be doing them, and when. We try to avoid project slippage by this methodology (there is always a 'total days' figure available), and especially to give early warnings of need for catchup.