Statement of work. 簡単そうに聞こえるが、正しく作成するのは簡単なことではない。 しかし、プロジェクトの成功にとって、これほど基本的なことはありません。 仕事のステートメントが曖昧すぎたり、広すぎたり、一般的すぎたりすると、さまざまな解釈の余地を残し、先々でトラブルにつながる可能性があります。 社内プロジェクトでもそうですが、ベンダーが絡むと二重の意味でそうなります。
「作業指示書の適切な実行の失敗は、しばしば当事者が論争に陥る原因です」と、Greenberg Traurig LLP のニューヨーク・オフィスのテクノロジー、メディア、およびテレコミュニケーション業務グループの弁護士である David M. Greenberg は述べています。
プロジェクトを最初から成功させるには、効果的な作業指示書（SOW）を書くためのガイドラインに従います。
SOWが何であるかを理解する。
SOWは、必要な作業の範囲と、それを実行する時間を定義します。 マサチューセッツ州ウェストボロにあるエネルギー供給会社 National Grid USA の IT 調達マネージャー、Nick Scafidi 氏は、「契約の基礎」であると述べています。 「期待値、成果物、許容範囲、価格、価格設定スケジュールを設定するものです。 それがなければ、請負業者に『家を建ててくれ』と言って、いつ、どんな種類の、どれくらいの大きさの家を建てるかを伝えているようなものだ」。
何を含めるべきかを知ること。
Bruce Russell は、ソフトウェア開発会社の最高執行責任者であったときに多数の SOW に署名し、良いものにはこれらのことが含まれると述べています。
- 主な成果物とその期待時期。
- 成果物をサポートするタスクと、採用企業またはサービス プロバイダーのどちらがそれらのタスクを実行するか。
- プロジェクトに必要なリソース、使用される施設、必要な機器、およびテスト要件。
- 誰がいつ、どのコストを支払うのか。 「そして、より正確で、より定量的なものを作ることができれば、より良いのです。
成功を定義する。
仕事の声明は、すべての当事者にとって、何が成功または失敗を構成するかを明確にするべきだと、ワシントンのMcDermott Will & Emery LLPの知的財産、メディアおよびテクノロジー取引グループの弁護士であるMelise R. Blakesleeは述べています。
「何が仕事であるか、そして、何かが成功裏に完了したと両者が合意する方法の基準を適切に記述しなければならない」と、ニュータウンスクエアにあるプロジェクトマネジメント研究所の標準マネージャーであり、元ITプロジェクトマネージャーであるRuth Anne Guerreroは述べている。
たとえば、ベンダーにユーザー要件を作成させる場合、SOW には、ベンダーが特定のユーザーグループにインタビューし、要件を承認した時点で仕事が完了したとみなされることを明記する必要があると、彼女は述べています。 これは、単に「ベンダーはユーザー要件を作成する」と言うよりも、成功を定義するものです。
成功の定義はプロジェクトに依存すると、Guerrero 氏は言います。 ITプロジェクトリーダーは、実装の成功がスピード、レスポンスタイム、使いやすさ、あるいはその3つすべてによって定義されるのかを特定し、SOWでそれらを定量化する必要がある。
タイムテーブルを忘れてはならない。
成功する実装は、システムの速度や応答性だけで定義できるわけではありませんが。 結局のところ、構築するのに10年かかるような優れたアプリケーションに何の意味があるのでしょうか。 そのため、SOWには時間的な要素を含める必要があります。 ゲレロは、カレンダー上の固定された日付ではなく、ある程度の柔軟性を持たせた言葉を使うことを勧めている。 例えば、エンドユーザー要件は契約締結の2ヶ月後に提出するようにSOWに明記する。
SOWはまた、正式なレビューのための特定の時間を指定する必要があり、すべての関係者は自分たちが軌道に乗っていることを確認できると、パース州ビラノバのビラノバ大学商学・金融学部決定・情報技術学科教授およびジョン F. コネリー経営学教授は述べています。
マイルストーンに支払を結びつける。
仕事を順調に進めるためのもうひとつの重要な要素は、SOWに特定のマイルストーンを設定し、支払いが成功裏に完了するように結びつけることだと、ブレイクスリーは言う。
ScafidiがSOWを書くとき、彼はベンダーへの支払いは主要な成果物が受理されたときに行われることを指定します。 また、すべての成果物が一緒に機能することをベンダーが証明するまで、報酬の一部を保持することも明記しています。
誰もが理解できる言語を使用する。
SOWを使用するのはIT部門とそのベンダーだけではない、とBlakeslee氏は言います。 ですから、IT担当者だけが見るような書き方はしないでください。 「エンドユーザー、サービスプロバイダー、経営陣、そして裁判官にも理解できるものでなければなりません」と彼女は言います。
具体的であること。
多数の関係者が作業指示書を理解しなければならないが、プロジェクトの範囲と要件を正確に記述することだと、Blakesleeは言う。 彼女は、「自分の能力を最大限に発揮してくれるだろう」といった曖昧な目標を設定した文書を見たことがあります。 それは、家庭の所有者がペンキ屋を雇うときに、”可能な限り最善の努力をする “という指示を出すようなものだと、彼女は例えています。
「画家がそのとおりにしても、家を白ではなく紫に塗ってしまったら、彼に対するクレームはないでしょう」と、彼女は言います。
スカフィディはこのようなアドバイスを心に刻んでいます。 あるタスクが「妥当な時間」かかると言う代わりに、Scafidiは「指定されたタスクは4時間以上かからないだろう」と書いています。
「弁護士は、そのようなことについて明確で曖昧でない定義があると気分がいいものです」と彼は言っています。
ポストプロダクションのニーズを忘れないようにする。
ゲレロは、SOW にポストプロダクションの要件を含めることを推奨しています。 ベンダーから必要とされるテストとサポートについて明記することだと、彼女は言います。 また、インストール後に社内の人間がシステムをサポートする予定であれば、ベンダーがスタッフのトレーニングを行うかどうかをSOWに記載する必要があります。 このような文言があれば、ベンダーが「システムを納品して終わり」ではないことが保証されると、彼女は言う。
Pratt は、マサチューセッツ州ウォルサムの Computerworld 寄稿ライターです。 彼女の連絡先は、[email protected].
です。