プロジェクト組織-プロジェクトの機能と役割

広告

プロジェクトは一時的な組織であるため、プロジェクト内の構造や階層、コミュニケーションチャネルが規制された独自のプロジェクト組織も必要です。プロジェクトとラインの境界線を明確にして、ライン内でもプロジェクト内でも効率的に行動できるようにしなければなりません。

プロジェクトの数も、プロジェクトに関わる社員の数も、常に増加の一途をたどっています。プロジェクトに加えてラインの活動も担当しなければならないため、リソース不足はよく知られています。そのため、ラインとプロジェクトの境界線を明確にすることが重要になります。プロジェクト組織を設立することで、最大限の透明性を確保することができます。

プロジェクト組織の確立に向けての挑戦

企業がプロジェクト管理のために追加人員を雇うことは、ごく稀です。プロジェクト担当者は、日常業務の中で、ラインワークに加えて追加の仕事を与えられています。上司にも本人にも、どの活動にどれだけの時間を割けばよいのかがわからないことが多い。

プロジェクトワークによる能力の混乱

ほとんどの場合、この二重のタスクには二重の上司が伴います。ライン・マネージャーに加えて、プロジェクト・マネージャーも突然指示を出します - これらの指示は、ほとんど合意されることはなく、しばしばお互いに矛盾し、従業員に過負荷をかけます。場合によっては、これが従業員の側の脱落とフラストレーションにつながることもあります。最悪の場合、このような状況が長く続くと燃え尽き症候群になります。ここでは、紛れもない規制が絶対に必要です。

コミュニケーションと意思決定の経路

プロジェクトでは、日常的に行わなければならない部署間のコミュニケーションや意思決定のパスは、多くの場合、退屈で長引き、プロジェクトの進行に大きな支障をきたす。そのため、明確なコミュニケーション、意思決定、エスカレーションパスを作成するためには、プロジェクト組織を会社組織から部分的または完全に切り離す必要があります。

広告

プロジェクト組織の目的

臨時プロジェクト組織は、原則として、独自の規則、役割、コミュニケーションの仕組みを持つ臨時の会社です。プロジェクトに関わる人々の協力を規制するための不可欠な手段です。

明確な機能、役割、階層

機能と役割が明確に定義されていることで、仕事と能力の明確な配分とライン組織への明確な区分けがなされています。階層はフラットですが、明確に定義されています。誰が誰に報告し、誰がどのような決定を下し、誰がどのような「命令」を下すのかを誰もが知っています。これにより、関係者全員に透明性が生まれ、プロジェクトの遂行を何倍にも早めることができます。

今、X部門の社員AがY部門の社員Bの判断を求めている場合、ライン組織のようにそれぞれの上司を経由するのではなく、社員Aと社員Bの間で直接明確にすることができるからです。


プロジェクト組織の目標

  • プロジェクトの透明性の創出
  • 事業関係者の協力の規制
  • 意思決定、報告、エスカレーションパスの特定
  • コミュニケーションチャネルの短縮
  • 機能と役割の定義による明確なタスクとコンピテンシーの配分
  • プロジェクトコミュニケーション/情報発信の基盤づくり

プロジェクト対ライン

プロジェクト組織では、社員はプロジェクト期間中、ライン組織から一定割合の労働時間を「差し引き」ます。プロジェクト組織は、ライン組織よりも無駄がなく、フラットな組織であるため、プロジェクトチーム内の情報、コミュニケーション、エスカレーションの効率を高めることができます。

プロジェクトタスクとラインタスクの違い

役割とタスクの明確な定義とラインとの明確な区分けが不可欠である。ここで最も重要なのは、プロジェクトマネージャーが完全な意思決定と指示の権限を持ち、プロジェクトを推進する機会を持つことです。

プロジェクターとライン

プロジェクトチームのメンバーや参加者全員が、新しいプロジェクトの構造に対応するための学習をしなければならず、実際にはかなりの困難を伴うことが多い。突然「プロジェクトマネージャー」の称号を与えられたからといって、実際の従業員に報告するのが好きな上司は誰でしょうか?

プロジェクト組織は現実的に住みやすいものでなければならない

プロジェクトの役割を擬人化するとき、それは従って可能な相違を最初から緩和するために通常の階層をあまり変えないことは大きい利点である。戦略的な課題は、一時的な組織を生きたものにすることである。プロジェクトにおける役割と機能を定義することで、すべての従業員は、自分のタスクとコンピテンシーだけでなく、プロジェクトの同僚のタスクについても知ることができます。したがって、権利と義務についての不必要な議論は、少なくとも最初の段階で回避することができます。

広告

プロジェクト組織への道

プロジェクトの役割の定義

プロジェクト組織は、プロジェクトの初期段階で必ず作成されます。最初のステップは、人に依存しないプロジェクトの役割の定義である。どの役割が必要かは、プロジェクトによって異なります。時々基本的なものだけを含んでいる最も小さい形態で十分である。プロジェクトのクライアント、プロジェクトマネージャー、プロジェクトチームです。プロジェクトの規模によっては、技術的な専門家としてのプロジェクトスタッフ、関係するすべての組織単位を代表する運営委員会、またはプロジェクトコーチが呼ばれることもあります。

プロジェクト内での役割の人員配置

役割が定義されたら、それらはタスクを実行するのに最適な人々に割り当てられます。プロジェクトのクライアントがライン組織の中でより高い位置にいればいるほど、プロジェクトの優先順位が高くなり、一方ではプロジェクトのクライアントが決定のほとんどを自分で行うことができるため、プロジェクトにとってはより良い結果となります。

プロジェクトマネージャーは、自分のプロジェクトチームを選択するのが理想ですが、実際には、既存の人材と能力のプールからプロジェクトチームを割り当てられることが多いです。プロジェクトチームの「採用」は、どのような場合でも、それぞれのラインマネージャーと調整しなければならない。

報告構造と意思決定パス

プロジェクト組織は、ライン組織と同様に、報告構造と意思決定パスに関する情報を提供し、プロジェクトのコミュニケーション計画の基礎となるものである。誰が誰に報告し、誰が誰に指示を出すかという情報を提供する。

プロジェクトの組織をグラフィカルに表現

プロジェクトの組織を図式化するには、図式化するのが最適である。ライン組織との違いを明確にするために、円や楕円形で表現されることが多い。他の表現も可能であるが、普及していない。

なぜなら、プロジェクトの特定のフェーズにおいてのみ、特定の権限が必要とされるからである。すべてのプロジェクト計画と同様に、プロジェクト組織は常に有効性をチェックし、必要に応じて修正しなければならない。

従業員がプロジェクトや会社を全く離れてしまうこともあります。また、新たに定義されたプロジェクトタスクのために、新しい従業員を呼ばなければならないこともあります。プロジェクト組織は、プロジェクト計画の内容と一緒に生活しています。

プロジェクト組織の例

プロジェクト組織


古典的なプロジェクトの役割 - タスクとコンピテンシー

プロジェクトクライアント/プロジェクトスポンサー

  • プロジェクトマネージャーへのタスクの明確な割り当て
  • プロジェクトマネージャーとの戦略、プロジェクト目標、優先順位の定義
  • プロジェクトマネージャーとの組織体制条件の合意
  • パワープロモーターとしてのプロジェクトマネージャーのサポート
  • 戦略的プロジェクトの意思決定
  • 予算の決定を行う
  • 戦略的プロジェクトの制御
  • すべての被災地とのプロジェクトの調整
  • プロジェクトの利害関係を外部に表現する
  • 問題や危機が発生した場合のプロジェクトマネージャーのサポート

運営委員会・運営委員会

  • 審査会」などと呼ばれることが多い。
  • 部署横断的、組織横断的、プロジェクト別の意思決定を行う
  • プロジェクトマネージャーの影響力による支援(パワープロモーター
  • プロジェクト部分の受け入れとプロジェクト全体の成果
  • プロジェクト依頼者は運営委員会のメンバーでなければならず、通常は運営委員会の議長を務めます。

プロジェクトマネージャー/プロジェクトマネージャー

  • プロジェクトプランニング
  • 運用型プロジェクト管理(パフォーマンス、納期、コスト、リソース
  • プロジェクトのコミュニケーションと情報の設計
  • プロジェクトチームのリーダーシップ
  • プロジェクトの運営調整・管理・完了
  • プロジェクトのクライアント/運営委員会との調整・調整
  • プロジェクトの文書化とレポート作成
  • プロジェクト会議の司会と成果の確保
  • プロジェクトの全体的な責任を持つ

プロジェクトチームメンバー

  • 割り当てられたプロジェクトタスクの実施とその結果に対する責任
  • 技術ノウハウの提供
  • プロジェクトチームの会議への参加
  • プロジェクト計画におけるコラボレーション
  • プロジェクト実施におけるコラボレーション
  • プロジェクト管理での連携
  • プロジェクトマネージャーへの情報提供

プロジェクト協力者

  • 技術ノウハウの提供
  • 割り当てられたプロジェクトタスクの実施
  • プロジェクトチームへの情報提供

チェックリストプロジェクトの構成

私のプロジェクトを整理する方法 - 最初の一歩

  • プロジェクトの開始時には、プロジェクトの組織が確立されている必要があります。
  • すべてのプロジェクトメンバーがまだ定義されていない場合、プロジェクト組織は、後に名前が付けられる役割と機能で満たされているだけです。
  • プロジェクトの構成をフリップチャートやホワイトボード、または同様のメディアで作成するのが最善の方法です。
  • ライン構成と区別するためには、円形または楕円形の表現が推奨されます。
  • 最低でも含まれている必要があります。プロジェクトの顧客、プロジェクトマネージャーおよびプロジェクトチーム。
  • 例えば、以下のようなものを追加することができます。技術専門家、運営委員会、サウンディングボード、サブチーム、外部の役割、プロジェクトコーチ。

プロジェクト組織における役割と機能の定義

  • プロジェクトの各役割ごとにタスク、コンピテンシー、責任が定義されています。注意。これらは重複してはならない、そうでなければ、プロジェクトの過程で曖昧さにつながる。
  • 誤解がないようにしましょう!プロジェクトで移動速度に達してしまえば、通常は不明確なコンピテンシーについて議論する時間はありません。
  • ヒント:自分の定義を外部の人にチェックしてもらい、その人が自分と同じことを理解しているか、矛盾に気づいているかどうかを確認してもらいましょう。

プロジェクトチームの指名

  • 人を指名するときは、ライン組織をあまり混乱させないように注意してください。プロジェクト内の従業員に報告しなければならない部門の長は、通常、チーム内の緊張につながり、最悪の場合、それは全く動作しません。
  • ラインの社員数が多いほど、社内でのプロジェクトの優先順位が高くなり、意思決定が早くなります。
  • あなたのプロジェクトの中であまりにも多くの人のために計画しないことを確認してください、疑わしい場合には、あなたはむしろ少ない計画を立てます。2人の技術専門家は、5人よりもはるかに効率的に仕事をすることが多いです。
  • プロジェクトチーム(運営委員会、プロジェクトクライアントなどを含まない)の理想的な規模は5~10人です。チーム内の従業員の数が多い場合は、サブグループを形成することは理にかなっています。
  • いずれにしても、プロジェクトチームメンバーの指名をラインマネージャーと調整しましょう!

プロジェクト内の組織の設定

  • プロジェクトチームの各メンバーが、プロジェクトにおける自分の役割を認識し、自分のタスク、能力、責任を理解し、実行できるようにする。
  • プロジェクトの組織をベースにして、プロジェクト内のコミュニケーションを計画する。その結果がプロジェクトのコミュニケーション計画です。つまり、プロジェクトチーム内の構造化されたコミュニケーションも「クロックイン」されているということです。
  • チームがお互いを知ることができるキックオフミーティングを開催しましょう。
  • プロジェクトから外れた」活動は、特に最初の段階ではもちろん、その間のチームビルディングやモチベーション対策としても適しています。
  • プロジェクト組織の妥当性と意味があるかどうか、定期的にチェックしてください。新しいタスクは、新しいプロジェクトメンバーを意味するかもしれない。彼らも同じようにプロジェクト組織に統合されなければならない。

プロジェクト組織で目標を達成したか?

  • 関係者は周知の上、文書化されています。
  • 各プロジェクトの従業員は、誰がどのプロジェクトの役割に割り当てられているかを知っています。
  • 各プロジェクトの役割には、タスク、能力、責任が割り当てられています。
  • コミュニケーションの仕組みは透明性があり、プロジェクトの従業員は誰に何を伝えなければならないのか、誰に何を伝えるべきなのかを知っています。
  • プロジェクトにおける意思決定の階層が明確に定義されている。
  • プロジェクトのコミュニケーションは、可能な限り最短の経路で実行されます。
  • 階層はラインよりもフラットで、意思決定のパスが短く、情報の流れが効率的になります。

現場からのお役立ち情報

  • フリップチャート、ホワイトボード、または同等のメディアを使って、プロジェクトの組織を作成することをお勧めします。
  • 円や楕円などで表現することで、ライン組織との差別化を図ることができます。
  • チームビルディングを容易にする"オフザプロジェクト"のスタートワークショップと活動。
  • すべての共同研究者は、自分たちの役割、すなわち自分たちに課せられた期待を明確にしなければならない(例:役割/機能を少なくとも簡潔かつ簡潔に記述する)。
  • 役割の説明の濃さは、プロジェクトの規模やプロジェクト参加者のプロジェクト経験によって異なります。