3.0プロジェクト展開のフェーズ(パート2)

発達 #

開発フェーズでは、プロジェクトの実装に必要なすべてのコンポーネントが組み立てられます。 潜在的なサプライヤーまたは下請け業者に連絡し、スケジュールを作成し、消耗品とツールを注文し、従業員に指示を出します。 実装フェーズを開始する準備ができたら、開発フェーズは完了です。 実行の責任者のために、すべての問題を明確にする必要があります。

特定のプロジェクト、特に小規模なプロジェクトでは、正式な開発フェーズはおそらく不要です。 重要なのは、実装フェーズで何を、誰が、いつ達成する必要があるかが明確であるということです。

実装 #

実装フェーズでは、プロジェクトが形になります。 このフェーズでは、プロジェクトの成果を実際に構築する必要があります。 プログラマーはエンコードし、デザイナーはビジュアルコンテンツを作成し、請負業者は構築し、実際の再編成が行われます。 これは、プロジェクトが始まったばかりだと信じている外部の人にプロジェクトが明らかになる期間です。 NS

実装は「実行」フェーズであり、この期間を通じて勢いを維持するために重要です。

あるケースでは、プロジェクトチームは、重要なチームメンバーの1人が親になることに気づかなかったため、約1か月間完全に利用できなくなりました。 彼を交代させる時が来たとき、チームが停止するのを防ぐために外部の専門家が呼ばれました。 チームは維持することができましたが、外部の専門知識が予算を大幅に削減しました。

実装フェーズの終了時に、結果は定義フェーズで確立された要件のリストと比較されます。 さらに、それは設計に関連して評価されます。 たとえば、オンラインアプリケーションがInternet Explorer5およびFirefox1.0以降をサポートしていることを確認するためにテストを実行できます。 建物のトリムが合意に従って建設されたかどうか、または使用された材料が実際に定義段階で指定されたものであったかどうかを確認することができます。 このフェーズは、すべての基準が満たされ、結果の製品が設計と一致したときに完了します。

プロジェクトに参加する人は、定義段階で述べられたすべての基準を正確に満たす製品を入手することは非常にまれであることを覚えておく必要があります。 プロジェクトの実行中に、予期しない出来事や理解の進歩により、プロジェクトチームは最初の一連の要件やその他の設計ドキュメントから離れることを余儀なくされる可能性があります。

これは、特に外部クライアントがプロジェクトの結果を注文した場合に、競合の原因となる可能性があります。 場合によっては、顧客は定義プロセス中に達した合意を呼び出すことができます。

通常、定義プロセスが完了すると、要件を変更することはできません。 これはデザインにも当てはまります。デザインプロセスが完了すると、デザインを変更することはできません。 これが必要になった場合(場合によっては発生します)、プロジェクトリーダーは、変更がすべての利害関係者(特に意思決定者または消費者)にできるだけ早く伝達されるようにする必要があります。 さらに、将来の誤解を避けるために、行われた変更を適切に記録することが重要です。 プロジェクトのドキュメントに関する追加情報は、このガイドブックの後半に含まれています。

クローズアウト&フォローアップ #

重要ではありますが、フォローアップのステップは見過ごされがちです。 このフェーズでは、プロジェクトの成功を確実にするために、すべての重要な準備が行われます。 フォローアップフェーズには、マニュアルの作成、ユーザー向けの指示とトレーニング、ヘルプデスクの設置、結果の維持、プロジェクト自体の評価、プロジェクトレポートの作成、パーティーの開催が含まれる場合があります。結果の達成、プロジェクトチームの取締役への異動、およびプロジェクトチームの解体を祝うため。

フォローアップフェーズの重要な問題は、プロジェクトがいつどこで終了するかです。 プロジェクトマネージャーは、プロジェクトの最初の90%は速く動くと冗談を言うことがよくあり、最後の10%は数年かかる場合があります。

プロジェクトがこれらの制限に達した後、フォローアップフェーズでプロジェクトを閉じるために、プロジェクトの境界はプロジェクトの開始から評価する必要があります。

プロジェクトの最終結果がプロトタイプになるのか、機能する製品になるのかが、関係する個人にとって不明確な場合があります。 これは、不確実な結果を伴う創造的なイニシアチブで特に一般的です。 顧客は製品の受け取りを期待しているかもしれませんが、プロジェクトチームはそれがプロトタイプを開発していると信じているかもしれません。 このような状況は、フォローアップ期間中に最も発生しやすくなります。 新しいアイデアを検証するために設計されたソフトウェア開発作業の例を考えてみましょう。 調査結果を取得する可能性については、かなりの懸念がありました。

最終的に、プロジェクトは前向きな結果をもたらしました。 チームは、少なくともテスト環境の範囲内で、うまく機能するソフトウェアを作成しました。 情報技術に不慣れなクライアントは、機能的な製品を手に入れたと信じていました。 結局のところ、それは彼のオフィスのコンピューターで動作していました。 プログラムはうまく機能しましたが、50人の作業者のPCに配置すると、プロトタイプに問題が発生し、いくつかの点で不安定になりました。

プログラマーはソフトウェアを修復することはできましたが、次のプロジェクトに参加したため、時間に追われました。 さらに、彼らは実験的なアイテムと見なしたものを修理することにほとんど興味がありませんでした。 数か月後、MicrosoftがWindows Service Pack 2を導入したとき、プログラムは完全に動作しなくなりました。 クライアントは、「製品」が製造中止になったことに激怒しました。