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.

• CM only applies to documents.
   
• CM only applies to source code.
   
• CM is not appropriate during development because we are using the latest iterative and concurrent engineering and evolutionary process models.
   
• CM is not appropriate during development because our development approach is rapid prototyping.
   
• It's not that big a project.
   
• You can't stop the technical people from making a quick patch when they find a problem in integration test or in the field.
   
• We made the change without bothering to submit an Engineering Change Proposal (ECP) because the customer's technical manager asked us to and we want a satisfied customer.
   
• We don't need a separate CM effort because CM is automatically done by the Upper and Lower CASE tools we will use.
   
• It's too hard to go back to the CASE tool and change the design, so we change the design with changes to the source code generated by the CASE tool.
   
• We have de-emphasized CM because MIL-STD-973 has been superseded by MIL-STD-498, which puts much less emphasis on CM.
   
• We don't have CM on several of our external interfaces because they are the responsibilities of other organizations.
   
• CM is a DoD-unique practice, and DoD now follows commercial practices.
   
• Our developers do not turn source code units over to CM because CM does not have the technical skill needed to build modules for integration test.
   
• We don't do CM on internal interfaces because this limits technical team flexibility.
   
• Our CM staff keeps all records manually because they are not experienced with software tools for CM.
   
• CM will be minimal on this project because most of the software will be an integration of Government-Off-the-Shelf (GOTS) and Commercial-Off-the-Shelf (COTS) software.
   
• We lower our cost by using only minimum-wage persons on our CM staff because CM does not require much skill.
   
• We don't use the same CM process and tools as our subcontractors because they have a different corporate process.
   
• We don't need functional and physical configuration audits because we are using CASE tools.
   
• We don't put the software architecture and detailed design under formal change control during development because this limits the flexibility of the developers.
   
• We don't put operating systems, middleware, run-time libraries, and compilers under CM because CM only applies to the application software that is developed under this contract.
   
• We don't put software development files under CM because they are not contract deliverables.
   
• The only baselines controlled by the buyer are the functional, allocated, and product baselines. Therefore the buyer has no right to see any contractor data from the developmental baseline.
   
• CM cannot control anything in the developmental baseline other than source code because we are using CASE tools and CM tools that are not integrated.
   
• CM can only control information stored in flat files because our CM tool only manages flat files

top

---