1. カテゴリーの実際の目的
パンチ項目は記録された不具合です。カテゴリは次の1つの質問に答えます。 これは次のマイルストーンを停止させますか？ 項目に関するその他すべて（説明、写真、担当者、部門）は欠陥を記述します。カテゴリーのみがそれをスケジュールに接続します。
そのため、パンチ項目の量よりもカテゴリーの整合性が重要になります。4,000の項目が正しく分類されたプロジェクトは、900の項目すべてがカテゴリーAであるプロジェクトよりも良好な状態にあると言えます。
2. 3つのカテゴリ
| カテゴリ | 意味 | マイルストーンへの影響 |
|---|---|---|
| A | 安全性、機能、または次の段階に進む能力に影響します。 | ブロック状態です。証明書発行前にクリアする必要があります。 |
| B | 進行を妨げませんが、最終的な引き渡しまでに修正する必要があります。 | 可視性を保って繰り越され、最終承認をブロックします。 |
| C | 外観または軽微 — 塗装、ラベリング、整理整頓。 | 最大限の努力をもって追跡・クローズされます。 |
厳密な定義はプロジェクトの手順によって設定され、オペレーター間で異なります。一部のプロジェクトではAとBのみを運用し、一部ではAをフェーズによってA1とA2に分割します。重要なのは、定義が文書化され、クライアントと合意され、項目を起票する全員が同じルールで適用することです。
数値化する
これは現在、貴社のプロジェクトにどれくらいの費用がかかっていますか？
転記、登録統合、ドシエ作成によって失われる時間とコストを、編集可能な仮定と計算式を表示して見積もります。
3. カテゴリーの肥大化と、その止め方
デフォルトの障害モードは、すべてがカテゴリーAになることです。これは合理的な理由で発生します。誰も、後でインシデントを引き起こした項目を格下げした人物になりたくないからです。結果として、ゲートが交渉可能になるほど長いブロックリストができあがり、本来の目的を損ないます。
それを削減する4つの要素:
- 形容詞ではなく、テスト形式の定義を記述してください。 「システムへの安全な給電を妨げる」はテスト可能です。「深刻な」はテストできません。
- カテゴリを割り当てる担当者の氏名。 発見者ではなく、通常は専門分野のリーダーまたはコミッショニングエンジニアが担当します。
- カテゴリーを毎週バッチでレビューします。 短時間の再分類レビューにより、リストの信頼性が保たれ、判断が複数の人々に共有されます。
- 経時的なレポートカテゴリの構成。 Aの割合が着実に増加する場合、それは品質問題ではなく分類の問題です。
4. 利用可能なパンチ項目に含めるべき内容
- タグ。 エリアや部屋ではなく、影響を与えるタグです。そのため、適切なサブシステムのゲートを管理できます。
- 写真。 1枚の画像で、ほとんどの追加質問や完了時の紛争が解消されます。
- 平易な言葉による欠陥の説明です。 何が問題なのか、どうすべきかではない。
- カテゴリーと、その理由。 一行の正当化により、後からのレビューが可能になります。
- 所有者。 修正を担当する部署（ディシプリン）、請負業者、または個人です。
タグなしで起票された項目は、処理できないパンチリストの最も一般的な原因です。不具合箇所でタブレットを使って起票すると — 例えば パンチリストソフトウェア — それが明白な時点でタグを必須にするための方法と言えます。
5. クローズアウトと検証
パンチ項目のクローズは2番目の確認であり、指摘と同様の厳格さが求められます。クローズアウトには、修正の証拠と、それを受諾する権限を持つ人物（通常、作業を行った人物とは異なります）による受諾署名が必要です。
これを省略すると、クライアント自身のウォークダウン中に同じ不具合が再発し、納期が変更されていないにもかかわらず、パンチリストを再度実行する必要が生じます。
自社のプロセスを確認する
8つの質問で引き渡し準備状況を採点する
登録管理、証拠取得、承認、およびゲートロジックの構造化された自己評価 — 各ギャップに対する具体的な推奨事項付き。
