Failed software projects are usually easy enough to analyze after the fact. You can almost always spot some fundamental sound practice taht wasn't followed; if it had been followed, the project would have succeeded, or at least failed less completely. Often the good practices that weren't followed are basic ones that practically everyone knows are essential. When that happens, project management can always cite a reason why the practice wasn't followed--an excuse or rationalization.

To save everyone a lot of time, we have collected some of the most common bad excuses for not using good practices.... The next time you're considering managing a project without a careful risk management plan, for example you needn't wrack your brain for an excuse. Just consult this page.

• We can always get out of schedule problems by adding people.
    
• We can always get out of schedule problems by performing fewer tests. 
  
• We can make schedule by working overtime. 
   
• It's not our fault that a crucial external dependency was late and caused our delivery to slip. 
   
• What is schedule compression? 
   
• We don't have schedule problems because, when the calendar time allocated to a task is used up, we end the task and move on to the next task. 
   
• It is a success-oriented schedule, but when you challenge people they do great things. 
   
• How could we have known before integration test that the network did not have enough throughput? 
   
• Our expectations for a highly compressed schedule didn't work out, but we will meet the delivery date by delivering a prototype. 
   
• We are behind schedule because the buyer can't stabilize system requirements. 
   
• The schedule problem is not requirements volatility; it is the contractor's lack of management skill. 
   
• We don't use the Budgeted Cost of Work Scheduled (BCWS) and Budgeted Cost of Work Performed (BCWP) metrics because those are 1970s technology. 
   
• We thought we could do more things in parallel because of the new technology we used for the first time. 
   
• This is incremental development. Any schedule slip will be made up in subsequent releases. 
   
• We're behind schedule because we spent too much time on planning and architecture design. 
   
• Quality of design will minimize testing. 
   
• If I schedule to a level of great detail, I'll tie my hands.  
   
• We will deliver on schedule because we can fix it while they are using it. 
   
• What difference does it make if the schedule slips as long as we don't have a large cost overrun? 
   
• Our schedule slip was a vendor's fault. The vendor of the Database Management System (DBMS) was late in delivering version 7.3. 
   
• We were forced into a schedule we can't possibly meet because our buyer didn't want to give bad news to the future users. 
   
• We didn't meet the schedule because we didn't know about the poor quality of the software we planned to use from the reuse library. 
   
• Our schedule slipped because the buyer was slow in approving our intermediate products. 
   
• Our schedule slipped because another company raided our technical staff.

top

---