Monat: März 2012

One week of skiing. Weather was nice, but way too warm. Snow was too wet. I hate skiing in spring, really, I don’t mind – 15 °C but + 5 °C at 2500 m is silly. Days were packed but I still had time to read a book of Clarence (Kelly) Johnson. His work always interested me, because he is one of the most successful aircraft designers. Probably you don’t know his name, but Lockheed’s Skunk Works should be known to everybody. Also the planes he and his team designed:
P38 Lightning
P80 Shooting Star
F104 Star Fighter
U2
A12 – SR71 Blackbird
… to name a few
Apart from the technical stuff he describes, his way of running the shop and getting projects done in time and below budget is remarkable. It is almost unimaginable today, that money is payed back to the customer and he finished most projects, even very difficult ones, before dead line.
He had 14 points of management. Not all of them are suitable to IT projects and corporate customers, but some certainly are.

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.
   Definitely! IT Project managers must have the absolute power.
2. Strong but small project offices must be provided both by the military and industry.
   SMALL! You can easily replace the military with a corporate customer. One reason why projects go awry, is the long chain of command. Many managers are more interested in covering their ass, than taking decisions.
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).
   Logic, no?
4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.
   That works for other documents, too.
5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
   Doing reports is important but unproductive and most of the time nobody reads them anyway. Therefore keeping it to a minimum makes sense.

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 90 days late, and don’t surprise the customer with sudden overruns.
   No comment necessary.
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.
   In some cases four eyes see more, but 16 is overdoing it.
   
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.
   OK, that is a bit difficult, since we often don’t need that functionality, but „eat your own dog food“ goes in that direction.
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.
    Very, very important. Many projects fail, because the desired outcom wasn’t clear at all. Customer and contractor had different ideas. Measure twice, cut once.
11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
    That’s only fair.
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.
    No cc, no bcc, one email a day or whatever works. I strongly suggest a team room and no email conversations at all.
13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
    That could prove useful, if too many want to influence.
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.
    The guys who do the work are important. Not the ones pushing excell sheets and reports around.

    He made a few other points in his book.
    In my own words:

    Don’t work overtime. From the start of the project, work on it with constant pressure. Don’t be lazy at the start and get in a hurry in the end. Otherwise peoples performance will fall towards the end, when pressure rises.

    We owe our employees good working conditions and some kind of job security.
    The „you are below average therefore you should look for another job“ mentality that is more and more common today is just plain stupid and shows that the Cxx-level has not understood statistics or are just using this argument to get rid of people. By far most people are just average, including the Cxx-level.

    Keep everybody close together. In the Skunk Works, engineers worked in the same building or even rooms alongside the mechanics, where the parts and the planes were build. It’s not a bad thing, if the engineers get their hands dirty.
    In our world of home office and working everywhere, this sounds odd, but it still holds true. People who work close together and are in continuous communication get better results.

    Let people make mistakes and let them fix them. If people are afraid to make mistakes, they are more concerned about not making mistakes than about the projects. Rather look for the reason why mistakes happen, than for the culprit.

    A book worth to read.