「プロジェクトマネージャーが守るべきルール100」で共感できる12のこと
あちらは設備もHWもSWも一から作らないといけないし、人命が掛かっている点ではそのプロダクトに求められる品質の要求レベルは大分高いものになっていると思いますが、それはそれとして共感できたもののうち、12項目を挙げてみました。
03：
マネージメントのツールは変わりましたが、根本の原則は昔から変わりません。仕事をする適切な人を見つけ出し、彼らに道をあけるだけです。
チームのキーパーソンを如何に確保するか、です。
15：
問題の種は初期段階からまかれているもので、プロジェクトの問題点や失敗したプロジェクトの評価が示すものは、スタート地点にあることがあります。仕事の取りかかりはプロジェクトの最も重要なパートの1つだということを肝に銘じましょう。
トラブルプロジェクトとは急にトラブルになるわけではないのです。最初からジワジワと進行しているんです。
16：
協調していくためにはよいコミュニケーションと「早期警戒」が必要です。これは、プラン変更を初期段階やたとえ噂でもすぐにパートナーに伝えられる姿勢でいるということ。事態が最終段階に入ってからパートナーに伝えるようなプロジェクトマネージャーは「誠実」とはいえず、パートナーにモノ扱いされてしまいます。
警戒と言うよりは、危ないと思うところをいかにウォッチするか、です。
36：
信頼がかかっているので、評価者から何かを隠そうとしないこと。穴ぼこがあろうと吹き出物があろうと全てをさらし、しかし言い訳はしないことが大切です。事実だけを提示してください。
隠すのは良くない。
73：
過去に行われた多くのプロジェクトは失敗のためではなく粗末な予測のためにスケジュールを超過しました。よりよい予測を行うためには費用がかかりますが、NASAの評判を上げることになるでしょう。現在の環境においてよりよい評価は不可欠です。
粗末な予測、こんな言い方もあるのか。
74：
全ての問題はやがて解決します。万一の場合に備えて余裕のあるスケジュールを組んでください。さもなければ次のプロジェクトではあなたの位置には別のマネージャーがついているでしょう。
時間があれば、というケースは多いです。ただ、時間があればあるだけ工夫しなければコストは増えます。
84：
イラストなどを見て決定を行わないでください。ハードウェアや設計図など現実の情報を得ること。多くの時間の無駄は原理を説明するためのイラストにある事実を修正しようとする人々から生まれます。
論理構成とか物理構成はちゃんと見ておかないと。
87：
プロジェクトを成功に導くためにはチームワークが求められます。多くのチームにいるのはボスではなくコーチですが、コーチは常にプレーを呼びかけなければいけません。
自分を含め、すぐ忘れてしまうんです。
92：
失敗した時にやるべきことは、
a：起こったことのタイムラインを作り、当たり前のこと含めて全てを書き込むこと。
b：知っている事実を書き出し、事実に対するあらゆる考えをチェックすること。
c：本当のことが分かるまでデータを破棄しないこと。
d：結果に飛びつかないで、通常から逸脱していることには説明がつくようにすること。間違った結論は次の失敗の発端になることを忘れないこと。
e：やめ時を知ること。
失敗を重大障害と読み替えてもいけます。
95：
これまで、テストを済ませ認定されたもので、何一つ問題のなかったプロジェクトは存在しません。時間と準備だけが問題に対する安全装置になります。
だから、リハーサルをやるんですよね。
98：
初期のNASAが持っていた利点の1つは、誰もが「当たり前だと思っていた事実が間違っている可能性がある」ということを知っていたことです。
当たり前は危ないのです。
100：
言い訳をせず、次にとる行動の計画を示してください。
やることはまだある、と言うことです。
