そして、人生が始まり、プロセスは独自の方法で進み、独自の方法で決定を下しましたが、文書は棚に残りました。 RPは、顧客が設定された期限を遵守していないこと、または他の契約に違反していることを示すためにそれを取り出すことがあります。 しかし、これはプロジェクトの緊張が高まり、当事者が自己防衛する必要があるときに行われます。 RPがプロセスを更新しようとする状況もありますが、多くの場合、結果ではなく「紙片」を扱う官僚として「askew」と見なされます。
その結果、そのようなドキュメントは、RPニックネームまたは請負業者を保護する機能、または請負業者のマーケティング機能を実行します。 プロジェクトテクノロジに取り組んでいます！」 ドキュメントを機能させたい。
まず最初に、概念について説明しましょう。 ITプロジェクト業界では、憲章とプロジェクト管理計画の2つの文書がどのように1つの文書に結合され、「プロジェクト憲章」と呼ばれるかをよく観察します。 特にプロジェクトの最初に作成されたこの「チャーター」がプロジェクトの実装で使用されなくなった場合、これにはおそらく何も問題はありません。 しかし、作業中のドキュメントを取得する必要がある場合は、ソースに目を向ける必要があります。
PMBoKによると：「プロジェクト憲章は、プロジェクトの開始者またはスポンサーによって発行された文書であり、プロジェクトの存在を正式に承認し、プロジェクトの運営に組織のリソースを使用する権限をプロジェクトマネージャーに与えます。 ビジネスニーズ、仮定、制限、顧客ニーズ、高レベルの要件の理解、および作成予定の新製品、サービス、結果を文書化します。 ""プロジェクト管理計画は、プロジェクトの実装方法、実装方法を説明する文書です。監視と制御。 計画プロセスから生じるすべてのサポートおよび基本計画を統合および統合します。
そのため、プロジェクトの憲章はプロジェクト管理計画よりも静的です。 これはプロジェクト自体の本質を定義し、顧客（またはスポンサー）からプロジェクトマネージャー（以下「RP」と呼びます）への注文です。このような特定の制限内でプロジェクトを作成する必要があります。 憲章の修正内容を変更する必要がある場合、ポーランド共和国または請負業者にとって、これは顧客との契約関係を修正する機会です。 したがって、このドキュメントは、RPまたは請負業者ではなく、顧客またはスポンサーによって作成されます。 これは重要です！ 私たちは、プロジェクト管理計画がスケジュールではないという事実に焦点を当てません。 ここで、おそらく、ロシア語で「計画」という言葉を使用した歴史が語っています。 プロジェクト管理計画では、憲章に記載されている境界とパラメーターの範囲内で結果を達成するために、RPとプロジェクトチームがこのプロジェクトを実行および制御する方法について説明します。 このドキュメントはより動的で、すべてのプロセスをすぐに判断することはできないため、プロジェクトの過程で揮発性があります。
プロジェクトはユニークな企業であるため、ユニークな一連のプロセスがあります。 プロジェクトの開始時に、いくつかのプロセスのバリエーションを計画していると想定できますが、プロジェクトのキャンペーンではそれらを修正するニュアンスが明らかになり、これは正常です。 ドワイト・アイゼンハワーが言ったように、「計画は何もない、計画がすべてだ。 すべての計画は、開発が完了した時点で廃止されます。 しかし、計画プロセスでは、あなたとあなたの部下は状況と決定基準を一目見ます。したがって、驚きの時に、彼らは正しい決定を選択します。 したがって、PMBoKプロセス図では、プロジェクト管理計画は複数の異なるプロセスの出力であり、これはプロジェクト憲章では発生しません。 したがって、これら2つのドキュメントを分離する最初の理由は、目的が異なることです。 2番目の理由は、変更のダイナミクスです。 変更を管理すれば、この理由の重要性を理解できます。 3番目の理由があります。 プロジェクトの開始時には、プロジェクトの実行方法を正確に決定することは不可能です。 RPの任命後（憲章の助けを借りて）、チームを編成し、請負業者を決定し、プロジェクトの組織構造を構築し、コンテンツを分解し、効果的なプロセスを検討する必要があります。 これには数か月かかる場合があります。 したがって、プロジェクト管理計画は憲章よりも後に生まれます。
概念を理解したら、多くの場合「定款」と呼ばれるプロジェクト管理計画が機能しない理由について説明しましょう。 プロジェクトの最初に作成されたこのような「チャーター」をたくさん見ました。一部は非常にボリュームがあり、美しく、プロセスの明確な内容と説明がありましたが、プロジェクトのプロセスのほとんどは完了しませんでした。 そして、これはプロジェクトのすべてが悪いという意味ではありませんでした！ プロジェクトの実際のプロセスが、文書で正式に定められたプロセスに対応していなかったというだけです。 私はこの不一致の支持者ではありませんが、プロジェクトは進行中であり、そのようなプロジェクトの結果は得られています。
なぜこれが起こっているのですか？
顧客がプロジェクト管理を持っていない場合、すぐにそれを実装して、設計技術に従ってプロジェクトを美しくすることはできません。 プロジェクト管理は、通常とは別の管理アプローチです。 そのプロセスの実装にはかなりの時間が必要であり、多くの場合、完全に別個の大規模なリエンジニアリングプロジェクトが必要です。 そのため、企業のプロジェクト管理の成熟度などがあります。 つまり 会社（顧客）は、段階的に段階的に成熟します。 そのため、あるレベルから次のレベルにジャンプするだけで、夢を見る必要はありません。 移行は何年も続くことがあります。
プロジェクト管理の成熟度モデルを記述するいくつかの標準があります。
それらの中で最も有名なものは：
- P3M3-ポートフォリオ、プログラムおよびプロジェクト管理の成熟度モデル-ポートフォリオ、プログラムおよびプロジェクト管理の成熟度モデル。
- OPM3-組織プロジェクト管理成熟度モデル-組織プロジェクト管理の成熟度モデル。
たとえば、Wikipediaの「管理の成熟度レベルを測定するシステム」の表を見ると、典型的な成熟度レベルとその特性があります。
レベル2の「管理対象」（「反復可能」）でのみ、プロジェクトアプローチが初期形式で表示されることがわかります。 したがって、紙のアクションをプロジェクトの実際のアクションに対応させたい場合は、プロジェクト管理計画を作成する前に、顧客のプロジェクト管理の成熟度レベルを評価してください。 私の推奨事項は次のとおりです。
- レベル0「欠落」の場合。 プロジェクト管理計画を立てることは意味がありません;誰もそれを実装しません。 チャーターを作成し、プロジェクトの主なパラメーター（スポンサー、顧客、RP、目標、目標、成功基準、メインステージとその結果、ワーキンググループの構成）を入力します。 あなたが請負業者である場合は、これを契約または申請書に直接反映してください。
- レベル1「初心者」向け。 憲章に加えて、プロジェクト管理計画の開始点があります。プロジェクトの組織構造、ドキュメントの承認のタイミングを伴うプロジェクトのドキュメント配布のルールを規定できます。
- レベル2の場合、「管理対象」（「繰り返し可能」）。 ほとんどの場合、顧客はすでに他のプロジェクトに適用した規制文書の特定の例を持っています。 これらの他のプロジェクトでどのように実装されているかを理解することをお勧めします。 それらを訪れて分析することができます。 実行されていないものをすぐに削除し、このドキュメントを基礎としてください。 しかし、このレベルでは、リスク管理、コミュニケーション管理、コンテンツ管理のプロセスを説明する意味はまったくありません。
- レベル3「定義済み」（「標準化」）の場合。 ほとんどの場合、顧客は特定の形式のプロジェクト管理計画を既に持っています。 他のプロジェクトの例でどのように実行されているかを理解することもお勧めします。 しかし、このレベルでリスク管理プロセスを説明することには意味がありません。
- レベル4「測定可能」および5「最適化可能」の場合。 この成熟度レベルでは、顧客は原則として、プロジェクトとそのリスクの本格的な管理のためのすべてのプロセスを持っています。 プロジェクト管理計画が完了します。 従業員はすでに規定のプロセスに従って作業しており、必要なスキルを習得しています。
原則として、機能しない本格的なプロジェクト管理計画を作成しても問題はありません。 上記のアプリケーション（保護とマーケティング）に加えて、彼は顧客にプロジェクト管理の種をsoき、従業員はこれが起こることを知り、それについて考え、おそらく時間とともに成長します。