Most of the examples are describing problems with IT projects in the 1960s but they could as easily be applied to the projects I’ve worked on over the last decade. The table summarising aspects of the 1968 Nato Report on Software Engineering Problems (PDF) is scarily applicable.

Lack of understanding in system requirements on the part of customers and designers.

Large gaps between estimates of costs and time with actual expenditures due to poor estimating techniques, failure to allow time for changes in requirements, and division of programming tasks into blocks before the divisions of the system are well-enough understood to do this properly.

Large variations, as much as 26:1 in one study, in programmers’ productivity levels.

Difficulty of dividing labor between design and production (coding), since design-type decisions must still be made in coding.

Difficulty in monitoring progress in a software project, since “program construction is not always a simple progression in which each act of assembly represents a distinct forward step.”

Rapid growth in the size of software systems.

Poor communication among groups working on the same project, exacerbated by too much uncoordinated or unnecessary information, and a lack of automation to handle necessary information.

Large expense of developing on-line production control tools.

Difficulty of measuring key aspects of programmer and system performance.

A tradition among software developers of not writing systems “for practical use,” but trying to write new and better systems, so that they are always combining research, development, and production in a single project, which then makes it difficult to predict and manage.

Rapid growth in the need for programmers and insufficient numbers of adequately trained and skilled programmers.