Classic Mistakes

1
Classic Mistakes
2
The Effect of mistakes on a development schedule

• Essentially - one bad apple can spoil the whole
  barrel.
• You dont have to just ensure that you do a few
  things right but that you must also avoid doing
  things wrong (Vosburgh 84).
• It is almost impossible to single out root causes
  of slow development.
• To slip into slow development it only takes one
  big mistake to occur.

3
Classic mistakes Enumerated

• Most classic mistakes have seductive appeal.
• how do you rescue a project?
• Add more people!
• A key team member is aggravating the rest of the
  team.
• Wait till the project finishes then sack him/her!
• These mistakes are surprisingly common.

4
People-related mistakes

• 1Undermined Motivation
• motivation has a greater effect on productivity
  and quality than any other factor.
• 2Weak Personnel
• individual capabilities of personnel is probably
  the second most important factor.
• 3Uncontrolled problem employees
• Failure to deal with problem personnel threatens
  development speed. Failure to deal with a problem
  employee is the most common complaint against
  team leaders.

5
People-related mistakes

• 4Heroics
• Can-do-attitudes can escalate minor setbacks
  into true disasters (DeMarco 95). Steady,
  consistent and meaningful progress is usually
  best.
• 5Adding people to a late project
• The most classic of classic mistakes. This is
  like pouring gasoline on a fire (Brooks 75).
• 6Noisy, crowded offices
• Most developers rate their working conditions as
  unsatisfactory - either they are not private
  enough or quiet enough (DeMarco and Lister 87).
  Productivity is better in quiet, private work
  areas.

6
People-related mistakes

• 7Friction between developers and customers
• Arguments may develop over schedule or
  requirements issues. There may be personality
  clashes. Poor communication can be the main cause
  and effect of friction.
• 8Unrealistic expectations
• Realistic expectations are one of the top 5
  factors required to ensure an in-house software
  project is successful (Standish Group 94).
  Managers may get in trouble by getting funding
  based on overly optimistic schedule estimates or
  pie-in-the-sky feature sets may be promised.
• 9Lack of effective project sponsorship
• Lack of an effective executive sponsorship
  virtually guarantees project failure (Thomsett
  95).

7
People-related mistakes

• 10Lack of stakeholder buy-in
• All the players must buy into the project -
  executive sponsor, team leader, team members,
  marketing staff, end-users, customers, etc.
• 11Lack of user input
• Number one reason that IS projects succeed is
  because of user involvement (Standish Group 94).
  Lack of user input runs risk misunderstanding
  projects requirements. Projects are vulnerable to
  feature creep at later stages.
• 12Politics placed over substance
• Political operators specialize in managing up,
  however putting politics above results is
  disastrous.

8
People-related mistakes

• 13Wishful thinking
• Not just optimism but closing your eyes and
  hoping something turns up when there is no
  reasonable basis for this!

9
Process-related mistakes

• 14Overly optimistic schedules
• Sets project up for failure by undermining
  planning and abbreviating aspects such as
  requirements analysis and design. Ultimately
  demoralizes developers.
• 15Insufficient risk management
• Actively manage risks to avoid catastrophes.
• 16Contractor failure
• Contractors frequently deliver products that are
  late, of a low quality or below spec (Boehm 89).

10
Process-related mistakes

• 17Insufficient planning
• Say no more .. this speak for itself.
• 18Abandonment of planning under pressure
• This happens routinely (Humphrey 89). The problem
  is more to do with not replacing it with a new
  plan but rather fall into code-and-fix.
• 19Wasted time during the fuzzy front end
• Easier, cheaper and less risky to be efficient
  with time at the fuzzy front end rather than
  compress the development schedule by the same
  amount.

11
Process-related mistakes

• 20Shortchanged upstream activities
• Requirements analysis, architecture and design
  may be sacrificed first because they dont
  produce code!! The results known as jumping into
  code can cost 10 - 100 times the cost of doing
  properly in the first place (Fagan 76).
• 21Inadequate design
• Rushed projects undermine design by not
  allocating enough time to it, difficult as a
  result then to come up with the best designs.
• 22Shortchanged quality assurance
• Hurried projects often sacrifice code reviews and
  test planning. Short cutting 1 day of QA early in
  a project may cost 3 to 10 days downstream (Jones
  94).

12
Process-related mistakes

• 23Insufficient management controls
• Before you can keep a project on track you have
  to be able to tell whether it is on track in the
  first place.
• 24Premature or overly frequent convergence
• There is always a temptation to force a product
  out early and so ignore planning at the last -
  this is often counterproductive.
• 25Omitting necessary tasks from estimates
• Omitted necessary tasks often add up to 20-30 of
  a development schedule (Van Genuchten 91).

13
Process-related mistakes

• 26Planning to catch up later
• Things that you learn about your project as you
  go along should be built into the schedule. E.g.
  if it takes 3 months to reach a milestone that
  was expected to be achieved in two months then
  dont expect to catch this time up later.
• 27Code-like-hell programming
• Never really works in a time-limited project.

14
Product-related mistakes

• 28Requirements gold-plating
• Some projects have more requirements than are
  actually needed, right from the beginning.
• 29Feature creep
• An average project experiences about a 25-percent
  change in requirements over its lifetime (Jones
  94).
• 30Developer gold-plating
• Developers sometimes are keen to try out new
  technology regardless of whether it is beneficial
  or not.

15
Product-related mistakes

• 31Push-me, pull-me negotiation
• A manager may approve a schedule slip on a slow
  moving project then add completely new tasks
  after the schedule change.
• 32Research-oriented development
• If your product goals push the state of the art -
  algorithms, speed, memory usage, then you should
  assume that your schedules are highly speculative.

16
Technology-related mistakes

• 33Silver bullet syndrome
• Teams that expect a single new practice,
  technology or process to solve their problems are
  often disappointed (Jones 94).
• 34Overestimated savings from new tools
• Improvements in productivity are normally slow
  and steady.
• 35Switching tools in the middle of a project
• Hardly ever works. The learning curve, rework and
  mistakes cancels out benefits.
• 36Lack of automated source code control
• Manual co-ordination of software is more
  difficult and may result, for example, in one
  developer over-writing another's code.