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

ユニークなプロジェクトがその可能性を最大限に到達するために、もう数週間余計に必要とする場合、あなたはおそらくそれを許可する必要がある。では、プロジェクトの納期がすべて時間不足であるときはどうだろう。そんな場合はプロジェクトを延長することになる、とブルース·ベンソン氏は、取るべきオプションについて述べている。 ベンソン氏は、彼と彼のチームが競合より先に製品を市場に投入した最初の方法の話と関連付けている。それはかなりバグが多かったが、利用可能な唯一のオプションであったことと、また本当によく売れたのだ。だが、その後、競合が失われた時間を補って非常に高い品質の製品を出した。ベンソン氏の会社の新しいソフトウェアは、その基盤として最初にバグだらけのソフトウェアであったため、氏とそのチームにとって約束どおりに時期に新製品をリリースするのは難しく、一方、競合はそれを自分に有利に推し続けていたのだった。 ベンソン氏の会社の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の目標を合わせることが必要です。現在進行しているプロセス(ここの例では問題管理)を更に精緻化することはシンプルでなければなりません。サポートプロセスの観点からどの領域が改善されるべきかを見極める必要があります。 ここに挙げた例は非常にシンプルな性質のものですが、大局的に見た場合、何をすることができるかが示されています。別のケースでは、単にコミュニケーションの仕方を改善し、仕事の進め方を単純化するだけで、容易に解決できる問題点を見つけ出し、顧客に対するサービスを改善することが可能とする場合もあり得るでしょう。

続きを読みます »

プロジェクトリーダーシップの陰と陽

多くの人々は、仕事や人生いずれにしろ〝バランス”について話そうと試み、大抵はでっち上げて終わります。スサンネ・マデッセン(Susanne Madsen)はそのような過ちを犯していません。彼女は陰と陽のコンセプトを適用してプロジェクトの卓越性を達成しており、実際的助言でそうしています。 マデッセンはプロジェクトチーム管理への二つの補完的方法に集中させるために陰陽コンセプトを使います。”陰”のアプローチは支援、安定、尊敬を強調します。それは個人の精神力とモチベーションを引き出し、チームを統合し士気を高めようとするより育成的なマネジメントスタイルです。”陽”のアプローチは責任、事実解明、高水準設定を重視ます。どちらか一方のアプローチに偏りすぎて学ぶよりは、それらを等しく混ぜて学ぶことを彼女は推奨しています。 陰の活動: リスニング、支援、コーチング、安定した職場環境の提供、自信を育む 陽の活動: 厄介な質問を投げかける、チームメンバーに責任を課す、結果の要求、道理をわきまえる 陰と陽をグラフの縦軸と横軸として配置して、マデッセンはプロジェクトマネージャーに関連する4つのカテゴリーを作っています。陰カテゴリーに重きを置き過ぎるリーダーはプロジェクト環境での自己満足を促進します。陽側に強き重きを置きすぎると、チームメンバーにはストレスの多い人生を作り出し、最終的には生産性を削り取ることになります。どちらかの要素がなければ、プロジェクトマネージャーは仕事を適切にこなすことができません。しかし、これら要素が組み合わされた場合、彼らはサポートを受け試されているという両方の気持ちを持つチームにかなり従事します。マデッセンは以下を結論づけています: チームは陰と陽両方の動的引力を必要とし、またリーダーはその二つを調和させる必要があります。リーダーシップとは 、“どちらか一方/または”に関してではなく、“および”に関してなのです。私たちは可能にし続けて力強く; 許し続け要求し続ける; 柔軟性がありしぶとい;協力的であり挑戦的でいなければならないのです。 原文投稿を一読ください(英語): http://www.susannemadsen.co.uk/blog/provide-your-team-with-the-best-conditions-for-growth-the-yin-and-yang-of-project-leadershiptm

続きを読みます »

ナレッジマネジメントへ”イエス“と言う

世間一般の通年はナレッジマネジメント(KM)に関連する最も深刻な問題が明確にされていること私たちに信じさせています。IT青年のジョーはわかりません。彼は該当する知識の見極めから知識共有、アクセス、利用可能、適時性まで、成されるべき改善が多くあると提案します。 KMはあなたが誰に質問するかにより異なって定義されるかもしれません。ITSM(ITサービスマネジメント) perspective circa(考え方シルカ) ITIL 2011から、”考え方、アイデアなどの共有に責任あるプロセス・・・ちょうどいい場所でちょうどいい時にこれらが利用可能であることを確実にするために”。本質的には、それは知識の利用と再利用なのです。しかしながら、ITILはその用語として”知識”を決して定義せず、その代わりに一つのプロセスのようにそれを取り扱っています。 ITIL2011は、開発と育成の文化的方法の代わりにデータと情報伝達を強調しながらKMにアプローチすることにかなり専門的です。組織によりその保持力の至る所で他の人により知識が受け入れられ使用される場合、知識は組織にとって唯一貴重であることにジョーは気づいています。KMを”付属の”仕事として取り扱えばその目的を決して達成しません。 KMを思慮のない”手順”を超えたものにするには、知識維持と共有の文化の一部となり、また日常の実務の中に入り込む必要があります。 原文投稿を一読ください(英語): http://www.joetheitguy.com/2015/01/28/taking-the-no-out-of-knowledge-management/

続きを読みます »

エネルギッシュであり続ける方法トップ10

あなたは何を望んでいるのでしょうか?効率的に仕事をする。いつそれを望んでいますか?昼寝をした後。ケヴィン・パーディ(Kevin Purdy)は今あなたをエネルギッシュの状態にさせ、その推進力を維持するための10のヒントを書きます。 パワーバーやエネルギー飲料の代わりに、あるインターネットリサーチをしてあなた自身のエネルギー製品を作り上げて下さい;たくさんのレシピが世界中にあります。しかし、一般的なエネルギースナックには、チーズ添えリンゴやフィッシュ添えベジーは賢明なオプションです。朝に、混乱の中で数分間のエクササイズを割り込むことができるかどうかを確認してください。仕事場で、気が散らずにあなたの脳を引き込むために、バッハのようなあまり覚えやすくないリラックスできる音楽に耳を傾けることができます。香油を使って香りの感覚に引き込まれ、少し冷えた環境の中で仕事をするように試みてください;暖かさはあなたを眠たくさせます。 あなたは仕事で燃え尽きた場合、休暇時間の利用や新しいプロジェクトを探す試みについて考えてください。おそらくあなたは1日何時間(多分、早朝)最善の仕事をしているのか既にご存じであるので、あなたが最も目覚めている時に従って大変な仕事を予定して下さい。それに従事している間、約15分割いて外に出れば、ビタミンDを吸収することができます。あなたのカフェイン摂取を減らすか、カフェインをより少量にしてください。そしてついに”パワーナップ(軽い仮眠)”を習得するのです! 原文投稿を一読ください(英語): http://lifehacker.com/5054947/top-10-ways-to-stay-energized

続きを読みます »

サービスデスクのマネージャ各人が周知しなければならない6つのKPI

サービスデスクの運営には、多くの技能と広範な測定基準の知識を必要とします。スチュアート・フェイシーは、どのマネージャでも知るべき6つの主要業績評価指標(KPI)を強調する記事を書いています。 顧客の満足スコアを知る。 サービスレベルについて考える。 傾向を見つけるために、昨日の問題点を見る。 顧客のニーズをより良く理解するために、サポートセッションを精査する。 床の上を歩き回る。 チームの質の高い点とチームの改善可能な点を知る。 あらゆる顧客の満足スコアに対して、KPIがあります。最も正確な顧客の満足の情勢を得るために、ビジネス、マネージャ、またはプロセスによってデータを一覧にして、どの領域が改善を必要とするかに注目します。次に、はっきりと理想的なサービスレベルを定義する必要があります。この基準線から、顧客の満足における偏差を判断することができます。このKPIには、放棄率、平均の保持時間、固執率があります。 前日の問題記録でのパターンを再審査するために、受信した通話の種類での変更を探し、代理店がいかによく変更を取り扱っているかを知りたくなります。その日の最初の通話を聞けば、顧客の要求に関する新たな洞察が得られます。最も共通の問題が何であり、代理店がどのように問題に取り組んでいますか? もう一つのヒントは床の上を歩き回ることであり、これによって、チームの勤労意欲とサポートの質的状態が得られます。KPIは、チームの入力であり、メンバーを最も成功に導く技法です。最後に、全体の評価では、チームが受け継いでいるか、改善を必要とするレベルを正確に指摘すべきです。この場合のKPIは、二つの部分の品質スコアであり、ビジネスの影響と顧客の影響との間で分割されます。 最初の記事をお読みください(英語)。 http://www.servicedesk360.com/six-kpis-every-service-desk-manager-must-know/

続きを読みます »

容易な4ステップでプロジェクトのパニックを回避

あなたは優秀なプロジェクト・マネージャであるかもしれませんが、遅かれ早かれ、頭上に入り込むようになります。その時間が来ると、頂点に立っている間は、ありがたいことにパニックを進むのを助けるステップがあります。ケニス・ダータは、攻撃の計画を展開する記事を書いています。 トラブルの状況では、最初のステップは穏やかなままです。あなたが当惑したと感じるときは、通常は、手元にある課題の不可解さに起因しています。その心配の種を追い払うには、その問題を理解できて管理できる部分に分割しなければなりません。 次のステップは、助けを求めて手を伸ばすことになります。あなたがそれを実行している間には、絶望的だと思われないことを覚えておいてください!明快さと自信をもって、「チャレンジ」(「問題」ではない)を同僚に取り継ぎます。自分自身の理知的な声で伝えられている問題を聞くことで、いかに冷静になっているかに驚くでしょう。 パニックを避けるという現実の仕事は、チャレンジの再構成を含むために、積極的な変更に資するようになります。もちろん、1日や1週間でも、これを達成できない場合もあります。プロジェクトの予定を書き直すことは、一例です。それでもなお、無条件に必要なことだけに焦点を合わせるのがまず最初です。他の全部は、待つことができます。 最後に、あなたはチャレンジを克服するための接合点に到達します。おそらく、適切に管理してあれば、いくらかの新たな技能、より良い製品/サービス、ただ単に新たな展望をもって、切り抜けます。いずれにせよ、それはしばしば最も大きな報酬をもたらす、最も困難な障害です。 最初の記事をお読みください(英語)。 http://www.projectsmart.co.uk/getting-in-over-your-head.php

続きを読みます »

10変更管理の伝説

変更管理は非常に重要ですが、依然として時々は処置をかなり誤っています。ごくわずかではなくて、イニシアティブの全部に応えるようなビジネスの一部になりたくはありませんか?スコット・スパンは、10項目の最も大きな変更管理の伝説を記事にして述べています。 変更は、やさしい。 人々は、言われたことをする。 立案は、十分である。 リーダーシップは、リラックスさせうる。 反対者は、ほとんどいない。 反対者は、見捨てられうる。 変更は、すばやく起こる。 技術は、鍵である。 顧客は、第二である。 あらゆるモデルが、適用可能である。 変更は、やさしくはありません。有能なリーダーは、チーム、個人、組織が気まぐれで簡単に変化しないことを認識しています。そして、人々が言われたことを実行しようとするときであっても、人々は誰もが実際に求めていたことを選んでいないかもしれません。誰もが確実な服従を期待する前に、人々が「理由」と「方法」を知ることを確かめた方がよいのです。自分自身を適切にはっきりと表現する方法を知ることは、良い立案の一部です。しかし、その計画が「現実的で実施可能できて、カスタマイズ可能」であったとしても、それを働かせるためには、依然として効果的な変更の作因が必要です。 いくら傾倒した反対者の人数が少なくても、その要求を無視してはいけません。従業員の関心事を含めて肯定することは、変更を生起させる方法です。彼らが反抗することに熱心であれば、変更に熱心になるように、彼らを納得させます。変更が奥深ければ奥深いほど、それを達成するのに時間がかかります。それは、プロジェクト管理の主なレッスンです。 技術は、極めて緩和に役立ちますが、それ自体のソリューションとして使おうとしてはいけません。技術は、単純には働きません。同様に、顧客を変更の過程に巻き込む必要がないことは伝説です。顧客の満足が究極の目標であることを覚えておいてください。あらゆる変更には、顧客の入力が必要となるはずです。そして、最後に、他の人に効果のあった変更管理のモデルを知っていることが役に立ちますが、あらゆる状況が固有であるのも覚えておいてください。以前に働いたことは、今では働かないかもしれません! 最初の記事をお読みください(英語)。 http://www.business2community.com/leadership/10-myths-change-management-0904871

続きを読みます »