トッププロジェクトマネージャーの5つの不可欠な資質

公開: 2022-03-11

この記事の音声バージョンを聞く

トップPMであることはあなたを際立たせ、あなたがトップPMであると認められれば、あなたは高い需要があります。利害関係者はあなたをより信頼し、あなたと一緒に働きたいと思うでしょう、そして彼らはあなたのアドバイスにもっと耳を傾けるでしょう。あなたが構築を支援しているものが何であれ、トップPMは世界中の組織で常に需要があります。これは、トッププロジェクトマネージャーのいくつかの重要な資質のリストです。うまくいけば、彼らはあなたが一つになるか、あなたがすでにあなたの処分でこれらの習慣を持っているかどうかをチェックするのを助けるでしょう。

1.チーム内で信頼を築く

信頼はすべてのチームの重要な側面です。それは頻繁に話題になり、書かれていますが、プロジェクトの実行に関してはめったに見られません。プロジェクト管理プロセスにおける信頼の重要性は、さまざまなプロジェクト管理組織によっても認識されています。

国際プロジェクト管理協会は、プロジェクト、プログラム、ポートフォリオ管理における個々の能力の世界標準であるICB4認定への信頼に関するセクションを含めました。

同様に、スクラムの経験論の3つの柱は、信頼が経験的なプロジェクト管理を維持するための3つの最も重要な要素の1つであるという考えに長い間基づいていました。信頼を構築する同じ傾向は、LEANおよびその他の従来のプロジェクト管理方法論にも見られます。これが長い間このような差し迫ったトピックであった場合、PMがチーム内で真の信頼を確立することを妨げる主な阻害要因は何ですか？

この質問に対する最も頻繁な答えの1つは、「文化のせい」です。信頼文化を実現するための鍵は、この文化から離れ、代わりにすべての間違いを学習の機会に移すことです。

これを実現するために、PMは、チームメンバーが自分自身を表現して間違いを犯すことができる環境でほとんどの人がはるかに優れたパフォーマンスを発揮するため、チーム内の透明性と快適さの適切な環境を促進する必要があります。

トップPMは、チームと一緒に生活し、間違いを共有することを奨励し、学習の例に変えることで、例によってチームにこれらの原則を教えます。トップPMは、謙虚さと脆弱性を示すことが強さの表れであることを認識しています。特に自分の過ちを認めるということになると、人々は防御的になったり、責任を転嫁したりする傾向があることはよくあることです。あなたが間違いを犯したことと、なぜあなたが傷つきやすいと感じることができるのかを説明しますが、これらの間違いを公然と認めて分析する場合、この習慣は他の人が将来それを回避するのに役立ち、誰もが信頼を築き、彼らのスリップアップについてオープンにするのに役立ちます。たとえば、主要な利害関係者に可能な限り早くマイルストーンを完了することを約束しすぎた場合、その主題についての技術的な深さが不足しているため、チームに間違いを認め、非難するのではなく、物事を誤って評価したことを彼らに知らせてください。彼らはあなたが望むほど速く技術を提供しなかったためです。これにより、他の人があなたやそのチームメートとのより強いつながりを築き上げることができます。

チームメンバーを理解します：彼らの能力、恐れ、欲求不満、彼らが好きか嫌いか、そして彼らが他の人々とどのように相互作用するか。チームメンバーが自分が大切にされていると感じたとき、彼らはより簡単に価値を提供します。チームを目的に向かって強制的にプッシュするのではなく、目前のタスクでチームをやる気にさせる方法を見つけます。そのためには、プロジェクトとプロジェクトチームの役割と責任の成功がどのように見えるかを明確に説明しますが、その後、彼らをそれぞれの分野の専門家にします。チームメンバーが何をする必要があるかを教えてくれることを期待してください。それらに耳を傾け、意思決定を分散化してチームに力を与えますが、必要に応じて難しい決定を下す準備をしてください。

結局のところ、あなたのチームはあなたが従事するためにそこにいます。あまりにも多くのPMは、タスクの作成に直接飛び込み、その責任を自分で取りすぎるという間違いを犯します。これは、これらのチーム内の信頼と理解の欠如が原因で発生することがあります。チームの信頼を得るときは、チームが作業の範囲を定め、ユーザーストーリーを作成し、一般的に重要だと感じる問題についてアドバイスを提供することに関与するようにしてください。

トップPMは、チームが彼らの最高の資産であることを認識し、それぞれの機会を利用して彼らとの強力な関係を構築します。交渉者および進行役になりますが、何よりもまず、チームと一体になります。彼らはあなたが彼らと一緒に働いているかのように感じる必要があり、上の誰かのためではありません。これは、この記事のより技術的なヒントの前兆です。この信頼がないと、プロジェクトで一連の問題が発生する可能性があります。

重要なポイント：「誰もが間違いを犯していることを示してもかまいません。 あなたが間違いを犯したときにあなたの間違いを共有し、あなたが彼らの側にいることをあなたのチームに示し、あなたのチーム内の信頼を優先させてください。」

2.利害関係者を関与させて、彼らが本当に必要としているものを手に入れます

PMとして、あなたはおそらく、多くのソフトウェアプロジェクトが、利害関係者が望んでいた、または必要としていたもの以外のものを提供することになるという事実をよく知っています。この問題は多くの異なる要因によるものであり、この問題を解決しようとする一連の新しい方法論を生み出しました。

しかし、アジャイル開発の時代でさえ、私たちはまだ時々間違ったものを構築するという罠に陥ります。利害関係者の分析は不可欠ですが、多くの場合、間違った質問から始まります。「なぜこれを行うのか」という質問をせずに、多くのプロジェクトが開始され、誤って定義され、実際のビジネスニーズに対応できなかったソリューションに向けて構築するという罠に陥ります。

「なぜ」と併せて、トップPMは「誰に」のフォローアップを依頼する必要があります。ソリューションを提供するために、どの利害関係者をサポートして、彼らの「理由」をカバーしていますか？

ここで、トップPMが重要な違いを認識します。ソリューションは成果物または成果物として定義できますが、トップPMは、ソリューション自体が必ずしも元のビジネスニーズをカバーするとは限らないことを理解しています。たとえば、利害関係者がビジネスニーズがERPシステムの実装であると考える場合、PMは、ERPなどのソリューションを使用する背後にある実際のビジネスニーズを明らかにするのを支援する必要があります。 ERP自体はソリューションであり、ビジネスニーズではありません。

真のビジネスニーズを認識するには、コンテキストと利害関係者、彼らの態度、権力または影響力のレベル、関心のレベル、プロジェクトへの影響、プロジェクトの影響、懸念、そしてもちろん、彼らが何を受け入れるかについての深い理解が必要です。プロジェクトの成功。

したがって、プロジェクトを目的の達成に成功させるために、ビジネス目標に影響を与えるソリューションを作成するプロジェクトマネージャーの責任は、ソリューションの作成自体を超えて、ソリューションが実行される場所にまで拡大し、実際に生成された価値が期待される目的と一致するかどうかを明確に測定します。目標の定義で。

PMは、プロセス全体を通じてプロジェクトを提供することの真のメリットは、実際のビジネスニーズ、目標、および目的に合わせて調整する必要があることを常に念頭に置く必要があります。

開発や要件の変更の最中にビジネス目標が忘れられることがよくあります。多くの場合、プロジェクトは機能的な製品を提供することになり、最初に製品の開発を促した実際のビジネスニーズの一部を解決しますが、すべてを解決するわけではありません。これは、利害関係者が適切に管理され、製品の反復が頻繁に提示される場合に防ぐことができます。

トップPMはまた、プロジェクトを主導する上での彼らの役割を認識しており、したがって、利害関係者がプロジェクトの開始時にすべての要件を伝達することを期待していません。彼らは、一部の利害関係者が自分たちのニーズを明確にする方法を常に知っているとは限らないことを理解しており、要件の引き出しからプロジェクトの実施に至るまで、利害関係者が自分たちのニーズを明確にするのを支援するのが彼らの役割です。要件を引き出すプロセスでは、利害関係者からの要件だけでなく、その懸念も引き出す必要があることを覚えておくことも重要です。

たとえば、成熟度の低い組織では、新しいプロジェクトの開始時に興味深いパラドックスが発生することがよくあります。プロジェクトの初期化フェーズでは、開発チームは、利害関係者が開発先のソリューションのすべての要件とニーズを明確に特定することを期待しています。同時に、利害関係者は、配信チームが時間とコストの両方で正確な見積もりを提供することを期待しています。

ただし、プロジェクトのスコーピングの開始時に、これらの見積もりを確定するには不確実性が多すぎます。そうすることで、非現実的な見積もりを作成する危険があります。時には、利害関係者は、現在あまり具体的でないソリューションの不確実性に対応するために、可能な限り多くの要件を含めます。その間、配達チームは未知のもののための非常に概算の見積もりを提供します。

この結果は、利害関係者が利用する完全な要件の20％しか得られないソリューションになる可能性が最も高いでしょう。残りの部分は、プロジェクトの予算を超過し、スケジュールを超過することを念頭に置いて、明確な目標を設定せずに開発されます。

幸いなことに、トップPMは、利害関係者を関与させ、プロジェクトのVUCA（変動性、不確実性、複雑性、およびあいまいさ）の世界の各ステップを通じて利害関係者を導く方法を正確に知っています。プロジェクトマネージャーは、プロジェクトをより具体的な増分に分割し、関係者を関与させながら、学習全体を積極的に作成およびレビューすることができます。

ここで重要なポイントは次のとおりです。「ソリューションはビジネスニーズを解決するために構築されています。PMは、プロジェクトの作成時にこの目標を逃さないようにする必要があります。利害関係者が彼らのコアニーズと懸念に対処するために彼らと関わることによって、正しいものを構築したいと思っていることを確認してください。」

3.プロジェクトのリスク管理を有機的な演習にする

ほとんどのプロジェクトには、プロジェクトの初期化の開始時に発生する一連の一般的なリスクがあります。

ほとんどすべてのプロジェクトは、変更に対するユーザーの抵抗、リソースの不足、未成熟なテクノロジーなど、これらの一般的なリスクから始まります。トップPMは、チームを関与させて、一般的なリスクだけでなく、最も差し迫った固有のリスクを特定します。これにより、リスクの特定は、プロジェクトの開始時の面倒な作業ではなく、プロジェクトのライフサイクル全体にわたる反射的なものになります。

リスクを認識する際に、トップPMは、主要な利害関係者とのコラボレーションにも目を向けます。主要な利害関係者は、要件や懸念事項にリスクを明示的または暗黙的に定義することがよくあります。優れたPMは、このプロセスが要件の引き出しステップからプロジェクトのライフサイクル全体に至るまで行われることを理解しており、これをプロセス全体のリスクを定義するための資産と見なしています。

専門家のPMはまた、チームを信頼し、専門家の知識をリスク軽減の源として認識しています。チームメンバーがリスクを積極的に特定できるようにするために、PMは、チームがプロジェクトの所有権を取得し、リスクの特定と管理に積極的に参加できるようにします。

実際には、毎日のスタンドアップでの3番目の質問は、「何が邪魔になっているのですか？」です。チームがプロジェクトの成功に貢献する権限を与えられているため、より慎重な対応が反映されます。もちろん、一部のブロッカーは一時的であるか、スクラムの直後に削除される場合がありますが、一部は潜在的な候補であり、実質的なリスクに発展する可能性があります。チームメンバーは、これらの潜在的なリスクを特定するように奨励される必要があり、プロジェクトのライフサイクルの最後でも見下すのではなく、それらのリスクが含まれることを祝う必要があります。

リスクの認識も、リスクを述べて前進するほど単純ではありません。リスク認識は、確率、重大度、および時々忘れられるメトリック、つまり近接性の観点から定期的に評価する必要があります。後者のメトリックにより、チームは、「次のリスク認識ステップまで何もしない」か、リスクがより近くにある場合はより具体的な何かであるかにかかわらず、適切なアクションアイテムを定義できます。ここで認識しておくべき重要なことは、リスクが管理されていない場合、リスクは役に立たないため、トップPMはリスクを実行可能にする方法を理解しているということです。さらに、アクションアイテムのリストは、事後対応的であるだけでなく、本質的に事前対応的である必要があり、最終的にはリスク調整済み製品バックログに通知します。

要するに、トップPMは、経験や権限に関係なく、リスクの認識と管理の単一の情報源ではなく、またそうすべきではないことを認識しています。利害関係者、そのチーム、およびその他の重要なプロジェクト貢献者は、初期段階だけでなく、プロジェクトのライフサイクル全体を通じて定期的にリスクの認識と管理に関与する必要があります。プロジェクトの開始時に特定されたが、それ以降は管理されていないリスクの使用はほとんどないため、これは重要です。

ここで重要なポイントは次のとおりです。「プロジェクト管理を成功させるには、チーム全体がリスクの特定に責任を持つ必要があります。 リスクの発見は、プロジェクトの全期間を通じて行われる継続的なプロセスでなければなりません。」

4.環境を理解する

トップPMは、中国の店で雄牛のようなプロジェクトを開始するべきではありません。プロジェクトマネージャーは、方法論やプロジェクトアプローチを強制するのではなく、手元にある環境、正式な構造、非公式な構造、文化、習慣、ツール、機能、および組織資産の詳細な分析を実行する必要があります。そうして初めて、彼は変化の旅を始めることができます。

どのPMも、自分たちが行っているプロジェクトが組織に影響を与えることを理解していますが、トップPMは、組織が同様に自分たちのプロジェクトに影響を与えることを認識しています。

欠陥のある、万能の考え方の代わりに、トップPMは、環境を理解することによってアプローチを調整します。そうすることで、最も差し迫ったビジネスニーズ、組織がソリューションをどのように適応または受け入れるか、採用、および目標の達成に適切に適合するためにソリューションにどのような変更が加えられるかをよりよく認識できるようになります。

効果的なプロジェクト管理アプローチを調整する一方で、トップPMは、さまざまなPMアプローチだけでなく、ビジネス分析方法論、変更管理フレームワーク、エンタープライズアーキテクチャフレームワーク、およびその他の有用な分析方法についても、さまざまな方法論を深く理解している必要があります。これにより、PMは、自分たちが取り組んでいるプロジェクトを遂行するために、手元にある会社に最適なソリューションを見つけることができます。

たとえば、非常に厳格な階層組織でプロジェクトを開始する場合、さまざまな承認レベルがあり、最適なアプローチは、混合またはハイブリッドのプロジェクト管理アプローチです。構造化された要件の引き出しフェーズを実行し、要件の承認を事前に行ってから、プロジェクトを正式なステージゲートを使用してステージに分割することができます。並行して、PMは、開発チーム内にアジャイルのような反復実行を設定して、より伝統的なプロジェクトを実行しているにもかかわらず、反復開発のベストプラクティスをキャプチャすることができます。

要約すると、トップPMは企業文化を尊重し、プロジェクト管理慣行を改善するための新しいアプローチとコーチング組織を尊重します。彼らは、多くの組織がさまざまな成熟点にあり、変化への準備が整っていることを認識しており、プロジェクト管理のベストプラクティスを実装する各企業の能力にプラスの影響を与える脅威ではなく機会と見なしています。

ここで重要なポイントは次のとおりです。「プロジェクトマネージャーは、自分のアジェンダを盲目的にプッシュするのではなく、組織の働き方に適応し、必要に応じてゆっくりと変更を提供する必要があります。」

5.リーン原則の適用

トップPMは、旅が目標と同じくらい重要であることを知っています。時々、プロジェクトの旅は、物事がどのように行われるべきかを定義するプロセスによって特に面倒になります。これは、不必要に重いテンプレート、無意味な会議、または旅を妨げる周辺機器の邪魔になる可能性がありますが、これらの障害がチームにできるだけ影響を与えないようにするのはPMとしてのあなたの責任です。

トップPMは、LEAN方法論で明確に定義されたアジャイルプロジェクト管理の原則に基づいて、チームにとってより効率的で効果的なプロセスを特定する必要があります。

よくある誤解は、LEANは製造にのみ適しているというものですが、これは単に真実ではありません。 LEANプロジェクト管理方法は、すべてのプロジェクトとすべてのプロセスを強化できます。これは単なるコスト削減プログラムではなく、チームのために考え、行動する方法です。

リーン生産方式を適用することの利点は、トヨタのCEOである渡辺捷明氏の言葉に要約されています。「優れたプロセス管理は私たちの戦略です。私たちは、素晴らしいプロセスを管理している平均的な人々から素晴らしい結果を得ています。 競合他社は、壊れたプロセスを管理している優秀な人々から平均的な（またはさらに悪い）結果を得ることがよくあります。」

不必要なプロジェクトのノイズと作業を排除するためのバイアスを持つトップPMは、当然、プロセスをLEANの原則に向けて推進します。トップPMは、プロダクトオーナー、そのチーム、および関連する利害関係者と緊密に連携して、ニーズとそれらのニーズへの対応としての期待値を合理化および指定できるようにする必要があります。

プロジェクトのベストPMプラクティスを借用するために、LEANを超えて検討することも役立ちます。たとえば、PRINCE2方法論だけが、プロジェクトの開始段階で学んだ教訓を取り込むという義務的なタスクを持っています。これは、プロジェクトの最後に新しいドキュメントを開始するときに他の人がほとんど使用しないドキュメントを作成するのではなく、以前のプロジェクトから学んだすべての教訓をキャプチャします。不必要なステップを排除し、真の価値を付加するステップに焦点を合わせるために、プロセスを変更することを恐れないことが重要です。

これは、プロセスを支援および再形成するため、またはチームが最初から適切なプロセスを選択するのを支援するための良い機会です。これらの明確なパフォーマンス指標は、プロジェクトの成功の明確なガイドを定義するために、関係者全員と透過的に共有する必要があります。

ここで重要なポイントは次のとおりです。「適切なソリューションを見つけることは、それらのソリューションを提供するための適切な合理化されたプロセスを持つことと同じくらい重要です。」