タグ

projectmanagementに関するjjzakのブックマーク (42)

  • プロジェクトマネージャは、説得術を磨くべし

    プロジェクトマネージャは、説得術を磨くべし:やる気を引き出すプロジェクト管理(5)(1/2 ページ) プロジェクトを円滑に運営していくためには、各関係者をうまく説得して、各々の利害を調整する必要がある。こうした仕事を苦手とするプロジェクトマネージャも多いようだが、いくつかの重要なポイントさえ押さえておけば、さほど難しいことではない。 プロジェクトマネジメントで最も重要な課題 連載の第2回「プロジェクトは、計画通りに進まなくて当然」で、プロジェクトマネジメントにおいて最も重要な課題は、 「成果の設定(仕様の確定)と仕事の設計(作業の洗い出しとスケジュール化)は不確実である」というリスクへの対応 プロジェクトが「うまくいっている」「うまくいっていない」の判断 の2点であると説明しました。 さらに、1つ目の課題については、その対応策として大別して5通りの方法が存在することをお伝えしました。 顧

    プロジェクトマネージャは、説得術を磨くべし
  • 第1回 相手を納得させて諦めさせる「うまく断る」技術とは? - 芦屋広太の“超具体的”説得術:ITpro

    説得が仕事を成功に導く・・・私が人を指導する際に伝える言葉です。 私はITエンジニアプロジェクトマネジャー,システムプランナーとして15年以上,システム開発,問題システムの改善,システム統合などに関する業務を行い,多くの人間を説得してきました。この経験から「他人を説得できると仕事が楽に進む」ことと「説得にはノウハウやコツがある」という2つのことを学びました。つまり,説得のノウハウやコツを知っていれば,仕事を成功させる可能性が高くなるのです。そんな説得のノウハウをこの連載で紹介していきます。コンセプトは「超具体的」であること。私が現場で行ってきた実例をできるだけ使い,実際の会話を再現しながら,日常業務ですぐ役に立つ「超具体的な説得術」を説明しましょう。 ●今回のテーマ:「他部門から協力をお願いされたが,うまく断りたい」 会社などで仕事をしていれば,他部門に「協力してほしい」との話を受けるこ

  • ITプロジェクトにおける失敗の兆候--この12のサインに注意!

    文:Michael Krigsman(Special to ZDNet.com) 翻訳校正:村上雅章・野崎裕子 2010-09-02 08:00 プロジェクトの納期が守れそうにない、あるいは予算を超過しそうだと知って慌てふためくマネージャーをよく見かける。とは言うものの、プロジェクトが問題に直面していることを示す兆候を見逃してしまっている場合もよくあるものだ。 この件に関して『Early Warning Signs of IT Project Failure:The Dominant Dozen』(失敗するITプロジェクトの兆候:主な12のサイン)という学術論文を執筆するために、2人の研究者が19人の専門家と55人のITプロジェクトマネージャーの協力を得てデータを収集した。そして彼らは、「重要な兆候や問題に対する「初期の警戒信号」はしばしば、プロジェクトが実際に失敗に終わる時点よりもずっと

    ITプロジェクトにおける失敗の兆候--この12のサインに注意!
  • ビジネス交渉ツールとしてのRFP (Decent Consulting (ディイセント コンサルティング))

  • プロジェクトマネジメントOS本舗-手法7

    第7回(2002.07.31) PERT(Program Evaluation and Review Technique)分析 ◆PERTとCPM プロジェクトにおいては,各作業(アクティビティ)の所要期間がぴったりと一つに決まることは珍しい.例えば,Webの設計をするのに過去の経験から考えると5日かかる可能性が最も大きいが,うまく行けば4日で終わるだろう.でも,下手をすると7日かかるかもしれないといった感じで考える方が現実的である.ところが,悩ましいことにCPM(Critical Path Method)でスケジュールを作る際にはそのような曖昧さがあるとスケジュールができない.そこで「エイヤー」で決めるという話になる. このようなときに使える見積もり手法がPERT(Program Evaluation and Review Technique)分析である. ◆PERTとは よくPERT/

    jjzak
    jjzak 2011/02/20
    三点見積り
  • DCF法の活用方法【3つの事例を解説】|ビジネスノート

    マイナスは、投資額を表し、プラスは投資によって得られるキャッシュになります。いずれも投資額は同じで、回収する総額も同じです。数字だけ見ると、どれでも同じになりますが、DCF法で評価する上では、 すべて現在価値に直して考える必要があります。 ここで、割引率を6%として、各PJのキャッシュの現在価値(NPV)と内部収益率(IRR)を求めると次のようになります。 NPV(A) = 95    NPV(B) = 104    NPV(C) = 106 IRR(A) = 22%    IRR(B) = 28%    IRR(C) = 36% この場合は、NPVの観点からもIRRの観点からもCが一番よいPJということになります。 AとBは、同じタイミングで投資しているので、キャッシュ回収の早いBの方がよいということは直感的にわかりますが、Cは支払いのタイミングまでずれているので、直感だけではわかりにく

    DCF法の活用方法【3つの事例を解説】|ビジネスノート
  • 要求分析

    要求分析2002-11-06プログラムを開発する前に、ちょっと立ち止まってみて下さい。あなたは自分が何をしようとしているのかをきちんと把握していますか? ソフトを開発する時に一番最初にしなければならないこと、それは何を作りた いのかをはっきりさせることです。これを「要求分析」と言います。これの重 要性はくどくど述べる必要もないでしょう。何を作ったらいいのかもわからな いのに、どうやって物を作れっていうんでしょう? これは当たり前のように見えますが、現場では案外できていません。多くの場 合、これをしっかり考えずに「まず出来る所から手をつけよう」とプログラミ ングを始めてしまいます。そして、要求ではなく実現レベルで物を考えがちで す。良くある例は「以前手で書いていたこの帳表をパソコンで印刷できるよう に」という要求です。当にしたいのはそんな事ですか?それが当に客先の 要求であることもありま

  • iwatamの個人サイト

    現在、当サイトはリニューアル作業中です。お気づきの点がありましたらご連絡いただけると幸いです。 ご意見、ご感想、コラムやブログのネタのリクエストなどはゲストブックへお気軽にお寄せ下さい。 公開したくない場合は、管理者宛メールフォームにお寄せください。

  • マイクロソフトにおけるアジャイル開発はこんな風に進められている - Publickey

    マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech

    マイクロソフトにおけるアジャイル開発はこんな風に進められている - Publickey
  • 進捗管理の基本を知ろう

    プロジェクト・マネジャーが自分の経験を基に,プロジェクトの計画を策定したり,進捗管理を行ったりする──。従来のこのやり方が限界に近づいている。製品や技術の高度化・専門化が進んだことでプロジェクト・マネジャーの経験が通用しないケースが増えたり,ビジネスの改革につながる高度なシステム案件が増えたりするなど,プロジェクトに関するリスクが多様化しているためである。 そこで注目を集めているのが,プロジェクト・マネジャーの経験や勘に頼らない科学的な進捗管理の手法である「EVM(Earaned Value Management)」だ。プロジェクトで実施すべき作業を細かく分割し,それぞれに対して定義した予定コストに基づいてプロジェクト全体のスケジュールやコストの状況を可視化するものだ。ここでは,進捗管理手法の命と言えるEVMの基を解説する。 Part1 科学的な進ちょく管理が不可避に Part2 作業

    進捗管理の基本を知ろう
  • WBSを使った作業計画とスケジュール作成の実践知識---目次

    進ちょく管理の第一歩は,納期・コスト・品質を守るためのスケジュールを立てることにある。その時に最も重要なのは,現実感のある作業内容を明確に定義することだ。この記事では2回にわたって,「WBS(Work Breakdown Structure)」を使って緻密で現実的な計画を作るための勘どころを解説する。 WBSを使った作業計画とスケジュール作成の実践知識(1) WBSを使った作業計画とスケジュール作成の実践知識(2)

    WBSを使った作業計画とスケジュール作成の実践知識---目次
  • システムの納期とは確率分布だ − Publickey

    昨日はIBMのラショナルソフトウェアカンファレンスに参加しました。1日中、ソフトウェア開発方法論に関するセッションを聞いていたのですが(最後のセッションは、自分が司会のパネルディスカッションでもありましたが)、その中で最も印象的だったウォーカー・ロイス氏のプレゼンテーションを紹介したいと思います。 ウォーカー・ロイス氏はIBMラショナルソフトウェア部門のバイスプレジデントで、アジャイル開発手法としてよく知られるRUP(Rational Unified Process)の創始者でもあります。彼の講演は、この日の基調講演の1つでした。

    システムの納期とは確率分布だ − Publickey
  • プロジェクトマネジメント・コンサルティング・サービス会社 ピーエム・アラインメント PM Alignment

    今回は、前回紹介したアロー・ダイアグラム法を、スケジュール・リスクの分析に利用する方法について説明します。始めにアロー・ダイアグラム法であるPERT技法を紹介しておきます。 ◆PERT(Program Evaluation and Review Technique) PERTは、1950年代後半に米国海軍ポラリス・ミサイル開発プロジェクトで実用化された日程計画・管理のための技法としてあまりにも有名です。なお、同様の技法として、費用との関係を見ながら工期短縮を図ることをねらいとしたCPM(Critical Path Method)も、同じ頃にデュポン社工場建設のために実用化されています。 PERTの用法の一つとして、確率・統計理論を用いてプロジェクトに内包するスケジュール・リスクを分析することが挙げられます。例えば、各作業の所要期間を1通りではなく、楽観値、最可能値、悲観値の3通りで見積

  • ORWiki

    OR学会50年の歴史の中で,OR事典の編纂・改訂は通算3度目となる.いろいろな理由からOR事典編集委員会は,「OR事典」をWebに公開するという手段をとることになった.前回はCDによる出版であった. 資料編だけは「OR事典」から切り離して,OR学会の通常のホームページの中に移すことになった.これは逆瀬川浩孝委員長のアイディアである。内容の性格上,資料追加も間違いの訂正も広報委員会の責任で簡単に出来るようになる. 前回までの学会の歴史資料はそのまま残してある.今回はデータ追加作業を基に多少の資料追加を行った.前事務局長の藤木秀夫さんには,その後の学会活動全般にわたる記録をまとめて原稿を作成してもらった.学術会議関係も藤木さんが前回の形式に習って資料原稿を作成し,FMES会長の高橋幸雄さんに目を通していただいた. 各支部から増補追加の原稿が送られてきた.Webのサンプルを見てくださいと言って

  • 大人の見積もり

    1960 年生まれ,独身フリー・プログラマの生態とは? 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から,現在に至るまでの生活を振り返って,順次公開していく予定です。プログラミングに興味がある人もない人も,フリー・プログラマを目指している人もそうでない人も,“華麗”とはほど遠い,フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており,現在では異なる場合があります。 私の知人に,風俗店で働く女性がいる。私は彼女の店に行ったことがないのだが,1時間で5万円からするような店なのだそうである。彼女は酒を飲むたびにこの話をする。「私は時給5万以上だから」と自慢するのである。それを聞いて,そういえば私の単価はどのぐらいだろう,と考えたことがある。 顧客から急ぎの作業依頼が来ることがある。ど

    大人の見積もり
  • 機能構成図(DMM)の策定−EAポータル

  • 脱・人月のPBC契約 - 情報セキュリティプロフェッショナルをめざそう!(Sec. Pro. Hacks)

  • [ThinkIT] 第2回:品質・コスト・工数の関係 (1/4)

    品質とコストの関係を考える上での問題は、「どこまで品質を高めると、いくらコストは高くなるのか」ということが明確にならないことである。 図1は、「納入時の潜在欠陥が500万円単位に1個の欠陥で収めることが出来る実力ベンダーに、10倍の品質にまでシステムを良くした場合、どの程度費用は高くなるのか」という見積評価尺度を質問した時の図である。 このようなユーザの要求に対して、「それなら、これこれの理由でxx%高くなります」と透明性を持って見積回答をしてほしいのだが、そのような基準は存在しないのがソフトウェア産業の常識である。日だけでなく世界中のソフトウェア産業において、発注者と受託者の間にはこのような問題が山積である。 「何かこの品質と価格の関係の糸口を見つけたい」、そのための調査が必要と考える。

  • 株式会社 RDPi - ソフトウェアメトリクス管理事例

    ある電子機器メーカーでの事例を紹介する。市場は世界であり、海外も含めて競合が厳しい製品を開発している。一年ごとに普及モデルから高級モデルまでのほとんどのモデルを入れ替えるような新製品リリースを従来から行っている。しかし、近年、製品規模や機能が増大することによって定期的な新製品リリースへの対応が困難を極めており、開発要員を増やすだけでは対応できない状況になりつつあった。したがって、開発期間を伸ばすことなく生産性を飛躍的に向上させることが経営課題であった。 アセスメントした結果、必要な固有技術について十分な経験を持つ技術者は、十分とはいえないまでも必要な開発を担当できる程度にはいるがわかった。しかし、プロジェクト管理を任されているマネジメント担当者に技術職からの脱皮ができないままの人が多いことわかった。ヒアリングの中で、マネジメント担当から、「プロジェクト管理という仕事は何をすればいいのか、何

  • Loading...