Kelly Johnsons 14 Rules of Management… for software!

Clarence Kelly Johnson is a famous aircraft designer who worked from the 30s to the 80s on high tech government projects. His management style has become famous because most of his projects ran extremely successful. In fact there are 14 rules of management attributed to him. Here, I attempt to convert them into rules of software management:

1.The software project manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.

2.Strong but small project offices must be provided both by the customer and software development company.

3.The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

4.A very simple coding and source control system with great flexibility for making changes must be provided.

5.There must be a minimum number of reports required, but important work must be recorded thoroughly.

6.There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don’t have the books ninety days late and don’t surprise the customer with sudden overruns. (sic I would even go further and do this every second week).

7.The software development company/department/team must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project.

8.A good review system (as currently used by my team) which meets the intent of existing customers requirements should be used on new projects. Push more basic review responsibility back to subcontractors, vendors or other teams delivering components to your team. Don’t duplicate reviews. This is OK because someone delivering faulty products knows they won’t be used in the future.

9.The software development team must be delegated the authority to test their final product in its production environment (or equivalent). It can and must test the system in the initial stages. If it doesn’t, it rapidly loses his competency to design other systems.

10. The specifications applying to the hardware/software must be agreed to well in advance of contracting. Projects are allowed to have a specification section stating clearly which important company specification items will not knowingly be complied with and reasons therefore.

11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support customers projects.

12. There must be mutual trust between the customer organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

13. Access by outsiders to the project and its personnel must be strictly controlled (by security measures if appropriate).

14. Because only a few people will be used in engineering and most other areas, so ways must be provided to reward good performance by pay and other perks not based on the number of personnel supervised.

It has been years since I read these rules, but I was pleasantly surprised that we are running our project to meet 11 of these rules. Obviously number 2 isn’t being met since we moved to our new "hot desking" office, but never mind…