We will only give realistic schedules. Software developers the world over are frequently asked to 'implement Project X in three months' because that is a commercial timeframe either already 'committed' to, or for some other immovable reason. We ensure that Marketing and Sales departments get the information to show that their dream application cannot be feature-full and perfect in too short a time. We try to itemise every development point to avoid project creep (adding 'features' which were 'always intended' but never quite made itto the project specifications).

Of couse, small additions and modifications are welcome to improve the product, but significant additions need to be assessed item by item, in terms of time and cost (and risk, of course!).

Over-optimistic scheduling can (and frequently does) backfire - According to industry studies, 75% of large projects succumb to schedule pressure, and virtually 100% of very large projects do so. The original schedule for Microsoft Word for Windows was 1 year. It eventually took 5 years. Microsoft Windows 95 was delivered a full year and a half later than its original announced release schedule. The widely-reported airlines reservation system to suceed SABRE had massive turnover of developers, managers and eventually executives, because nobody would own up to the degree of lateness on the development, 'hoping' that they would catch up.

It is an easy trap to fall into, and we try to keep aware of, and flag such risks early to customers.

Unrealistic, over-optimistic schedules lead to late projects, low quality products and trouble all round. Developers get demotivated, managers get frustrated and customers get angry. Accurately planned schedules using the best estimates (rather than the shortest!) are the fastest way to the software product.

Another problem is where a project is wanted by all, in nine months time,and the timescales are about nine months. However, the resources can only be allocated after internal bureaucracy (planning, sign-offs, business case justification meetings) has taken place. This 'fuzzy front end' is a major cause of software schedule slippage (or decreased development time & all that goes with that!), and seemingly goes unrecognised by the planners.

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.