プロジェクト管理:運用vs. プロジェクトアプローチ

Habrユーザーから尊敬されている著者の投稿に対するコメントの1つで、プロジェクトが失敗した主な理由は、「through%opu」または「どうなるか」という方法論の使用ではなく、プロジェクト内の運用管理のみの存在だと答えました。 このようなマネージャーのプロジェクトアプローチは、プロジェクト見積もりの​​準備が完了すると終了します。

この投稿では、運用アプローチと設計アプローチのより詳細な比較を行います。



プロジェクト管理レベル







1.運用レベルとは、数時間続く操作(通常「タスク」と呼ばれる)のレベルと、これらのタスクの完了時に発生する問題です。 このレベルでは、多くの「ささいなこと」が蓄積されます。ここで考える時間はありません。すぐに実行する必要があります。

2.プロジェクトレベルは、数日間続く作業レベル、作業ブロック、およびコントロールポイントです。 このレベルでは、タスクを開始するのではなく、さらに分析し、予測する必要があります。 ここでも問題は解決され、リスクを伴う追加作業が実行されます。

3.プログラムレベルとは、プロジェクトキュレーターまたはプログラム/ポートフォリオマネージャーのレベルであり、プロジェクトにあまり没頭しておらず、原則としてコントロールポイントの通過、主要な問題とリスクの解決に関心があります。

4.手動制御。 これは最も簡単ですが、他の方法に比べて最も影響力のあるアプローチです。 「リーダー」が命令を出した場合、それは実行に必須であり、計画やプログラムに何があってもかまいません。 すべての作業は、マネージャーの指示に基づいています。 使いません-仕事がありません。

注意! これらのアプローチはすべて、特定の1つだけでなく、プロジェクト管理で使用されます。



比phor



手動制御

画像-何をする必要があるかを指で指します。



運営管理

画像はコンベアです。

コンベアの動作をカスタマイズします。 タスクを定式化し、コンベヤに転送します。その後、彼は解放されたチームメンバーにタスクを個別に分配します。

主な原則:「通常の実行-通常の実行になります。」



プロジェクト管理

画像-ビリヤードのプロのゲーム、プレイヤーがキューでゲームをするとき。

シリーズ全体を計算して、キューに追加する必要があります。

次のボールを誤って入力した場合、次のボールを獲得する前に、シリーズを再計算する必要があります。その後、ボールを獲得します。

つまり、プロジェクト管理では、運用管理(ボールを獲得するため)を実行するだけでなく、常に最後のボール(最終結果)に焦点を当てて、数歩先の状況を計算する必要があります。



思考の地平線



タスクやプロジェクトの管理に最も洗練されたシステムを使用している場合でも、脳は、コンピューターのプロンプトでさえ、これらのシステムに含まれるすべてのタスクを管理できません。 したがって、限られた割合の情報が視野に入るでしょう。

以下は、運用レベルとプロジェクト管理レベルの考え方の比較です。





運用レベル


このレベルでは、マネージャーは通常、タスクのリストを持っています。 1つのタスクを閉じた後、マネージャーは次のタスクを解放された従業員に転送します。 通常、マネージャーは主なタスクを特定し、プロジェクトチームのメンバーが作業するコンベアに再び転送します。

したがって、思考の地平線は一連の優先操作(「タスク」)です。



設計レベル


プロジェクトアプローチは、プロジェクト全体の制御を意味します。 ただし、実際には、約1年以上続くプロジェクトの場合、プロジェクト全体を常に把握しておくことが常に望ましいとは限りません。 したがって、このような状況では、「接近波」方式が使用されます。 最初に、1つの段階が実行され、小規模な作業(2〜3か月続く)について詳しく説明されます。 次に、主にこの段階のみを管理するための作業が行われます。 そして、次の段階に移行すると、「次の波が来ます」とプロセスが再び繰り返されます。 ただし、プロジェクトアプローチは現在の段階の管理だけに限定されず、定期的に次の段階で遠い未来を調べる必要があります。

したがって、思考の地平線はプロジェクトの段階です(プロジェクト全体は小規模プロジェクト向けです)。



実行制御



制御が必要な理由と、どのような制御結果を得る必要がありますか?


プロジェクトは限られたアクティビティであるため、このプロジェクトを特定のフレームワーク内に維持するよう努める必要があります。 このフレームワークが制御されない場合、おそらくこのプロジェクトだけではそれらに留まらないでしょう。 一般的に、国境管理がなければ、それは決して終わらないかもしれません。

「航海の場所がわからない場合、風のいずれかがあなたにとって公平ではありません!」中国の民俗の知恵を読みます。





制御プロセスの結果は、次の情報になります。

-ステータス (何が行われ、どのような問題が発生しましたか?)

内容:何をする

タイミング:費やした時間

コスト:費やされた金額

変更:変更の要求が表示された(コンテンツ/条件/コストへの影響の評価)

問題:どのような問題が発生しますか

その他



-偏差 (満たすまたは超過する時間がないもの)

内容:計画に関して満たす/超過する時間がないもの

タイミング:どれくらいの時間が遅れていますか? 計画を完了するのにどれくらい時間がかかりますか

コスト:どれくらいのお金が使いすぎた/節約されたか? 計画を完了するために必要な金額

その他



-予測 (将来何が起こるか、いつ、どのようにコントロールポイントが渡されるか、どのような問題が発生する可能性がありますか?)

内容:今後どのような結果が得られるか

日付:マイルストーンはいつ渡されますか

コスト:コントロールポイントでプロジェクトに費やす金額

変更:上記の予測は、変更を含めることを考慮して提供する必要があります

問題:どのようなリスクとそれらにどのように対応するか(リスク-これらは将来起こりうる問題と機会です)

その他



どのくらいの頻度で監視しますか?


監視操作-常に実行します。

プロジェクト管理-定期的に(1週間に1回、2週間に1回)。



おわりに



運用レベルでは、多くの操作があるため、マネージャーはプロジェクトのごく一部しか管理せず、プロジェクトの残りの部分を見えなくします。 彼は客観的に偏差を測定し、プロジェクト全体(またはプロジェクト段階)の予測を行うことはできません。 そして、測定も予測もできないものを制御することはできません。

プロジェクトレベルで、マネージャーは偏差を測定し、プロジェクトの予測を行い、それに応じてこれを効果的に管理できます。



これらのアプローチは両方ともプロジェクト活動で使用する必要があります。



All Articles