Wednesday, September 22, 2010

Kelly's 14 Rules for Skunk Works

Kelly's rules got their start on the XP-80 project in 1943, but it wasn't until the early 1950's that they were formalized and set in place as the Skunk Works®' rules of operation.

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. Don't have the books ninety days late and don't surprise the customer with sudden overruns.

Kelly Johnson at desk.

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 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 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.

Kelly Johnson with executives examine a model of the F-180C.


Wednesday, September 8, 2010

What if you screw up and make the wrong call?

But wait, what if you screw up and make the wrong call? It’s ok. This isn’t brain surgery, it’s a web app.

The Price of a Features

Expose the price of new features
Even if a feature makes it past the “no” stage, you still need to expose its hidden costs. For example, be on the lookout for feature loops (i.e. features that lead to more features).

We’ve had requests to add a meet-ings tab to Basecamp. Seems simple enough until you examine it closely. Think of all the di?erent items a meetings tab might require: location, time, room, people, email invites, calendar integration, support documentation, etc. That’s not to mention that we’d have to change promotional screenshots, tour pages, faq/help pages, the terms of service, and more. Before you know it, a simple idea can snowball into a major headache.

For every new feature you need to...
1. Say no.
2. Force the feature to prove its value.
3. If “no” again, end here. If “yes,” continue...
4. Sketch the screen(s)/ui.
5. Design the screen(s)/ui.
6. Code it.
7-15. Test, tweak, test, tweak, test, tweak, test, tweak...
16. Check to see if help text needs to be modi?ed.
17. Update the product tour (if necessary).
18. Update the marketing copy (if necessary).
19. Update the terms of service (if necessary).
20. Check to see if any promises were broken.
21. Check to see if pricing structure is a?ected.
22. Launch.
23. Hold breath.