ホーム / タグのアーカイブ: featured

タグのアーカイブ: featured

デロイトからの2015年技術報告書が示す4大動向

デロイトからの第6回年次技術動向報告書は、最高情報責任者(CIO)の技術統合者としての新しい役割からアンビエント・コンピューティングに至るまでの多くの新しい技術的進展を取り上げています。コナー・フォーレスト(Conner Forrest)は、これらの実態をすべてのCIOが理解すべき2015年の4大動向として以下のように要約しています。 最高統合責任者としてのCIO アプリケーションプログラミングインタフェース(API)経済 アンビエント・コンピューティング ソフトウェアで定義•制御化されたすべて CIOは企業におけるITの要であるとデロイトは報告し、CIOの役割はオペレーター、科学技術者、戦略家、促進者という4つの面においてシフトしていると説明しています。更に、CIOはベンチャーキャピタリスト等も含めたIT全体を管理し、最適なポートフォリオ管理戦略に基づいて計算され予測されたリスクを負い、またプロジェクトを選択すべきであると、フォーレストは述べています。 APIが出現してからもう大分経ちますが、ようやく現在に至ってそれは企業にとって極めて重要なものであることが認識されています。APIが単に技術的資産として取り扱われているだけではなく、ビジネス上の最重要事項の一つに取り上げられているのはそのような理由からきています。ある製品にはその製品に対する特別の事業計画が求められるのと同じように、それぞれのAPIに対しても同様に取り扱うことが勧められています。 APIを導入する際には、その作用や能力の範囲を明確にしなければなりません。不適切に書かれたコードや過去に休眠していたセキュリティがAPIを通して表面に沸き上がって来るリスクがありますので、それらが発生した時に生じる問題に対応できるよう準備を整えておかなければならない必要があります。 長い間待ち望まれていてようやく表面化し始めている傾向の一つにモノのインターネット(IoT)革命、本報告書では「アンビエント・コンピューティング」と呼ばれているものがあります。これは、ビジネスの実態を導き出すような様々な、一見するとバラバラな対象物やデバイスをネットワーク化することを意味しています。例として、IoTは分析論においては欠かせないものとなるでしょうが、企業がネットワーク化されたさまざまな「モノ」を利用することによってコスト削減の変化を見ようとする場合は、単なる情報だけではなくそれ以上のものが必要とされるものなのです。 最後に、仮想化の大流行が、ソフトウェアで定義•制御化されたネットワーク化(software-defined networking (SDN))やソフトウェアで定義•制御化されたストレージ(software-defined storage (SDS))となって現れてきています。この「ソフトウェアで定義•制御化されたパス(software-defined path)は軽々しく踏みつけられてしまうものではありません。仮想化はネットワークの複雑性に対応するために作りだされたものですが、その互換性とスケールに対しては注意を払う必要があります。 原文(英語)を読むには:http://www.techrepublic.com/article/four-takeaways-from-deloittes-2015-technology-trends-report/

続きを読みます »

技術スキルはITガバナンスを効果的に主導するのに必要だろうか

組織にとってITガバナンスに対する強い関心が有益であるか否かを問わず、それは議論にはならない。効果的なITガバナンスを設置している組織は、市場シェアを増加し、財務を改善し、技術革新を増加し、組織の評判を増加することを経験することだろう。 1 COBITの作成を担当関連であるISACAは、ITガバナンスを「取締役会および経営管理」の責任とし、「…リーダーシップ、組織構造や、組織のITが組織の戦略とその目標を維持、拡張を確認するプロセス」を構成している、と定義している。2 この定義によると、ITガバナンスは単にITリソースの日常業務ではなく、それは、組織に価値をもたらすためにビジネス目標とITを整合させることにある。 ITガバナンスが非常に有益で、複数の幹部が含まれている場合、上級管理職の38%だけがITが支配されている方法を知っているのはなぜだろうか。 3 『ACMのコミュニケーション』に出版されたある記事には、「一部のITの専門家には誤って、ビジネスリーダーは技術スキルが不足しているために、ITを管理することができないと思っている。」と書いてあた。その記事は、現実には技術的な知識は実際に必要ではないことを強調し「ITがもたらす能力を理解したり、ITのより賢く、より効果的な利用によって有効化された新しく改善されたビジネスのスキルを計画するには、ITシステムの設計や構築、またはその操作方法の具体的な知識を必要としない。」という。4 さらに、その要点を証明するのに、その記事の2名の著者はこの概念を自動車と比較している。 誰かがタクシーのサービスを操作する場合は、車の設計の方法やどのように車を設計製造するかではなく、そのサービスの操作に使用される自動車用の機能と要件を理解しなければならない。 したがって、効果的なITガバナンスを主導するITスキルを必要とはしない。 タクシーサービスのアナロジーに戻ることにする  –  人は自動車を運転するために、そのデザインや製造を理解する必要はないが、完全に理解すべきものがいくつかある。さらに重要なのは、彼らが効率的に操作し、以下の如く競争力を維持するために理解すべきものがいくつかある。すなわち、 リソースの割り当て サービスに関連するリスクを管理する方法 健全なビジネス上の意思決定を行う方法 ブリッジポート大学の副学部長および技術管理部門のディレクターであるガドJ. セリグ博士によると、「ITガバナンスの成功は、方針、手続き、プロセスおよび技術よりも、リーダーシップや文化変容の十分な管理等の人的なスキルによって決定されることがより頻繁に起こるという。」5 ハードスキルは彼の仕事のうち、ITガバナンスに必要な必要なスキルの40%だけを占めていると報告された。これらは、以下のように学習するにはより簡単なスキルです。 方針 メトリック プロジェクト管理 リスク管理 状況報告 他の60%は、リーダーシップ、人、および他のソフトのスキルであり、そのうちのいくつかは、以下のようにより頻繁に経験を通じて学習されている。 効果的なコミュニケーション 信頼 完全性 チームの構築 変更管理 洗練されたITシステムを構築するために必要な特定のスキルとは対照的に、ITガバナンスは、リーダーシップ、意思決定、説明責任についての詳細である。 その要点とは? ハードのITスキルを持っていない企業幹部でも、まだ自分の組織のためのITガバナンスで成功することができる。彼らは絶対に臆病になって言い訳をすべきではない。ビジネスリーダーは、単に一般的に強いリーダーシップのために必要なスキルを有し、前方のビジネスを駆動するために効果的なITガバナンスモデルのビジョンと感謝を共有する必要がある。 (参考文献) 1http://www.isaca.org/Journal/archives/2005/Volume-2/Pages/JOnline-IT-Governance-Pass-or-Fail.aspx 2http://www.isaca.org/Indonesia/Documents/ITGovernance.aspx 3Weill, P. and Ross, J. How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press, 2004 4JUIZ, C., & TOOMEY, M. (2015). To Govern IT, or Not to Govern IT?. Communications of the ACM 5http://www.atilim.edu.tr/~mrehan/ISE511-Text.pdf

続きを読みます »

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

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

続きを読みます »

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

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

続きを読みます »

2017年以降のサービスデスク

サービスデスク協会(SDI)は、将来何が起こるかについて、ハワードケンドールとダニエル·ウッドの作成による新しいホワイトペーパーをリリースしました。 SDIは、サービスデスクは一般的に指導や援助が必要な時に「主要な顧客インタフェース」として今見られている、と言っています。この役割は、将来何を必要とするのでしょうか。 ホワイトペーパーは、広範なトピックをカバーしていますが、その目標は常に、2017年にサービスデスクがどのように機能するようになるかを描くことにあります。そこには、まず次の

続きを読みます »

プロジェクトのポートフォリオを管理するための4つの秘訣

IT管​​理の他の側面ほど、より多くのバランスや、状況の変化に対するより多くの注意深さ、またはプロジェクトポートフォリオ管理に多くの隠されたリスクを伴うものはない。プロジェクトの成功率が現在64%で失速している場合の、プロジェクトポートフォリオをより良く管理するための4つの便利なヒントをジェン・スクラバック氏は提供している。 持続可能なプロジェクト/プログラムを選択する ポートフォリオの上限を知る ミスを認め、迅速に調整する 自らの平均値を測定する 組織の強みと弱みに合うプロジェクトの目標を選択する。計画の予定に当たっては、過度に楽観的にならず、現実的になること。また、企業の文化がサポートしていない場合は、熟考を重ねたプロジェクトですら依然として拒否されることがあることを心に留めておく。特に短期間におけるプロセス変更で数百人を含む大規模なプロジェクトを扱う場合は、変更管理を忘れてはいけない。 スクラバック氏はまた、「2015年にポートフォリオの投資収益率で1億米ドルを達成する」等の静的な目標を超えた、可能性の数字を伸ばすことを意味する、ポートフォリオの「上限」内で動作するように助言している。 ポートフォリオの上限は、予算、能力(スキルや知識)、容量… または文化(既存のプロセス、変更に必要な組織的機敏性と食欲)によって定義できる。 基本的には「最高のリソース消費期間」を目指し、初期のランプを超えた上限を計画する。 但し、プロジェクトがうまくいかなかった場合はどうだろう。そんな場合はスポンサーにそれをキャンセルするように薦める備えがあるだろうか。プロジェクトの健全性を判断するためには、明確な財務パフォーマンス監視は重要だ。スクラバック氏は、プロジェクトのコースを修正せざるを得なくなるような大変化が急に発生し、敏捷性を要することも起こりうる、と警告している。 最後に、ポートフォリオとは当然のことながら、一つではなく数多のプロジェクトを意味する。時間をかけて、最も実値が作られている所を発見するために、大小のプロジェクトを検証すべきだろう。 元の投稿 (英文) はこちらからどうぞ: http://www.projectmanagement.com/blog/Voices-on-Project-Management/12945/

続きを読みます »

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/

続きを読みます »

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の成功の定義が不完全で幅が狭過ぎる可能性がある。とどのつまり、トリプル制約、または競合する制約には、ちょうどそういった制約があるからだ。それは動作のためのメトリックでしかない。これは重要であるが、他の実績のメトリックがプロジェクトの成功を測定するために使用されるべきだ。それは戦略的ではなく、価値とプロジェクトの利点を測定していない。 我々が運用メトリックを満たすために自らの能力を評価することによって、プロジェクト管理の成功を測定する際には、いくつかの奇妙な結果が起こる。 制約のために確立された数字を達成すれば、値を追加することよりも重要になる。 プロジェクトが利益を達成することは重要ではない。 戦略的議論の余地には、議論は非常に戦術的になる。 変更要求、技術革新、新しいアイデアは、それらがもたらす恩恵ではなくベースラインに対して評価される。 成功のより良い定義 我々は良いプロセスやプロジェクト管理の実践が必要だが、それら可能性を生み出すものである。プロジェクトの効率化をサポートするためのツールであって、プロジェクトの最終的な目標ではない。また、将来もそうはならない。さらに、戦略的目標を含めて、それを測定できることが重要だ。 当社のクライアントは、我々が彼らの特定の結果を達成するの​​を助けるために我々に支払いをしている。彼らが心の中でそのプロジェクトについて考えるとき、彼らはプロジェクトの利益に焦点を当てている。彼らは我々が専門家として適切な方法論を用いることを前提としているのだ。それでは、彼らがどのように考えるかを理解し、そのプロジェクトを表示してみよう。 プロジェクト管理者として、次の方法で、プロジェクトのさまざまな要素を評価するために、トリプル制約や競合する制約を越えて行く方が良い。 戦略:利害関係者への利点とプロジェクトの価値 運用:計画には通常さまざまな制約が伴う インフラ:プロジェクトに使用可能な、ツール、プロセス、ソフトウェア、および資源の質と妥当性 プロジェクト管理では、プロジェクト管理の方法論とその運用メトリックの値を受け入れることは非常に迅速なことが多い。しかし、専門職は、プロジェクト管理の戦略的なビューを採用で非常に遅い。我々はタスクの監督とタスクの実行などのプロジェクト管理の役割を狭くすることを好婿とが多い。 それだけでプロジェクト管理が世界の運用と戦術ビューを持っている場合、組織の戦略的ツールにすることはできない。 まとめ あなたの顧客は、プロジェクトが成功することを望んでいる。プロジェクトが開始されたのには理由がある。プロジェクトリーダーになり、それが何であるかを知っているかを確認していただきたい。運用メトリックは契約管理には良いが、顧客の満足度は、価値と成果の利益に基づいて行われるのだ。 プロジェクトのこの戦略的な面を持つていれば、我々はプロジェクトのすべての段階を管理する方法に重大な影響を与える顧客と対話し、変化に対応し、意思決定を行うことができる。

続きを読みます »

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

大規模な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/

続きを読みます »