Kelly’s 14 Project Management Rules: Everything You Need To Know

Kelly Johnson was an engineer at Lockheed who is famous for his leading role in designing over 40 aircraft. He was the leader of Lockheed’s Skunk Works program, and it was here that he devised his 14 Rules and Practices for project work. Here we look at those 14 rules and see how they are still relevant today.

Who was Kelly Johnson?

Born in 1910, Clarence L ‘Kelly’ Johnson was a senior manager at the Lockheed Aircraft Corporation (LAC) during the Cold War. At LAC, he developed the Skunkworks program, which has become the standard for high-risk, high-gain projects. As well as being a leader, Kelly Johnson was a renowned aeronautical and systems engineer. Kelly made a significant impact on a range of important aircraft designs. These include the Lockheed U-2 and SR-71 Blackbird, both of which were honored with the prestigious Collier Trophy. Kelly was also recognized for his contributions to the design of aircraft engines and systems, earning him the nickname “The Engineer of the Century.” Kelly Johnson’s life and work provide a fascinating glimpse into the history of aviation. In addition, his 14 project management rules and practices are essential for anyone looking to be successful in project management.

What was Skunkworks?

Skunk Works is an official pseudonym for Lockheed Martin’s Advanced Development Programs (ADP), formerly called Lockheed Advanced Development Projects. Some of the most famous and groundbreaking Skunk Works projects include the SR-71 Blackbird and the F-117 Nighthawk. Lockheed Skunk Works was formed in 1943 when Kelly was asked to develop the first U.S. Jet fighter to counter the (then) superior jets of the Luftwaffe. Johnson argued that the only way to get the job done quickly was to form a top-secret group outside Lockheed’s normal reporting lines. He formed a very small group of specially selected engineers and mechanics.

Skunk Works was an American success story. The term ‘Skunk Works’ has since been used to define any project shrouded in secrecy and focused on bringing innovative and cutting-edge technology to market quickly.

14 Rules and Practices for project work

Kelly devised 14 Rules and Practices at Skunk Works. Here they are in full:

1. The Skunk Works® 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 military and industry.
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 drawing and drawing release 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.
7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection.
9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.
10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
12. There must be mutual trust between the military project organization and the contractor the 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 appropriate security measures.
14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay, not based on the number of personnel supervised.

Source: https://www.lockheedmartin.com/en-us/who-we-are/business-areas/aeronautics/skunkworks/kelly-14-rules.html

Applying Kelly’s 14 rules and practices for project work

Kelly forged his rules eighty years ago. But they still hold today.

Firstly, there is an emphasis on keeping teams small (rules 2 and 3). Every person that gets added to a project team is another person who needs to be informed of progress and consulted for decision-making.  Large groups have greater complexity and can be slower to make decisions and respond to change. Another factor to consider here is team culture. When you form a project team, it is common to develop a way of working that makes the project unique. It is often described simply as ‘how we do things around here.’ Team bonding and group identity are formed much more rapidly and organically in small groups than in large, sprawling teams.

Bringing people together for meetings can be hugely beneficial. Innovation and collaboration thrive when people are together. Also, meetings ensure teams are aligned and understand the bigger picture. But too many meetings can be counterproductive. The same is true of reporting. Reports are essential communication tools. But reporting is time-consuming, and people who are writing reports are not focused on developing project deliverables! On your projects, strike a balance between what is necessary and what is not. Keep reporting to an absolute minimum while ensuing teams have close corporation and communication. The 13th rule strictly controlled access by outsiders. While your projects may value transparency over secrecy, it is still essential to understand your stakeholders and decision-makers. It is often worth creating a RACI matrix to understand which groups of people need to be informed and consulted while avoiding other parties adding noise and becoming a distraction.

If your project uses contractors and third parties for their expertise, make sure you delegate them sufficient authority to succeed. There is nothing more frustrating for consultants to be engaged for their specialist expertise, only to find themselves hamstrung by overzealous controls and micromanagement. If you bring in experts – treat them as such, and delegate them enough responsibility to get the job done.

Finally, manage upward and actively prevent organizational processes and decision-making boards such as steering groups and financial approvers from impeding the creative development process. Be mindful of upcoming decision points and budgetary checkpoints and do everything you can to avoid these becoming blockers for the team.

Kelly’s rules as a precursor to Agile

Many in the world of software development view Agile methods as something modern. However, we can see clearly that many of Johnson’s project rules and practices were similar to some of the principles and techniques applied in modern agile frameworks. For example, at Skunk Works, small teams collaborated and developed iteratively. Documentation was kept to a minimum, and authority was delegated to the team. Long before a group of consultants got together in a ski resort and wrote that Agilists should “Respond to change over following a plan,” Johnson was already advocating release systems with great flexibility for making changes. We have spoken previously on this site about the waterfall vs. agile fallacy. Still, it is worth reminding ourselves that the idea that before Agile came along, the world was following a five-step waterfall model is inaccurate. Much can be learned from delivery methods deployed before the creation of the Agile Manifesto in 2001.