調査会社のIDCが、ITプロジェクトの失敗と成功について調査したレポートの概要をプレスリリースとして公開しています。 調査は2012年にニュージーランドで行われたもの。レポートのタイトルは「Project Failure is all about Business Perceptions」（プロジェクトの失敗はすべてビジネス認識にある）。調査では、ITマネージャとそれ以外のマネージャのあいだでITプロジェクトに対する認識の差が広がっていることを指摘しています。そしてこのマネージャ同士の認識の差が、プロジェクトの成功率に影響を与えているとのこと。 プロジェクトを失敗させないために、どのような点に気をつけるべきなのか、ここでは、その主な要因にあげられた6つのポイントを紹介します。 Project Failure is all about Business Perceptions Inadequ
みなさんこんにちは。@ryuzeeです。 20 Questions All Project Managers Should Askが良い記事でしたので、抜粋・意訳にてご紹介します。 原文ではAll Project Managerとあり、従来型のプロジェクト推進を想定して書かれていますが、アジャイルなプロジェクトの場合でも以下にあげるようなことはプロダクトオーナーは意識しておく必要があるものが多いので参考にしてください。 プロジェクトが達成しようとしているビジネスゴールは何なのか？そのゴールが達成された場合のビジネス上の利益は何なのか？もしプロジェクトが立ち行かなくなったり、目的を達成することができなかった場合のビジネス（ファイナンス面、評判面）での影響は何なのか？このプロジェクトについて簡単に実現できる代替案は無いのか？膨れ上がったプロジェクトのコストを必要としない他のソリューションが利用
Available for Windows, macOS and Linux. Downloads in seconds, installs instantly and ready to build projects immediately with zero setup. Simple, intuitive and uncluttered user interface will let you break down the work, build a Gantt chart, assign resources and calculate project costs in minutes. If you need some guidance into the basics of working with GanttProject, please watch this awesome vid
I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want
プロジェクトの様々な局面で意思決定を迫られるプロジェクト・マネジャー。本書は世界中で活躍するプロジェクト・マネジャーによる97本のエッセイを収録した書籍です。ソフトウェア開発においてマネジャーに求められることは何か、人とチーム、さらにステークホルダーの管理、プロジェクトプロセスやプロジェクト要求、契約、国際化への対応と地理的に分散したチームの管理などについて、経験豊かなプロジェクト・マネジャーが自らの体験を踏まえて解説します。プロジェクト・マネジャーを勇気づけ、新たな気づきをもたらす一冊です。日本語版には、奥沢薫、神庭弘年、重木昭信、芝尾芳昭、冨永章、初田賢司、林衛による11本の書き下ろしを収録。 目次 監修者まえがき はじめに 01 できるだけ早期にユーザーを巻き込む バービー・デイビス（Barbee Davis） 02 モグラたたき開発を避けよう ベンカト・スブラマニアム（Venkat
タイムマネジメントのツールと技法にローリング・ウェーブ計画法というものがある。 意味は以下のような感じである。 短期的に完了しなければならない作業を詳細に計画する一方で、遠い将来の作業はWBSの比較的上位レベルで計画する段階的詳細化の計画技法。 ローリング・ウェーブ計画法 プロジェクト・ライフサイクルにおいて、プロジェクト開始時点では、情報が限られていたり細部まで要件が明確になっていなかったりすることが多く、ワーク・パッケージ・レベルまで要素成果物や作業を分解することが難しいとされています。したがって、実際には開始当初はワーク・パッケージよりも上位の妥当なWBS要素レベルまでの分解に留め、機能仕様や基本設計が漸次明確になるのを待って下位レベルまで分解することになります。この方法に基づいて計画を詳細化することを、「ローリング・ウェーブ計画法」と呼んでいます。 ローリング・ウェーブ計画法は、P
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。 スコープ管理とは、プロジェクトの目標や作業範囲、成果物をきちんと定義し、その承認、検収について管理することです。スコープには成果物スコープ（Product Scope）とプロジェクトスコープ（Project Scope）があります。前者は、プロジェクトで作成すべき成果物を、後者はそのための作業の範囲を明確にすることです。 第2回のプロジェクト計画書（第2回：表1）に含入したプロジェクトの目標、成果物などは、もともとこのスコープ管理の計画プロセスのアウトプットなのです。スコープ管理では、PMBOKの知識管理体系（第2回：図1）に則り、[プロジェクトの立ち上げ][スコープ計画][ス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
