プロジェクトの見積りに惚れ込んでも大丈夫!

直面しよう。誰もが見積りを好むわけではないが、それは野菜のように我々にとって良いものだ!テリー・ボニオ氏は、あなたが次のプロジェクトに頭から跳躍する前に見積りを行うことのメリットについて説明している。 見積もりは、可視化の一形態である。使用することは、実際に飛行機で飛ぶ前のフライトシュミレーターの段階のように、詳細に状況を通して考えるように強制する。しかしブニオ氏は見積りとは起こるべき事を必ずしも約束するものではないことを警告している。それはプロジェクトの詳細が明確になるように、時間をかけて更新され、洗練されるべき推測なのだ。チーム全体によって構築された場合の見積もりも、焦点を加えることでプロジェクトに付加価値となる有益な議論を生む。実用的に実現可能ではない機能性を追求し、予算を無駄にしないように、最小の有望製品(MVP)はできる限り推定したいものだ。この議論の中心にあるのは戦略的なトレードオフのアイデアである。確かに、それは推定せずにプロジェクトを開始するにはより都合がよい。しかし、このポイントは、顧客は唯一のプロジェクトに焦点を当てることはないということだ。顧客が自らのポートフォリオ全体の費用と利益の比較を助長するために、管理上の観点からは、見積もりを行うことには意味がある。特定のプロジェクトが現在の予測に基づいて、見込みがないようであれば、そのMVPを超えた任意の資金は他の場所に割り当てることができる。 元の投稿₍英語₎はこちらからどうぞ: http://www.pmhut.com/why-i-like-estimates

続きを読みます »

ITベンチマーキングのための三つ又戦略

ITのベンチマークでは、誤った測定と分析プロセスは無意味か、あるいは誤解を招くような結果に終わることがある。戦略家のジョン・パーキンソン氏は、そのベンチマークによれば、あらゆる業界のトップパフォーマーの一つであった、ITグループでかつて勤務したことがあった。しかし、パーキンソンは、生産性を損なうことなく、約700名のグループの従業員数を250名まで削減するのを援助したことがある。その記事の中でパーキンソン氏は、3段階のプロセスであらゆるIT団体のべンチマークに使用することができる方法を説明している。 大手企業の最高情報責任者(CIO)は、かつて仲間に対して彼のIT組織をベンチマークするようにパーキンソン氏に求めたことがある。これほどの大企業をベンチマークすることにおける最大の課題は、それを比較するためにいくつかの同規模の組織があっても、さらに利用可能な選択肢の中から、その産業にとって有用な比較が生まれる可能性がある方法でも、無関係になることがあるということだ。 パーキンソン氏が考案したのは3本柱の解決策であった。まず、彼は公共のデータを利用し、主に迅速で定性的なベンチマークを行う上で同程度の規模と形態の約20社のグローバル企業を決定した。その目的は、CIOのグループと比較して他の企業が、同種なのかそれとも異種なのかを示すことができる、さまざまな規模の「マップ」の開発にあった。第二に、パーキンソン氏は、そのIT予算の売上高に合わせ、約50製品やサービスの組織を調べた。問題となっていた事業に類似したスケールで操業していながら最良な企業をベンチマークした。その後、パーキンンソン氏は変動が顧客体験にある場所を発見するため、他の部分に対するCIOのIT組織の各内部をベンチマークした。ここにあるのは、パーキンソン氏の言う戦略が非常に効果的であると言える理由である。 ベンチマークが適切に設計された場合、プロセス改善プログラムの効果の監視に、定期的に使用することができる。ベンチマークの対象とされた様々な団体はすべて単一組織のコンテキスト内であったため、独立した企業間の比較を行う外部変数の多くが困難であったか、または高価になってしまったことが要因ではないだろうか。さもなければ、よりたやすくコントロールすることができるだろう。 この戦略は確かにCIOにとって連続して略的計画に組み込まれた貴重な洞察を明らかにした。 元の投稿₍英語₎はこちらからどうぞ: http://ww2.cfo.com/it-value/2014/09/benchmarking-can-lead-astray/

続きを読みます »

複数の上司を管理するための専門家の忠告

昨今、一人の従業員が一名から七名の上司を持つことは珍しくない。七名ですよ! エイミー・ギャロ氏は、その全員を喜ばせるために何をすべきかについて、ハーバード・ビジネス・レビューのために書いている。 複数の上司を満足させる最も一般的な3つの課題は、仕事の過負荷、上司間でのメッセージの競合、あなたの忠誠心を薄く拡大することになる。幸い、ガロ氏はアドバイスを提供している。まず、あなたの主な上司が誰であるか知り、キャリアの見通しに影響を与えて、最も直接的にあなたのレビューを完了するその人を、最初になだめられるようにする。第二に、上司たちの活動を調整することで、自分の職務について積極的になり、自分のお皿の上にどれほどの時間が与えられているかをさりげなく知らせる事に加えて、可能ならば、上司を一つの部屋に集めて、自分のニーズについてお互いに議論してもらえば、あなたが常に大使になる必要はない。 それ以上に、あなたの一日が上司の中断という一定の流れによって中断されないように、あなたが中断を容認する時と頻度について境界を設定することを忘れないこと。通常、上司があなたの仕事の山にさらに多くの作業を追加したとしても、何も悪意によるものはない。それで、個人的に罰を受けないようにすること。 原文 (英語) はこちらからどうぞ: https://hbr.org/2011/08/managing-multiple-bosses.html

続きを読みます »

新しいプロジェクト管理者全員が実施すべき5項目

プロジェクト管理者(PM)にとって、日常の不満は不可避な事だ。ベテランのPMにはその仕組みの特殊点は分かっている。しかし、初心者のPMは、火で試されるほど物事が大変になることがよくある。そういう事態に備えるために、ポール・ネイバー氏は、以下の5つの技能を育てることを勧めている。: マルチレベルの通信 公における講義やプレゼンテーション リソースの実装 非技術的/批判的技能 定期的なチームの会合 おそらく、あなたは特定のレベルでのコミュニケーション法はマスターしているかもしれないが、優れたPMならば、幹部、チームメンバー、株主等、どの人とでも快適に話をする必要がある。第二に、あなたの仕事は確かにチームを主導することだ、だが、PMとして魅力的な情報を提供したり、利害関係者に自分のプロジェクトのアイデアを売るべき会社の会議に直面することもあるだろう。 適切なリソースをまとめる事は少なからず芸術的だ。優れたリソースを発見するには、一生懸命努力する事と同様に、適切な人々を知るための傾向が係わっている。急な学習曲線もあれば、最初から持ち併せているべき不可欠な技能でもある。技術的な技能ではある程度までしかいかない。だが口頭や書面によるコミュニケーション、意思決定、それに交渉技能は、自分の仕事を効果的に実行するには不可欠なことだ。最後に、定期的なチームの会合によって、効率的に情報を配信する時間の制約を設定し、リソースを割り当て、フィードバックを求め、ステークホルダーに更新事項を伝える自分の能力へのインパクトを過小評価してはならない。 原文 (英語) はこちらからどうぞ: http://www.projectaccelerator.co.uk/six-things-all-new-project-managers-should-do/3750

続きを読みます »

ITの生産性を増加する3つのステップ

誰もがビジネスでより生産的になると約束するが、そんな事はどれほど頻繁に起こるだろうか。しかし、ITはこの目標を達成することができる。トレブ・ガッテ (TREB Gatte) 氏は、ITがより多く産んでより良い結果を得るための3つの手順について書いている。すなわち、 正しい行動にのみ報いる。 断るべき時を知る。 非効率なことに耐えてはならない。 やりがいの結果に報いる事と努力に報いる事の間には大きな違いがある。ガッテ氏は、ITチームが取り組んでいたプロジェクトから完全に逸脱してしまい、そのプロジェクトをさらなる努力によって軌道に戻し、それがゆえにチームが報われ時の事を振り返った。問題は、チームが最初にベストプラクティスを無視したがために、逸脱してしまったことだ。その一方で、別のチームは中断することなく傑出した結果を出していたにもかかわらず、報いを受けなかった。それは公正なことだろうか。 そして、善意があっても、ITは常に誰をも幸福にすることはできない。 ITリーダーは、自分のチームのスケジュールが既にいっぱいであるのが分かっている時は、断る必要がある。幹部は、何で可能であり、何が不可能かを知っているリーダーを尊重し、無限な約束をしてもそのどれをも実現できない者は尊重しない。 最後の点について、ガッテ氏曰く、 皆さんの従業員は…仕事を達成すべく遅くまで残っているのだろうか。そんな人は彼らだけじゃない。2014年8月29日に行われたギャラップの世論調査では、給与所得者の半分が50時間以上働いている事が示唆された。この全労働時間のうち、効果的な生産性は週にわずか26時間まで低下した。精神的疲労が蓄積した挙句、ミスや不適切な意思決定が増加し、やり直しが増え、効果的な生産性は低下する。 誰もが定期的に残業をしている場合は、管理不行き届きや非効率的な処理が為されている証拠である。皆さんは自分を消耗せずワークフローを管理するために、より合理的で創造的な方法を考え出す必要がある。しっかりと睡眠を取って体を休ませた労働者は睡眠の足りない労働者よりも生産性が高いものだ。 原文 (英語) はこちらからどうぞ: http://www.cio.com/article/2913015/pmo/how-to-destroy-productivity-in-three-easy-steps.html

続きを読みます »

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

あなたがプロジェクトの範囲を時間通りに、それも予算内で完了した場合、あなたは成功したことになる。これは、プロジェクト管理で周知の三重の制約であり、これらの制約が我々の心の中に刻まれているかを確認することは常に興味深いものだ。『プロジェクト管理知識体系』(PMBOK)第5版は、現在の範囲、品質、スケジュール、予算、リソース、リスク(PMBOK, pp 6)の競合する制約について語っている。彼らのプロジェクト管理用語の競合する制約の概念の使用に、更新された分は非常に少ないようだ。 PMBOKは、セクション2.2.3(P 35)で競合の制約に基づいてプロジェクトの成功を定義している。 プロジェクトは本質的に一時的であるため、プロジェクトの成功は、プロジェクトマネージャと上級管理職の間で承認された範囲、時間、コスト、品質、リソース、リスクの制約内でプロジェクトを完了するという点で測定する必要がある。着手したプロジェクトの利益の実現を確約するため、試験期間 (サービスにおけるソフト起動など) は恒久的な操作に引き渡す前に、プロジェクトの総時間の一部とすることができる。プロジェクトの成功は、許可された利害関係者によって承認された最後のベースラインを参照すべきであろう。 現実の点検確認 我々はプロジェクト管理の成功率に関する多くの議論を参照している。残念ながら、上記の定義に基づく成功率は非常に低くなる傾向がある。この事実に最も頻繁に用いられる解決策は、以下のようなものと考えられる。 「我々がより多くの方法を実現することができれば、すべてが完璧になる。」 「我々がただより多くのより良いものを計画することができれば、すべてが完璧になる。」 「我々はより良い仕事をして、プロジェクトのスポンサーを持つことができれば、すべてが完璧になる。」 あなたが完全にこれら三つの解決策を実装できれば、おそらくよりうまく成功する可能性があるだろう。但し、与えられた成功の定義に基づくならば、我々は挑戦されたままの状態になる。解決策が期待どおりの結果をもたらさなかった場合は、分析を再考するのが賢明だ。 それは、PMBOKの成功の定義が不完全で幅が狭過ぎる可能性がある。とどのつまり、トリプル制約、または競合する制約には、ちょうどそういった制約があるからだ。それは動作のためのメトリックでしかない。これは重要であるが、他の実績のメトリックがプロジェクトの成功を測定するために使用されるべきだ。それは戦略的ではなく、価値とプロジェクトの利点を測定していない。 我々が運用メトリックを満たすために自らの能力を評価することによって、プロジェクト管理の成功を測定する際には、いくつかの奇妙な結果が起こる。 制約のために確立された数字を達成すれば、値を追加することよりも重要になる。 プロジェクトが利益を達成することは重要ではない。 戦略的議論の余地には、議論は非常に戦術的になる。 変更要求、技術革新、新しいアイデアは、それらがもたらす恩恵ではなくベースラインに対して評価される。 成功のより良い定義 我々は良いプロセスやプロジェクト管理の実践が必要だが、それら可能性を生み出すものである。プロジェクトの効率化をサポートするためのツールであって、プロジェクトの最終的な目標ではない。また、将来もそうはならない。さらに、戦略的目標を含めて、それを測定できることが重要だ。 当社のクライアントは、我々が彼らの特定の結果を達成するの​​を助けるために我々に支払いをしている。彼らが心の中でそのプロジェクトについて考えるとき、彼らはプロジェクトの利益に焦点を当てている。彼らは我々が専門家として適切な方法論を用いることを前提としているのだ。それでは、彼らがどのように考えるかを理解し、そのプロジェクトを表示してみよう。 プロジェクト管理者として、次の方法で、プロジェクトのさまざまな要素を評価するために、トリプル制約や競合する制約を越えて行く方が良い。 戦略:利害関係者への利点とプロジェクトの価値 運用:計画には通常さまざまな制約が伴う インフラ:プロジェクトに使用可能な、ツール、プロセス、ソフトウェア、および資源の質と妥当性 プロジェクト管理では、プロジェクト管理の方法論とその運用メトリックの値を受け入れることは非常に迅速なことが多い。しかし、専門職は、プロジェクト管理の戦略的なビューを採用で非常に遅い。我々はタスクの監督とタスクの実行などのプロジェクト管理の役割を狭くすることを好婿とが多い。 それだけでプロジェクト管理が世界の運用と戦術ビューを持っている場合、組織の戦略的ツールにすることはできない。 まとめ あなたの顧客は、プロジェクトが成功することを望んでいる。プロジェクトが開始されたのには理由がある。プロジェクトリーダーになり、それが何であるかを知っているかを確認していただきたい。運用メトリックは契約管理には良いが、顧客の満足度は、価値と成果の利益に基づいて行われるのだ。 プロジェクトのこの戦略的な面を持つていれば、我々はプロジェクトのすべての段階を管理する方法に重大な影響を与える顧客と対話し、変化に対応し、意思決定を行うことができる。

続きを読みます »

プロジェクトを遅らせる必要があるだろうか

ユニークなプロジェクトがその可能性を最大限に到達するために、もう数週間余計に必要とする場合、あなたはおそらくそれを許可する必要がある。では、プロジェクトの納期がすべて時間不足であるときはどうだろう。そんな場合はプロジェクトを延長することになる、とブルース·ベンソン氏は、取るべきオプションについて述べている。 ベンソン氏は、彼と彼のチームが競合より先に製品を市場に投入した最初の方法の話と関連付けている。それはかなりバグが多かったが、利用可能な唯一のオプションであったことと、また本当によく売れたのだ。だが、その後、競合が失われた時間を補って非常に高い品質の製品を出した。ベンソン氏の会社の新しいソフトウェアは、その基盤として最初にバグだらけのソフトウェアであったため、氏とそのチームにとって約束どおりに時期に新製品をリリースするのは難しく、一方、競合はそれを自分に有利に推し続けていたのだった。 ベンソン氏の会社のCEOは製品の配達を高速化することを望んでおり、一方、ベンソン氏は、既に12〜15カ月のウィンドウ内で約束した新製品の提供に対して、平均して18ヶ月かかっていたのに気づいた。彼らは明らかにまだない良い効果にこれをやっていたので、このシナリオでは、ベンソン氏は、プロジェクトの納期を遅らせることは助けになるとは信じていなかった。それどころかベンソン氏は、この解決策を思いついた。 我々は次の製品を通常開始するよりも3ヶ月前にそれを開始したのだ… 何が起こったのだろう。さて、この以前の我々のプロジェクト同様に、大変で危機に見舞われた、完成したときの違いは、顧客が我々の製品を受け入れてくれたことであり、それは約束した時間に間に合い、品質が向上していたからだった。- それも劇的な改善があったのだった。 原稿(英語)はこちらからどうぞ: http://pmtoolsthatwork.com/delaying-projects-lessons-learned-from-electronic-arts/

続きを読みます »

大企業のIT 2020年:予測と準備

TechRepublic誌のための記事で、パトリック·グレイ氏は2020年のIT環境のためのいくつかの大きな予測を行い、移行中に行動する方法についてアドバイスを提供している。 大企業のITに起こる変化のうちのいくつかは、エンドユーザーやビジネスユニットによる権限委譲、ITのセキュリティの強化とより高い応答性の要求、技術サプライヤーの影響の増加を挙げています。グレイ氏はOracleやSAPなどの企業に対する投影された最悪の予測は、ばったり倒れると述べている。なぜだろうか。古いメインフレームと1990年代のERPシステムの回復力を持つ大きなシステムは、単に気化しないことを証明している、と彼は指摘しているのだ。健全な証拠は携帯が面倒なレガシーシステムをアイデア神話とするほど、遥かに簡単な条件でプロにはOracleとのインターフェースが可能になっているという事実にある。 グレイ氏はさらにCIO(最高情報責任者)の役割に関する闘争の多くについては、CIOは以下の両陣営のどちらかに落ちることになり、今後数年間で、それ自体が解決されると予測している。 内部管理者は、ITセキュリティ、クラウド、およびSaaSのような内部の技術を主宰する。 多面的革新は、顧客向けのイノベーションに向けてマーケティングとの連携に注力して内部管理を外注する。 2020年までに崩壊する一つは、企業のネットワークだ。個々のアプリケーションや企業の周りにセキュリティの壁を構築するよりも。これらのアプローチから離れた根本的な変化が、クラウドの使用によって拍車をかけられて、従業員が生産性を失うことなく、さまざまなデバイスを使用して解放されることになるだろう。 原稿(英語)はこちらからどうぞ: http://www.techrepublic.com/article/enterprise-it-in-2020-predictions-and-preparation-tips/

続きを読みます »

遅延と予算オーバー?プロジェクト管理者の災害の回避の仕方

大規模なITプロジェクトを開始するということは、どこに出口を見つければ分からないまま長い暗いトンネルに入るようなものだ。これは、46億ポンドの資金で英国と仏国を結ぶ海峡トンネルに入って来て、オーバーシュートをその予算の80%で辛うじて管理したようなものである。フィリップ・モスコソ氏とジャウメリ・ベラ・セグラ氏は、プロジェクトのそういった運命を回避するための戦いのチャンスを与えるプロジェクト管理の方法論の適用について、フォーブス誌のために投稿している。 彼らはどのプロジェクトも一般的に、選択、定義、計画、実行監査、および完結行為という5段階のライフサイクルを通過するということが分かった。だが、伝統的なモデルには選択肢がある。会社が低コストの入札者が契約を授与された後で、そのコストを増加させることは、「コスト+インセンティブ費」として検討することができると見なしている。それは以下のように機能する。 顧客がプロジェクトの全体的な責任を保持し、その費用に利益の共有分を足して建築者に支払うこと約束した場合、双方が協働して、機能を向上させ、コストを削減し、作業を速く完了させるような革新的なソリューションの(やる気を起こさせる)インセンティブを作成する。 コストを削減する別の方法は、プロジェクトの側面を、価値を追加するもの、必要だが価値を増加しないもの、必要ではないが価値を追加するもの、タスク間で待ち時間がかかってしまうもの、の4つのカテゴリに分けてしまう。この最後の二つのカテゴリはできる限り外して、重要な支出だけが残るようにする。 原稿(英語)はこちらからどうぞ: http://www.forbes.com/sites/iese/2015/03/09/late-and-over-budget-a-method-to-avoid-project-management-disasters/

続きを読みます »

問題管理: お金が無駄に使われていませんか?

典型的なIT組織では、顧客と歩調を合わせ連携することについて話し合いがなされることが常となっています。多くの場合においては、このような話し合いは多くのIT関係者が大きな部屋に集まって、それが何を意味するのかを「考える」ことを話し合うことになってしまっています。そうではなく、実際に明らかにされなければならないことは、ITの全ての関係者が共通の事業目的に向かって事業主と協働するための戦略を話し合わなければならないことにあります。 サービス管理の観点からは、成功を必ず成就することができるようにするためには、まず水面下で実際に起こっていることを分析することから始める必要があります。事業を次のレベルに持ち上げることのできる私たちの能力に影響を及ぼすような出来事をすぐに指摘しがちですが、そうではなく、本当に指摘する必要があるのは、問題の原因が何であるのかを指摘することにあります。ここに問題管理が話し合いの中に入り込む必要性が出てくるのです。 問題管理についての話し合いとは実際のどのような点であるのかを説明するために、例を挙げて見て行くことにしましょう。 架空のビジネス あなたの顧客の事業目標の一つは、ITを含めた全事業部門の残業代を削減することにあります。 あなたはさまざまな出来事を活用していますが、現時点では正式な問題管理のプロセスはありません。 あなたのITオペレーションチームは8週間のオンコールローテーションになっています。 直面する問題点 このサポートチームは、誰かがエラーをクリアしてサービスを再スタートする必要があるようなアプリケーションの問題が毎週サービスコールとして発生しています。 毎回の「サービスコール」は最低でも1時間のサービスコール請求になっています。 このアプリケーション問題は、毎週、現地時間の午後6時から午後9時の間(時間外)に少なくとも一回の割合でサービスコールが発生しています。 四半期末になるとこのサービスコールは週二回に増えます。 このことによる影響はあなたの分析にとってはそう見る限りでは最小限のものになっており、しかもこのようなマイナーな中断によるサービスコールで追加収入になっています。 このことは何を意味するでしょうか? このサービスコールの平均を想定すると、これはこの問題で一年間で55~60時間のサービスコールになります。このような時間は誰も注意を傾けるような時間ではありません-但しお客様以外ではですが。お客様にとっては、この問題のサービスは特別の問題点、即ちダウンタイムとなるだろうと思われるところまでサービスに対する期待度が落ちてきてしまっています。これはあなたにとっては事態が悪く見えてしまいます! 問題管理者、即ち、この問題のプロセスを円滑に進めることのできる人を投入する必要があります。 この問題を取り扱ってきたオペレーションチームと問題管理者が事態を話し合った後、次のような事実が浮かび上がってきました: 分析はこの問題を取り上げたが、大きな問題とは見なさなかった(各人にすれば8週間に一度の問題であったので)。 分析は、このアプリケーションの問題は各々発生し解決されていたことを認識していなかった。 報告はこの種の問題を「探し出す」ように設定されていなかった。 4.  チームには別のサービスコールの残業代も含まれていたため、この問題の残業代が注意喚起を呼び起      こすことにはならなかった。 5.  この問題に対して責任を負うアプリケーションチームとの話し合いでは、チームはこのアプリの最新版にはいくつかの問題点がある可能性があることを認識していたが、現時点までこの問題に関して誰からも何の問題も聞いていなかったことが示されている。 どこから始める必要があるでしょうか? 顧客が何を求めているかを知っていると思い込むことを止める必要があります。お客様と協働することです。 事業の利害関係者と定期的に会合を持ち、サービスが目標どおりに提供されているかどうかを確認する必要があります。 ITの左手側は、右手側が行うことを知っていると思い込むことを止めなければなりません。コミュニケーションが鍵となります。ITの中で定期的に会合を持ち、顧客サービスに影響を及ぼしている問題点について話し合いをする必要があります。「お客様の手助けとなるためにお互いどのように助け合うことができるだろうか?」という点がテーマとなるべきです。 お客様が自分たちの事業成果を実現することができるための手助けとなるようにITをそれに合わす必要があります。より賢く働くことであり、よりハードにではないのです。事業と協働し、事業の求める成果を理解し、それをサポートするためにITの目標を合わせることが必要です。現在進行しているプロセス(ここの例では問題管理)を更に精緻化することはシンプルでなければなりません。サポートプロセスの観点からどの領域が改善されるべきかを見極める必要があります。 ここに挙げた例は非常にシンプルな性質のものですが、大局的に見た場合、何をすることができるかが示されています。別のケースでは、単にコミュニケーションの仕方を改善し、仕事の進め方を単純化するだけで、容易に解決できる問題点を見つけ出し、顧客に対するサービスを改善することが可能とする場合もあり得るでしょう。

続きを読みます »