プロジェクトマネジャーが犯す3つの大きな過ちとは?

プロジェクトマネジャー達は、プロジェクトチームのやる気を引き 出すこと、プロジェクトの利害関係者から協力を勝ち得ること、自分たちの努力にふさわしい結果を得ることに今もなお苦心していることが分かったと、プロ ジェクトリーダーシップのコーチを務めるスザーン・マッドセン(Susanne Madsen)は述べています。マッドセンはブログの中で、通常であれば非常に知能的に高いプロであるプロジェクトマネジャーでも苦心の種となる3つの大きな過ちを挙げています。 最大の過ち プロジェクトのチームメンバーを率いるのではなく、プロジェクトのタスクを管理してしまう 焦点が重要課題ではなく緊急を要する問題点に当てられてしまう 全ての問題点の解決に対応してしまう プロジェクトマネジャーがタスクを割り当ててスケジュールを作成することに集中すれば、そのプロジェクトは多分に成功することになるでしょう。しかし、何故このプロジェクトは重要なのかだとか、実際の人たちにどんな影響を及ぼすのだろうか、などとプロジェクトマネジャーが考えめぐらしたりしていると、誰か他の人によって創り出されたビジョンをプロジェクトを通して形あるものにすることではなく、ただ単にビジョンを実行することだけになってしまいます。 プロジェクトは期限厳守で遂行されるものです。集中力が奪われて しまうような問題点が発生すると、本来焦点を当てなければならない問題点に対する注意集中が置き去りにされてしまします。プロジェクトマネジャーは、翌月 のプロジェクトを正式に戦略化しなければならない時間を確保しようするがために、イーメールされてきた緊急の問題発生を無視することに罪悪感を感じるかも 知れません。しかし、マイナーな問題点が発生する度に果敢にそれらの問題点を回避しようと努めることによって「忙しそうに見える」という悪循環に陥ってし まうと、プロジェクトを苦しめるより深い問題点に対応するための時間を確保することは何時まで経っても永遠にできないくなってしまうでしょう。 もう一つの共通の過ちは、プロジェクトマネジャーはすべての回答 を欲しがり、すべてをコントロールしたがることです。このような進め方をすると、プロジェクトマネジャーはあらゆる決定を同時にすることになってしまい、 疲労困憊してしまうことは避けることはできません。更には、このようなやり方は、プロジェクトチームの個々のメンバーが自ら問題を解決し、全体の負担を 個々が負担するという理想の姿とは裏腹に、プロジェクトマネジャーから次の指示が来るまで何もしないで立っているというように、チームメンバーから個々の 権限を奪ってしまうという逆効果を生む結果となってしまします。 原文(英語)を読むには:http://www.pmhut.com/what-are-the-3-biggest-mistakes-that-project-managers-make

続きを読みます »

自分自身にウソをつくことを止める: リスク許容度の測り方

リスクを避ける、移転する、軽減する、又は受け入れる、等いずれかを決定する場合でも、全てのリスク対応戦略にはコストのリスクと内在 するリスクの二つが存在します。リスクを回避することは、通常の場合、機会コストをもたらす結果となるか、少なくとも利益が繰り延べられることになります が、内在するリスクは最小となる傾向にあるようです。例えば、スケジュールのリスクに対応する場合、スケジュールの範囲からある要素を取り除こうとするこ とは、リスクを回避することに当たりますが、この場合、その要素がもたらし得る利益を享受することができない機会コストが発生することになります。 リスク対応戦略の選択 私がこのことをここで論じる理由には、回避するか移転することができるようなリスクを軽減するか受け入れるこ とを選んでしまう組織や管理者が非常に多いことが挙げられます。それはより安全な対応策の認知コストに関することであるような場合も中にはあります。しか し、多くの場合は、異なる文化が混ざり合い、展開した後でたどり着く最終地点にまだ到達していないような吸収や合併が発生している組織の中に見ることがで きます。吸収合併以前の会社の一方はリスクに対する選好度がより高いかもしれませんし、中間管理職は吸収そのもを既に自分たちの中に取り入れてしまってい るかも知れません。或いはある特定の種類のリスクに対してはもう一方側の同僚たちよりも選好度がより高いのかも知れません。 昨年、私は、自分の会社よりも大きな会社に買収されようとしている会社と私の顧客として仕事をする機会がありました。その会社では、あ る一つの法的要件に順守していない状況が発覚する可能性を軽減することの目的のために、それが発覚することの可能性はほとんどないような状況だったにもか かわらずに、わざわざそのためにプロジェクトをスタートさせました。このプロジェクトのコストは、順守していないことが発覚した場合に発生し得るコスト や、既存のマニュアルのプロセスを改善するコストよりもはるかに高く付くものでした。しかし、このプロジェクトを決定した人にとっては、順守していないこ とのリスクを絶対に軽減しなければならないと思っていました。しかしながら、このプロジェクトはスケジュールと質の面からは非常にリスキーなものでした。 そのプロジェクトはその後開始されましたが、その会社はプロジェクトのキーとなる職務に比較的経験の浅いチームメンバーを任命し、その上、そのプロジェク トを遂行する上でどのような業務規定に沿うべきなのかについての社内コンセンサスが全くありませんでした。結局のところ、買収側の会社の経営幹部はこのプ ロジェクト廃止してしまいました。さまざまなリスクを一つにまとめたリスク全体に対する考え方が買収側の会社では大きく違っていましたし、内在するリスク のすべてに対応するのではなく、比較的コストが低く、影響度の小さなリスクとして受け入れてしまうことを決定したのです。 リスク選好度を測る リスク許容度を測ることは非常に難しいことであるし、それを意味のある言葉で説明することは更に難しいことです。あるインタビューの中で、私はプロジェクト管理室(PMO) の責任者にその方の組織のリスク許容度について尋ねたことがあります。その方は、そのような質問をされたことは今まで一度もなかったと言い、契約プロジェ クトの管理者としてふさわしい回答を見出すことに苦心していました。率直に言うと、どのレベルのリスクであれば許容できるかを説明できる人はほとんどいな いですし、リスクはまったく好まないと自ら認めるような組織はないということです。しかし、一まとまりのさまざまなリスクのコストを最適なレベルのものに することのできる能力は、組織が別の選択肢をどのように評価するかを理解できているかどうかによります。以上から、、リスク許容度を測るプロセスを始める ためのいくつかの質問を以下のように列記したいと思います: コストを軽減するためには、新規仕入先と進んで契約を結びますか? はい、であれば、リスク許容度がある程度高いと見られます。 自分の部下を増やすコストを削減するためには、派遣社員を雇うことによって離職率が高くなることを敢えて受け入れますか? はい、であれば、リスクをより進んで受け入れるタイプになります。 スケジュールどおりに完了するためには、質のリスクがより高くなることを進んで受け入れますか? もしプロジェクトが定められた完了日がない場合は、リスク許容度が高いことを示しています。 操業費を低く抑えるためには、設備費がより高くなくことを進んで許容しますか? はい、であれば、リスクを移転する意思と見られるかも知れません。 スケジュールのリスクを軽減するためには、完成させるものを進んで遅らせますか? はい、であれば、リスクを回避する意思と見られるかも知れません。 実行するリスクを軽減するためには、進んでプロジェクト管理をさらに複雑にしますか? これもリスクの移転に当たります。 上記リストは、特に全てを網羅しているものではありませんが、組織のリスク許容度についてある程度理解できるものと思いますし、或いは最低でも、提案されたプロジェクトに該当する組織の許容度を理解できるものと思います。

続きを読みます »

交代エージェントとしてのプロジェクトマネージャー

プロジェクトマネージャ(PM)は、変更の触媒です。そのため、リンダ・ボーンが、PMの変更を管理するために必要とされるさまざまな方法について説明します。 任意のPM 変更の最初のステップは、プロジェクトのスポンサーと変更マネージャーの責任を決定することです。その後、伝統的な変更管理は、新製品の開始のために、古 い製品から離れるに強い関心を培養するため、すべての利害関係者を準備する必要とする、起こります。それは、異なるスキルセットを必要とするため、2番目 のステップは、変更マネージャーではなく、PMの仕事です。 プロジェクトの活きを通じてのプロジェクトマネージャーの責任は変更マネージャーのニーズを認識し、利益を実現する機会を最大化するために、プロジェクトの作業を適応させることです。 プロジェクト変更管理プロセスは、PMが管理するための重要な「もの」です。そのプロジェクトチームのサポートの上で、PMが行う必要があります。 変更の特定:その変更は、必要とされるのか。もしくは、以前に発生したかどうか。 プロジェクトの目標に反面する効果が無いかを確認及び理解する。 変更に係る提言を準備する。 この変更を承認できる立場にいる人を見つける。(プロジェクトマネージャー、スポンサー、変更管理委員会   等) 確証と変更権限をサポートする。 承認または適切な変更をブロックすることにより、変更の結果を管理する。 変更管理と変更管理の違いは何であるか: 変更管理は、変更を管理するプロセスです。複数の変更は、単一の変更管理プロセスに沿って管理することができます。覚えておくべき重要な点は、アイデア、それがもう一方の端に出てくるときに利害関係者のニーズを満たす必要があり、プロセスの一端に入るということです。 (英語で)元の記事を読んでください。http://www.projectmanagement.com/blog/Voices-on-Project-Management/11493/

続きを読みます »

偉大なプロジェクトマネージャのトップ10の特徴

デビッド・C・ベイカー氏 はプロジェクトマネージャー(PM)のトップ2%になり、アンディー・クローが運営する研究について、’99U’のために書き込んでいます。 860のプールのうち、クローは、最高資質のトップ10に表示されています。 自然権威:リードする彼らの傾向が深く根付いており、彼らの永遠の楽観主義は、他の人の助けれるか。 •高速優先順位付け:データであふれた今の業界では、トップのPMは一瞬で学習する必要があるものだけを学ぶために、迅速で情報を取捨選択します。 焦点と再評価: 彼らは、必要ないE-メールの削除や、ミーティング、個人的なデータの入力など、様々なプライベートで大事な企業秘密を任せれていることを知っている。 仲間と華族へ: 最終PMは、どのような利害関係者との相互作用を最大限に活用する方法、また、彼らはコミュニケーションのスタイルを受信する方法を知っています。 公然に通信する: トップPMは、任意の責任を引っ張らないでください。むしろ、彼らはスタッフとの共同作業者との通知を保つために、明確で直接的な通信経路を取ります。 通信の制御: 偉大なPMは、プロジェクトの初期段階での成果にかわるコミュニケーションの予測可能なスケジュールを持っています。 適用された経験を保持する: 彼らは深くその電荷中の分野に精通し、戦略的優位性とリーダーシップの機会にこの知識を回します。 競合/コンセンサスのマスター: 本当に素晴らしいPMは、重要な取り組みから引き下がることなく、コンセンサスと拡散の競合を構築することができる。 社交通信者: 情報ネットワークは、それらのソースでプロジェクトへの脅威に対処するために、組織内と外で栽培されています。 仕事を愛す: 最大のPMに、プロジェクト管理のキャリア、報酬と課題は、同一です。 元の記事を読んでください(英語) ): http://99u.com/articles/6946/top-10-characteristics-of-great-project-managers

続きを読みます »

初めての企業家が犯す3つの大きな過ちを避ける方法

Entrepreneur誌の記事の中で、デイビッド・グリーンバーグCEOは自分がビジネスを始めたときに犯した3つの最悪の過ちを挙げています。 第一に、不適格な従業員を採用しないこと。最初は、自分の負担を軽くしようとすることだけを求めているために、誰でも適しているだろうと考えがちになります。それは間違い。例え少し高くついても、単純に適材である人を採用する必要があります。二番目に、事業を始めること自体は大変なこと。グリーンバーグは、自分の長所と短所を補完するような共同創始者を見つけ、そうすることによって頼ることのできる経験を2倍にすることを勧めています。そして三番目として、自分のアイデアを試したり守ろうするために多くのお金を使うのではなく、その代わりに、それとは全く逆に、アイデアを共有することを勧めています。そうすると、そのようなアイデアを完全なものにするために必要不可欠なフィードバックが直ぐに手に入ることができるようになります。加えて、自分が考えたアイデアなどは、多分に20人くらいの人がその前に既に考えているだろうから、違いはその実行にあるのです。 原文(英語)を読むには: http://www.entrepreneur.com/article/243630

続きを読みます »

突発事象管理を始めるための6つの秘訣

突発事象管理(IM)はミステリーではありません。IT専門家であるジョーが述べているように、何故IMをするのかは、実際にそれを行うのと同じくらい重要なことなのです。それは必要性から来るものであって、単にプロトコルから来るものではないのです。ジョーは自分のブログの中でIMを始める上での正しいやり方と正しい理由について6つの秘訣を説明しています。 「聞こえがよい」と理由でIMをしてはならない。 多分既にIMを行っている。 IMをする理由を考える。 IMをプロセスとしてではなくサービスとして見る。 専門用語に注意する。 顧客の目線で捕らえる。 IMを満たすべきプロトコルとして捕らえると、このことが分かります。ITはIMを顧客に対して外部的に提供するものとして使うため、そのことが何故それほど大きな意義を有するのかを理解することがまず重要です。正式なプロセスというものがない場合でも、大抵のビジネスとそれぞれのIT部門は、パスワードをの再設定、機能停止、その他不都合なハプニング等々、不可避な事態に対応する必要が出て来るために何らかの形のIMが必要となります。 [「何故IT管理をしているのだろうか?」という質問に対する]回答が、「ITが故障したときに直すため」であるなら、その質問についてもっと時間をかけて、もっと真剣に考えてみることを勧めます。突発事象は、技術的欠陥やITサービスが利用できないことなどよりもそれ以上のことであることは明らかなことではないですか? ジョーはITをプロセスとして見るのではなくサービスとして見るように勧めています。プロセスというものは人がその背後に回り、そのプロセスを使って顧客に優れたサービスを提供するためのものです。さらには、ITには「突発事象」があってしかるべきものなのでしょうか?勿論突発事象というものはITの中で管理しているものなのですが、顧客の観点からすると、それらは問題又は故障ということになります。経験則から言えば、IT専門用語を決して顧客に押し付けることがあってはならないということです。さて、IMにすっかり夢中になってしまう前に覚えておかなければなならなことは、あなたがしたいことをするのではなく、お客様が本当に必要としていることを実行することだけということです。 原文(英語)を読むには: http://www.joetheitguy.com/2014/12/05/12-tips-for-getting-started-with-incident-management-part-1/

続きを読みます »

モーレツ社員の結末は最悪のリーダー?

トップに上り詰めるためには、毎日を最大限に頑張って働かなければならないと思ってはいませんか?実は、どこかの時点で息抜きすることが大事なのですと、ハーバード・ビジネス・レビュー(Harvard Business Review)のロン・フリードマン(Ron Friedman)は勧めています。息抜きをすることによって、マネジャーやリーダーとしてのキャリアを生き残ることができるのです。それは以下のような理由からきています。 エグゼクティブ・コーチであるマーシャル・ゴールドスミス(Marshall Goldsmith)は自著の中で、自らのゴールに「取り憑かれる」ようになってしまうかのように常軌を逸した優れた業績を上げる人たちのメンタリティには賛成できないと述べています。それには、勝つことにこだわり過ぎたり、付加価値を付けることにこだわり過ぎたりする変わった考え方も関与していることもその中で述べています。問題は、成功することの価値ではなく、自分のキャリアの中で更に成功を収めるには息抜きすることが必要になる場合に、息抜きをすることができないことにあるのです。 結局のところ、身体的にも精神的にもストレス過剰となり、人と人との対人関係を処理する能力が欠けてしまうことにあります。専門能力において百戦錬磨のビジネス戦士が一旦は勝ち抜いたとしても、職位が上がるにつれて、今度は人との対人関係の手腕がものを言うようになってきます。フリードマンはそのことを次のように説明しています。 私たちは組織の中にあって職位が上であればあるほど、複雑な意思決定を迫られるようになります。研究の結果次のようなことが明らかになっています。不確実な状況の中をうまく舵取りしながらリスクに対応していかなければならない場合、私たちは疲れていると判断力が極端に落ちてしまいます。判断の選択肢が多くなればなるだけ、より多くのエネルギーを体内に蓄えておく必要があります。しかし、働き過ぎや働き過ぎから来る睡眠不足により問題点を明確に捉えることができなくなり、また創造的な問題解決策を見出すことができなくなってしまうのです。 原文(英語)を読むには: https://hbr.org/2014/12/working-too-hard-makes-leading-more-difficult

続きを読みます »

対人能力とあなた

私たちは多くの場合、対人能力というものはただ単に自分の履歴書に詰め込むようなものと考えがちです。実際にはその逆が真実なのです。対人能力はビジネスの世界では俗に言う土台となるものなのです。ミッシェル・ラブロッセ(Michelle Labrosse)は、そのような人との付き合い能力を磨く方法について幾つか助言を与えています。 対人能力は重要であり、プロの組織でもその重要性を認め始めています。これらの能力の中で最も重要なのは多分、リーダーシップ、チーム作り、そして動機付けであると思われます。対人関係に長けた人というのは、他人に恐怖心を植えつけるような手段を取らなくとも信頼感を勝ち得ることができ、それぞれに一番適した役割に人々を配置することができ、また動機付けとなるような様々な奨励策を適用することのできる術を身に付けているものなのです。 上に述べたような特質というもの全てには更に、効果的なコミュニケーション、正しい意思決定をする習慣、そして人に影響を与えかつ人を説得する才覚も求められます。適切なコミュニケーションというものは、どのようなチームであってもそのチームを固く結び付けるものであり、それは影響力というものが人を動機付けさせることができる人の重要な特性であるのと同じものなのです。 一人の管理者として注意を払うべきものの大半は対人能力にあるという論点を強固にするということは、他の重要な特質の大部分に匹敵することでもあるのです。人は世界の様々な問題点、即ち会社の権力闘争や文化を認識しなければなりません。人はまた、国際的な大使のように同僚たちの間に信頼感を築き上げ、軋轢をなくすよう努めなければならない一方で、異なる意見を認め合い、また業績の悪い人たちを優秀な業績へ引き上げるために指導しなければなりません。 原文(英文)を読むには: http://www.qualitydigest.com/inside/quality-insider-column/interpersonal-skills-and-you.html

続きを読みます »

ITプロジェクトが失敗する3つの要因

ITプロジェクトに対するビジネス要件は、「永遠に続くものを作り上げる」から「変更できるように設計する」へと目的が変わり、その結果、状況が複雑化してしまい、プロジェクトが憂慮すべき頻度で失敗する事態が生じています。パール・チュー(Pearl Zhu)はブログの中で、プロジェクトの失敗は3つの根本原因に起因するとしています: スポンサーのエゴ ロスの忌避 確率の無視 スポンサーというものは往々にして、成功する可能性を犠牲にしてでもプロジェクトが失敗しないように舵取りをしようと試みるものです。その理由はただ単にリスクを避けるという単純なものであるかも知れませんし、或いは、スポンサーが個人的利益を得る目的でプロジェクトを操作しているためのものであるかも知れません。別のシナリオとしては、プロジェクトのスポンサーが全ての必要とされる変更に喜んで関与し、監督するけれども、それは最初のうちだけというような状況です。それは、時間が経過するにつれて、スポンサーのプロジェクトに対する興味がその意気込みと後押しと共に薄れてしまうというものです。 顧客のためにプロジェクトを成功させると言うことは、言うは易し行なうは難しです。成功するための適切な物差しなくしては、プロジェクトチームは暗闇の中で火を灯すようにもなります: 必要とする要件、プロジェクトマネジャー、悪しき規範等々全てを列挙することはできますが、結局のところ、次のような3つの要因が絡み合ってプロジェクトは失敗に終わります:専門知識の欠如、停滞した又は時代遅れのIT能力、そして会社全体にわたるコミュニケーション体制が機能していないことが挙げられます。 ITプロジェクトの30%が完全に失敗すると推定されています。またプロジェクトの70%までが顧客の期待に応えることができないとも言われています。プロジェクトのリスクを適切に分析することは、失敗を防止するための第一のステップであることは勿論のことです。結局のところ、信じられないことが実際に発生してしまうことは避け得ないものであると言えるでしょう。 原文(英語)を読むには: http://futureofcio.blogspot.com/2015/01/three-aspects-of-it-project-failures.html

続きを読みます »

ITプロジェクトを打ち切るのは最後の手段としてのみ

それはプロジェクトマネジャーが考慮する最後の手段ですが、プロジェクトがコントロールできない状態に陥った場合は、最初に考慮されなければならないことです。メリー・シャックレット(Mary Shacklett)は何時の時点で問題となっているプロジェクトを打ち切るのかについて書いています。とは言え、関係者に打ち切りを告げる以前に、その問題のプロジェクトを生かすことのできる次善策や予防対策を考えることが必要です。 大きなプロジェクトが倒れてしまうことはよくあることです。いつのかの時点において、プロジェクトマネジャーは関係者に対して、「事態は悪くなっています。しかし、この破滅状態を救うためにできることはあります。」と勇気を持って告げなければならない時があります。思慮深いプロジェクトスポンサーであれば、状況を理解しプロジェクトマネジャーと共に事態を切り抜けようと試みるものです。 危機に陥っているプロジェクトを再起動させるための別のアプローチとしては、まずプロジェクトを前に進めることを一旦停止し、少し時間をかけてプロジェクトであるソフトウェアをバーチャル化してみることも挙げられます。バーチャル化することによって関係者に最終製品が現実的にどのようなものであるかを見てもらうことには多くの利点があります: 最終ビジネスユーザーが完成したソフトウェアの「承認テスト」を実施する時点になると、テストの後でITのところに戻って来て、「これは我々が期待していたものとは全く違うではないか!」と言うような場合は結構あるものです。そのような時点までには、相当の予想と期待が既にでき上がってしまっていますので、プロジェクトマネジャーの進退問題にもなりかねません。 現実には、ソフトウェア開発プロジェクトの実に45%が目標を達成することができていません。ソフトウェアが完成する以前に、プロジェクトのスポンサーにソフトウェアが完成した場合の姿を簡単に説明しておくだけでも、相当の時間と様々な資源を節約することが可能であることを考えてみると、このような統計は非常に破滅的なものであることがわかります。 原文(英語)を読むには: http://www.techrepublic.com/article/pull-the-plug-on-an-it-project-as-a-last-resort/

続きを読みます »