In my last blog I looked a People Related Classic Mistakes from Rapid Development: Taming Wild Software Schedules by Steve McConnell, which although it’s now been around for at least 10 years, and times have changed, is still as relevant today as when it was written.

As Steve’s book states, classic mistakes are classic mistakes because they’re mistakes that are made so often and by so many people. They have predictably bad results and, when you know them, they stick out like a sore thumb and the idea behind listing them here is that, once you know them, you can spot them and hopefully do something to remedy their effect.

Classic mistakes can be divided in to four types:

• People Related Mistakes
• Process Related Mistakes
• Product Related Mistakes
• Technology Related Mistakes

Today’s blog takes a quick look at the second of Steve’s categories of mistakes: Process Related Mistakes, which include:

• Overly Optimistic Schedules
• Insufficient Risk Management
• Contractor Failure
• Insufficient Planning
• Abandonment of Planning Under Pressure
• Wasted Time During Fuzzy Front End
• Short-changed Upstream Activities
• Inadequate Design
• Shortchanged QA
• Insufficient Management Controls
• Premature or Overly Frequent Convergence
• Omitting Necessary Tasks from Estimates
• Planning to Catch Up Later
• Code Like Hell Programming

Overly Optimistic Schedules

Related to Wishful Thinking. Setting an overly optimistic schedule sets a project up for failure by under-scoping the project, short cutting requirements analysis and testing and failing to appreciate some of the most important development activities. It is a failure to recognise that software takes time to develop. This also has a detrimental affect on staff morale and productivity.

Insufficient Risk Management

If you don’t manage risks then only one thing has to go wrong to throw your project in to the gutter. Failure to plan for catastrophe and manage risk is a classic mistake.

Contractor Failure

Contractors frequently deliver work that is late, of low quality and fails to meet specifications - despite the fact that they’re frequently used and well paid! Unstable or ill-defined requirements or interfaces are magnified when a contractor is used. Manage the contractor relationship carefully or else contractors can slow a project down rather than speed it up.

Insufficient Planning

If you don’t plan to produce good software then how can you produce it.

Abandonment of Planning Under Pressure

Project teams make plans and then abandon them under pressure - like when they run into schedule trouble. The problem is that plans need to change and adapt. Failing to make new plans and dropping into "Code and Fix" mode is common.

Wasted Time During Fuzzy Front End

This is the time normally spent before a project commences, seeking approval and budgeting. Keep this stage short and intense saving your self time that can be used later when the project is under way.

Shortchanged Upstream Activities

Don’t skimp on activities that don’t directly produce code such as Requirements analysis, architecture and design. Do not "jump into coding", fixing bugs later in a project is ten times more costly in terms of time than doing it right in the first place.

Inadequate Design

A special case of the above - some people just don’t do design, they go straight into coding.

Shortchanged QA

Projects in a hurry often miss out QA. This includes eliminating design, coding reviews, test planning and performing only very basic testing. Short cutting 1 days QA will cost you 3 to 10 days later.

Insufficient Management Controls

Controls are needed to provide timely warnings of impeding schedule slips and other problems. Often controls are abandoned when trouble occurs.

Premature or Overly Frequent Convergence

Tying together all the various bits of the project to make a product (e.g. documentation, code modules and installation program) either too often or too early in the project life cycle can waste time and effort.

Omitting Necessary Tasks from Estimates

People don’t keep records from previous project, they forget about the less visible tasks. These tasks add up. Omitted effort from the original estimate adds up to 20 to 30 percent of a development schedule.

Planning to Catch Up Later

When late many projects simply plan to catch up later, but they never do. Re-estimated schedules need to reflect slips and lessons learned in building the product. They also need to reflect changes in the requirements specification. If a new function point is added that requires 3 weeks development, then the schedule slips by 3 weeks.

Code Like Hell Programming

Or code and fix programming. It is often thought that once a loose requirements specification is defined then well motivated developers can overcome any obstacle using fast loose code as you go techniques.