Michel Dion

Michel Dion is a CPA and PMP, living in Ottawa, Canada with his wife and 2 kids. He also has a certification in Internal Audit (CIA), Risk Management (CRMA) and Fraud (CFE). Michel has managed in his career many projects, including special initiatives and emergency projects. He is developing a website called Project-Aria, and is very active in the project management community on the web. The key areas of focus of Project-Aria are project management, leadership, productivity, mind and health, and career and training. He has loved technology since the moment he played on the TRS80 a while ago. Despite that, his two sons insist that they know more about technology than him. Sometimes, he will comment on other subjects, as he likes fitness, travel, chess, photography, and music. He also has a goal of mastering four languages: English, French, Spanish and Swedish. Pay Michel a visit at Project-Aria by clicking the button below.
  • リスク管理

    プロジェクトの複雑さ:プロジェクトを台無しにする変数の監視

    プロジェクト管理にあまりにも頻繁に起こることは、一つの単純なモデルを選択し、すべてのプロジェクト管理に適用させることである。プロジェクト管理者がこんなアプローチを使用すると、すべてのプロセスにそれが完全で平等に使用されることになるので、すべてのプロジェクトの実装は即座に支障をきたし始めてしまう。モデルが単純過ぎるということは、判断力が無く、分析力も無く、ツール使用のずれ弾性率も無いということになる。 モデル 対 現実 理論的には、すべてのツールとプロセスは適切であるので、それらを使用することは合理的な選択となるはずである。また、それはプロジェクトをビジネスの方法論に完全に準拠させるはずだ。ところが残念ながら、そんな盲目的な実装では、プロジェクトに適応する柔軟性は欠けてしまう。 我々は、プロジェクト管理の美しさは、異なる分野で、異なるコンテキストにおいて、異なる大きさのプロジェクトのために使用され得ることにあるのを知っている。それは、大規模な建設プロジェクトや、ソフトウェアデザインプロジェクト、技術革新的なプロジェクト、あるいは非常に小さなチームによる研究調査でもありうる。このように、プロジェクト管理理論は、プロジェクトの非常に広い範囲に有用であるように明確に設計されている。 しかし、それぞれのプロジェクトにはユニークで独自の要件が独自のコンテキストに内在している。プロジェクトの成否は、そのコンテキストの現実内で起こる。我々のプロジェクト計画とアプローチを現実に合わせて設計することは重要だ。 すべてのプロジェクトが同じプロファイルを持っているわけではない。すべてのプロセスを盲目的に適用することは、プロジェクトのあらゆるコンポーネントが複雑だと仮定していることになる。 プロジェクトの複雑さの評価 戦略的なプロジェクトリーダーとして、扱っているプロジェクトの複雑さを理解することは不可欠だ。それによって、適切なプロジェクト計画の開発に役立ち、プロジェクトチームを作成し、監視と進行を制御するアプローチを最適化することができる。 非常に類似したプロジェクトを幸運にも実行することもできる。それでも、まだ2つのプロジェクトがまったく同じであることは、非常に稀であることを注意しておこうと思う。各プロジェクトの複雑さのプロファイルは異なっている可能性がある。仮定する罠に陥らないことは重要だ。それなら、プロジェクトを評価して複雑さのプロファイルを確立する方がはるかに優れている。少なくとも、戦略的な選択肢は意図的なものであって、仮定に基づいてはいないのだ。 複雑さの要素 私は計画段階で、プロジェクトの複雑さのプロファイルを開発するのが好きだ。それは、そのプロジェクトの必要に合わせて、適切なツールや技術を選択するようにプロジェクトチームを導いてくれるからだ。また、特別な注意が必要な中枢要素を識別してくれる。これらの要素を意図的かつ積極的に対処することによって、我々の行動はより戦略的になり、顧客、スポンサー、そして様々な利害関係者にとって価値が増加されることになる。 ここに各プロジェクトにおいて考慮すべき複雑さの要素のいくつかを挙げておく。それらを監視すれば、プロジェクトのライフサイクル全体を通じて、あなたやあなたのチームを導く複雑プロファイルが作成される。 法的環境 市場における競争の激しさ 革新レベル プロジェクトチームの規模 主題の専門家を含め、全体としてのプロジェクトチームが必要とする能力 調達活動…

    Read More »
  • プロジェクト管理

    プロジェクト管理の成功を再定義

    あなたがプロジェクトの範囲を時間通りに、それも予算内で完了した場合、あなたは成功したことになる。これは、プロジェクト管理で周知の三重の制約であり、これらの制約が我々の心の中に刻まれているかを確認することは常に興味深いものだ。『プロジェクト管理知識体系』(PMBOK)第5版は、現在の範囲、品質、スケジュール、予算、リソース、リスク(PMBOK, pp 6)の競合する制約について語っている。彼らのプロジェクト管理用語の競合する制約の概念の使用に、更新された分は非常に少ないようだ。 PMBOKは、セクション2.2.3(P 35)で競合の制約に基づいてプロジェクトの成功を定義している。 プロジェクトは本質的に一時的であるため、プロジェクトの成功は、プロジェクトマネージャと上級管理職の間で承認された範囲、時間、コスト、品質、リソース、リスクの制約内でプロジェクトを完了するという点で測定する必要がある。着手したプロジェクトの利益の実現を確約するため、試験期間 (サービスにおけるソフト起動など) は恒久的な操作に引き渡す前に、プロジェクトの総時間の一部とすることができる。プロジェクトの成功は、許可された利害関係者によって承認された最後のベースラインを参照すべきであろう。 現実の点検確認 我々はプロジェクト管理の成功率に関する多くの議論を参照している。残念ながら、上記の定義に基づく成功率は非常に低くなる傾向がある。この事実に最も頻繁に用いられる解決策は、以下のようなものと考えられる。 「我々がより多くの方法を実現することができれば、すべてが完璧になる。」 「我々がただより多くのより良いものを計画することができれば、すべてが完璧になる。」 「我々はより良い仕事をして、プロジェクトのスポンサーを持つことができれば、すべてが完璧になる。」 あなたが完全にこれら三つの解決策を実装できれば、おそらくよりうまく成功する可能性があるだろう。但し、与えられた成功の定義に基づくならば、我々は挑戦されたままの状態になる。解決策が期待どおりの結果をもたらさなかった場合は、分析を再考するのが賢明だ。 それは、PMBOKの成功の定義が不完全で幅が狭過ぎる可能性がある。とどのつまり、トリプル制約、または競合する制約には、ちょうどそういった制約があるからだ。それは動作のためのメトリックでしかない。これは重要であるが、他の実績のメトリックがプロジェクトの成功を測定するために使用されるべきだ。それは戦略的ではなく、価値とプロジェクトの利点を測定していない。 我々が運用メトリックを満たすために自らの能力を評価することによって、プロジェクト管理の成功を測定する際には、いくつかの奇妙な結果が起こる。 制約のために確立された数字を達成すれば、値を追加することよりも重要になる。 プロジェクトが利益を達成することは重要ではない。 戦略的議論の余地には、議論は非常に戦術的になる。 変更要求、技術革新、新しいアイデアは、それらがもたらす恩恵ではなくベースラインに対して評価される。…

    Read More »
Close

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.