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 SchedulesRelated 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 ManagementIf 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 FailureContractors 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 PlanningIf you don’t plan to produce good software then how can you produce it.
Abandonment of Planning Under PressureProject 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 EndThis 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 ActivitiesDon’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 DesignA special case of the above - some people just don’t do design, they go straight into coding.
Shortchanged QAProjects 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 ControlsControls are needed to provide timely warnings of impeding schedule slips and other problems. Often controls are abandoned when trouble occurs.
Premature or Overly Frequent ConvergenceTying 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 EstimatesPeople 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 LaterWhen 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 ProgrammingOr 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.