任正非氏は、プロジェクトが立ち上がった後、顧客のニーズをどの程度理解しているかが、プロジェクトがスムーズに進むかどうかを左右すると考えています。同氏は、厳しい国際競争に直面する中、ファーウェイの意思決定者と経営陣は顧客ニーズの理解の精度を高め、的を射る成功率を高め、プロジェクトのフロントエンドニーズの管理を強化する必要があると強調した。

効果的な顧客需要分析は、プロジェクト需要分析の最初のステップです。重要なのは、核となる利益のニーズを明確に表現することです。

プロジェクトを開始する前に、まず顧客が現在直面しているボトルネックを分析し、顧客のニーズを理解して要約し、顧客の課題を特定するプロセスに入ります。エラーが特定された場合は、顧客が直面している実際の問題が正しく特定されるまで、顧客のボトルネック分析と顧客理解の 2 つの段階を複数回繰り返す必要があります。図 1-1 は、顧客のニーズとタスク分析のプロセスを示しています。

顧客の問題を正確かつ明確に理解した後、要件定義とタスク分析の段階が始まります。これら 2 つの段階の主な目的は、プロジェクト チームの顧客ニーズの理解を統一し、収集した顧客ニーズに基づいてタスク分析と設計を実施し、顧客の期待を向上させ、プロジェクトのタスク設定を調整し、その 2 つを同じプロジェクト要件分析に組み込むことです。フレームワーク 。要件定義フェーズが完了したら、要件範囲管理フェーズに進みます。この段階では、顧客の中核的な要求の範囲内で一連の要件を定義し、その要件を追跡して、どの要件を優先して完了する必要があるか、また特定の条件下ではどの要件を完了できないかを明確にする必要があります。それらは要件の範囲を超えています。要件の範囲を明確にした後は、優先要件を改善し、プロジェクトのタスクを分解することで、顧客ニーズと対応するタスクモジュールを突き合わせ、顧客ニーズと分解されたタスクの整合性を図る必要があります。

ファーウェイの製品マネージャーは、プロジェクトの実践においてこの原則を説明しています。つまり、顧客のニーズを洞察し、顧客が直面している実際の問題を深く分析し、顧客のニーズを正確に定義して改善し、相手の問題を解決する観点から対応する分解タスクを照合することです。 、これにより、ニーズとタスクの一貫したマッチングを通じて、市場におけるファーウェイの競争力を構築します。

お客様の課題を真に解決してこそ信頼を勝ち取ることができ、課題を整理・分析することが課題解決の鍵となります。クライアントの問題は、多くの場合、現在の現実と望ましい目標状態との間のギャップとして現れます。この差を縮めるためには、顧客が直面している問題が具体的に何なのか、問題がいつどこで発生したのか、問題が発生したプロセスやキーパーソン、問題の頻度、現状と期待される目標の範囲を把握する必要があります。ギャップなど。

顧客の問題を発見するには、表 1-1 の顧客の問題の説明と例を使用して、上記の 4 つの側面、つまり問題の特性、範囲、時間、規模から問題を説明することで、プロジェクト チームが明確にするのに役立ちます。顧客の現在の問題を調査し、プロジェクトの欠陥の重要なポイントを特定し、実際の状況に基づいてプロジェクトの推奨事項を作成します。

顧客の問題を明確に定義するには、プロジェクト チームが体系的に考え、全体的な状況を考慮する必要があります。プロジェクトの実行過程では、これまでの独立したモジュールの問題を扱う思考習慣を変え、問題モジュール間の相関関係に着目した考え方に変える必要がある。問題をグローバルな視点で捉え、現状と将来予想とのギャップを明らかにする必要がある。

図 1-2 では、顧客の問題の定義は、顧客の問題が現状と期待の間のギャップまたは変化から生じることを明確に示しています。また、このギャップと変化は機会、つまり潜在的な市場機会が存在することも意味していると指摘しています。顧客の問題を解決する過程にあります。したがって、プロジェクト チームには、顧客を取り巻く環境を洞察し、機会を特定する能力が求められます。

まず、プロジェクトをどのように行うかよりも、何を行うかを明確にすることが重要です。図 1-3 は、ハックマン分析手法における「何を行うか」と「どのように行うか」の具体的な意味を示しています。

プロジェクトの目標の正確性は、プロジェクトの成否に関係します。一度確認された目標は、プロジェクトの進行中に変更することはできません。したがって、プロジェクトの目標を策定する際には、プロジェクトのわかりやすさを考慮する必要があります。過度に複雑な表現は、プロジェクト チームのメンバーが目標を明確に理解するのに役立ちません。通常、プロジェクトの目標の特徴は次のとおりです。 (1) 説明が短く明確であること。 (2) 用語や略語は使用せず、過度に複雑ではありません。 (3) 定量化可能、検証可能、実行可能。 (4) 制限時間を指定する。 (5) 資源の範囲内。 プロジェクト チームがプロジェクトの目標を簡潔な言葉で説明できない場合、それはチームがプロジェクトで何をしようとしているのかを理解していないことを意味します。プロジェクトの目標を真に理解していなければ、プロジェクトの実現可能性計画を立てることは不可能です。

目的実現可能性計画は、プロジェクトの目標を明確にした上で、プロジェクトを具体的に実行するための明確なヒントを提供します。顧客の課題を発見し、プロジェクトの目標を策定したら、顧客のプロジェクト計画の全体設計を行う必要があります。制約された条件下で顧客やプロジェクトチームのリソースをどのように活用するのか、プロジェクトの実装上どのような困難に直面するのか、どのような方法を選択するのがプロジェクトにとって最善の道なのかを体系的に考える必要があります。プロジェクトの実現可能性計画で検討および計画されている。

表 1-3 プロジェクト計画またはミッション ステートメントは、プロジェクトの実現可能性計画を反映しています。実現可能性計画では、プロジェクトの基本的な状況を明らかにし、プロジェクトの背景と目標を記述し、プロジェクトの各段階で完了することが期待される作業と結果を示し、評価基準を作成する必要があります。目標に基づいて策定され、実現可能性計画の評価基準を通じてプロジェクト目標を再決定する必要があるかどうか。もちろん、実現可能性計画を策定するときは、プロジェクトの全体的な性質から出発し、プロジェクトの制約と主要な関係者を考慮に入れる必要があります。

プロジェクトの各段階にはさまざまな不確実要素が伴い、あらゆるプロジェクトには必然的にリスクが伴います。したがって、プロジェクトの開始時にリスクについて体系的に考える必要があります。ほとんどの人は、「リスク」の定義に「不確実性」の意味が含まれていることには同意します。プロジェクト チームがリスクを検討するとき、実際には、どのリンクとどの不確実なイベントがプロジェクトに損失をもたらすかを考えています。一般に、プロジェクトのリスクには、不確実な要因が発生する可能性と、不確実な要因が発生した場合の結果、つまりリスクの度合いの 2 つの要素が含まれます。図 1-4 は、各不確実要素のリスクが「可能性」と「影響」の関数であることを示しています。リスクを伴います。

プロジェクト チームは通常、既存のツールに基づいて、予想される潜在的なボトルネックに基づいてリスクの特定を行います。通常、リスクはリターンに正比例します。プロジェクトが直面するリスクが大きければ大きいほど、プロジェクトが成功すれば得られる利益も大きくなるということです。リスクの解釈は、それが組織にもたらす損失に完全に限定されるわけではなく、その存在は企業に利益をもたらし、利益を増加させる可能性も秘めています。ビジネスチャンス。したがって、リスク管理とは、やみくもにリスクを回避することではなく、プロジェクトのリスク管理ツールを通じてリスクを合理的に管理し、リスクによる損失を削減し、リスクと機会のバランスをとることを意味します。

プロジェクト チームがリスクの存在を判断したら、プロジェクト マネージャーは、チームのリソースの制約とプロジェクトの技術的なパスに基づいて、どのレベルのリスクが許容されるかを決定する必要があります。プロジェクト チームがそのような決定を下す場合、リスク階層にはプロジェクトのコスト、利益、チームの福利厚生、潜在的な損失、デメリットの分析と判断が含まれるため、しばしば議論の的になります。通常、プロジェクトの利益と利益が重要である場合、プロジェクト チームが受け入れることができるリスクのレベルは比較的高くなります。

プロジェクトの損益の観点から見ると、プロジェクトのリスクは、プロジェクトのコストと収益に悪影響を与える不確実な出来事です。リスクの発生はランダムに分散するという特徴があり、プロジェクト計画において特定のリスク要素を明確に定義することはできません。同時に、リスクを評価するのは簡単ではありません。これは、イベントが発生する確率とその結果を直接パラメータとして測定することが容易ではなく、プロジェクト チームの知的資本、統計、データの助けを借りてのみ取得できるためです。および関連ツール。したがって、リスクの発生には、時間や範囲の不確実性が伴うことがよくあります。プロジェクトのコストと収益に対するリスクの影響は、プロジェクト全体で発生する場合もあれば、プロジェクトの細分化されたモジュール内で発生する場合もあります。したがって、プロジェクトのリスクは、プロジェクトのコストと収益に与える影響の範囲に基づいて、プロジェクト レベルのリスクとモジュール レベルのリスクに分類できます。プロジェクト レベルのリスクとモジュール レベルのリスクの詳細な分類については、表 1-4 を参照してください。

プロジェクトの範囲が明確であれば、プロジェクト チームは顧客にどのようなサービスを提供すべきかを明確に知ることができ、プロジェクト構築中にチームの作業手順を計画するのにも役立ちます。プロジェクトのスコープの決定は、まずプロジェクトの開始フェーズから始まり、プロジェクトの開始の最後にプロジェクト憲章が作成され、プロジェクト マネージャーが選択されます。その後、検証後の不合理なプロジェクトスコープの変更管理を考慮したプロジェクトスコープの計画、定義、検証フェーズに入ります。プロジェクトの範囲を明確にすることは、プロジェクトのさまざまな段階で重要な役割を果たします (図 1-5 を参照)。

プロジェクト スコープとは、特定のパフォーマンスと特性を備えて提供する必要がある製品、サービス、またはその他の提供形態を完成させるために実行する必要がある一連のアクティビティです。プロジェクトの不合理な範囲は、通常、2 つの形式で現れます。1 つは、範囲の説明が不完全で、プロジェクトに関係するすべての要件が部分的にしか説明されていないため、必然的に一部の成果物の省略につながります。2 つ目は、範囲の説明が超過しています。要件を満たさないと、計画や予算の範囲内に収まらない成果物も発生し、必然的に組織コストの無駄やプロジェクト遅延のリスクが生じます。

図 1-6 からわかるように、プロジェクト スコープ ステートメントには、プロジェクト スコープ、プロジェクトの受け入れ基準、成果物、プロジェクト外の責任、およびプロジェクト プロセス中の制約に関する詳細な規制と説明が記載されています。プロジェクト範囲を決定する際、プロジェクト チームとクライアントは、プロジェクト チームが取り組むべき作業を確認することに注意を払う必要があります。プロジェクト範囲記述内のタスクは、外部環境の変化をタイムリーに明確にするか、記録する必要があります。制御できないポリシーは、適時に報告する必要があります。プロジェクトの制約は例とともに明確に記載されます。つまり、検証プロセスでは、プロジェクトチームが担うべき作業を明確にするだけでなく、双方が負う責任や役割分担について顧客と合意形成する必要がある。

効果的な顧客コミュニケーションでは、顧客の課題解決の観点から、適切なチャネルを通じて適切な形で適切なタイミングで情報を提供し、その情報が顧客やプロジェクトの協力にとって有益な影響を与えるようにすることが重要です。プロジェクトの協力が完了する前に、顧客とコミュニケーションをとることで、顧客の核となる利益と協力意欲をさらに理解することができます。この段階での顧客とのコミュニケーションは、プロジェクト全体のニーズの分析に基づいて行われ、顧客からプロジェクトの重要な情報を入手し、プロジェクトの最終的な目的とプロジェクト開始後の範囲をさらに明確にします。顧客とのコミュニケーションにおいて、プロジェクトチームは顧客の要求に積極的に対応し、顧客の長期的な発展の観点に立ち、専門的な思考を用いてプロジェクト協力の見通しを説明し、顧客の信頼を獲得し、顧客の意欲を強化しなければなりません。協力する。

顧客コミュニケーションの段階では、ハイレベルの意思決定者、中間管理者、草の根の幹部従業員に至るまで、あらゆるレベルで顧客のニーズやプロジェクトの重要なポイントに基づいて情報を交換する必要があります。また、さまざまなレベルでのコミュニケーションの質も異なります。顧客の協力意欲に影響を与えます。図 1-7 は、クライアントとプロジェクト実施者間の 3 つのレベルでの顧客コミュニケーションの形式を示しています。

(1) 高度なコミュニケーション。これは、会社の CEO およびその他の上級意思決定者と、クライアントの社長およびその他の上級マネージャーとの間のコミュニケーションを指します。企業の CEO はハイレベルの意思決定者として、リソース配分の方向性を決定することがよくありますが、顧客の上級マネージャーはプロジェクト資金の意思決定者であり、プロジェクト立ち上げの最高意思決定者でもあります。両当事者は権威ある発言権と権限を持っています。プロジェクトで期待されるメリットに焦点を当てますが、あまり詳細に注意を払わないでください。プロジェクトを請け負う会社の CEO は、クライアントの上級管理職と緊密な連絡を維持し、いくつかの高レベルの問題やプロジェクトを推進できます。

(2) 中間レベルのコミュニケーション。会社のプロジェクト マネージャーとクライアントのプロジェクト マネージャー間の正式なコミュニケーションを指します。両当事者間のコミュニケーション中に、企業のプロジェクト マネージャーはプロジェクトの範囲を定義し、当事者 A のプロジェクト マネージャーのニーズと提供されるリソースに基づいてプロジェクトの時間、コスト、制約を予測し、両当事者間の協力に関するコンセンサスを強化する必要があります。二つの当事者。

(3) 草の根コミュニケーション。プロジェクト チームのメンバーとクライアントの従業員の間のコミュニケーションを指します。このレベルのコミュニケーションには、プロジェクト マネージャーからのコミュニケーションが伴うことがよくあります。お客様のニーズに合わせて、プロジェクトの内容からお客様の疑問にお答えすることで、お客様がプロジェクトチームを全面的に信頼し、お客様の協力意欲を高めます。

プロジェクト入札の段階に入ると、顧客の要求に対するプロジェクト チームの対応力と問題処理における専門的な態度が、プロジェクト入札の成否に直接影響します。この段階では、プロジェクトチームは入札主体であると同時にプロジェクト執行チームでもあるという、プロジェクト部門型の入札組織構造の特徴を示している。これまでのプロジェクトで蓄積された豊富な経験とソリューションにより、プロジェクトチームは顧客から新たな要求や問題が提起された場合に迅速に対応でき、プロジェクトの業務運営や技術的リスクを容易に理解できるため、落札の可能性が高まります。入札が成功すると、入札と実行を統合するプロジェクト チームは、初期段階と後期段階の間のシームレスな接続を簡単に実現でき、実行の後期段階でのリソースの無駄を回避できます。図 1-8 は、プロジェクト入札チームの構成を示しています。

プロジェクト入札チームは通常、商務省と技術省の職員で構成されます。技術部門は顧客のニーズや顧客から提起された新たな問題に基づいて技術サポートを提供する責任を負い、商務部門は財務、法務、設備の問い合わせと見積もり、およびプロジェクト入札プロセス中のデバッグ サービスを担当します。両当事者の監督者は、担当するプロジェクトのキーノード情報を入札文書アグリゲーターに提供し、顧客応答段階で行われた変更に応じて更新バージョンを入札文書アグリゲーターにタイムリーに提供する必要があります。十分に機能し、顧客のニーズを満たす入札図書は、入札プロセス中に何度も修正および更新されます。何度も更新されるプロジェクトの入札図書は、顧客の信頼を獲得し、落札の可能性を高めます。

プロジェクトの技術文書は入札書類全体の本体であり、プロジェクトを落札する鍵となります。標準化された正確なプロジェクト技術文書は、プロジェクト チームの入札の誠実さを反映しており、チームの厳格で専門的なプロフェッショナルな態度も反映しています。高品質のプロジェクト入札文は、正確な見積もりを取得するための基礎であり、入札文書の品質を厳密に管理します。これは、入札の 3 つの段階で実行できます (図 1-9 を参照)。

契約関係の確立はプロジェクト立ち上げの基礎であると同時に、リスクを回避するために定められた一連の拘束力のある条項でもあります。プロジェクト チームは、契約に含まれる条件を慎重に検討し、プロジェクトに関連する契約関係を慎重に検討し、適切な契約の種類とテンプレートを選択する必要があります。表 1-5 に、契約関係を確立する際に考慮すべき要素を示します。

リスクの観点から見ると、契約関係には主に 2 つのタイプがあります。1 つは固定価格契約、もう 1 つは費用補償契約です。定額契約とは、あらかじめ計算されたプロジェクト費用に基づいて顧客がプロジェクト実施者に支払うことを意味し、契約関係が確立されると、予想コストを超える費用はすべてプロジェクトチームが負担することになります。顧客にとってはリスクは低いですが、プロジェクト実施者にとってはリスクが比較的高くなります。費用補償契約のリスク負担は、その逆であり、プロジェクト遂行中に予想コストを超えた費用を顧客が補償しなければならず、リスクの大部分は顧客が負担することになります。プロジェクトの特性と顧客の要件に応じて、支払い時間は進捗支払いまたは時間支払いに基づくことができます。同様に、プロジェクトに関連するペナルティとインセンティブのルールは、成果物、時間、およびプロジェクトのパフォーマンスに基づいて実装できます。

顧客との契約関係を確立する場合、契約シナリオ エンジニアまたは契約マネージャーは、その専門的役割を活用して、両当事者の権利、義務、責任を明確にし、当事者間でリスクを配分する必要があります。契約締結後、契約マネージャーはプロジェクト実施チームによる契約条件の履行を常に監督および検査し、成果物の品質と有効性を確保する必要があります。プロジェクト チームのメンバーとしての契約マネージャーの責任は、プロジェクト チームに限定されず、法定代理人や代理人の役割などのラインラインの職務にまで及ぶ場合があります。通常、プロジェクトが大規模で複雑になればなるほど、契約をより明確に説明し、認定する必要があります。曖昧な説明は双方にとって不利益をもたらします。条件が明確に説明されず、責任が明確に定義されないと、契約の起草者であるプロジェクト チームはより大きなリスクを負うことになります。したがって、プロジェクト チームと顧客の間に確立された契約関係における契約マネージャーまたは契約シナリオ エンジニアの役割は、図 1-10 で詳しく説明されています。

プロジェクトマネージャーは、プロジェクトの目標を達成するためにチームを率いる役割を果たします。プロジェクト マネージャーの役​​割は、機能マネージャーの役​​割とは異なります。プロジェクトマネージャーの責任の観点から見ると、プロジェクト管理の知識、実践能力、個人の行動、態度、性格、リーダーシップなどの特性に関する彼または彼女自身の認識が、タスクのニーズ、チームのニーズ、および個人のニーズを満たす必要があります。プロジェクト管理の仕事は困難と課題に満ちています。しかし、これまでのプロジェクトの経験からまとめられた手順が、必ずしも特定の作業タスクに完全に適用できるとは限りません。このため、プロジェクト マネージャーは、プロジェクトの円滑な開発を確保するためにさまざまな関係者との連絡を確立する必要があります。図 2-1 は、プロジェクト マネージャーと関連する利害関係者の間のやり取りを示しています。新しい製品やサービスの研究開発やプロジェクトで実現される業務プロセスの改善は、ますます企業価値に貢献します。したがって、企業とプロジェクトチームとの架け橋として、プロジェクトマネージャーが果たす戦略的役割はますます重要になり、プロジェクトチームにおいてプロジェクトマネージャーの管理機能がますます重要な役割を果たします。

ファーウェイが現在プロジェクトマネージャーに提供しているトレーニングシステムは、顧客対応の経験と実戦からのチーム構築の経験を探求することに重点を置いている。世界中からプロジェクト マネージャーを集めて実践的な事例について議論し、その後プロジェクトの現場に戻って作業を行うことで、プロジェクト マネージャーの遂行能力とチーム構築能力が向上します。この研修システムは、プロジェクト遂行の最前線で働く多くのプロジェクトマネージャーに、スムーズな推進・育成の基盤を提供します。

プロジェクトマネージャーの最も重要な特性はリーダーシップです。プロジェクト マネージャーは、プロジェクトのライフ サイクルの各段階で、チーム メンバーを率いて、プロジェクト内で発生するさまざまな問題に対する決定的な解決策を提供する必要があります。プロジェクトマネージャーの責任は、実行チームのリーダーの範囲をはるかに超えています。優秀でプロフェッショナルなプロジェクトマネージャーが、リソースの割り当て、コストの予算編成、スケジュールの調整について説得力のある意見を述べるとき、その役割の性質はより重要なものになります。総合的な経営者になること。ファーウェイは、プロジェクト管理と建設のビジョンの中で、リーダーとして企業のプロジェクト管理能力とさまざまなビジネス分野におけるマルチプロジェクト管理能力の継続的な向上を推進し、プロジェクトマネージャーが個人のプロジェクト管理能力を継続的に向上させるよう促すことを明確に述べています。会社のあらゆるビジネス分野におけるプロジェクトの成功の継続的効率向上を促進し、顧客のニーズに継続的に対応します。

プロジェクト マネージャーは、プロジェクト プロセスにおいてコーディネーター、プロモーター、マネージャーという 3 つの役割を果たします (図 2-2 を参照)。対応する具体的な責任は、プロジェクトのプロセス全体の組織化と管理、プロジェクト チームの管理、顧客と他の利害関係者の関係の調整などです。プロジェクトマネージャーは、プロジェクトの成果が予定通りに納品されるよう、プロジェクトの円滑な進行を促進する必要があります。プロジェクトチームに関しては、マネージャーの機能を最大限に発揮し、リソース配分を最適化し、合理的な組織構造を確立し、従業員の責任を明確にし、満足のいく快適な職場環境を作り、チームメンバーが効率的に働けるようにする必要があります。 。同時に、プロジェクトの開始から成果の提供、プロジェクトの終了に至るまで、プロジェクトマネージャーが提供するサービスは、すべての関係者を繋ぐ総合的なマネージャーとしての能力が求められます。いつでも情報を処理できるようにするとともに、顧客やパートナーの信頼を得るために、プロジェクトに関連する管理と調整にも注意を払う必要があります。

「顧客中心」はファーウェイの中核戦略です。これは、プロジェクトチームが顧客のニーズを正確に把握する必要があることを意味するだけでなく、プロジェクトの提供プロセス中に顧客が提供された製品とサービスを体験できることも強調しています。明らかに、この目標は従来の垂直組織に依存するだけでは達成できません。達成するには、組織の境界が弱く、一貫した目標を持つプロジェクト チームが必要です。

ファーウェイの「Iron Triangle」の本質は、本来の機能組織の境界を打ち破り、顧客の要件を満たすプロジェクト中心の柔軟で機敏な組織を形成することです。 「アイアン・トライアングル」は、相互牽制の組織体系ではなく、顧客を重視し、顧客のニーズに応える共闘部隊である。

プロジェクトの組織構造は、利用可能なリソースの可用性と、プロジェクトの実行方法および効果に影響します。したがって、プロジェクト管理の成功と実施されるプロジェクトの有効性は、組織構造に大きく依存します。特定の組織構造は、特定の情報伝達方法とコミュニケーション スタイルを形成します。

図 2-3 は、プロジェクト チーム内のプロジェクトに対する従業員の投入の度合いに基づいて、組織構造を機能、プロジェクト、およびその間のさまざまなマトリックス構造に分けています。プロジェクトにフルコミットする従業員の割合が高いほど、組織構造はプロジェクトベースの組織になる傾向があります。プロジェクトに全力で取り組む従業員の割合が低いほど、組織構造は機能別組織になる傾向があります。例えば、従業員がパートタイムでプロジェクトを管理し、他のプロジェクトメンバーがさまざまな機能単位から構成されている組織では、この構造は、機能指向が強く、マトリックス構造が弱いことを意味し、これを「弱いマトリックス」構造と呼びます。

プロジェクト中心の組織は、プロジェクトのフロントエンド業務においてタイムリーかつ効果的な調整・変更支援を提供できる一方で、組織が構築するマネジメント支援体制をしっかりとシステム的にサポートします。プロジェクト運営プロセスの中期以降。これは、プロジェクトのフロントエンドとバックエンドを接続する完全なアーキテクチャであり、プロセスや知識などのリソースの循環もカバーします。ファーウェイが構築している組織レベルのプロジェクト管理システムは、プロジェクト中心の管理システムであり、成熟したプロジェクト管理理論とプロセス運用ツールを使用しています。このようなプロジェクト管理システムは、駐在員事務所のイニシアチブを最大限に発揮し、プロジェクトのニーズや顧客のニーズの変化に応じてプロセス設計を柔軟に調整し、取引管理の標準化された管理モデルを形成することができます。

この組織レベルのプロジェクト管理システムにより、プロジェクトチームは一貫したイメージの成果物を顧客に提供することができるほか、プロジェクトの将来の開発方向や状況を予測してタイムリーな調整やレイアウトを行うことで、チームのオペレーションを改善することができます。効率性と収益性。数年間の調整を経て、ファーウェイの組織構造は、当初の機能指向の弱いマトリックス組織構造から、機能補助的でプロジェクト指向の組織構造へと徐々に変化してきました。同時に、プロジェクトマネージャーとプロジェクトマネージャーの役​​割認識は大きく進歩しましたが、プロジェクトマネージャーは、権限や予算管理能力の点で依然として従来の管理モデルに留まっています。したがって、これらの課題に対処するために、ファーウェイはプロジェクトチームをサポートする仕組みを事前に構築し、組織レベルのプロジェクト管理システムの利点を最大限に活用する必要があります。

組織構造の選択は、プロジェクトの特性に応じて調整および設定されることが多いため、組織構造が異なると、プロジェクト マネージャーの権限、利用可能なリソース、および各プロジェクト チーム メンバーの役割に一定の違いが生じます。表 2-1 は、プロジェクトに対する組織構造の影響を示し、特定のプロジェクトの特性と組織構造の対応を示しています。

ファーウェイのプロジェクト管理の「8人のメンバー」は強力な総合戦闘能力を備えたチームだ。 「主要8メンバー」とは、主にプロジェクトマネージャー、技術エンジニア、調達専門家、サプライチェーン専門家、財務担当者、契約マネージャー、プロジェクトチームの人事担当者、品質専門家を指します。明らかに、彼らは全員、豊富なプロジェクト実施経験を持っており、プロジェクト管理において 8 つの重要な役割を担うため、「エイト メンバー」として知られています。 「主要メンバー8名」で構成されたプロジェクト管理チームは、ビジネス指向であり、お客様に完全なプロジェクトソリューションを提供するために、強力なコラボレーション意識と実行力を必要とする、クロスドメインの共同運営を実現します。ファーウェイのプロジェクト管理リソースプールは、特に「8 つの主要メンバー」の協力意識を育成するためのプラットフォームを提供します。

ファーウェイのプロジェクト管理の最前線は、業界ではしばしば「火事場」と呼ばれています。これは、プロジェクトチームのメンバー全員が、成果物をスケジュール通りに完了するために、全力を尽くして昼夜を問わず懸命に働くことが多いためです。チーム内での最大の価値。ファーウェイのプロジェクト管理リソースプールは、プロジェクトチームに定期的に新鮮な血液を注入し、プロジェクトチームの効率的で専門的な戦闘能力を確保します。同時に、プロジェクトチームの「8人の主要メンバー」があらゆるプロジェクトの入口点を迅速かつ正確に見つけられるようにするために、ファーウェイは彼らがビジネスプロセスに慣れるのに役立つさまざまな実践的なシミュレーショントレーニングも提供しています。さまざまな種類のプロジェクト。

ファーウェイの「8人の人材」は、さまざまな専門分野のハイエンドな人材であり、それぞれの専門分野で核を持っています。能力。彼らは同じプロジェクト管理チームに集まり、顧客にあらゆるデリバリーサービスを提供できる、総合的な戦闘能力を備えた優れたチームです。

大規模で複雑なプロジェクトのプロジェクト チームは、多くの場合、多機能なタスクを実行するさまざまな専門職のメンバーで構成され、プロジェクトを円滑に進めるためにはチームワーク能力が重要です。チームを構築するとき、プロジェクト マネージャーは、専攻や経験が異なる人々を、優れたコラボレーションと総合的な戦闘能力を備えたチームに統合する必要があります。しかし、プロジェクトのライフサイクルは限られており、プロジェクトごとに特性も大きく異なります。包括的なプロジェクト チームを編成するのは非常に複雑な作業です。ただし、チームが形成されると、各メンバーの目標がチームのプロジェクト目標の達成を推進します。

ファーウェイのプロジェクト管理では、チームを編成する際に合理的なチーム構造を設計することの重要性を強調しています。プロジェクト管理の成功は多くの要因に影響され、チーム構成だけが決定要因ではありませんが、不合理なチーム構成はプロジェクト管理に多くの問題をもたらし、プロジェクトの正常な運営に影響を与えます。ファーウェイのプロジェクト管理チームは基本的に専門的なスキルに基づいて構築されています。たとえば、ファーウェイは成都金融共有センターに財務プロジェクトチームを置いており、このチームはわずか 11 人で、全国 28 の駐在員事務所と 8 つの研究機関の管理費の会計を担当しています。会計担当者はチームを 3 つの運営グループに分け、それらをフットボール チームのキャンプにたとえました。

ファーウェイはプロジェクトのあらゆる側面においてルールを非常に重視しており、ルールと規律の遵守はファーウェイの厳格な要件となっています。一部のチームメンバーがルールに従わない活動を始めることを防ぎ、ファーウェイ社員がルールを尊重するよう育成するため、新入社員には入社時から懲戒教育を実施する。ルールはプロジェクト全体の円滑な進行を制約するものではなく、明確な要件を通じてメンバーの活動基準を定めることが目的です。合理的なルールは、プロジェクト チームと顧客の間の契約の精神を高めることができます。できるだけ早く明確なルールを確立して従うことは、公正な職場環境を作り出し、秩序ある行動を保証するのに役立ちます。

ファーウェイは、従業員が入社時にさまざまな研修制度を通じて規律意識を確立できるよう支援します。従業員は、会社命令を遵守し、業務上の責任を遂行することを自らの行動規範として内面化することが強調されており、規律意識には業務の遂行と遂行についても具体的に規定されている。この規律の意識を通じて、従業員は仕事やプロジェクトの目標を質と量をもって完了するよう意識されます。

ファーウェイに入社する新入社員は、ファーウェイの規律規定を学ぶ必要があり、従業員は革靴、ズボン、シャツ、ネクタイを着用して勤務する必要があります。ファーウェイに入社するすべての従業員は、この規律を遵守する必要があります。さもなければ彼らは解雇されるかもしれない。

ファーウェイのソフトウェア技術職には、ソフトウェアコードを作成するすべての従業員に対するプログラミング標準に関するトレーニングに重点を置く規律があります。トレーニングを通じて、従業員のコードが標準化された形式に統一されるため、異なるプログラマー間のコミュニケーションの障壁と時間コストが削減されます。

この規律訓練は、従業員がルールに従うための基礎を築きます。軍隊式の規律訓練を通じて、従業員は厳格な態度と規則の尊重を確立するよう育成され、これによりファーウェイの従業員はプロジェクト実行中に時間通りに効果的に作業を完了することが奨励され、プロジェクトチームの効率が向上します。

表 2-3 は、プロジェクトの実施に関するファーウェイのルールと要件を説明しています。ファーウェイが国際市場で強い競争力を持っている理由は、その厳格で専門的なルール意識と密接に関係している。任正非氏はかつてファーウェイの社員に対し、ルールの問題についてルール遵守について深く考えるよう求めた。同氏は、「ハイウェイ（ファーウェイのITシステム）が構築されたと言う人もいるが、ビジネスルールはない。草案を作成し、すべての関連部門に意見を求めて、『生産』というビジネス目標に関して合意に達することができる」と語った。食料を増やし、土地の肥沃度を高めることです。」最終的には、すべての部門が遵守すべき効果的なルールを確立します。

さまざまな部門間のサービス効率を向上させるために、ファーウェイは「内部顧客」の概念を導入しました。ファーウェイは国内企業の中で社内顧客の初期の実践者として、良い成果を上げてきました。任正非氏は、社内顧客とは社内の同僚、つまりサービスを提供すべき顧客を指すと強調し、例えば、人事管理部門は自らを管理部門として位置づけるべきではないと強調した。部門は社内顧客の人事管理部門です。社内のさまざまな部門に優れたサービスを提供することによってのみ、生産、販売、研究開発、その他の部門が会社に価値を生み出し、外部の顧客により良いサービスを提供することができます。

内部顧客の概念は、マッキンゼー、HP、IBM などの世界的に有名な企業によっても強く提唱されています。これらの有名企業から学ぶ過程で、ファーウェイは研究開発、生産、管理担当者が本業に集中できるようにするために秘書サービス制度を確立しました。多くの企業に共通する現象は、従業員が自分の利益を考慮して、他の同僚からの助けの要請に積極的に応じないことです。しかし、社内の顧客サービスが良くない場合、どうすれば顧客中心になれるでしょうか?

有名な経営学者ジョン G. ナイスビットはかつて社内顧客を定義しました。同氏は、企業のすべてのメンバーが内部サービスと内部供給の概念を確立し、お互いの内部顧客になる必要があり、それが部門を超えた水平的なコミュニケーションと協力に役立つと強調した。たとえば、営業スタッフは、ある程度、研究開発チームからの技術サポートを必要とします。研究開発チームにとって、営業スタッフは、ユーザーのニーズに関連する情報が必要な場合、営業スタッフの顧客になります。両者間の相互協力と社内の顧客の役割の周期的な切り替えにより、作業効率を効果的に向上させることができます。

プロジェクト チームはまず社内の顧客に適切にサービスを提供する必要があります。つまり、チーム メンバーはまずお互いに適切にサービスし、プロジェクトのあらゆる側面でシームレスな接続を達成する必要があります。チームメンバーがプロジェクトを開始すると、基本的にプロジェクトのサプライチェーンが形成されます。各部門には異なる分業がありますが、部門間には協力関係があり、サービスを提供することとサービスを提供されることの間には関係があります。

プロジェクトチームは業績評価やKPI指標を一方的に追求することはできず、上司に対する責任や社外顧客へのサービスのみを考慮し、他のチームメンバーへのサービスや他のメンバーとの一貫したプロジェクトサービスチェーンの形成を無視します。このような仕事の考え方では、プロジェクトに対する熱意、興味、使命感を失いやすく、個人の理想を達成できないだけでなく、プロジェクト チームの全体的な目標も達成できなくなる可能性があります。ファーウェイの元副社長である徐家軍氏は、普通の技術者から努力を重ねてファーウェイ・グループの副社長に就任した、そのキャリア経験は、自分のキャリアと目標に責任を負う好例です。 、自分自身、そして自己規律の概念。図 2-5 は、チーム メンバーの責任感を育んだ結果を示しています。

任正非はかつてこう言いました、「企業はオオカミの集団を育成しなければならない。オオカミには三つの大きな特徴がある。第一に鋭い嗅覚、第二に不屈の攻撃精神、第三に集団闘争である。企業が拡大するにはこれらを備えていなければならない」プロジェクトチームの内部の強さも無視することはできません。各メンバーの責任感は、プロジェクトチームが相互にコミュニケーションを取り、協力し続けるための基礎となります。相互のサービス意識と責任に対する姿勢が、プロジェクトチームを形成します。グループ闘争に対する責任感は、複雑なプロジェクトの実行や成果物に反映されることがよくあります。

ファーウェイは、責任回避を職務怠慢であるとみなしており、このような行為を行う従業員は、問題を積極的に解決しない習慣が長年にわたって形成されており、会社の発展と従業員の個人的なキャリアの成長に悪影響を及ぼすだけでなく、プロジェクトにとってさらに有害です。無駄なゴール。表 2-4 は、責任を回避するチームと責任あるチームの違いを比較したものです。

ファーウェイは、周囲のプロセスと関連する立場の調整を非常に重視しています。任正非氏はまた、一人やチームが進歩するだけでは十分ではなく、周囲のプロセス全体が進歩し、良い結果を達成することができて初めて、プロセス全体の進歩と最適化が実現できると強調した。任正非氏のリーダーシップの下、ファーウェイの管理構造全体は、周囲のプロセスや関連業務との連携を強化することを非常に重視しており、事業発展の過程で徐々に「自己修復」メカニズムを形成してきました。この仕組みは、プロジェクト上で問題が発生した場合、上司が調整するまで問題を拡大することなく、周囲のプロセスや関連部門が積極的に最適な解決策を模索し、プロセス間の連携によって問題をスムーズに解決できることを重視しています。

プロジェクトチームの各メンバーがそれぞれの業務に責任を持ち、明確な責任と明確な体制を長期にわたって維持できれば、チームの目標の実現につながります。しかし、メンバー間には複雑なインタラクティブな関係が存在することが多く、この関係はプロジェクト構築のあらゆる側面から切り離すことができず、プロジェクトの目標、複雑な現場環境、主要な技術ノードの多様化により、利害の調整がより困難になります。プロジェクトマネージャーは、プロジェクトの周囲のプロセスを調整してバランスを取り、メンバー間の関係を整え、プロジェクトを円滑に実行する必要があります。図 2-6 は、プロジェクトを取り巻くプロセスの調整に関するいくつかの側面を示しています。

図 2-6 からわかるように、プロジェクトに関するプロセスの調整は 2 つの側面に分けることができます。 1つ目は、複数の目標の調整です。プロジェクトマネージャーは、プロジェクトの品質、コスト、スケジュールなどの目標を調整する必要があります。複数の目標とタスクの相互作用を総合的に考慮し、目標管理のバランスポイントを見つける必要があります。プロジェクトのレベルとさまざまな分野間の交流の多様な目標を調整し、バランスをとることによって、プロジェクトチームの関係調整のための目標体系が徐々に形成されます。 2つ目は関係者との調整です。プロジェクト マネージャーは、関連する利害関係者の目標を包括的に考慮し、メンバー間の潜在的な対立要因を弱め、すべての関係者にとって有利なプロジェクト ソリューションを見つける必要があります。プロジェクトの関係者間の関係の調整は、プロジェクトのライフサイクルのすべての段階に浸透する必要があり、プロジェクトの各段階で、各主題の相反する目標を現在のシナリオに従って調整し、それによって全体的な付加価値を促進する必要があります。プロジェクトの段階全体。

関連する職務を調整するプロセスには、多くの場合、特定のリンクまたはタスクの委任が伴います。プロジェクト チームにおける承認は、多くの場合、チーム メンバーの参加型管理を意味します。これにより、チーム メンバーがプロジェクト マネージャーと意思決定権を共有することが促進され、それによって従業員の仕事への熱意と満足度が向上します。

ファーウェイのプロジェクト管理は物に対する責任を重視しており、これは人に対する責任体系とは根本的に異なる拡張的なシステムです。物事に責任を持つことが、ファーウェイのプロジェクト管理プロセスと適時性を重視した運営を形作ってきました。ファーウェイでは過去に、プロセスに携わる下位レベルのマネージャーが、すべてのことについて上司に指示を求めるという労働習慣を維持していた現象がありましたが、これは間違いでした。ファーウェイは、日常的な事柄や手続き的な問題は、上司に指示を求めて時間を無駄にするのではなく、できるだけ自分で解決し、すぐに終わらせるべきであると強調しています。これは、物事に責任を持ち、日常的な事柄に時間を浪費しないという姿勢を完全に反映しています。すべてにおいて指示を求めることは、人々に責任を負う集中システムを反映しています。ファーウェイのプロジェクトマネージャーと監督者は、適切に承認し、管理における不必要なつながりを減らし、エネルギーを集中して予期せぬ問題や緊急事態に集中する方法を知っている必要があります。管理が効率的に実行されます。

周囲のプロセスや関連する作業位置を調整するための権限では、プロジェクト マネージャーがプロジェクト チームのメンバーに権限を与える必要があることが主に強調されています。このレベルでは、プロジェクトマネージャーが従業員にタスクを割り当てることから始まり、従業員が作業分解構造の作成に関与することで承認が与えられ、プロジェクトの実行プロセス中にチームメンバーに一定の意思決定権と業務に従事する権利が与えられます。特定の活動。表 2-5 は、プロジェクト マネージャーが効果的に作業を調整し、権限を委任するための提案と、注意が必要な重要な点を示しています。

プロジェクトマネージャーがプロジェクトの実践を通じて豊富な経験とスキルを蓄積し、上級プロジェクトマネージャーになると、そのようなプロジェクトは多くの場合、複数のサブプロジェクトで構成され、それぞれが独立して動作します。しかし、プロジェクトはプロジェクトとは異なります。それらの間には密接な結合関係があります。したがって、プロジェクトマネージャによる各サブプロジェクトの管理は、単に直接参加して発注するだけではなく、サブプロジェクトリーダー、プロジェクトマネージャ補佐、新たなプロジェクトマネージャを育成するなど、プロジェクト管理の効率化を図る必要がある。明らかに、この段階でのプロジェクト マネージャーの主な仕事は、プロジェクト チームのメンバーに指導を提供し、ビジネス スキルを向上させることです。

上級プロジェクト マネージャーは、サブプロジェクト マネージャーに経験を与え、特定のプロジェクト管理において一定の指導と支援を提供することにより、各サブプロジェクトのリーダーを訓練することができます。具体的には、プロジェクトの潜在的なリスクを予測し、事前に予防計画を作成するようサブプロジェクトマネージャーに注意を喚起することから始め、サブプロジェクトリーダーをチームビルディングに導き、プロジェクト運営プロセスの主要な問題の解決を支援します。表 2-6 は、プロジェクト管理においてさまざまなレベルのマネージャーが習得および習得する必要があるビジネス スキルを示しています。

プロジェクトマネージャーによる新人研修・指導により、長期的な自己啓発を促す文化が従業員に伝わり、より多くの従業員のプロジェクトへの参加意欲が高まり、ほとんどの従業員が意欲的にプロジェクトに参加し、キャリア開発を確立することができます。目標を達成し、学習経験を積み、プロジェクト チームのトレーニングの機会を得ることができます。同時に、新人を指導する過程で、プロジェクト マネージャーは、プロジェクト メンバーをより適切に指導するために、過去のプロジェクト経験を体系的に整理して要約し、プロジェクト管理の専門知識、実践的なスキル、個人的な対人スキルの間の相互関係を見つける必要があります。経験の継承には、プロジェクト マネージャーが理論と事例を統合し、真実の説明に基づいて従業員にタイムリーかつ継続的な指導を提供することが必要であることがわかります。このプロセスは、プロジェクト マネージャーにとって自己改善のプロセスでもあります。

プロジェクトマネージャーは、プロジェクトチームや他の関係者と連携して、プロジェクトを円滑に進める必要があります。自らが持つコンセプチュアルスキル、テクニカルスキル、対人スキルなどを総合的に活用し、プロジェクトの状況を正しく分析し、適切に対応することで、有能なプロジェクトマネージャーへと徐々に成長していきます。図 2-7 は、有能なプロジェクト マネージャーが持つべき重要な対人スキルを示しています。

プロジェクト マネージャーは、対人関係のスキルを活用して、プロジェクトに対する関係者の期待と目標を管理します。プロジェクト マネージャーの対人スキルは、関連する利益グループ間で信頼を構築し、当事者間の利益相反を弱め、複数の当事者の利益に積極的に耳を傾けることに役立ち、それによってプロジェクト変更に対する抵抗を効果的に克服します。プロジェクト マネージャーが人間関係にどのように対処するかは、プロジェクト チームの作業に重要な影響を及ぼします。具体的な人間関係への影響を表 2-7 に示します。

プロジェクト マネージャーは、自分自身の影響力の構築にも注意を払い、自分の影響力と対人スキルを利用してプロジェクト リソースを合理的に割り当て、チームのモチベーションを高めるという目的を達成する必要があります。プロジェクトマネージャーは、まず模範を示し、プロジェクトに対する専門的な感覚と問題への敏感さを維持し、影響力を利用して構築し、プロジェクトのプレッシャーに自分自身で耐えるだけでなく、そのプレッシャーを適切に下方に伝えて、プロジェクトが評価されるようにする必要があります。チームワークを高め、作業効率を高めます。

プロジェクト マネージャーの影響力は、対人スキルでもあります。プロジェクト マネージャーは、関係者間の協力を促進し、すべての関係者にとって有利な目標を達成するために、いくつかの重要な対人スキルを統合する必要があります。具体的には、プロジェクト マネージャーは次の方法でチーム メンバーに影響を与えることができます。 (1) プロジェクトマネージャーは自らの行動を標準化し、模範を示し、常に責任感を示さなければなりません。 (2) プロジェクトの各段階における意思決定プロセスの透明性を維持します。 (3) 長期的なコラボレーションを実現するために、プロジェクトの特性と関係者の目標に基づいて対人スキルの組み合わせを柔軟に調整します。

プロジェクトを開始する前に、プロジェクト チームはプロジェクトの開始を可能にする重要な要素を特定する必要があります。プロジェクトはクライアントの戦略的目標とニーズに応じて開始されます。この段階では、プロジェクト チームは範囲外で戦略的に推進されていないプロジェクトをキャンセルする必要があります。

図 3-1 は、プロジェクトの起動要素を示しています。通常、プロジェクトは次のような状況が発生したときに開始できます。 (1) 顧客のニーズが明確に表現されており、プロジェクトに関わる関係者の利益も比較的明確である。 (2) 顧客がプロジェクトの運営に戦略的なサポートを提供し、強い協力意欲を示すことができる。 3) ) 技術の向上によりプロジェクトの発展が促進される。 (4) プロジェクトに関連するリソースの入手が比較的容易である。

プロジェクトの立ち上げフェーズでは、チーム全体が互いに同期し、統一された理解を持っている必要があります。特に、立ち上げフェーズで重要なノードについては綿密な議論を行い、合意に達する必要があります。プロジェクト立ち上げ時に潜む危険。表 3-1 は、プロジェクト開始フェーズの重要なポイントを示しています。

表 3-1 からわかるように、プロジェクトの開始段階では、プロジェクト チームは次の点を考慮する必要があります。 (1) プロジェクトの推進要因を確認する。それは、「プロジェクトを始める前になぜを問う」習慣を身につけることです。 (2) 期待される結果。プロジェクトの期待される結果を明確にすることは、プロジェクトの開始プロセス中に準備する必要があるステップの 1 つです。 (3) プロジェクトの方針を決定します。もちろん、具体的な行動には多くの選択肢がありますが、最初にプロジェクトの行動方針を考えることは、プロジェクト チームの適応力を高めるのに役立ちます。 (4) プロジェクトの目標の説明。プロジェクトによって達成されるタスクを説明するために使用され、方法ではなく何を行うかをできるだけ明確にします。プロジェクトの目標の詳細については、図 1-3 を参照してください。

プロジェクトの特性によってプロジェクト立ち上げの難易度や所要時間が決まるため、プロジェクトごとにキックオフミーティングの目的や内容は多少異なるはずですが、キックオフミーティングの核となる内容や条件は比較的に異なります。一貫性のある。図 3-2 は、プロジェクトのキックオフ ミーティングで議論される項目の一部を示しています。

プロジェクトが小規模で、期間が短く、複雑さが少ない場合は、プロジェクトのキックオフ ミーティングでプロジェクトのコストと期間の見積もりに関する事項について話し合うことを検討する必要があります。プロジェクトの規模が大きく、期間が長く、難易度が高い場合には、事前打ち合わせでプロジェクト費用や期間の見積りを決定する必要があります。

表 3-2 に、プロジェクト立ち上げに関するいくつかの会議と具体的な内容を示します。コスト見積もりスケジュールの観点から見ると、プロジェクトのキックオフ ミーティングには次の主要なミーティング マイルストーンが必要です。 (1) 発売前ミーティング。 （２）基本ルール検討会。 (3) リソースの投入と評価の会議。 (4)総括会議及び発表会。

プロジェクトのキックオフ ミーティングには、プロジェクト計画の策定を担当するメンバーの代表者、つまりアシスタント プロジェクト マネージャー、プロジェクト マネージャー、プロジェクトに関与する専門分野の専門家、機能マネージャー、および主要な技術ノードを担当するプロジェクト チームのメンバーが出席することがよくあります。プロジェクトのキックオフミーティングでは、プロジェクトの実施方向と主なプロセスを明確にし、プロジェクトを進める過程での熱心な行動や活動を避け、潜在的なリスクや困難を特定する必要があります。プロジェクトの開始時にできるだけ早くプロジェクトを開始します。

表 3-3 に、プロジェクト会議議事録の構成要素と具体的な内容を示します。表 3-3 は、プロジェクトキックオフ会議の具体的な議題を示しています。プロジェクト計画の策定を担当するメンバーは、キックオフミーティングでプロジェクトの最終的な目的と範囲を明確にし、関連するステークホルダーがプロジェクトのどの側面に参加するのか、その範囲と責任を理解した上で、プロジェクトの計画を策定する必要があります。プロジェクトの成果が無事に達成され、完了しました。

プロジェクト フェーズとは、プロジェクトの製品、サービス、その他の成果物を正常に完了するために、プロジェクト プロセス中に特に制御する必要があるキー ノードに従ってプロジェクトを分割することによって形成されるプロジェクト フェーズを指します。プロジェクトの各段階では主要な制御ノードが異なり、作業の焦点も異なります。入力リソース、出力内容、必要なツールやテクノロジー、その他の要素も異なります。プロジェクトのライフサイクルに従って、さまざまな組織とさまざまな専門スキルが関係するプロジェクトを、開始、計画、実行、監視、終了の 5 つの段階に分けることができます。これは、プロジェクト全体の管理と制御に役立ちます。

図 3-3 は、プロジェクトの開始から終了までの 5 つの段階と、各段階で管理する必要がある重要なポイントを示しています。 (1) スタートアップフェーズとは、新規プロジェクトの開始または元のプロジェクトの新しいフェーズを意味します。この段階での重要なポイントは、第一にニーズとサポートを明確にすること、第二にプロジェクトの目標と位置付けを明確にすること、最後にプロジェクトキックオフミーティングで主要な課題について合意と統一理解を達成し、プロジェクトのミッションステートメントを形成することです。これに基づいて。 。 (2) 計画段階における重要な管理ポイントは、プロジェクトの範囲を明確にし、潜在的なリスク要因を包括的に特定し、各主要ステークホルダーの特性と関心の要求に基づいてコミュニケーション計画を立てることです。 (3) 実行および監視段階における重要な管理点は、まずプロジェクトの関係者と良好なコミュニケーションをとり、次に進捗状況を厳密に監視し、すべての関係者間の関係をタイムリーに調整し、問題を解決し、高レベルの監視に重点を置くことです。危険なタスクを回避し、事前に予防措置を講じます。 (4) 終了段階における重要な管理ポイントは、プロジェクトの評価と受け入れをできるだけスムーズに完了することです。プロジェクトの完了後は、経験をタイムリーに要約し、関連する情報を整理してアーカイブする必要があります。

マイルストーン計画に従って、プロジェクト部門のスタッフは訪問の実現可能性分析を実施し、次の作業手配を明確にしました。まず、会社の受付リソースを決定し、次に顧客視察旅行が月末までに完了するようにします。 、そして最後に、顧客を遠方に配置することを検討してください。会社から車で 30 分以内のホテルは、上級幹部がホストします。最終的に、マイルストーン計画に従って、顧客の上級管理職の訪問は成功裡に完了し、ファーウェイの技術的能力を完全に肯定および認識し、これまでの疑念を払拭した。

標準化された完全なプロジェクトマイルストーン計画は、プロジェクトチームが納品タスクを迅速かつ正確に完了するための魔法の武器であることがわかります。これは、ファーウェイのプロジェクトチームが一般的に使用するツールでもあります。表 3-4 では、ファーウェイのプロジェクト管理でマイルストーン計画を使用する具体的な手順を簡単に説明します。

プロジェクトのマイルストーン計画の策定と実行は、大きく 4 つのステップに分けられます。 (1) プロジェクトのステップを分析します。プロジェクトの実行プロセスを慎重に検討することで、マイルストーン計画はより運用しやすくなり、プロジェクト プロセスの詳細が不明瞭であることによって引き起こされる修正の繰り返しやリソースの無駄などの問題を回避できます。 (2) 重要なステップを決定します。プロジェクトの実行中、前の段階で分析されたすべてのプロジェクト ステップから主要なリンクとステップが抽出されます。 (3) 実行時間を割り当てます。各ステップとリンクの開始時間と期間を明確にして、各段階のタスクと全体的な目標を計画どおりに完了できるようにします。 (4) マイルストーン計画を策定します。前の手順に基づいてプロジェクトの主要なリンクと時期を決定したら、プロジェクトの特性に合ったテンプレートを選択し、マイルストーン計画を作成します。

大規模で複雑なプロジェクトでは、各段階でプロジェクトの実現可能性を高めるために、明確に定義された作業タスクと明確に詳細な作業内容が必要です。作業タスクを明確に定義するための核心は、作業分解構造 (WBS) と呼ばれる文書を作成することです。WBS は、プロジェクト チームが複雑なプロジェクトを運用可能で測定可能な一連の作業システムに分解するのに役立ちます。 WBS は、プロジェクト マネージャーがプロジェクト計画内の重要な作業リンクを見逃さないように、プロジェクト全体の範囲とタスクを定義します。

表 3-5 は、作業分解構造の原則と最下位レベルの特徴を簡単に説明しています。作業分解構造は、端まで水平、底部まで垂直の原則を満たす必要があります。横方向は、作業タスクを分解するときに、プロジェクトの範囲外のタスクを省略したり WBS に含めることはできず、すべてのタスクを徹底的に割り当てる必要があることを強調します。プロジェクトの各段階でのタスクの割り当てと、タスクの重複と範囲を回避し、タスク間の独立性を実現するための標準。

WBS の最上位レベルはプロジェクトです。中間レベルは、プロジェクトプロセスに関わる主要な段階のタ​​スク、つまり成果物レベルです。最下位レベルは、作業パッケージと呼ばれる、タスクを完了するための特定の作業の集合です。作業分解構造には、通常、図形式とディレクトリ形式の 2 つの表現形式があります。図 3-4 は、作業分解構造の 2 つの表現を示しています。

WBS はコミュニケーション ツールとして機能し、プロジェクト チームと経営陣に詳細なプロジェクト情報を提供します。一般に、プロジェクトが大規模で複雑になればなるほど、WBS の最上位レベルと最下位レベルの間にある層が多くなり、対応する作業分解構造プロセスのコストが増加します。 WBS が十分なレベルを設定できない場合、各ステージのアクティビティの一貫性が比較的低くなり、2 つのステージのアクティビティを接続するために発生した時間コストが無駄になります。ただし、レイヤーが多すぎると、特定の重複設定で問題が発生しやすくなります。したがって、明確かつ明確で、タスクが重複しない作業分解構造を準備するのは簡単ではありません。図 3-5 は、Huawei T 顧客検査会社のグラフィカルな作業分解構造の例を示しています。

プロジェクトの各リンクのタスクが作業分解構造を通じて絞り込まれた後、各タスクを適切なプロジェクト チーム メンバーに割り当て、各タスクに特定の担当者を割り当てる必要があります。タスクの責任者が決定したら、その責任者はタスクをスムーズかつタイムリーに完了する責任を負う必要があります。もちろん、タスクの委任では、チーム メンバーの個人的な特性と専門的スキルを考慮する必要があります。タスクを割り当てる前に、プロジェクト マネージャーは、チーム メンバーの中で誰が最も関心があり、特定のプロジェクトを完了するのに適切な能力を持っているかを考慮する必要があります。タスクは指定された責任者に委任されますが、どのレベルまではプロジェクトの規模と難易度によって異なります。

タスクの委任と責任者の特定は、作業分解構造と同時に行われることが多いため、指定された責任者にタスクを割り当てることを検討する場合は、作業分解構造 (WBS) とチーム組織構造 (OBS) を一緒に考慮する必要があります。表 3-6 では、Huawei プロジェクトを例として、WBS と OBS に対応する責任マトリックスを簡単に説明します。

プロジェクトのタスクが指定された責任者に委任されると、プロジェクト チームはこの役割分担を全体として見直し、検討します。レビューと検査の過程で、一部のタスクが委任されていないことが判明しました。その理由は、チームの誰もプロジェクトに興味を持っていないためなのか、それともプロジェクトに参加する専門的な能力を持っていないためなのかを分析する必要があります。 、またはタスクが定義され、明確に説明されていません。考えられるすべての原因を分析し、解決策を見つけます。図 3-6 は、タスクの委任と検査のプロセスを示しています。

図 3-6 は、タスクの委任と検査のプロセスを簡単に説明しています。タスクの割り当てを確認することで、チームメンバーは特定の時間に個人的な週次レポートを提出してタスクを明確にし、後の期間にタスクの進捗状況を記録してチームの作業効率を向上させることができます。タスク委任の失敗につながる可能性のある理由を考慮して、プロジェクト チームは、プロジェクトの特定のタスクを再記述し、有能な従業員を吸収し、特定のプロジェクトに対する既存の従業員の専門的能力と関心を育てることを検討する必要があります。責任者の特定の運用タスク中、プロジェクト マネージャーは常に監視し、必要に応じて指導や支援を提供し、タイムリーに人員配置を調整する必要があります。

プロジェクトチームは、プロジェクト内のすべての活動プロセスの詳細をエンドツーエンドで整理し、タイミングを明確にすることで、プロジェクトの円滑な実施を促進します。プロジェクトの各タスクの作業分解構造を明確にし、タスクを委任し、責任者を割り当てた後、プロジェクトの各リンクのスケジュールを明確にする明確な進捗計画も必要です。プロジェクト スケジュールには、分解されたタスクが特定のタイム スケジュールに反映され、プロジェクト全体の開始時刻と終了時刻が明確に規定されます。同時に、プロジェクトに含まれるすべてのアクティビティの開始時刻、期間、終了時刻が明確に規定されます。予定に反映されます。表 3-7 では、プロジェクト スケジュールの役割を簡単に説明します。

スケジュールを調整するときは、次の要素を考慮する必要があります。まず、時間の変動が大きい、より複雑なアクティビティの場合は、必ずしもできるだけ早く開始することが良いとは限らないため、開始時刻は科学的に決定する必要があります。第二に、各アクティビティに割り当てられたリソースが合理的であるかどうか、リソースとアクティビティの間に重複したリソース割り当てや不一致がないかどうかに注意を払う必要があります。表 3-8 は、ファーウェイの T 顧客検査会社プロジェクトの最初の 2 段階を例として、プロジェクトのスケジュールを示しています。

完全なスケジュールとプロジェクト チームの最大限の注意により、遅延やその他のインシデントを効果的に回避できます。また、チーム メンバーがスケジュールの理解に基づいて例外を処理する際に混乱する可能性もあります。プロジェクトのスケジュールは、プロジェクトの複雑さと実際の状況によって異なります。

一般に、プロジェクトのスケジュール計画を立てるためによく使われるツールは、ガント チャートとネットワーク分析チャートです。ガント チャートの横軸は時間、縦軸はアクティビティを表し、プロジェクト内の各アクティビティの開始時間と終了時間が横棒グラフで表されます。しかし、従来のガント チャートでは、さまざまなアクティビティ間の相互関係を直感的に反映することができません。タイムテーブルとネットワーク図を組み合わせることで、プロジェクトのタイム スケジュールと進捗計画を明確に反映できます。図 3-7 は、スケジュールを設定するためのネットワーク図を示しています。

プロジェクトのすべてのリンクと段階では、関連する利害関係者との円滑な連絡と情報交換が必要です。そのために、プロジェクト マネージャーは事前にコミュニケーション計画を策定する必要があります。プロジェクト管理コミュニケーションは 4 つの原則に従う必要があります。つまり、適切なチャネルを通じて、適切な利害関係者から、適切な時期に、適切なプロジェクト利害関係者に伝達され、プロジェクトの利害関係者が伝達された情報を正しく理解できるようにする必要があります。表 3-9 では、ファーウェイのプロジェクト コミュニケーション プランを例として、プロジェクト コミュニケーション プランの内容を簡単に概説します。

世界的に有名な経営の第一人者であるトム・G・ピーターズは、かつて次のように強調しました。「経営効率の問題は、実際のところ、経営者が従業員や顧客とのコミュニケーションを失っていることです。このつながりとは、主に顧客や従業員との誠実で心のこもったコミュニケーションを指します。」 「プロジェクト マネージャーは、コミュニケーション計画を立てるときに、次のようないくつかの質問を明確にする必要があります。誰とコミュニケーションを取るのか?なぜコミュニケーションをとるのでしょうか？通信当事者はどのような情報を取得または知ることを期待していますか?コミュニケーションの頻度はどれくらいですか？コミュニケーションの目標は何ですか?どのようにコミュニケーションをとればよいでしょうか？

上記の課題を整理することで、ステークホルダーのコミュニケーションニーズ、プロジェクトへの関心、影響度を明確にし、ステークホルダーごとのコミュニケーション計画を立てることができます。図 3-8 は、プロジェクトに対する利害関係者の関心と影響に基づいたコミュニケーション計画を示しています。優れたプロジェクト コミュニケーション プランでは、適切な量の情報をタイムリーかつ正確に双方に提供できる必要があります。

アメリカの経営学者ランズデンは、時間管理の研究を行う過程で、通常、目標志向で組織的で、優れた時間管理の概念を持っている従業員は、作業効率が高く、冗長な作業や重複作業が少ないことを発見しました。任正非氏はかつて従業員に対し、本当に重要な事柄に十分な時間とエネルギーを投資していないのであれば、時間管理に問題があるに違いないと従業員に強調したことがあります。現時点では、冗長で些細な事柄のための時間を削減する必要があります。 。

プロジェクトの実行計画を策定する過程において、プロジェクトマネージャーはチームメンバーに一定のプレッシャーを適切に伝え、それによってチームメンバーがプロジェクト全体に注意を向けるようになり、一定のモチベーション効果を発揮することができます。同時に、プロジェクトマネージャーは一部のタスクを従業員に委任することで自分自身のプレッシャーを軽減することができ、委任先の能力もある程度発揮されます。プロジェクト チーム全体で通常のストレス状態を維持することで、従業員はタスクの期限を守ることができます。ただし、プレッシャーの伝達はプロジェクトの状況に応じて適切に調整する必要があり、過度のプレッシャーはプロジェクトメンバーの無駄な消耗につながり、その消耗によって生じる大きなプレッシャーはプロジェクトマネージャーに伝わります。表 3-10 は、プロジェクト マネージャーとメンバーが直面する可能性のあるプレッシャーを示しています。

過度のストレスの消費は、必ずしもプロジェクトの作業量や難しさによって引き起こされるわけではなく、不合理な時間管理によって引き起こされる場合もあります。したがって、プロジェクトマネージャーは時間管理をしっかり行い、タスクの優先順位を付けてアクションプランを策定する必要があります。プロジェクトをスムーズに完了し、実装を成功させるには、適切な時間管理が鍵となります。時間をより効果的に管理するために、プロジェクト マネージャーは必要な準備を行う必要があります。図 3-9 は、プロジェクト マネージャーが効果的な時間管理を実装するために使用できる手法の概要を示しています。

時間を適切に管理し、作業効率を向上させるために、プロジェクト マネージャーは時間管理の原則を確立し、プロジェクト内のさまざまなタスクに優先順位を付けて時間を分類し、重要な事項のために一定の時間を確保する必要があります。プロジェクト マネージャーが時間管理を行うときは、次のようないくつかの質問を明確にする必要があります。現在行っていることは必要ですか?現在行われていることをグループのメンバーが行ったほうがよいでしょうか?タスクに優先順位が付けられていますか?

To Do リストと毎日の作業スケジュールは、プロジェクト マネージャーが効果的な時間管理を実行し、重要なことに優先順位を付けるのに役立ちます。表 3-11 に、プロジェクト マネージャはこのフォームを使用して、実行する必要があるアクティビティとタスクをリストし、対応する優先順位を割り当てて、作業の進捗状況を確認します。

どのようなプロジェクトでも不確実性分析は必要であり、プロジェクトの進行に伴ってさまざまな段階で不確実性要因も出現します。このセクションの不確実性評価は、主にプロジェクトのアクション計画段階で実行されるべきであることを強調しています。不確実性要因の評価と分析を通じて、新しい機会を見つけて新しい発見ができるかどうかを確認し、プロジェクトの WBS と調整を行うことができます。タイムリーにタスクを委任します。

図 3-10 は、プロジェクトの不確実性評価のプロセスを示しています。不確実性評価を行う場合、プロジェクトチームはプロジェクトの目標と範囲を明確にした上で詳細な分析を行う必要があります。チームメンバーは、関連データを収集し、考えられるさまざまな不確実性をブレインストーミングし、不確実性の原因と本質を分析し、ツールを使用してすべての考えられる不確実性の発生確率を評価し、プロジェクトに関連する不確実性を最終的に決定し、責任を割り当て、責任を割り当てる必要があります。監視方法を決定します。

プロジェクトの不確実性を評価し、それに対処するための具体的な戦略を採用するのが正しいアプローチです。もちろん、不確実な要因の存在は常に悪影響をもたらすわけではなく、場合によっては有利な機会ももたらすため、さまざまな不確実要因に対して対応戦略を採用する必要があります。表 3-12 は、不確実性に対処する戦略の概要を簡単に示しています。

一部の対処戦略では、新しい作業分解構造とタスクの委任が生じる場合があり、プロジェクト マネージャーは、生成されたタスクに対する責任を割り当てる必要があります。対応戦略に表示されるタスクとアクティビティが以前の作業分解構造に属している場合、元の責任者が引き続きこれらの成果物に対して責任を負います。しかし、対応戦略に基づくアクションが新しいタスクである場合、プロジェクト マネージャーは新しいタスクに新しい責任者を割り当てる必要もあります。

プロジェクト ディレクターは次のように強調しました。結果を出すことに重点を置くことがプロジェクトの結果指向の要件であり、これが仕事の基本原則です。プロジェクトの実施中に適切な指導や支援を提供することも、成果を確実に達成するために必要な手段であり、この点については将来的に監視を強化することができる。しかし、専門職が多い総合部門では、プロジェクトマネージャーが各部門や各プロジェクトチームに十分な指導やフィードバックを与えることが難しいという問題があります。技術分野には専門性があり、プロジェクトマネージャーにとって不慣れな業務もあります。その場合、プロジェクトマネージャーはプロジェクトの細部を完全にコントロールするというよりも、戦略の方向性や全体の進捗状況を把握する役割を担うことが多くなります。管理者に求められている専門的な指導は難しい。結局のところ、組織はプロジェクト マネージャーを包括的にトレーニングし、彼らにさらに忍耐力を与える必要があります。一夜にして各プロジェクト チームに慣れることはできません。

同時に、従業員が実行プロセス中に困難やリソースのボトルネックに遭遇した場合、上司が従業員を求めていないこの側面は改善が必要ですが、従業員も積極的に上向きの役割を果たさなければなりません。現在困難または克服できない問題については、上司に指導を求めてください。上向きのマネジメントもプロジェクト実施時の社員の必須科目です。

成熟した組織では、会社の上級管理者がプロジェクト スポンサーの役割を担うことがよくあります。このような組織では、プロジェクトマネージャーがプロジェクト実行のリーダーとなることが多く、上級マネージャーはプロジェクト開始後のプロジェクトへの参加には消極的であると同時に、常にプロジェクトをサポートし、プロジェクトマネージャーを全面的に信頼しています。プロジェクトチームは正常に機能すると信じています。

社内でプロジェクト管理が徐々に成熟するにつれて、上級マネージャーがいくつかの新しい役割を引き受け、本来のプロジェクト責任を中級および下位レベルのマネージャーに分配するようになります。表 4-1 は、上級マネージャーが引き受ける必要がある新しい役割と、プロジェクトの責任を中間マネージャーに分散する理由の概要を示しています。

プロジェクトマネージャーは自らの権限に影響され、意思決定権限の範囲が比較的小さいため、プロジェクトマネージャーはタイムリーな上方管理を行う必要があります。ラインマネージャーや中上級マネージャーの権限と権限を通じてプロジェクト関連リソースを割り当て、ラインマネージャーや上級マネージャーと重要な問題について合意を形成し、会社からのサポートを獲得します。そのためには、プロジェクトに参加する際のラインマネージャーとシニアマネージャーの役​​割を明確にし、プロジェクトマネージャーが上向きのマネジメントを行えるようにする必要があります。表 4-2 は、プロジェクト管理におけるライン マネージャーとシニア マネージャーの主な役割を簡単に説明しています。

中堅・上級管理者は、プロジェクトマネージャーのプロジェクトの円滑な推進を支援する責任を負い、プロジェクトマネージャーの良きはしごとなる意欲が求められます。大規模で複雑なプロジェクトでは、クライアントの上級管理者がプロジェクト実施当事者の上級管理者とコミュニケーションをとり、タイムリーなフィードバックを得たいと考えることがあります。したがって、プロジェクトマネージャーは中間管理者や上級管理者と合意を形成し、プロジェクトに対する彼らの支援を積極的に得る必要があります。

限られたリソースの影響を受けるため、特に代替リソースが用意されていない場合、プロジェクト リソースは各リンクの要件を常に満たせるとは限りません。プロジェクト全体の継続的な開発を推進するために、プロジェクト チームはリソースの制約を受けてプロジェクト全体の進捗に影響を与えないよう、関係者のリソースを調整する必要があります。

プロジェクトの利害関係者を調整および管理し、プロジェクトのライフサイクル全体を通じてプロジェクトの利害関係者と協力してリソースを共有します。したがって、プロジェクト関係者のリソースを調整する際には、リソースが複数のプロジェクト関係者間で共有されるリソースであることを考慮する必要があります。

プロジェクトマネージャーは、関係するステークホルダーの共同管理を実行します。具体的には、図 4-1 に示す活動が含まれます。関係者のマネジメントを調整する際には、一つのプロジェクトに求められる最適なリソース配分を実現するだけでなく、顧客、プロジェクトチーム、関係者全体として最適なリソース配分の状態を考慮する必要があります。

プロジェクト関連利害関係者の共同管理を通じて、プロジェクト関連利害関係者がプロジェクトの目的、利点、リスクを明確に理解し、各プロジェクト利害関係者がプロジェクト内で適切な役割を果たすことができるようにし、プロジェクトに必要なリソースを積極的に提供する必要があります。プロジェクトの要件を満たします。

プロジェクトの利害関係者を協力して管理し、関係者のリソースを動員することで、プロジェクトに効果的な指導を提供できます。したがって、利害関係者と関連リソースの協力的な管理計画を策定する必要があります。図 4-2 は、プロジェクトのステークホルダー間の相互作用の度合いを決定するために使用される、ステークホルダーとステークホルダーのリソース共同管理計画の内容を示しています。

リソース計画の策定とは、プロジェクトの実際の状況に基づいて、プロジェクト チームが必要なリソース、リソースの入手経路、リソースの使用方法、使用の開始時刻と終了時刻を決定することを意味します。合理的なリソース計画により、プロジェクト チームはリソースが不足している場合に代替リソースを迅速に見つけ、リソースの無駄を回避し、高コストのリソースの価値を可能な限り最大化し、ボトルネック リソースの使用効率の向上に重点を置くことができます。表 4-3 は、プロジェクトのリソース計画の内容を簡単に示したものです。リソース計画を通じてリソースを合理的に割り当て、リソースの利用率を向上させることができます。

リソース計画を策定する際、プロジェクト マネージャーは、まずリソースの制約を無視してリソース割り当てのクリティカル パスを見つけ、プロジェクトの要件に基づいてクリティカル パス分析を組み合わせ、次にリソースの制約を考慮してリソースの計画とスケジュールが実現可能かどうかを検証します。リソース計画とスケジュールの実現可能性を分析する場合、希少なリソースの使用が必要なアクティビティを特定し、これらのアクティビティにリソースを使用する優先順位を計算し、最も優先度の高いアクティビティに希少なリソースを使用する必要があります。図 4-3 は、プロジェクト リソース計画の作成プロセスの概要を簡単に示しています。

図 4-3 からわかるように、リソース計画では、まず設備、資材、技術などのニーズに基づいて、予備的なリソース リストと初期の人員配置を作成する必要があります。次に、プロジェクト リソース会社のプロジェクト管理部門がさまざまな計画を組織する必要があります。部門およびプロジェクト関連の利害関係者をリソースリストに追加し、レビューし、調整します。同時に、プロジェクトを担当する会社のラインマネージャーは、人員配置計画とリソースリストを確認し、承認後、会社の上級管理者がリソース計画を承認する必要があります。

プロジェクトの予算には、プロジェクトへの先行投資、成果物を達成するために必要なリソースとタイミング、つまりプロジェクトの目的を達成するために予想されるコストと支出が含まれている必要があります。適切な予算システムは、プロジェクト マネージャーやプロジェクト チームのメンバーがプロジェクトを完了するためのリソースと時間の制約を明確にするのに役立ちます。プロジェクト マネージャーと主要メンバーは通常、予算の作成と管理プロセスに積極的に参加するため、予算の制約は基本的にプロジェクト マネージャーが期待する制約を反映することができます。成功したプロジェクト マネージャーは、割り当てられたリソースを使用して予算目標とプロジェクト目標を達成するプロジェクト チームを指揮します。

明らかに、適切に構成された予算は、各プロジェクト チームやプロジェクト マネージャーのパフォーマンスを測定するための基準である一方で、プロジェクトのリソース計画と実際の実行との乖離を特定するための有効なツールでもあります。プロジェクト予算を通じてリソース計画をタイムリーに調整します。プロジェクトの予算目標はプロジェクトの目標を反映するため、予算構造の制約によってプロジェクトのリソース割り当て、運用モデル、スケジュールが決まります。もちろん、プロジェクトの予算構造の決定は、内部および外部の環境要因の影響を受けることがよくあります。図 4-4 は、プロジェクトの予算構造に影響を与える要因を反映しています。

プロジェクト マネージャーは、多くの場合、プロジェクトのコスト管理と予算作成の最初の責任者になります。会社にとって戦略的価値のあるプロジェクトには、フルタイムのプロジェクト ファイナンスを備え、徐々に予算文化を形成する必要があります。予算文化の形成は、最終的にはあらゆるレベルの予算計画の作成に導入されなければなりません。通常、予算計画は長期予算、中期予算、短期予算に分けられます。プロジェクトマネージャーは、予算作成段階で準備手法やツールを活用し、長期戦略予算を中期予算に変換し、さらに中期予算を短期予算に変換し、目標を達成するための段階的なスケジュール計画を策定する必要があります。プロジェクトの目標。図 4-5 は、プロジェクトの実行における長期、中期、および短期の予算の変換プロセスを示しています。プロジェクトの実行中には、同時に実行する必要がある 3 つのステップがあります。

プロジェクト予算計画は、プロジェクト チームのコミュニケーションの媒体としても機能するため、プロジェクト予算明細書が明確であればあるほど、チーム メンバーが理解し、使用しやすくなります。通常、プロジェクトの予算計画のプレゼンテーションの質は 2 つの側面で評価されます。1 つは、限られたリソース条件下でプロジェクトの実施目標を予定よりも早く完了できるかどうかが予算計画に明確に記載されているかどうかです。予算計画は、プロジェクト チームのメンバー、顧客、パートナーに重要な情報を明確に伝えることができます。

プロジェクト調達管理は、商品やサービスを入手するための一連のプロセスの管理であり、多くの場合、異なる目標を持つ 2 つの関係者が関与します。購入者と供給者の双方向の対話関係は、特定の市場状況やマクロおよびミクロ環境の影響を受けます。ミクロ環境では主にプロジェクトのニーズ、企業のリソース状況、顧客の規制などの要因が重視され、マクロ環境では経済的背景、現地通貨のインフレ、人口失業などの外部要因が重視されます。調達の時期と方法に影響します。

マクロ環境とミクロ環境の影響を受けるため、プロジェクトの調達においてはさまざまな要素を考慮し、調達管理システムを構築する必要があります。図 4-6 では、ファーウェイの調達管理プロセスを例として、調達管理の基本的な手順とプロセスを説明します。ファーウェイの調達管理プロセスでは、まず事前の調達計画を策定する必要があります。次に、プロジェクトの要件とリソースの制約に基づいて特定の調達戦略を策定する必要があります。次に、特定の調達計画を策定し、調達プロセス中に関連する調達リンクを管理する必要があります。調達の最終段階。

プロジェクト調達のプロセス全体には、通常、調達の計画、調達の実施、計画された調達の管理、調達の終了が含まれます。計画・調達では、プロジェクトの全体的な分析を通じて、プロジェクトの調達ニーズを決定し、調達方法を明確にし、潜在的なサプライヤーを特定するプロセスが主に重視されます。計画および調達プロセスの最後には、図 4-7 に示すコンテンツが作成されることがよくあります。調達の実施に入る際には、サプライヤーとの双方向のコミュニケーション活動を実現し、サプライヤーを特定し、相互に契約を締結することに主に重点が置かれます。その際、プロジェクトの要件や調達計画の決定に基づいて、適切な調達戦略と最適なサプライヤーを選定し、調達を円滑に進める必要があります。

購買管理の主な役割は、購買当事者間の関係を管理し、両当事者が約束どおり契約を履行しているかどうか、プロジェクトの調達ニーズを満たしているかどうか、調達完了段階にスムーズに入るかを監督することです。その際、技術や需要の変化に応じた調達計画を策定する必要があります。調達プロセスを制御すると、図 4-8 のような結果が得られます。クロージング調達とは主に、必要な調達書類の整理とアーカイブ、成果物の受け入れに向けた関連書類の保管、経験と教訓の要約、最良の調達経験の学習など、一連のクロージング作業を指します。

調達管理の計画、実施、管理、最終段階を通じて、プロジェクト調達のスムーズな展開を促進し、サプライチェーンのスムーズな流れを確保し、プロジェクトに必要な製品やサービスをプロジェクトのあらゆる側面に提供する必要があります。タイムリーに調達コストとサプライチェーンコストを削減します。

ファーウェイのプロジェクトマネージャーである趙娜氏が参加したプロジェクト運営では、基本的にフロントエンド商品とバックエンド商品に関する協調的な意思決定が実現され、フロントエンド商品とフロントエンド商品の納期が短縮され、フロントエンド商品の納期が短縮されました。フロントエンドの供給プロセスも合理化されました。したがって、フロントエンドとバックエンドの商品供給の円滑性を確保し、フロントエンドとバックエンドのサプライチェーンの安定性を向上させるためには、一方ではフロントエンドが需要を明確に表現することが求められます。資材や商品の需要を明確に表現することで、サプライチェーンの応答時間や在庫の準備を短縮できます。一方、フロントエンドは、希少なリソースや特殊なリソースについては、調整を行う必要があります。フロントエンドと連携して、資材や商品の配送と輸送を決定します。図 4-9 は、フロントエンドからバックエンドへのアジャイル プロビジョニング プロセスを示しています。

フロントエンドの商品需要システムの改善により、バックエンドの倉庫業は同様のプロジェクトまたは同様のリンクの商品需要データをタイムリーに取得できるため、一部の需要が変動したり予測不可能になったりすることがなくなりました。これには、バックエンドが関連するツールと手法を使用して、フロントエンドの需要を事前に予測および分析し、供給リズムを把握し、サプライチェーン全体がエンドツーエンドの同期運用を実現できるようにする必要があり、中間の時間コストを削減します。リンクと不要な在庫コスト。

プロジェクトのリソース割り当てでは、フロントエンドとバックエンドの商品リソースの一貫性がプロジェクト運営の効率を決定し、タスクの提供にかかる総コストにも影響します。フロントエンドとバックエンドでの商品の物理的な流れには、情報の同期的な流れが伴います。良好な情報の流れは、在庫管理のコストの削減に役立ちます。従来のフロントエンドの需要からバックエンドへの供給は、需要主導型の供給モデルです。バックエンドが商品を準備するときは、フロントエンドが指示を受け取ってから準備を開始する必要があります。バックエンドで数日分の在庫を確保し、在庫の準備をフロントエンドの一時保管場所に転送します。このプロセスの具体的なプロセスを図に示します。 4-10.

同期モードでの在庫管理の発展により、供給モデルは徐々に進化し、従来のモデルと比較して、エンドツーエンドの商品の転送を直接実現できます。情報の流れを通じて、フロントエンドの需要が明確になった後、バックエンドは商品をフロントエンド生産ラインの指定されたエリアに直接転送します。これにより、X 日分の在庫管理コストが削減されます。バックエンドの在庫プロセスを管理し、在庫を X 時間まで直接指定することで、中間リンクの時間とスペースのコストが削減され、オンタイム供給効率が向上します。バックエンドはツールを利用してフロントエンドの商品需要のサイクルと数量を計算し、事前に出荷準備を行い、機敏な供給を実現します。同時に、現状の最終財がある程度消費されると、次の循環供給が行われるというフィードバックの仕組みを構築することも検討すべきである。

プロジェクト マネージャーは、プロジェクトの中核問題を解決するためのリソースを集め、それによってプロジェクト全体の成功への突破口を開く必要があります。もちろん、プロジェクトの運営において、プロジェクト マネージャーは、プロジェクトの主な問題点やリソースのボトルネックとなる可能性について事前に上司に伝え、上司の助けを求めなければなりません。続いてプロジェクトチームを組織し、問題解決のためのクリティカルパスを共同で特定し、そのクリティカルパス上で必要なリソースを明確にし、既存リソースと不足リソースを比較・分析して解決策を提案します。図 4-11 は、プロジェクト マネージャーがリソースを収集するプロセスを示しています。

図 4-11 からわかるように、リソースを収集する過程で、プロジェクト マネージャーは既存のリソースの現在のステータスのデータ分析を実施して、十分な根拠に基づいたリソース要件のリストを提供し、リソース不足に備える必要があります。プロジェクトのニーズに基づいて。プロジェクト マネージャーはプロジェクト運営のあらゆる側面を最もよく理解しているため、プロジェクトの優れたリーダーは通常、リソース データ分析と、プロジェクト マネージャーが不足しているリソースを入手できるようにプロジェクト マネージャーが提供する代替案に基づいて、プロジェクトに必要なリソースを割り当てます。リソース。

任正非氏はかつて、ファーウェイの資源統合はパイプラインベースであるべき、つまり中核問題に取り組むために優れた人的、財政的、物的資源に焦点を当てるべきだと強調した。ファーウェイの資源統合問題に直面したとき、彼はかつて林彪の都市攻撃の例を挙げた。林彪が都市を攻撃するとき、彼はまず最も熟練した軍隊を集めて突破口を開くだろう、そして次に両翼の主力部隊がそうするだろう。徐々に両側に拡大し、結果を徐々に深めて拡大します。

明らかに、プロジェクト マネージャーのリソースの割り当てと使用も、このロジックに準拠しています。図 4-12 は、主要なリソースに焦点を当て、プロジェクトの主要な課題に取り組むプロセスを示しています。プロジェクト ディレクターとプロジェクト マネージャーは、プロジェクト運営に資金と人的リソースを提供し、これらの有利なリソースを収集する方法を知らなければなりません。困難で複雑なプロジェクトに直面したとき、プロジェクトマネージャーは、軍隊の配置が合理的であるかどうか、優れた優れたリソースの価値が最大化されるかどうかを常に考慮する必要があります。プロジェクトの突破口を開くためには、専門的で有利なリソースを十分に集める必要があります。

プロジェクト開発プロセスでは、リソースや時間などの制約により、プロジェクトのスケジュールと計画との間に一定のずれが生じる場合があります。したがって、プロジェクトマネージャーまたはプロジェクトスーパーバイザーは、プロジェクトの実際の進捗が計画または予想された進捗と一致していることを確認するために、プロジェクト全体の進捗を監督する必要があります。特に、リスクが発生しやすいリンクとプロジェクトの主要なマイルストーンには、より多くの注意と監督を与える必要があります。図 6-1 は、プロジェクト プロセスの監督シナリオと注意が必要ないくつかの側面を簡単に説明しています。

図 6-1 からわかるように、プロジェクトの進捗は、プロジェクトのスケジュールと取り決めに従って監督される必要があり、実際のタイム スケジュール、各リンクのリソースとコスト、関連する利害関係者の参加、主要なマイルストーンの実施が監視される必要があります。審査。計画に沿わないスケジュールに対しては速やかに指示や指導を行い、チーム全体の作業リズムを合理的にコントロールします。同時に、プロジェクトプロセスを監視することで問題の関連性が特定され、技術的な修正計画と解決策がタイムリーに策定されます。

プロジェクトプロセスの監督中に、プロジェクトの進捗が遅れていることが判明した場合は、プロジェクトの進捗を加速し、合理的に制御するために、現在のタスクに最も近く、より長い時間の見積もりを持つ作業パッケージを選択する必要があります。プロジェクトの進捗状況。図 6-2 は、プロジェクトプロセスが遅れた場合の監督措置を示しています。

プロジェクトの進捗が遅れ、プロジェクトの実行サイクルを短縮する必要がある場合、リソースの割り当てを増やすことでタスクにかかる時間を短縮したり、効果的なツールや手法を使用してタスクをキャンセルしたりすることができます。または特定のリンクをマージすることで、プロジェクトの実施状況に応じて期間を調整することもでき、これをうまく行えば時間を大幅に節約できます。

プロジェクトのプロセスを監視し、各キーノードが高品質でスケジュールどおりに完了していることを確認することで、プロジェクト全体のスムーズな納品を促進できます。通常、プロジェクト プロセスでは、プロセス全体を通じてすべてのリンクを追跡および監視する必要があり、主要な制御ノードの計画を調整する必要があります。モニタリングを効果的に実施するには、モニタリングプロセスを常に追跡し、プロジェクト状況報告フォームを作成する必要があります。表 6-1 は、プロジェクト状況レポート フォームの主な内容を簡単に説明しています。ステータス レポート フォームには、プロジェクトの進捗状況と既存の問題が反映されます。

表 6-1 からわかるように、プロジェクトプロセスの状況を反映することで、現在のタスクの主な活動と潜在的なリスク、プロジェクトプロセスサイクル内の問題点と解決策を明確にし、モニタリングすることができます。プロジェクトの進捗状況の実装。

プロジェクト全体は、各基地局の運用と監視中に正常に完了しました。各サイトの運用および保守プロセスを監視することにより、各キーノードの技術パスが厳密に管理され、プロジェクトプロセスが大きな障害なくスムーズに実行されることが保証されます。

プロジェクトの進行中に人的資源、物的資源、技術管理などの側面でエラーが発生すると、プロジェクトプロセスに影響を与えることは避けられません。したがって、プロジェクト プロセスを監視する場合、プロジェクト マネージャーまたは各サブタスクのプロジェクト チーム リーダーは、いつでもジョブの実際の進捗状況を把握する必要があります。図 6-3 は、進捗状況の実装のための分析プロセスと処理手順を示しています。

図 6-3 からわかるように、実際の進捗と計画された進捗の偏差に基づいて、偏差、総時間差、および自由時間の差を比較および分析して、このリンクが総工期に及ぼす影響を判断する必要があります。次に、ノード計画を柔軟に調整し、リスクの高いリンクをタイムリーに調整して処理する必要があります。

プロジェクト開発プロセスにおいて、プロジェクトチームが高度な専門的および技術的要件を伴う連携を単独で実行すると、コストの上昇や標準以下の品質などの問題が発生し、プロジェクトプロセスにさらなるリスクが加わる可能性があります。このとき、下請けを利用して、優れたビジネス能力、信頼性、良好なビジネスパートナーシップを備えた下請け業者を探し、高品質と低コストを目標にプロジェクト内の一部のタスクを完了することができます。したがって、プロジェクトチームは下請け業者を適切に管理し、良好な協力関係を築き、プロジェクトプロセスを推進する必要があります。表 6-2 は、下請け業者管理のいくつかの側面を示しています。

表 6-2 からわかるように、プロジェクト プロセス中の下請け業者の管理は、スケジュール、品質、コスト、契約、情報などのさまざまな側面から下請け業者を管理できる動的管理モデルです。下請け業者はプロジェクトの特定の側面に責任を負いますが、プロジェクト チームのリスクの一部も分担します。プロジェクトのプロセス全体で、プロジェクト チームと下請け業者のリスク共有モデルが形成され、リスクに対抗する全体的な能力が向上します。

プロジェクトプロセスのスムーズな進行を保証するために、下請けリンクのタスクを常に追跡し、注意を払う必要があります。インセンティブ制度を設けることで、下請け企業へのインセンティブ管理は大きく「プラスインセンティブ」と「マイナスインセンティブ」の2つに分けられます。下請けの作業タスクが品質と時間の基準を満たしている下請け業者に対しては、材料レベルまたは評判レベルでのプラスのインセンティブを使用することができます。契約要件に従って目標を達成できない下請け業者に対しては、マイナスのインセンティブペナルティメカニズムを使用して下請け業者を罰する必要があります。サプライヤーは一定の圧力をかけて、作業プロセスと進捗をタイムリーに調整します。図 6-4 は、下請け奨励金制度に含まれるいくつかの具体的な方法を示しています。

下請け業者に対するプラスのインセンティブには、目標インセンティブと協力機会インセンティブが含まれます。対象インセンティブとは、下請け業者が作業品質の向上や作業時間の短縮を目的として新しい技術やツールを採用し、コスト補償や追加の報酬を要求することを指します。協力機会インセンティブとは、評価を通じて複数の協力下請け業者、優れた業績をあげた下​​請け業者にインセンティブを提供することを指します。総合的な分析で再び協力することができます。負のインセンティブには、圧力制約と修正制約が含まれます。圧力制約とは、契約期間を通じて下請けリンクの進捗状況と品質をタイムリーに追跡することを指し、特に進捗が遅れている場合には、下請けリンクが計画どおりに完了するように圧力をかける必要があります。制約は、下請けリンクの品質を重視し、品質と安全性の要件が満たされない場合、下請け業者に一定の金銭的罰金を課し、下請け業者は是正を行って品質基準を満たすことが求められます。

リスクはプロジェクト プロセスのあらゆる側面に存在するため、リスクの特定はプロジェクト プロセス全体でも行われます。大規模で複雑なプロジェクトのリスク特定には、リスクが発生する理由と、その後の業務への影響の範囲を理解する必要があります。リスクの原因を理解することによってのみ、リスクが発生するより深い理由を理解することができます。通常、リスク源は客観的リスク源と主観的リスク源に分けられます。客観的なリスク源は過去のプロジェクトの経験やデータによって表されることが多く、主観的なリスク源は主にインタビューやその他の主観的な専門家情報によって表されます。同時に、プロジェクト プロセスのリスク特定はプロジェクト ライフ サイクルにも依存します。図 6-5 は、プロジェクト ライフ サイクルの各段階でのリスク特定を簡単に説明します。

図 6-5 からわかるように、リスクはプロジェクトのライフサイクル全体に付随します。したがって、リスク特定後のリンクであるリスク分析も体系的なプロセスであり、各段階で特定されたリスクのレベルを評価する必要があります。プロジェクトの各段階の特性に基づいて、特定されたリスクの原因と、それらが他のリンクでリスクを引き起こすかどうかを分析し、リスク関連の情報とデータを収集することによって、リスクイベントの確率と結果を判断します。通常、プロジェクトのライフサイクル全体において、コスト、スケジュール、テクノロジーはリスクの高いリンクであり、リスク分析の中心となる作業が定性的分析手法と定量的分析手法のどちらを使用するかに基づいて行われます。各リンクのコア作業と機能の選択。

リスク分析が完了したら、その結果を使用してリスク レベルを分類する必要があります。異なるリスク レベルに対応するリスク対応アクションにも一定の違いがあります。表 6-3 に示すリスク レベルの分類は、さまざまなレベルに対してとるべき措置を示しています。

リスク対応では、特定および分析されたリスクに対処し、リスク事象の責任者を決定するための特定のテクノロジーとツールの使用が主に重視され、実行プロセスはリスクを望ましいレベルまで低減することを目的としています。この目標を達成するには、リスク対応をプロジェクトの他の側面の指導計画と調整する必要があります。同時に、適切な技術ツールを選択し、中リスクおよび高リスクのイベントに対する特定の対応計画を策定する必要があります。リスク対応方法と機会を表 6-4 にまとめます。

プロジェクトの進行中、衝突は避けられません。一般的な矛盾は、人材、機器構成、管理手順、技術的なつながりなど、プロジェクトのライフサイクル全体で発生する可能性があります。プロジェクト マネージャーは一般に、対立の発生はプロジェクト サイクルに遅れをもたらすことが多く、性格の不一致によるプロジェクトへの悪影響は潜在的であり、無視できないと考えています。紛争は避けられませんが、事前に健全な紛争解決策を講じることは可能です。紛争解決計画の設定には、多くの場合、関連する利害関係者の協力と理解が必要です。もちろん、コンフリクトがプロジェクトに与える影響は必ずしもマイナスであるわけではありません。問題を改善し、プロジェクトをより円滑に進めるために、コンフリクトが発生することもあります。したがって、有益な競合は、プロジェクトの制約に違反しない限り、プロジェクトの存続期間中存在し続けることができます。

各プロジェクトが直面する競合は大きく異なりますが、企業は多くの場合、一連の競合解決ソリューションを定期的に用意する必要があります。図 6-6 は、4 つの一般的な競合解決ソリューションを示しています。最初のオプションは、各プロジェクトの特性が異なるため、社内で確立された競合処理ポリシーや手順が特定のプロジェクトの競合に必ずしも適用できるとは限りません。 2 番目のオプションは、プロジェクトの各側面の計画を策定するときに競合の可能性を考慮することです。同時に、各プロジェクト マネージャーが独自の戦略と原則に従ってそれらを処理することで、多くの場合、より良い結果が得られます。 3 番目のオプションは階層型の処理で、上位の管理レベルによる競合インシデントの処理を指します。これは通常、プロジェクト マネージャーも機能マネージャーも解決できない複雑な競合に適しています。 4 番目のオプションは直接接触です。これは、紛争当事者間の直接の交渉とコミュニケーションによる紛争の解決に重点を置いています。交渉プロセス中は、新たな紛争を可能な限り回避する必要があることに注意してください。

ファーウェイでは、アカウントマネージャーは他の役職に比べて顧客の要望をより迅速かつ直接的に把握できるポジションですが、顧客とプロジェクトの間で衝突が頻繁に起こる原因でもあります。 Zhu Yiwei がマリ駐在員事務所の最大の部門である S システム部門に勤務していたとき、この部門は顧客との関係が最も複雑な部門でもありました。彼が率いるチームは、エネルギー、固定ネットワーク、調達、マーケティング、および顧客と頻繁に接触するその他のプロジェクト リンクを担当しており、納期どおりに配送タスクを完了し、プロジェクトが確実に支払われるようにするだけでなく、各リンクでの競合にも対処する必要があります。 。

競合は避けられないため、競合イベントを処理する適切な方法を見つける必要があります。優れたプロジェクト マネージャーは、競合プロセス中に率先して継続的に改善し、競合イベントや問題を詳細に分析してすべての関連情報を収集し、チーム構成に基づいて自分のチームとプロジェクトに適した一連の競合を見つけます。特徴と具体的なプロジェクトの管理スキル。図 6-7 は、プロジェクト マネージャーが競合を管理するために実行する手順を示しています。

図 6-7 からわかるように、プロジェクト マネージャーによる競合管理のプロセスは 3 つの段階を経ます。紛争を緩和する場合、プロジェクトマネージャーは、まず紛争の対象者と信頼関係を築き、紛争解決のプロセスに積極的に参加できる雰囲気を作り、すべての当事者の意見に耳を傾ける対等な姿勢を保つ必要があります。第二に、得られた情報を使用して紛争の根本原因と動機を考え、紛争の属性を定義し、紛争の性質に基づいて問題解決グループを設立し、行動計画を策定します。最後に、プロジェクト マネージャーは、競合の円滑な解決を促進するために、すべての関係者との連絡を維持する必要があります。したがって、コンフリクトマネジメントの観点から、有能なプロジェクトマネージャーはプロジェクトチームとプロジェクトの特性を十分に理解し、関係者全員の意見を聞く過程で、評価ではなく理解する姿勢で耳を傾ける必要があります。

プロジェクトの実行においては、プロジェクトが深くなるほど変更コストは高くなり、内部要因を伴う調整や変更も複雑になります。たとえ小さなリンクの変更であっても、コストやリソースに大きな変動が生じ、プロジェクトの進行にも一定の影響を及ぼします。同時に、変化のタイミングによって変化の難易度や必要性も決まります。したがって、プロジェクトのコストと進捗を管理するために、社内に適切なプロジェクト変更管理システムを確立することが非常に重要です。表 6-5 は、プロジェクトに変更が発生した場合に特定する必要がある要素を簡単に説明しています。

変更が発生した場合、プロジェクト マネージャーはまず、変更管理で何ができるのか、どのリンクと要素が変更できないのかを明確にする必要があります。次に、変更リクエストが送信されたら、プロジェクト マネージャーはプロジェクト チームと相談して合意に達し、変更がコスト、リソース、スケジュール、パフォーマンスに及ぼす影響を評価する必要があります。承認された変更については、プロジェクトの進捗に大きな影響を与えないよう、更新情報や最新状況をプロジェクト関係者とタイムリーに共有する必要があります。

プロジェクトの変更はコスト、リソース、スケジュール、パフォーマンスに影響を与えることが多いため、プロジェクト チームは、変更のリンクと範囲がプロジェクトのコスト、スケジュール、成果物に与える影響を合理的に制御するための完全なメカニズムを確立する必要があります。大規模プロジェクトの場合、プロジェクト マネージャーは一連のプロジェクト変更管理プロセスを組織して確立し、それをサポートする変更管理チームを編成する必要があります。変更管理チームのメンバーは、プロジェクト マネージャー、プロジェクト スポンサー、顧客、主要サプライヤー、プロジェクト チームのコア メンバーなどの重要な関係者で構成されています。変更管理チームは、変更管理プロセスに従って、プロジェクトのコスト、スケジュール、その他の重要なパフォーマンス指標に対する変更要件の影響を評価します。図 6-8 は、プロジェクト変更管理プロセスの作業手順を示しています。

どのプロジェクトも主観的または客観的な要因の影響を受け、変更要求が生じる可能性があります。プロジェクト チームは、最初に変更管理プロセスに同意し、変更管理チームを設立し、変更要求が発生した場合は作業手順に同意する必要があります。手順。同時に、変更を行うかどうかを決定する際、変更管理チームは、変更要件がプロジェクト プロセスを推進し、プロジェクトの最終目標を達成するのに役立つかどうかの分析に重点を置く必要があることに注意してください。

プロジェクトのスケジュールは静的なものではなく、時間とリソースの制約を受けるため、プロジェクトの目標をスムーズに達成できるように継続的に調整および更新する必要があります。また、プロジェクト マネージャーは、プロジェクト プロセス中の緊急事態にタイムリーかつ適切に対応し、プロジェクトのコスト、リソース、時間、その他の要素をプロジェクトの目標を達成するために合理的な範囲内に保つようにプロジェクトのスケジュールを調整する必要があります。ただし、プロジェクト全体の最適なインプットとアウトプットを確保するために、プロジェクトのスケジュールをすべて調整する必要があるわけではありません。図 6-9 は、プロジェクト マネージャーとチームがプロジェクト スケジュールを調整する必要があると考える理由を示しています。

プロジェクトマネージャーやチームメンバーは、必要なさまざまなスケジュール調整イベントに迅速に対応するために、プロジェクトが運用中に時間、コスト、リソースの制約を受ける場合に、関連する方法やツールを事前に準備する必要があり、これらの準備されたツールを使用することで問題なく完了できます。スケジュール調整。同時に、プロジェクト マネージャーは、この段階でチーム リーダーの役割を最大限に発揮し、チーム全体が進行上の問題について意見やアイデアを創造的に提供できるように鼓舞し、指導する必要があります。

通常、時間とリソースの制約に合わせてプロジェクトのスケジュールを変更するには、いくつかの方法があります。 1. リソースを増やしてラッシュ時間を短縮します。 2. 迅速なフォローアップ。プロジェクト チームは、タスクが発生する順序に従って、同じ期間内で連続して接続されたタスクを配置します。 3. 時差を利用して、プロジェクト内の一部のリンクの作業を延期し、リソースの消費を調整します。 4. プロジェクトの範囲を縮小し、作業分解構造から一部のタスクを削除します。プロジェクトの範囲を合理的に縮小しても、プロジェクトの品質と目標は損なわれません。もちろん、上記の方法を使用するかどうかは、プロジェクト マネージャーのプロジェクトの理解に依存します。プロジェクト マネージャーは、どのタスクが時間内に短縮できず、作業を急ぐことによってのみ完了できるのか、どのリンクが消滅してもプロジェクトの成果物の実現に大きな悪影響を及ぼさないのかを明確にする必要があります。

プロジェクト チームがスケジュールを調整してプロジェクト期間を短縮する場合、期間短縮のコストが元のスケジュールのコストよりも高くなるかどうかを検討する必要があります。図 6-10 は、プロジェクトの期間と個々のタスクの期間およびコストの間のトレードオフの関係を示しています。図 6-10 からわかるように、プロジェクト期間が長くなるほど、プロジェクト運営中に発生する管理コストも増加します。そのため、プロジェクト全体の期間が長くなるにつれて、プロジェクト全体の間接コストも増加します。 1 つのタスクの期間という観点から見ると、タスクを最短時間で完了するコストも最も高くなりますが、同時に、通常は 1 つのタスクを通常の時間内に完了するコストが最も低くなります。プロジェクトチームが工期を短縮して間接費を節約したい場合、スケジュールを圧縮する活動によって発生するコストとリソースを負担する必要があることがわかります。

プロジェクト中に迅速なフォローアップを確保し、プロジェクトの進行を加速するために、通常、タスクの順序と特性に従って 2 つ以上のタスクが同時に実行されるように調整されます。短い製品ライフサイクルや新製品の発売などのプロジェクト状況では、プロジェクト マネージャーは、迅速なフォローアップとプロジェクト範囲の縮小を組み合わせて、プロジェクト期間を短縮することがよくあります。ただし、迅速なフォローアップで複数のタスクを同時に実行することを重視すると、調整がうまくいかないと、プロジェクトの進行に影響を与えるため、プロジェクト マネージャーとチームがより適切な調整を行う必要があります。コミュニケーションスキル。プロジェクト マネージャーが迅速なフォローアップと急ぎの作業を組み合わせる場合、複雑さが高い場合は、プロジェクトの初期段階のタスクやタスクについては、建設期間を簡単に短縮するべきではありません。期間が長いほど、迅速なフォローアップや期限の短縮の機会を見つけることが容易になります。表 6-6 は、迅速な追跡調査を実施する際に考慮すべき要素を示しています。

プロジェクト マネージャーがプロジェクトのあらゆる側面を迅速にフォローアップできるようにタスクを割り当てるときは、複数のタスクを同時に実行することが効率に影響を与えるかどうかに注意を払う必要があります。特にチームが複数のタスクを引き受ける場合、アイデアの切り替え、情報の整理、進捗状況の追跡などに時間とエネルギーが消費される可能性があり、これらの消費がチームの全体的な効率に影響を与える可能性があります。図 6-11 は、Wheelwright と Clark が実施した実験結果を利用したもので、プロジェクトを迅速にフォローアップするためのタスク割り当てに対する、チームが複数のタスクを引き受けることの影響を反映しています。

図 6-11 からわかるように、チームが引き受けるプロジェクトが多すぎると、各プロジェクトの付加価値時間が大幅に低下します。チームが引き受けるプロジェクトが多すぎると、チームの効率に影響が及ぶことがわかります。常にプロジェクトの進行にプラスの影響を与えます。したがって、プロジェクトが迅速なフォローアップのために複数のタスクを割り当てる場合、複数のタスクを同時に実行するチームは、プロジェクトの進行を加速しながら各タスクの効率と品質を確保するために、タスクの難易度を考慮する必要があります。 。

プロジェクトを進めるときは、毎日の計画と活動リストを作成します。

プロジェクト基準はクライアントと合意する必要がある

既存システムのもとで業務プロセスの最適化を図る

プロジェクトに関わる何千人もの人々の情報伝達管理を適切に行う

標準化された作業に従って作業し、全体的な作業品質を確保します

最適な作業方法を選択し、最初から正しく実行する

プロジェクト チーム メンバーの運用能力を向上させるための現場指導に近い

毎日の宿題は「毎日クリアして完了する」必要があります

プロジェクト チームは、常に良好なチームの雰囲気を作り出す必要があります。これは、チーム メンバーを物質的に動機付けることを意味するだけでなく、より重要なことに、チーム メンバーが精神的なレベルで自分の仕事を好きになり、全員が一緒に完成した成果物には価値があり、価値があると信じさせることを意味します。意味のある。プロジェクトマネージャーは、コミュニケーション、コンフリクトマネジメント、交渉などのさまざまなマネジメントスキルを駆使して、プロジェクトチームの仕事に適した雰囲気や環境を作り、チームメンバー間の連携を促進し、効率的なプロジェクトチームを形成する必要があります。

大規模で複雑な納品プロジェクトや過密なプロジェクト スケジュールはプロジェクト チームに一種のプレッシャーをもたらし、そのプレッシャーが時間の経過とともに意見の相違や摩擦を引き起こすことがよくあることに注意してください。良いチームの雰囲気を作り出すには、チームのメンバーがこれらの問題に直面して解決する必要があります。また、個人的要因以外の要因によって引き起こされた問題をチームに暴露し、メンバー全員が一緒に議論して問題を明確にし、新しい対処メカニズムを形成することもできます。 。

業界にはプロジェクトを成功させるための多くの基準がありますが、チームの雰囲気にも明確な要件があります。つまり、良好で前向きで協力的な作業雰囲気が確立されているかどうかが、プロジェクトの成功を決定する重要な要素の 1 つです。チームの雰囲気は、プロジェクトを円滑に遂行するための重要な要素であるだけでなく、チームの全体的な能力と総合的なスキルの開発にも非常に重要です。通常、良好なチームの雰囲気と環境は、さまざまな微妙な要因の影響を受けながら、プロジェクト チームのメンバー間の強い帰属意識を促進し、プロジェクト チームの結束を強化し、パフォーマンスの高いチームを形成します。チームが予期せぬ事態や大きな問題に遭遇したとき、自由に対応できるかどうかは、微妙に形成されている雰囲気や文化にかかっています。図 7-1 は、プロジェクト チームの構築プロセスにおいて良好なチームの雰囲気が果たす役割を示しています。

図 7-1 からわかるように、プロジェクト チーム編成の 4 つの段階は、チームの雰囲気とチーム環境に影響されます。最初の段階では、雰囲気によって個々のメンバーが徐々にチームメンバーになり、共通の目標に向かって団結していきます。第 2 段階はチームがプロジェクトを開始し始めるショック段階であり、必然的に困難やボトルネックに遭遇します。このとき、ポジティブな雰囲気を持つチームはより強力な戦闘能力を持ち、一緒に困難に立ち向かい、ボトルネックを解決する意欲を持っています。プロジェクト。プロジェクトが進行するにつれて、チームは徐々にチームの正式な段階である第 3 段階に入ります。慣らし運転を経て、良い雰囲気の影響でチームメンバー同士も打ち解け、職場での暗黙の了解も高まってきました。プロジェクトが深まり、チームの雰囲気が徐々に浸透していくにつれて、プロジェクトチームは第4段階であるパフォーマンス段階に入ります。この段階では、チームの雰囲気が深まり、プロジェクトが進行することで、チームメンバーのプロジェクトに対する理解が促進され、成果物に限定されるものではなく、プロジェクトがスケジュールどおりに遂行されることによってもたらされる長期的な価値と重要性が高まります。配達。

プロジェクト マネージャーは、チームが直面する困難を、チームがエネルギーを集め、創造的な変更を加え、ボトルネックに積極的に対処するようチーム全体を導く機会として捉えることに慣れている必要があります。このプロセスで蓄積された経験は、チームに役立ちます。戦闘力の高いチームになります。

任正非氏はかつて、ファーウェイの救急救命士事務所の定例会議でマネージャーの感情的な問題について言及し、一部のプロジェクトマネージャーは非常に横暴な管理思想を持ち、部下が問題を解決できないと叱責したり批判したりすることが多く、座ることができないと強調した。従業員と辛抱強く問題の核心とそれに対処する方法を共同で分析します。チームメンバーはプロジェクトの運営に精通しているため、チームメンバーの意見やフィードバックがプロジェクトの意思決定に重要になる場合があります。プロジェクト マネージャーが感情のコントロールに注意を払わず、従業員の間違いを合理的に忠告し、チーム メンバーがあまり批判されたくないという考えからプロジェクト マネージャーと積極的にコミュニケーションを取ろうとしない場合、これは次のような問題につながります。いくつかの実際の重要な情報が失われる可能性があります。

プロジェクトがボトルネックや困難に直面したとき、チーム運営のリーダーであるプロジェクトマネージャーの感情の変化は、他のチームメンバーの思考の変動に影響を与えます。したがって、プロジェクトマネージャーは落ち着いて対策を考え、時にはチームメンバーを慰め、チームメンバーを困難から救い出す必要があります。プロジェクトマネージャーの困難に立ち向かう前向きな姿勢と感情は、従業員を前進させる原動力となり、特にプロジェクトチームが長期にわたってどん底の状態に陥った場合、プロジェクトマネージャーは模範を示し、素晴らしい仕事をしなければなりません。能力を発揮し、模範を示してリードする姿勢は、チーム メンバーに影響を及ぼし、プロジェクトのボトルネックや問題を解決するために彼らに従います。図 7-2 は、プロジェクト マネージャーが従業員のモチベーションを高め、模範を示すための具体的な行動規範を示しています。

プロジェクト マネージャーがチーム メンバーにやる気を起こさせることで、チーム メンバーは熱心に取り組む意欲を得ることができます。このような暗黙のインセンティブにより、チームメンバーは上司からの信頼やチームから与えられる名誉を重視するようになり、成果や躍進が達成されると、物質的なインセンティブでは得られない喜びを感じるようになります。したがって、プロジェクトマネージャーまたはプロジェクトスーパーバイザーは、プロジェクトの進行のあらゆる側面において、挫折や困難に断固として秩序正しく対処し、前向きで楽観的で進取的な気分がチームメンバーに影響を与えて困難を克服し、全員が前進し続けるように導く必要があります。

コミュニケーションはプロジェクトのプロセスに伴い、あらゆるつながりに存在します。良好で効果的なコミュニケーションがプロジェクトの成功の鍵です。プロジェクト チーム内で双方向の平等なコミュニケーションを実現すると、プロジェクト内の既存の問題をタイムリーに明らかにし、解決策をできるだけ早く提案できるようになります。また、プロジェクト マネージャーが進捗状況を追跡できるようになります。プロジェクトの状況を常に把握し、緊急事態が発生した場合にタイムリーに対応できるように調整します。同時に、タイムリーで効果的な双方向コミュニケーションは、チームに対する非物質的なインセンティブの現れであり、会社と親組織による従業員への配慮の反映でもあります。

チーム内で平等なコミュニケーションがもたらすモチベーション効果を最大限に発揮するには、完全なコミュニケーション プラットフォームを確立し、相互運用可能なさまざまなコミュニケーション チャネルを形成し、従業員が理解されていると感じ、自分の考えを表現できるチャネルを確保する必要があります。図 7-3 は、4 つの異なる方向の通信チャネルを示しています。図 7-3 からわかるように、プロジェクト チーム間のコミュニケーション環境は複数のコミュニケーション チャネルで構成されており、各双方向コミュニケーション チャネルはコミュニケーション全体についてオープンなままです。ネットワークをより効果的にするために、情報のフィードバックの速度もそれに応じて増加します。

効果的な双方向コミュニケーションにより、従業員は積極的に行動に参加できるようになります。そのため、従業員はプロジェクトに精通し、行動を起こすことの重要性を理解する必要があります。プロジェクトチーム内での双方向コミュニケーションは、単に情報を伝達するだけでなく、情報の伝達やフィードバックを通じてプロジェクトチームのモチベーションを高める役割も担っていることがわかります。

図 7-4 は、プロジェクト マネージャーが従業員と対等にコミュニケーションをとることによってもたらされるモチベーションの効果を示しています。したがって、双方向の対等なコミュニケーションを通じてプロジェクト チームのモチベーションを高めるためには、プロジェクト マネージャーが従業員の意見やアイデアに耳を傾け、プロジェクト マネージャーが真剣に考えていると従業員が感じられるようにする必要があります。この理解されたという感覚により、従業員は今後のさまざまな形でのコミュニケーションにおいて、よりポジティブなフィードバックを行うようになります。社員から出た意見や提案が採用されると、社員自身の価値観がさらに高まり、プロジェクトへの積極的な関与が期待できます。

プロジェクトチームのモチベーションはチームメンバーの内的要因によって決まるため、モチベーションを高める方法や手段も従業員のニーズの違いに応じて柔軟に使い分ける必要があります。従業員の中には、キャリア開発において自分の価値を実現し、キャリア計画においてスムーズな昇進チャネルを享受したいと考えている人もいます。プロジェクト運営中、キャリ​​ア開発に熱心な従業員は、比較的複雑ではあるが、プロジェクト全体にとってより重要でやりがいのあるタスクに積極的に取り組み、そのようなタスクに参加して完了することで、専門的なスキルと総合的なスキルを発揮できます。 。したがって、プロジェクトマネージャーは、各メンバーの専門分野や特性などを事前に深く理解し、有能で優秀な新入社員に、個人のキャリア形成に合わせてタイムリーに困難なタスクを割り当てる必要があります。ニーズ。図 7-5 は、困難なタスクがプロジェクト チームのメンバーとチームに及ぼす動機付けの効果を示しています。

図 7-5 からわかるように、プロジェクト チームのメンバーに困難なタスクを割り当てると、個々の従業員のモチベーションが高まるだけでなく、このモチベーションがプロジェクト チームやプロジェクトベースの組織にも徐々に広がります。プロジェクト内の困難なタスクは、通常、プロジェクトの重要なノードであり、このタスクを完了することで、個々の従業員の技術的能力を向上させることができます。モチベーションの効果が徐々にチーム全体に波及すると、挑戦的なタスクはプロジェクトチームの遂行能力をある程度向上させます。

プロジェクトマネージャーがタスクを割り当てる際には、従業員の特性やニーズを考慮する必要があります。能力はあるが実務経験が不足している優秀な新入社員には、より困難なタスクに取り組む機会が与えられるべきです。経験豊富な古い従業員の場合は、タスクを割り当てるときに過度に疲れないよう注意し、新しい従業員を指導し、困難なタスクを急速に成長させるための時間とエネルギーを確保できるように、古い従業員にメンターの役割を引き受けてもらいます。

もちろん、プロジェクトマネージャーが新入社員に重要な責任を任せることは、プロジェクトチームの上位リーダーが社員の能力を信頼していることを反映しており、チーム全体に相互信頼の雰囲気を醸成することにつながります。図 7-6 は、信頼できるプロジェクト チームの特徴を示しています。相互信頼のあるチームで働くことで、従業員は個人の目標を追求し、チームの目標と高い一貫性を保つことができ、その雰囲気がプロジェクトチームのモチベーションをさらに高めることになります。

ファーウェイは、特に技術開発の分野で従業員が社内で間違いを犯すことを許容しており、研究開発担当者に一定の余地を与え、技術的および革新的な分野での間違いを許容するが、プロセスは厳格であるため、プロセス上の間違いは許容しない。このようなエラーが繰り返されるということは、チームがビジネス プロセスを注意深くレビューしておらず、過去の間違いについて深く考えていなかったことを示しています。プロジェクトのプロセスは順風満帆ではなく紆余曲折があり、チームメンバーが技術的なボトルネックや困難に遭遇すると、必ず何らかのミスが発生します。プロジェクトマネージャーは、チームメンバーに冷静に失敗と向き合うよう促し、チーム全体が回り道をしないように、プロジェクトが失敗した後にどのように総括し、反省するかを第一に考えるべきです。

任正非氏は社内スピーチの中で、管理部門、プロジェクトマネージャー、プロジェクトチーム全体が創造的な間違いに対して寛容な姿勢を維持し、従業員に新しいことに挑戦するよう奨励する必要があると何度も強調してきました。しかし、試行錯誤が最終目標ではなく、試行錯誤を経て、目標を達成するための最善の方法を見つけ出す必要があります。もちろん、管理部門やプロジェクトマネージャーは常に自己批判的な姿勢を持ち、プロジェクト運営上の問題点を常に改善し、プロセスの進歩を図る努力をしなければなりません。大規模で複雑なプロジェクトでは、間違いには寛容ですが、反省した後は、次回同じような間違いをしないように努めてください。この間違いに対する寛容さと自己批判の組み合わせにより、ファーウェイはチャイナモバイルのTビューローの配送業務を無事に完了することができた。

任正非は、間違いが起こったときは、自己修正と成長に最適な時期でもあると信じています。失敗の教訓を振り返り、まとめることで、問題の鍵を徐々に理解し、間違いを通じて問題に対処する能力を継続的に向上させ、自分自身を修正し、より多くの成長の機会を得る必要があります。

プロジェクトの実行中、リソースと時間の制約、およびチーム メンバーの特性により、特定のリンクでエラーが発生する可能性があります。創造的な間違いに対して、プロジェクト マネージャーまたは監督者は寛容な態度を維持し、従業員が間違いを犯した後に積極的に反省して解決策を見つけるよう奨励する必要があります。ファーウェイの元副社長兼技術リーダーである徐家軍氏は、退任前にファーウェイの従業員にこう尋ねた。「ファーウェイの従業員には、これからも勇気を持って練習し、間違いを犯す勇気を持ち、主に間違いを犯す勇気を持ち続けてほしい」具体的な実践においては、間違いを通じて要約された経験がチームメンバーに大きな影響を与えることを強調します。

従業員が革新的なことでミスをしたとき、プロジェクトマネージャーやスーパーバイザーが寛容であれば、従業員はマネージャーからの信頼を感じることができ、それがチームの暗黙のモチベーションとなります。革新的な試行錯誤を奨励するプロジェクトマネージャーの姿勢は、チーム全体の革新的な精神にも微妙に影響を与えます。

プロジェクトのプロセス中に間違いを犯しても、継続的に反省し、間違いを要約することで、プロジェクトの不確実性を徐々に弱め、正しい方向性を見つけ、ブレークスルーを見つけることができます。勇気を持って試行錯誤し、失敗を許容する環境がチーム内に形成されると、チーム全体の緊急事態への対応力が徐々に向上していきます。チームメンバーは、ミスを回避する方法を考えるのに忙しいのではなく、失敗を冷静に受け入れることが重要です。すべてのミスに対して新しい道と方法を見つけることが重要です。

あらゆる失敗や間違いについて、その理由を十分に分析して解決策を模索し、次に同様の問題に直面したときに備えて事前に計画を立てる必要があります。もちろん、プロジェクト マネージャは、エラーを効果的に管理し、低レベルのエラーやプロセス エラーをできる限り回避し、エラーに対する許容度の動機付け効果を真に最大化するために、効率にも重点を置く必要があります。プロジェクトチーム。

ファーウェイは、会社に貢献した従業員に多大な報酬を与え、高い生産性と高いパフォーマンスを発揮した従業員が会社の注目と評価を得ることができるようにしています。任正非氏は、ファーウェイのインセンティブ制度では、優秀な従業員に物質的なインセンティブを提供し、彼らの経済的待遇を徐々に国際基準に合わせるだけでなく、非物質的なレベルでの業績を評価し、従業員の内なる誇りを高めることも必要であると強調した。 、そして自信を訓練します。一連の研修と学習の導入により、優秀な社員のスキルがさらに向上し、効果的なモチベーションから効率的なアウトプットへの好循環が形成されます。

同様に、プロジェクト チームにも管理者の階層がありますが、チーム メンバー全員の性格は平等です。したがって、プロジェクトマネージャーまたはプロジェクトスーパーバイザーは、従業員の考えや行動を理解することに注意を払い、特に貢献した従業員を十分に評価し、従業員の努力への動機付けを行う必要があります。そのために、プロジェクトマネージャーは、日々の業務において仕事の成果を尊重し、従業員の価値を認める雰囲気を醸成する必要があります。表 7-1 は、従業員の価値を評価する際のプロジェクト マネージャーの行動規範を示しています。

会社が、よく働き、高いパフォーマンスを発揮する優秀な社員に十分な配慮をできなければ、すぐに優秀な人材の流出につながります。プロジェクトマネジメントにおいて、プロジェクトマネージャーやプロジェクトスーパーバイザーは、貢献する従業員の満足度を最大限に高め、インセンティブの仕組みを最大化するために、優秀な従業員の個人的な価値観に基づいてモチベーションを高める必要があります。

任正非氏はかつて、ファーウェイの価値分配システムは、貢献を果たした従業員と努力を続ける従業員に向けられるべきであると強調した。経営者は、会社の現在の発展に沿わない時代遅れの方針を敢えて打破しなければならない。より高いキャリア開発を追求する優秀な従業員に、よりスムーズなキャリア開発パスを提供します。

ファーウェイの人事管理改革に関するガイダンスでは、ファーウェイの報酬制度は貢献に結び付けられるべきであると強調されている。一方で、従業員のこれまでの貢献に基づいて評価されなければなりませんが、他方では、価値を創造し、会社に貢献し続ける従業員の能力を審査する必要があります。優れた管理能力とチーム構築能力を備えた努力家には、その可能性を刺激し、試すために、いくつかの困難な仕事の機会が提供されるべきです。

同時に、ファーウェイの人材評価システムは、従業員の潜在能力を検討する過程で、一時的に潜在能力を発揮できない従業員については、その潜在能力と貢献度に基づいて給与や福利厚生を評価する必要があることも強調しています。機会が与えられたときに傑出したパフォーマンスを発揮する優秀な従業員に対しては、スムーズな昇進経路と報酬の提供をタイムリーに考慮する必要があります。

ダイナミックなプロジェクト チームでは、メンバー全員が自分の仕事の結果と進捗がパフォーマンスに直接反映されることを明確に認識しているため、自分の仕事に対する献身や努力を惜しむことはありません。プロジェクト マネージャーがダイナミックなプロジェクト チームを構築したい場合は、チーム内の努力者や貢献者が相応の待遇と報酬を得られるように、パフォーマンス管理と評価を適切に行う必要があります。

同時に、プロジェクトマネージャーとプロジェクトスーパーバイザーや機能マネージャーは、従業員の貢献に応じて価値を配分し、効率的な成果と能力を持つ優秀な従業員が不利益を被らないように、従業員の業績評価プロセスにおいて円滑なコミュニケーションを維持することが求められます。プロジェクト マネージャーとプロジェクト ディレクターは、複数の方法を組み合わせて、プロジェクトにおける従業員のパフォーマンスを評価できます。図 7-7 は、従業員のプロジェクト パフォーマンスを評価するいくつかの方法を示しています。

図 7-7 によると、プロジェクト マネージャーは、機密の書面による評価報告書、公開可能な評価意見をプロジェクト ディレクターに提供するか、プロジェクト マネージャーが最初に口頭評価と従業員のパフォーマンスの総合評価を実施し、プロジェクトを評価することができます。ディレクターは自分の意見を提供し、その情報が統合され、プロジェクト マネージャーはプロジェクト マネージャーと協力して、従業員の貢献に基づいて利益と報酬を評価します。

もちろん、従業員のプロジェクトのパフォーマンスを評価する方法は、これらに限定されるものではありません。プロジェクトの特性に応じて、従業員の貢献を最も科学的に検証できる適切な方法やツールを選択する必要があります。従業員の待遇や報酬の差を広げ、直接か間接か、有形か無形を問わず、自分の貢献が最終的には業績評価に反映されることをチームメンバーに認識させ、プロジェクトチームのモチベーションを高めるという目的を達成します。

ファーウェイの草の根研究開発マネージャーは最近、業績発表で大きなプレッシャーを感じていたが、周囲の同僚たちもこのことについて懸念を抱いていることに気づいた。共同討議を経て、業績評価やコミュニケーションに関する考え方をまとめました。

彼らは、業績が発表された後、高業績をあげたチームの経験が要約され、洗練され、共有され、周囲の同僚に学習の機会が提供されると述べました。これは、学習を通じて能力を向上させ、キャリア開発を得たいという多くの同僚の願望にも応えます。同時に、草の根の監督者にとっては、パフォーマンスの発表により、チームのパフォーマンス目標を明確にし、日々の評価とフィードバックの作業をより適切に行うようになり、それによってパフォーマンス管理のレベルが向上します。もちろん、下位レベルのマネージャーにとって、パフォーマンスの開示はチームに集合的な学習の機会を提供するのに役立ちますが、いくつかの課題ももたらします。

課題は、発表後、監督者がチームメンバーとともにパフォーマンス結果を分析しなければならないことです。多くの場合、下位レベルの監督者は、チーム メンバーを率いてプロジェクトを次々と解決することに重点を置きますが、チーム メンバーの業績評価に重点を置くことはほとんどありません。では、チーム全体のパフォーマンスと個人のパフォーマンスをどのように公正かつ公平に評価するかが課題となります。草の根の従業員のために、草の根の監督者が業績発表から学ぶ方法と仕事の進め方について意見を共有しました。

監督者は、まず公表された具体的なタスクに注目し、そのタスクが自分たちでやったらどこまで進むのか、いくつかの困難は自分の能力の範囲内で克服できるかどうかを考える必要があると強調しました。第二に、優秀なチームの仕事能力、コミュニケーションスキル、技術スキルなどを学ぶと同時に、学んだことを自分の仕事の特性に合わせて応用し、より適切な方法を創造的に模索する必要があります。自分自身の仕事の習慣を形成するために。最後に、公表中にチームが一時的に遅れていることに気付いた場合は、広い心で一時的な谷に直面し、要約、反省、学習を通じてパフォーマンスの結果を改善および強化するために率先して取り組む必要があります。

プロジェクトチームメンバーの業績評価において公平性と公平性を重視するということは、各チームメンバーの業績が平等でなければならないという意味ではなく、業績評価の過程において、科学の発展を達成するために評価基準が公平かつ公平でなければならないことを意味します。プロジェクト チーム メンバー間のパフォーマンス ギャップの目的。プロジェクトメンバーに対する科学的、合理的、公平・公正な業績評価制度を確立するには、事前に業績指標を定める必要があります。プロジェクトメンバーの業績評価指標を表 7-2 に示す。

ファーウェイはかつて新入社員の研修で、真の絶対的な公平性は存在しないと強調したが、努力する人の前では機会は平等であり、高いパフォーマンスを目指して努力する可能性も平等である。公平性とは、業績が平等に反映されることを意味するわけではありませんが、公正かつ合理的な業績評価・報酬制度を確立することで、従業員に高い業績は高待遇・高報酬に相当するという心理的な固定観念を植え付けることができ、従業員が仕事に集中できるよう導くことができます。価値の分配に焦点を当てるのではなく、プロジェクトの実施タスクとその完了に焦点を当てます。

ファーウェイの業績評価では、プロジェクトの遂行結果もより重視される。企業は、残業時間の長さではなく、顧客のために生み出された価値と実際の個人的な貢献に基づいて従業員のパフォーマンスと勤務態度を評価します。この業績評価方法を通じて、企業は従業員に、自分の努力や貢献を価値あるものにするためには、業務プロセスに焦点を当てる必要があることを認識させます。

プロジェクトチームメンバーの業績評価には合理的かつ公平な指標体系を構築し、それに見合ったボーナスインセンティブ体系を構築する必要があることが分かる。どのような組織でも、従業員の士気を高めるためには、合理的な補助金やボーナスの奨励金が役立ちます。賞与インセンティブ計画を策定する際には、プロジェクトチームメンバーの専門知識や業務内容の違いに留意し、プロジェクトマネージャーやスーパーバイザーが報酬を配分する際に考慮すべき要素となります。図 7-8 は、プロジェクト マネージャーがボーナスを評価する際に遭遇する可能性のある困難を示しています。

厳しい品質意識を持った技術研究開発チームが、製品開発過程において、より高い品質基準に基づいて製品生産のあらゆる面を厳しく管理し、高品質な製品を開発します。同様に、プロジェクトの品質管理と管理においても、プロジェクト チームは最初から卓越性を追求するという品質意識を確立する必要があります。プロジェクト管理において重視される品質意識は、プロジェクトの実行プロセスに根ざしており、失敗を回避するためにあらゆる努力が払われます。プロジェクトプロセスにおける品質管理は、品質計画、品質保証、そして最終的に品質管理に至る完全なシステムです。図 8-1 は、プロジェクトの品質管理のプロセス全体を示しています。

図 8-1 からわかるように、品質管理分野のリーダーの見解とプロジェクト プロセスの特徴に基づいて、プロジェクト品質管理には、プロジェクト品質計画、プロジェクト品質保証、およびプロジェクト品質管理の 3 つの部分が含まれます。顧客中心の品質意識では、プロジェクトの品質管理を通じて失敗や問題の発生を減らし、高コストの手戻りを減らし、プロジェクトの初期段階で高い品質のタスクを実現し、高品質な製品やプロジェクトを一度に納品することが重視されます。品質基準を達成するために欠陥や問題を繰り返し排除するのではなく、顧客に提供します。

顧客中心の品質意識は、顧客の品質要求を無視し、製品とプロジェクト自体の品質のみに焦点を当てる従来の品質管理から脱却します。同様に、プロジェクトの過程で発生する障害や問題に直面した場合、従来の品質管理の考え方は、成果に基づく品質向上のみを重視しており、高品質なサービスを追求するこの段階の顧客には適していません。より高い品質と完璧な品質を追求します。表 8-1 は、従来のプロジェクト品質管理の意識と新しい時代のプロジェクト品質管理の意識の違いを示しています。

表 8-1 からわかるように、顧客中心のプロジェクト品質意識では、顧客ニーズのタイムリーかつ効果的な管理に基づいて、プロジェクト プロセス全体を通じて包括的かつ体系的な品質改善管理の実施を重視しています。ファーウェイのプロジェクトにおける品質管理の意識は、企業の特性を反映した品質管理システムの形成を重視しており、ファーウェイは、任正非氏の影響を受けて、製品やプロジェクトだけでなく、社内に浸透する品質管理システムを構築しました。組織文化とマネジメントの構築 組織文化としての品質管理の意識が強化されました。

ファーウェイは 2010 年に仮想化組織 CSQC (顧客満足度および品質管理委員会) を設立し、社内のすべてのレベルに分散しました。全社CSQC責任者は輪番制を採用しており、交代でCEOが兼務することで各階層の品質管理を徹底し、各階層の責任を分担しています。各レベルでは、品質要件と基準を明確に通知し、顧客要求を明確にし、顧客を中心として品質を向上させることができます。企業の組織管理レベルに浸透している CSQC に対応するのは、顧客管理品質システムです。これは、プロジェクトの品質責任を実行するために顧客の品質要求に基づいて確立されたシステムです。

ファーウェイは毎年、キャリアBGが招待した100社以上の重要顧客のCXOと3日間の品質改善ディスカッションを開催している。この会議の目的は、顧客の意見を求め、ファーウェイにとって改善が必要なタスクのリストを整理することである。 。ファーウェイは顧客と各作業リストを確認し、社内に品質改善チームを設置する。この品質改善チームは、品質改善プロジェクトチームに相当し、複雑な品質改善プロジェクトの場合は、プロジェクトやタスクを分解・改善し、分解されたサブモジュールごとに対応する責任者を割り当て、目標を定めて品質問題に取り組む必要があります。やり方の質問。

第2回年次総会では、前年度TOP10プロジェクトの品質向上状況をお客様に報告します。顧客の要求に基づいたこの種の品質改善により、品質の責任と管理を真に深く理解することができます。ファーウェイのCSQCは、「グランド・クオリティ・コンセプト」に基づいて確立されており、「グランド・クオリティ・コンセプト」は、製品の品質が耐久性があり、破損しにくいという基本的な品質要件に限定されず、品質に由来する優れたユーザーエクスペリエンスも要求します。

ファーウェイは、あらゆるレベルのCSQCに対して、管轄区域内の製品品質を定期的に検査し、各リンクの品質レビューを実施して、顧客が最も懸念している問題を特定し、主要な品質改善プロジェクトを形成することを要求しています。このようにして、管理レベルに由来する前方向の品質管理システムと顧客に由来する逆方向の品質管理システムが接続され、品質責任が継続的に洗練され、品質責任は顧客の要求に応じて継続的に進化します。

仮想化組織の導入により、ファーウェイの品質責任が各管理レベルで実装されていることがわかります。品質責任は階層ごとに分解されて厳格な品質責任チェーンを形成し、最終的にはすべてのリンクとすべての従業員に実装され、それによって品質が保証されます。それはプロジェクトの品質です。プロジェクト チームでは、各チーム メンバーが品質管理に重要な役割を果たします。すべてのメンバーが品質管理に積極的に参加する場合にのみ、品質責任を完全に実行することができます。その鍵は上級リーダーにあります。

管理レベルから見ると、最終的な品質責任は上位レベルのリーダーにあります。したがって、上級リーダーは、組織またはチーム内に質の高い職場環境を作り、品質基準の改善と向上に継続的に努力する必要があります。同時に、品質専門家が作成した内部品質方針を全面的にサポートし、プロジェクトマネージャーや品質専門家と共同で品質目標を策定し、品質方針と品質方針の二重の組み合わせを通じてプロジェクトの品質責任の履行を促進する必要があります。品質の目標。したがって、品質責任を明確にするためには、適切な品質方針と品質目標が不可欠です。表 8-2 は、優れた品質ポリシーと品質目標に何を含めるべきかを示しています。

プロジェクト マネージャーはプロジェクトの品質に対する最終責任を負い、失敗や問題を回避するためにプロジェクトの各主要ノードで品質を管理する必要があります。プロジェクトの成果物の品質が標準に達していることを保証するために、プロジェクト マネージャーは、サポート チームのメンバーに対し、障害や問題が発見された場合には直ちに報告し、話し合うよう奨励する必要があります。図 8-2 は、プロジェクト チームの品質責任を実装するプロセスを示しています。

同時に、チーム内で一連のトレーニングを定期的に組織する必要があります。トレーニングを通じて、一方では、プロジェクト チームのメンバーが自主的に品質責任を負うという意識が強化され、予期せぬ品質障害に対処するチーム メンバーのスキルが向上します。他方では、チーム メンバーが品質上の問題を特定し、問題を解決する能力が向上します。解決策と提案。プロジェクト監督者またはプロジェクトマネージャーは、従業員に権限を与えなければなりません。つまり、従業員は活動を停止し、品質手順の範囲外で作業し、トレーニングと権限付与の共同作業の下でプロジェクトの品質責任の履行を促進する権利を有します。

プロジェクトの品質計画は、プロジェクトの品質管理プロセス全体の最初の段階です。品質計画フェーズでは、プロジェクトに関連する品質基準を特定し、その品質基準を達成する方法を計画します。プロジェクトの品質計画は、品質はプロジェクトの実行プロセス全体に根ざしているという概念に基づいている必要があり、問題を引き起こす可能性のある主要なリンクを計画段階で考慮する必要があります。同時に、プロジェクトごとに品質要件が異なるため、普遍的な品質計画は存在せず、プロジェクトの品質計画はオーダーメイドする必要があることに注意してください。図 8-3 は、品質計画の必要性を示しています。

品質計画を策定する目的は、失敗を回避し、品質基準の一括達成を目指し、プロジェクト全体の品質を確保することです。プロジェクトの品質計画が明確であれば、他の要因の影響によって品質が低下しにくくなります。同時に、プロジェクトの品質計画を通じて、プロジェクトによって達成される実際の品質レベルを比較検討することができます。プロジェクトの品質計画全体を調整するか、主要な QC ノードを調整するかを決定します。

完全な品質計画を確立するプロセスは、プロジェクト品質の継続的な改善の始まりです。もちろん、完全な品質計画の具体的な実施プロセスでは、プロジェクトの品質管理を共同で推進するためのサポート品質保証システムが必要です。品質保証とは、プロジェクト開発プロセス中にプロジェクトの成果物または製品が品質計画で要求される品質基準を満たしていることを確認すると同時に、プロジェクト プロセス全体のすべてのタスクのリンクが品質の制限内にあることを確認することを指します。規格。したがって、品質基準を特定し、品質障害の発生を防ぐためには、優れた品質保証システムが必要です。図 8-4 は、品質向上プロセスにおけるプロジェクト品質計画の役割を示しています。

図 8-4 からわかるように、プロジェクト品質管理のプロセス全体における主要なリンクとして、プロジェクト品質計画が完了し、プロジェクト要件を満たしているかどうかは、品質障害の処理と品質改善のプロセス全体に影響を与えます。 、そして結果をもたらします。プロジェクト品質計画は、プロジェクト スコープ ステートメントと WBS およびその他のスコープ ベースライン、コスト ベースライン、スケジュール ベースラインで構成されます。プロジェクト品質計画は、品質検査プロセスの基準と基礎を提供します。品質基準が満たされていない場合は、プロジェクトの成果物が出力された後、品質管理サイクルの次の段階に基づいて品質を改善する必要があります。が入力されます。

品質を保証するために、プロジェクトの特定の運用中に各リンクの品質を監視および制御する必要があります。障害が発生したときだけ対策を講じるのではなく、適切な品質監視ツールを導入することでプロジェクトプロセス全体の品質を向上させる必要があります。プロジェクト プロセスの品質監視を通じて、継続的に障害を特定し、問題を排除し、技術レベルと品質レベルでの逸脱を削減し、プロジェクト プロセス全体の品質管理効率を向上させて、プロジェクトの成果物が品質基準を満たしていることを確認する必要があります。優れた品質管理システムが品質管理において重要な役割を果たしていることがわかります。図 8-5 は、完全な品質管理システムに含めるべき具体的な内容を示しています。

プロジェクトプロセスの品質モニタリングは、品質管理の技術レベルの活動とみなすことができ、プロジェクトチームのメンバーが確かな専門スキルを持っていれば、プロジェクトプロセスの品質管理に役立ちます。プロジェクトチームは完全な技術システムを確立し、さまざまな品質監視方法と管理手順を使用して、プロジェクトの開始から終了までの各ステップの品質が基準を満たしていることを確認し、それによってプロジェクト運営プロセス全体の品質が確実に満たされるようにします。規格。

プロジェクトの概要段階で、チーム メンバーは、このプロジェクトに参加することで多くの利益を得たと表明しました。日本の顧客によるプロセス品質の厳格なテストを受けて、プロジェクトチームのメンバーは、品質の観点から顧客のニーズに真に応えるために、今後の製品開発やプロジェクト開発において品質プロセスの監督とテストにさらに注意を払うことを決意しました。

プロジェクト運営プロセスの品質管理フェーズでは、7QC (品質管理) ツールとも呼ばれる 7 つの基本的な品質ツールを使用できます。基本的な品質ツールには、具体的には 7 種類の特性特性図、フローチャート、チェックリスト、パレート図、ヒストグラム、管理図、散布図が含まれます。各ツールには独自の使用範囲があり、プロジェクトの実際の状況に応じて品質監視ツールを選択する必要があります。図 8-6 は、因果関係図分析の品質のプロセスを示しています。

図 8-6 からわかるように、プロジェクト プロセスの品質監視段階で特性要因図分析を使用して品質上の欠陥や問題の原因を特定し、次回同様の問題が発生するのを回避できます。特性要因図を通して、まず品質上の問題が何であるかを確認します。次に、チームの専門分野の技術メンバーが選ばれ、品質問題をさらに評価して分類するためのブレーンストーミング チームが形成されます。次に、特定の品質問題の根本原因を特定するために共同で議論し、適切な解決策と是正措置を決定します。

プロジェクトプロセスの品質を標準化するには、プロジェクト全体の品質管理プロセスを改善するためのレビューメカニズムの導入が必要です。完全な品質レビューにより、プロジェクト運営のあらゆる側面の結果が品質基準を満たしていることが保証され、障害や問題をタイムリーに発見できます。図 8-7 は、要件への準拠を保証するために適切な品質レビューが何を行うべきかを示しています。

ファーウェイの品質管理では、製品テストにおける欠陥ゼロの追求と実験室での障害問題の排除が求められます。プロジェクト運営や製品開発においては、多くの不良を完全になくすことはできませんが、技術レベルや品質レベルでの作業によりプロジェクトの不良を削減し、最終的には不良ゼロを達成することができます。プロジェクト プロセス全体で欠陥ゼロを達成するには、特定の品質または技術的欠陥がどの程度許容されるかを計算するのではなく、すべてのリンクの出力が一度に品質基準を満たすことができることを認識する必要があります。各リンクの品質に欠陥がないことを保証するには、製品またはプロジェクトのテストを頻繁に実施する必要があります。図 8-8 は、一般的な製品テストに含まれる手順を示しています。

図 8-8 からわかるように、製品またはプロジェクトのテストのステップは、通常、計画、設計、実装、実行、完了の 5 つのステップに分かれています。もちろん、特定のテストでは、実際のテストに基づいて調整を行う必要があります。プロジェクトと製品の条件。同時に、テストを効果的に組織するためには、製品テストの有効性を確保し、欠陥ゼロという目標を達成するために、専門的および技術的担当者の役割分担を明確にすることも必要です。プロジェクトや製品の欠陥は自動的には消えないことがわかります。プロジェクトや製品の開発・運用初期段階でデューステージや品質テストが削減・省略されると、プロジェクト後半で障害や性能上の問題が集中的に発生し、顧客主導の受け入れテストがスムーズに通過できなくなります。 。したがって、プロジェクトの開始から結果の提供までのあらゆる側面において、段階的な出力で欠陥をゼロにすることが重要です。

プロジェクト運営のあらゆる側面で欠陥ゼロを達成するには、プロジェクトのすべての関係者が品質管理および制御プロセスに参加する必要があります。会社のトップから経営陣、従業員に至るまで、あらゆるレベルが欠陥ゼロの品質意識を確立し、欠陥許容値の計算ではなく品質基準を達成する方法に集中して取り組むことができるようにする必要があります。

同時に、社内の品質管理に加え、バリューチェーン全体の品質管理も基準を満たすようにしなければなりません。プロジェクトの円滑な実施は、最終成果物の高品質を達成するための、すべての上流および下流リンクの高品質に依存します。したがって、製品品質における欠陥ゼロの追求は、プロジェクト運営の全プロセスおよびバリューチェーン全体を通じて実行される必要があります。

プロジェクトで障害や事故が発生した場合、事故の根本原因を究明し、適切な解決策を講じるために、事故を総合的に分析する必要があります。品質問題を確実に効果的に解決するには、欠陥追跡を常に実行する必要があります。欠陥追跡プロセスを厳密に実装し、製品またはプロジェクトのプロセスにおける欠陥を記録することにより、品質レビュー、テスト、その他のリンクにおける問題解決プロセスを標準化するという目的が達成されます。同時に、欠陥処理の全プロセスを追跡することで、欠陥の修復漏れを効果的に回避し、問題や障害の処理を正確に反映することで、欠陥を減らすことができます。欠陥追跡プロセスを記録すると、一方では欠陥の追跡可能性が確保され、他方では、記録には大量のプロセス情報が反映され、プロジェクトの後半で欠陥や問題を統計的に分析するための情報源が提供されます。欠陥追跡プロセスは、プロジェクト プロセス全体の品質管理において重要であることがわかります。

欠陥を追跡するプロセスでは、記録と修復に加えて、欠陥を分析およびカウントし、プロジェクトへの影響に応じて欠陥を分類することがより重要なタスクです。統計と分類を通じて、欠陥に対処するために関連する専門チームのメンバーを調整し、プロジェクトの品質上の欠陥を修復する効率を向上させるのに役立ちます。表 8-3 は、欠陥の重大度レベルを示しています。

表 8-3 からわかるように、プロジェクト チームは欠陥の重大度に基づいて適切な措置を講じる必要があります。欠陥の重大度に対応するのは欠陥の緊急性であり、欠陥の緊急性はその重大度と密接に関係しています。一般的に言えば、プロジェクト チームはより緊急性の高い欠陥や問題に対処し、欠陥の緊急性と重大度を包括的に分析し、対応する修復措置を講じる必要があります。

欠陥の発見者は調整者に問題を提出し、調整者はその問題をプロジェクトマネージャまたはプロダクトマネージャにフィードバックし、プロジェクトマネージャまたはプロダクトマネージャが判断して欠陥を割り当て、調整者は割り当て結果を修正者に通知します。最後に、修正後、レビューのために譲渡者に提出する必要があります。欠陥が存在しない場合、または問題がない場合は、プロジェクトを再開できます。欠陥追跡プロセスは、欠陥の提出、判定、配布、修正、レビューから最後まで一貫したプロセスであり、主要な役割が互いに協力して実行されることがわかります。もちろん、プロジェクトの実際の状況に応じて、欠陥追跡プロセスの対応するリンクを柔軟に調整して、欠陥が正確に記録および分析されるようにすることができ、欠陥リンクを適切に修正するための実行可能なソリューションを提供できます。

「全自動」QCC（品質管理サークル）

プロジェクト組織内で品質管理サークル活動を徹底することで、プロジェクトの品質管理の効率化につながります。プロジェクトの品質管理プロセスでは、チームメンバーが品質向上や経営改善について上司に意見や提案をする必要があるため、社内の従業員やプロジェクト関係者を巻き込んだ品質管理サークルを設立することができます。ディスカッション グループは、品質上の失敗を解決し、品質の問題を改善するための幅広い意見交換の場を提供します。図 8-10 は、プロジェクトの品質管理のために品質管理サークルを設立する利点と重要性を示しています。

品質管理サークルの概念は日本で最初に確立され、徐々に発展、改良され、他の国々でも広く使用されており、その中でも米国での適用は良好な成果を上げています。図 8-10 からわかるように、品質管理サークルの設立はプロジェクト チーム メンバーの自発的な行動によってもたらされるため、完全な品質管理サークルの設立はチーム メンバー全体の品質意識の浸透に役立ちます。これにより、品質管理の効率が向上し、チームの結束力を高めることができます。同時に、品質管理サークル運動を始めることで、チームメンバー間のコミュニケーションや意思疎通が強化され、組織内に品質を大切にし、品質向上に注力する文化的な雰囲気が自発的に形成されます。

下位レベルの従業員の意見は無視されたり見落とされたりしやすいため、品質管理サークルをうまく確立するには、チーム内の管理者が品質に関する従業員の意見や提案に積極的に耳を傾ける必要があります。すべてのチームメンバーとプロジェクト関連の管理レベルは、品質向上の協力プロセスに積極的に参加する必要があります。顧客の品質エクスペリエンスを向上させる作業は、品質管理部門だけで行うことはできません。特に上級マネージャーは、品質管理サークルを設立する必要があります。途中の例。

任正非氏はかつて、ファーウェイの品質サークル活動が一定の成果を上げているのは、主に同社のほとんどの従業員が継続的改善に対する意識を持っていることによると強調した。従業員が小さな改善を主張することが習慣になっているため、継続的に仕事が最適化され、作業プロセスとプロジェクトの品質管理がより標準化され、合理的になります。したがって、長期的な観点から見ると、ファーウェイが提唱する「小さな改善、大きな見返り」政策は、同社の中核的な競争力の強化に役立つだろう。

同様に、プロジェクト品質管理の小さな改善では、各段階での品質の継続的な最適化が強調され、それによって大規模な品質改善イベントが回避され、手戻りによる時間コストが削減されます。図 8-12 は、競争的なプロジェクトの品質管理と非競争的なプロジェクトの品質管理の時間利用効率の違いを示しています。

図 8-12 からわかるように、プロジェクトの品質を継続的に改善することで、時間の利用効率が向上し、プロジェクト品質管理の競争力が形成されます。プロジェクトの品質管理を継続的に改善および最適化することで、手戻りや時間の無駄を削減でき、そのような品質管理のみが競争力を発揮します。

プロジェクトの品質管理では、継続的な改善と最適化により、より短い時間でより多くの作業を行うことができます。継続的な改善により、隠れた品質問題を徐々に排除し、より大規模な品質問題の発生を回避できます。同時に、プロジェクトの品質管理が徐々に成果を上げることは、品質管理レベルでの競争優位性が形成されたことを意味します。ただし、利点は静的かつ永続的なものではなく、プロジェクトの品質に関する競争上の優位性を長期間維持するために、プロジェクト チームは詳細や問題を継続的に改善および最適化する必要があります。図 8-13 は、プロジェクトの品質を継続的に改善する必要性を示しています。

図 8-13 からわかるように、継続的な改善と最適化により、プロジェクトの品質は徐々に向上し、プロジェクトの品質における競争上の優位性が新たな高みに押し上げられます。効率と品質における競争上の優位性を維持するには、継続的な改善と最適化の必要性を十分に理解する必要があります。

プロジェクトが受理および支払いの段階に達すると、プロジェクトの成果物は基本的に完成したことになり、この時点でプロジェクトのプロセス全体が終了します。ただし、プロジェクトの受注・代金回収段階は、一時点での活動ではなく、プロジェクトの終了に関わる一連のつながりから構成される段階であるため、プロジェクトの受注段階では結果を受け入れる必要があります。一歩ずつ。プロジェクト管理の受け入れプロセスにおいて、ファーウェイは、それを部分に分けて段階的に実行する方針に従い、サイトに応じて各リンクの結果を段階的に受け入れ、サイトに応じて段階的に支払いを徴収します。図 9-1 は、プロジェクトの承認と支払いの回収の手順を示すために、ファーウェイのプロジェクトを例にしています。

図 9-1 からわかるように、プロジェクトの承認と支払いの回収ステップは同時に実行されます。つまり、プロジェクトの各リンクの結果が承認されると、支払いもそれに応じて処理されます。したがって、各段階での顧客の受け入れ要件を満たすために、プロジェクトの開始時にプロジェクトの受け入れ計画を策定する必要があり、プロジェクトの開始段階でも受け入れ準備作業を準備する必要があります。

プロジェクトの承認リンクは、結果が正式に顧客に提供される前に、プロジェクトの未完了の問題を解決する最後の時間と機会を提供することに相当します。プロジェクトチーム全体にとって、プロジェクトは最初から最後まで計画的に進められる必要があるため、受け入れプロセスでは十分な準備を行う必要があります。適切な受け入れ準備活動により、チームは受け入れプロセス中にプロジェクト プロセス全体についてより深く考えることができ、将来のプロジェクト実施における同様のエラーを回避するための改善と最適化の機会がチームに提供され、それによってチーム全体のプロジェクト実施の効率が向上します。効果と効率を向上させます。表 9-1 は、プロジェクトの受け入れ段階で準備する必要がある主要なアクティビティと、納品文書の内容を示しています。

表 9-1 からわかるように、プロジェクトの受け入れ段階では、これらの主要な活動と文書を慎重に準備することによってのみ、プロジェクト全体が次の段階での規範とシステムの原則に従うことができます。準備、計画、実装の段階でプロジェクト受諾リンクがスムーズに実行されると、クライアントはプロジェクト チームに対する信頼を築き、プロジェクトの成果物に対するクライアントの信頼を高めることができます。

通常、プロジェクトを終了する時期は、プロジェクトの結果が正常に完了し、プロジェクトの実施が期待どおりの結果を達成したときです。プロジェクトの初期段階では問題が比較的少ないため、プロジェクト チームは後の段階に比べて期待された目標を達成することが容易になります。同様に、顧客にとっても、プロジェクトの進捗が遅れれば遅れるほど、プロジェクトの各段階で生み出される結果を目にする可能性は低くなります。プロジェクトの成功を検証することは、プロジェクト チームにとっても顧客にとっても簡単な作業ではないことがわかります。受入活動を促進し、プロジェクト受入の円滑な実施を促進するために、プロジェクトチームは、最終段階での顧客とのコミュニケーション作業において十分な準備と計画を立てる必要があります。図 9-2 は、クロージング段階における顧客とのコミュニケーションの促進レベルを示しています。

通常、クライアントは結果の有効性を検証するために、一定期間「観察」を続ける傾向がありますが、このような様子見はクライアント自身にとってもプロジェクトチームにとっても多大なコストがかかります。現時点では、プロジェクトを正常に終了させるために、プロジェクト チームは顧客と合意に達して、プロジェクトの承認作業を迅速化する必要があります。一般に、プロジェクトの目標が達成されたということは、プロジェクトが終了する時期が来たことを意味します。お客様とのコミュニケーションでは、主にプロジェクトの結果についての 3 つの側面からお客様との合意を形成します。図 9-3 は、プロジェクトの終了段階でクライアントとコミュニケーションをとる際に注目すべき 3 つの主な結果を示しています。

図 9-3 からわかるように、プロジェクトの最終段階では、資材、設備、人員、その他のリソースを再割り当てするための一連の明確なプロセスが必要です。強力な包括的なリーダーシップ スキルを持つプロジェクト マネージャーは、プロジェクト チームと顧客を積極的に導き、主要な結果について合意に達します。プロジェクト マネージャーが顧客とコミュニケーションをとる際の綿密な計画は、プロジェクトのスムーズな終了を促進し、プロジェクト チームのメンバーがプロジェクトから撤退して次の作業フェーズに投資するのに役立ちます。

ファーウェイのプロジェクトチームの多くは、プロジェクトの立ち上げ段階でプロジェクト終了計画を策定し、プロジェクトの進行に応じて終了計画のメンテナンスや引き継ぎ事項を段階的に調整し、各段階で成果の引き継ぎの準備を進める。開始段階のプロジェクト計画報告書やプロジェクトのミッションステートメントから、プロジェクト計画段階の作業パッケージ分解やコミュニケーションリスク計画、プロジェクト実施管理段階の進捗報告書や議事録などの文書まで、すべてが役割を果たします。これにより、プロジェクトの最終段階での結果の引き継ぎがスムーズな次元移行の基礎を築きました。この一連の文書を通じて、プロジェクト全体の各段階の作業を追跡し、隠れた危険を土壇場で回避することができます。

プロジェクトの終了段階では、ファーウェイのプロジェクトマネージャーは、顧客への結果の提供と転送に 2 つの側面から特別な注意を払います。

1つ目は技術の引き継ぎで、プロジェクトの最終段階で技術情報や資料を整理し、顧客に引き渡すことを重視しています。具体的な結果には、運用保守に関する技術情報、システム担当者の設定情報などが含まれます。これらの資料を通じて、お客様が成果物を正しく便利に使用するための技術的基盤が提供され、お客様のその後の使用、技術的なメンテナンス、容量拡張などの作業に役立ちます。

2つ目は組織レベルへの引き継ぎです。プロジェクトチームの成果物としては、具体的には、プロジェクトに協力するための組織構造や管理機構改革のためのソフトウェアをはじめ、本プロジェクト専用に構築された財務制度や人事制度など、プロジェクトの推進過程で確立された組織管理体制が挙げられます。運用、ハードウェア設備、組織構造などに関する情報文書技術レベルでの移転であれ、組織レベルでの移転であれ、プロジェクトマネージャーは、顧客が最終段階で特定のリンクを遡って使用できるように、プロジェクトの進行過程で生成された文書を顧客に引き渡す必要があります。同時に、これらのデータは、プロジェクトの実施結果が期待どおりの成果を達成したかどうかを判断するための重要な根拠でもあります。

プロジェクト チームが技術的および組織的な結果と文書を顧客に引き渡すことができた場合、それはプロジェクトが終了に近づいていることを意味し、評価や受諾などの受諾文書に署名するよう顧客に速やかに通知する必要があります。レポート、プロジェクト概要レポートなどを確認します。ただし、これでプロジェクトチームの作業が完全に終了するわけではなく、お客様から継続的な信頼を得るために、成果を活用する際の技術面などのサポートサービスを定期的に提供する必要があります。

プロジェクトの終了管理では、プロジェクト成果物の移転および移転プロセスに正式な標準ルール、明確なプロセス、および完全な移転文書が確実に存在することを保証するために、プロジェクト結果の移転および移転において適切な仕事を行うことも必要です。ファーウェイのプロジェクトクロージング管理では、メンテナンスの移転と引き継ぎは、外部移転と内部移転の2つの側面に分けることができます。外部転送は、プロジェクト チームが成果物と技術文書および組織文書を顧客に引き渡すことを指します。内部転送は、プロジェクト実施チームが結果とその後の作業を保守プロジェクト チームまたはカスタマー サポート部門に転送することを意味し、これらの部門はフォローを提供します。結果の運用に関するメンテナンスとサポートを強化します。

、プロジェクトの引き継ぎと保守のリンクでは、プロジェクトの人的リソースの適切な配置も引き継ぎ作業の焦点となります。プロジェクトチーム間で人員配置の問題に関する衝突を避けるために、プロジェクト要員を適切に配置し、従業員が次の作業計画を立てるのを支援する必要があります。

優れたマネジメント能力とチーム調整能力を備えたプロジェクトマネージャーが、プロジェクト終了時の移行や引継ぎを綿密に計画・管理し、チーム内外のプロジェクト担当者の不安を軽減します。同時に、保守移管プロセスがスムーズに進むことで、プロジェクト全体の時間とコストが節約され、不要なリスクが回避されます。メンテナンスの転送および引き継ぎのプロセス中に、プロジェクト実施チームは、外部への転送と内部のメンテナンス転送の両方の活動がスムーズに展開されるように、十分な準備と計画作業を行う必要があることがわかります。図 9-4 は、保守および引き継ぎプロセス中に注意すべき重要なポイントを示しています。

図 9-4 からわかるように、顧客の観点からの寸法転送プロセスでは、プロジェクトの結果が顧客のニーズを満たしているかどうか、および関連する文書や資料が完全であるかどうかを検証することに重点が置かれています。プロジェクトの漏れや漏れがこの段階で確実に完了し、顧客のニーズに完全に応えられるようにするには、寸法転送の具体的な事項について顧客との受け入れ会議を開催する必要があります。会議中、プロジェクト チームは前向きかつプロフェッショナルな態度を維持し、顧客の疑問や質問に答え、顧客の懸念に対して誠実かつ謙虚な態度を示し、不足している作業にできるだけ早く対処したいという意思を表明する必要があります。謙虚で誠実、間違いを正そうとするプロジェクトチームに対する顧客は、より信頼を寄せ、プロジェクトのクロージング作業を進めるために積極的に努力するようになるでしょう。

ファーウェイのプロジェクトチームは、顧客が必要なときにいつでも対応し、効率的なソリューションを提供します。たとえ障害の原因がファーウェイの機器に問題がなかったとしても、前段階の成果物が得られている限り、顧客の視点に立って損失を最小限に抑えたソリューションを提供する必要があるとプロジェクトチームは考えている。

プロジェクトの成果物が無事に顧客に納品され、寸法の移行や引き継ぎ作業が完了した時点で、プロジェクト全体が一旦終了したことになりますが、これでプロジェクトチームの作業が終了したわけではありません。また、プロジェクトチームは、顧客がプロジェクトチームの成果物に高い満足感を得ることができるように、成果の実装中に顧客が遭遇するさまざまな問題に対する技術サポートやサービスを提供し、プロジェクトのフォローアップサービスを提供する必要があります。 。同時に、優れたフォローアップサポートサービスは、次の協力の機会も獲得します。

プロジェクトチームが提供する「ナニー型」の保証サービスは、具体的な指標で測ることは難しいですが、この目に見えない特性が顧客に十分な満足をもたらすことができ、顧客がプロジェクトチームに対して信頼を寄せる必須条件となっています。プロジェクト チームは、このフォローアップ サポート サービスも顧客のニーズに基づいていることに注意する必要があります。プロジェクトの成果物を継続的に追跡し、顧客が直面する問題や困難を真に解決することによってのみ、私たちは真の「ナニースタイル」のサービスを提供することができます。

プロジェクトの結果が予定どおりに提供されたことは、プロジェクトの提供が正常に完了したことを意味するものではありません。プロジェクト実施プロセスの成功を測る鍵となるのは、成果物とプロジェクト運営の各段階が顧客のニーズを中心としており、顧客の問題を真に解決しているかどうかです。つまり、顧客満足度がプロジェクト管理作業を測る基準となるはずです。図 9-5 は、プロジェクトの実施中に比較検討する必要があるいくつかの重要な要素を示しています。これらは、プロジェクトの実施の成功の尺度でもあります。

図 9-5 からわかるように、プロジェクトを成功させるための測定基準は、プロジェクトの進捗状況、プロジェクトのコスト、プロジェクトのパフォーマンス、およびプロセスのリスク管理で構成されます。顧客満足度はプロジェクトのパフォーマンス評価の重要な部分です。高い顧客満足度は、プロジェクトのプロセス全体が顧客中心の原則に従って実行され、プロジェクトの各段階の結果が顧客のニーズを完全に満たすことを意味します。つまり、顧客の問題を真に解決できることが、プロジェクト遂行の成功の鍵となります。したがって、プロジェクトのクロージング段階では、顧客満足度の検査と評価を無視することはできません。

ファーウェイのインド駐在員事務所のプロジェクトチームは、顧客に価値を創造することが自社の仕事の満足度の源泉であるとみなしており、仕事の評価基準として顧客の満足度を使用することを長年主張してきた。顧客満足度が高いと、プロジェクトチーム全体が誇りに満ち、顧客満足度が向上し、チームの戦闘効率と作業効率が双方向で高まる好循環が形成されます。図 9-6 は、顧客満足度分析の閉ループを示しています。

図 9-6 からわかるように、プロジェクトを測定する尺度として顧客満足度を使用するには、顧客満足度を明確かつ明確に評価する必要があります。顧客満足度アンケートの発行、顧客へのインタビュー、インタビューや調査結果の分析などにより、生の情報やデータを得ることができます。長期にわたるプロジェクト運営では、主要ノードにおけるプロジェクトチームの貢献が顧客に無視される可能性があるため、プロジェクトマネージャーは各段階で作成された成果とチームの取り組みを承認レビュー会議で明確にする必要があります。顧客が満足していない問題については、原因を分析し、継続的な改善と修正を行うことで、同様の問題を回避し、次のプロジェクトでより高い顧客満足度を達成する必要があります。

ファーウェイでは、任正非氏が従業員に対し、業務後のレビューを通じて要約と継続的な改善を学び、それによって能力や習慣を向上させることを頻繁に奨励しています。要約が得意な従業員は、継続的に要約を行うことで、問題を解決するための思考ネットワークの形成に役立ち、問題の解決策を迅速かつ正確に見つけることができると強調しました。したがって、プロジェクトが終了したら、プロジェクトのプロセス全体を要約してレビューし、問題の関連性を分析して継続的な改善を行い、その後のプロジェクト作業の良い基盤を築く必要があります。表 9-2 では、プロジェクトの概要で注意が必要な要素について説明します。

任正非氏はかつて、ファーウェイにおける最大の無駄は、多くの部門やマネージャーがあらゆる仕事で貴重な経験を無駄にしていることだと指摘した。彼は、マネージャーも従業員もプロセス業務の一部であり、必然的に何らかの要因の影響を受け、仕事上でさまざまな困難や問題に遭遇するだろうと信じています。過去のプロジェクトの経験や情報、データなどの貴重な情報が保存されていないため、再び問題が発生したときに途方に暮れてしまいます。社内のさまざまな部門がこの有益な情報を適切に収集して活用し、優れたフィードバック メカニズム、問題解決メカニズム、監視メカニズムを確立できれば、会社の緊急事態はますます少なくなり、プロセスの運用は新たなレベルに引き上げられます。会社全体の業務効率が大幅に向上します。

貴重な経験はプロジェクト チームにとって有益なリソースであり、経験学習が組織にもたらす長期的な価値を最大限に活用する必要があることがわかります。現在、ファーウェイのプロジェクトチームはこの習慣が定着しており、プロジェクトが成功しても失敗しても「終了」プロセスを実行することになる。図 9-7 は、ファーウェイのプロジェクト チームによる経験の要約と学習の閉ループを示しています。

図 9-7 からわかるように、ファーウェイのプロジェクト チームの経験学習は、全社的な経験学習に拡張できます。プロジェクトチームは、プロジェクトの各運用段階やクロージング段階での成果やプロセスを評価・分析し、チーム内で経験を形成し、その後のプロジェクト業務に反映してプロセスの改善を図ります。そして、プロジェクトチーム内で形成された経験の要約や能力向上計画を組織基盤に共有することで、全社的な経験の共有と学習を促進し、全社のビジネス能力の向上を図ります。

プロジェクト プロセス全体を通じて文書を保持すると、プロジェクトの特定の側面を追跡するための貴重なデータが得られます。一般に、厳格な文書化プロセスを採用している組織は、学習プロセスの進歩が速くなります。同時に、包括的なプロジェクト文書は、プロジェクト結果のレビュープロセスにおいて、プロジェクトチームと顧客にとって重要な評価基準となり、特にプロジェクト運営における主要な問題をレビューする際に、詳細の曖昧な記憶に対する貴重な参照基準となります。プロジェクト チームにとって、経験を視覚的な学習ドキュメントに変換することは、新入社員が自分のポジションで急速に進歩するのに役立ち、全体的な作業効率を向上させるための基礎データを提供します。表 9-3 では、保存する必要がある主要なプロジェクト文書について説明します。

表 9-3 からわかるように、プロジェクトのプロセス全体には多くの典型的な文書が含まれており、文書の大部分はプロジェクトの最終段階まで収集されません。同時に、サイクルが長く、難易度が高い大規模かつ複雑なプロジェクトでは、時間の経過とともにファイルの総量が増加し、アーカイブと保存の最終段階で詳細の記憶に偏りが生じやすくなります。ファイル構成のエラー率が上昇します。したがって、プロジェクト マネージャーは、プロジェクトの運用プロセス全体を通じて、標準に従ってプロジェクト ドキュメントをアーカイブおよび保存するタスクを手配し、各段階で詳細かつ包括的な情報とデータを収集し、プロジェクト全体を通じてドキュメントの正確性を確保する必要があります。パフォーマンスと可用性。

プロジェクト文書の整理と保管は、プロジェクト運営の全プロセスを通じて行われ、各リンクおよびサブサイトのプロジェクト文書の品質は、プロジェクトの最終段階での承認プロセスに重要な影響を与えます。図 9-8 は、プロジェクト ドキュメントを作成および整理する手順を簡単に示しています。

図 9-8 からわかるように、プロジェクト チームはプロジェクトの開始時に顧客とプロジェクト文書の仕様を決定し、顧客が文書の内容を理解しやすくするために顧客の視点から文書を作成する必要があります。アーカイブ作業は、プロジェクト運営のすべてのリンクおよびサイトで適時に完了する必要があり、プロジェクトの支払い回収に関する文書は、プロジェクト財務および関連する利害関係者に適時に提出する必要があります。