はじめに
プロジェ プロジェクトは、製品やサービスを開発し、運用効率を得るために想定されています。 ビジネスはますますプロジェクト化されており、プロジェクトへの世界的な支出は年間数十億ドルのオーダーです（Williams、2005）。 理由は明らかです。 プロジェクトは、資源の効率的かつ効果的な利用を促進するプロジェクト管理慣行を採用する機会を提供します。 しかし、プロジェクト管理の規律と職業の進歩にもかかわらず、共通の経験は、多くのプロジェクトが失敗することを示唆しています（Williams、2005）。
一般に、組織は、プロジェクト目標を達成し、顧客の期待に応えるために、PMI基準に基づく伝統的なプロジェクト管理のベストプラクティスを実装するよう努めています。 ただし、Project Management Body of Knowledge（PMBOK®Guide）の推奨されるプロセスとプラクティスのすべてが、すべてのプロジェクトに関連するわけではありません。 多くの場合、選択的なアプローチは、そのサイズ、タイプ、複雑さ、およびプロジェクトが実施されている業界に基づいて、プロジェクトの特定のニーズに合 ITプロジェクトを管理するための別のアプローチのためのそのような必要性はプロジェクト管理の文献でよく文書化されています。
ソフトウェア開発プロジェクトは、ソフトウェア製品を加速させながら、信頼できるように堅牢で開発するという相反する課題に直面することが多い(Boehm,2002)。 急速に変化する技術開発のペースを維持することを目指して、ITプロジェクトは、多くの場合、計画と実装の段階で範囲の変更を受けます。 その結果、ITプロジェクトには従来のプロジェクトとは異なる課題があります。 従来のプロジェクト管理慣行に対するいくつかの調整と修正がITプロジェクトのために開発され、実践され、それによってアジャイルプロジェク
アジャイルなプロジェクト管理方法論—頻繁に変化するスコープへの適応性が高い—反復または段階的な計画と継続的な統合を使用しています。 主主義はプロジェクトの規模を柔らかい保つことです。 この方法論は、コラボレーションを促進し、顧客満足度の向上をもたらします。 しかし、アジャイルは、堅牢性と信頼性の顧客の要求を満たしながら、速いペースでソフトウェアを開発するための完全なソリューションではありません。 この文脈では、Boehm(2002)は、従来のプロジェクト管理と実行可能で望ましいアジャイルソフトウェア開発方法論の組み合わせを推奨しました。 補完的なアプローチは、アジャイルと計画主導の両方の方法の利点を保持し、同時にそれらの弱点の多くを緩和するように調整されたリスクベースのア
本研究論文は、ITプロジェクトとは異なるITコンサルティングプロジェクトを管理するための組み合わせたアプローチの上記の命題（Boehm、2002;Boehm&Turner、2003）を調 ITコンサルティングプロジェクトは、ITプロジェクトを管理し、プロジェクトサポートを提供するために考案されています。 彼らはしばしば政府部門で開始されます。 ITコンサルティングプロジェクトは、ソフトウェア開発プロジェクトではなく、ITプロジェ
本研究では、アジャイルプロジェクト管理の実践がITコンサルティングプロジェクトにどのように関連しているかを理解することを目指し この調査の目的は、アジャイルプロジェクト管理を使用することの利点、その適合性、および従来のプロジェクト管理のどの側面をアジャイルプロジ 次のセクションでは、アジャイルプロジェクト管理方法論の広範な文献レビューを使用して、従来のプロジェクト管理と比較して、アジャイルメソッドの顕著な特徴とプロジェクト管理に対する独自のアプローチを特定しました。 文献レビューは、アジャイルソフトウェア開発を使用することの重要な概念と利点の理解を深めるのに役立ちました。 また、文献レビューの結果に基づいて、ITコンサルティングプロジェクトの理解を深めるために、構造化アンケートを用いた研究方法を開発し、提示し その後に提示されたデータ分析と議論は、研究の重要な洞察と知見を提供する。 私たちは、ITコンサルティングプロジェクトのための私たちの研究成果と勧告と論文を締結します。
文献レビュー
包括的な計画によって駆動される伝統的なプロジェクト管理慣行は、プロジェクト仕様が明確に定義されている場合に使用できます。 一方、プロジェクトの存続期間中に仕様が頻繁に変更される場合、プロジェクトを管理する従来のアプローチは効率的に機能しない可能性があります。 ソフトウェア開発プロジェクトは、多くの場合、最小限の仕様で考案され、プロジェクトの実装中にこれらの仕様を頻繁に変更します。 さらに、ソフトウェアプロジェクトの開発期間は短い。 アジャイルメソッドは、従来のプロジェクト管理技術と比較して、開発期間が短いため、ソフトウェア開発プロジェクトに適しています（Hanakawa&Okura,2004）。
一般に、アジャイルプロジェクト管理などの様々なソフトウェア開発方法は、顧客満足度の向上、欠陥率の低下、開発時間の短縮を約束し、急速に変化す アジャイルプロジェクト管理とは対照的に、ステージゲートモデルは、コンセプトアイデアから最終的に配信される製品に作業プロセスを使用します。 このモデルは、プロジェクトを管理するための製品開発のさまざまな段階に基づいて、プロジェクト管理のライフサイクルフェーズを開発します。 ステージゲートモデルとアジャイルプロジェクト管理の重要な違いは、前者が要件の変更を最小限に抑えて、製品が時間内に完了するようにしようとしていることです(Karistrom&Runeson,2005)。 ソフトウェアを開発するための別の方法は、小さな機能横断的かつ自己管理チームを採用するプロジェクト管理原則のセットであるスクラムです(Schatz&Abdelshafi,2005)。 スクラムでは、各開発項目の開始時に各チームメンバーと製品所有者が協力する必要があり、方法論は既存の開発プロセスのラッパーとして機能します。 したがって、SchatzとAbdelshafiは、スクラムはプロジェクトの成功を測定するためのベースライン計画を持っていないと主張しました。 しかし，アジャイルプロジェクト管理は，ソフトウェア開発プロジェクトに対する柔軟性と適応性が高いため，この研究のために考慮されている。
上記の利点に加えて、アジャイル方法論は乱流で絶えず変化する環境にも適用可能である(Highsmith&Cockburn,2001)。 さらに、アジャイルメソッドは、市場、技術、およびプロセスへの適応性を強調している（Mellor、2005）。 アジャイル方法論は、最初に重要な機能に焦点を当てるアプローチであり、その結果、機能に関する早期のフィードバックを探す（Karistrom&Runeson、2005）。 重要な機能が特定されると、プロジェクトマネージャーは遅延がないことを確認します。 KaristromとRunesonは、アジャイルプロセスは、リソースの詰め込み、固定された計画、および長期計画のサポートを避けることができると示しました。
しかし、アジャイル方法論はすべてのソフトウェア開発プロジェクトに適しているとは限りません。 アジャイル方法の開発者であるScott Amblerを引用して、Boehm(2002)は、ライフクリティカルシステムなどの保証ソフトウェアのための伝統的な計画主導のプロジェ
アジャイルメソッドは、混沌と不確実性を特徴とする厳しいプロジェクト環境のために、挑戦的なニーズと要求を満たすために才能のある人々で構成されたプロジェクトチームを必要としている。 Constantine(2001)の調査研究を引用して、Boehm(2002)は、アジャイル手法には非常に有能な人が必要であることを示唆した。 さらに、アジャイルは大規模なチームには適しておらず（Highsmith&Cockburn,2001）、成功するには緊密に調整されたチームワークが必要であり、15人または20人以上の開発者を持つチームはプロジェクトの管理の難しさを増す（Constantine,2001）。
アジャイル手法が一貫したチームを採用していることは明らかです(Karistrom&Runeson,2005)。 KaristromとRunesonは、小規模で管理しやすいタスク、継続的な統合、自動テストなどの追加のアジャイル機能を特定しました。 その結果、アジャイルプロジェクトチームは、良好な内部コミュニケーション、より高い品質、および制御されている感覚によって特徴付けられます（Karistrom&Runeson）。 しかし、彼らはアジャイルチームのための潜在的な分離を想定しています。
コミュニケーション、文書ベースの進捗管理、品質管理の面では、従来のプロジェクト管理の一般的な慣行は、アジャイルソフトウェア開発方法（Hanakawa&Okura,2004）とは一致しない。 開発目標の継続的な再調整のための対面の相互作用は、通常、アジャイル方法論では好まれている(Melnik&Mauer,2004)。 MelnikとMauerは、従来の方法とアジャイル方法の違いを強調し、ソフトウェア開発においては、長い知識転送チェーンが使用され、多くの場合、情報の歪みや損失の影響を受けやすい伝統的なプロジェクト管理慣行とは対照的に、短い知識転送と直接コミュニケーションとコラボレーションが好まれることを提案しました。
計画主導型の伝統的なプロジェクト管理慣行とアジャイルメソッドの重要な違いの一つは、アジャイルメソッドは、伝統的なプロジェクト管理
もう一つの違いは、プロジェクトのために作成される文書の量と種類です。 計画主導型の従来のプロジェクト管理は、詳細な計画、監視、および制御文書を強調しています。 設計根拠、理由と正当性を表現する文書は、高度に自動化された手順を使用して作成され、これらの設計根拠はアジャイル文書として機能します（Sauer、2003）。
Coram and Bohner(2005)は、アジャイルメソッドの共通の特徴、すなわちコラボレーション、小さなチーム、短いリリーススケジュール、時間ボクシング、および一定のテストを プロジェクトマネージャーは、非常に協調的な環境を確保する責任があります。 この目的のために、アジャイルメソッドは、小規模なチームとプロジェクトごとにいくつかのサブチームを奨励してコラボレーションを促進します。 その結果、アジャイル手法は、チーム活動を調整するためのプロセスと計画を少なくする必要がある可能性があります。 アジャイルメソッドでは、短いリリーススケジュールも使用されます。 タイムボックスは、プロジェクト成果物のリリースに一定の期間を課す概念であり、金めっきとスコープのクリープを減らすのに役立ちます。 一定したテストは製品品質および統合を保障する。 さらに、CoramとBohnerは、プロジェクトマネージャーが進捗状況を追跡し、特定の計画に従うのではなく、変更への対応に重点を置いてビジネス上の意思決定を行
時間ボクシングは最良の推測による予測不可能な計画につながり、固定された日付は開発段階で予期せぬ驚きをもたらす可能性がある（Patton、2003）。 この反復的なプロジェクト計画プロセスのもう一つの結果は、アジャイルメソッドは完了率に基づいて進捗状況を監視できないということです（Patton、2003）。
小さなサブチームが計画に関与すると、やる気のあるソフトウェア開発エンジニアになり、技術的な問題はプロジェクトの初期に提起され、実装にはほとんど抵抗がない(Karistrom&Runeson,2005)。 さらに、アジャイルアプローチでプロジェクトスコープを定義すると、コスト削減につながります(Mcgovern,2002)。 アジャイルメソッドは、要件ベースの計画を使用し、スコープ（McGovern）を制御することもできます。
これまでのすべての参考文献と議論およびその他を使用して（Little Greene,Phillips,Pilger&Poldervaart,2004;Little,2005;Abrahamsson,Warsta,Siponen,&Ronkainen,2003;Ilieva,Ivanov,&Stefanova,2004;Lindvall,2004）、表1は伝統的なものと伝統的なものとの要約比較を提供する。アジャイルプロジェクト管理の実践。
表1: アジャイルと従来のプロジェクト管理の比較
| プロジェクトフェーズ | 伝統的な | アジャイル |
| イニシエーション |
|
|
| 企画 |
|
|
| Execution |
|
|
| 監視および制御 |
|
|
| クローズアウト |
|
|
文献レビューの概要
アジャイルプロジェクト管理方法論は、ソフトウェア開発プロジェクトに一般的に使用されています。 それに頻繁に変更の規模により大きい適応性があります。 その結果、アジャイルプロジェクト管理では、プロジェクトの生涯を通じて、反復的または段階的な計画と継続的な統合を使用します。 アジャイルプロジェクト管理の重要な原則は、プロジェクトスコープをソフトに保つことです。 アジャイルプロジェクト管理方法は、伝統的に重要ではないと考えられている要因に重要性を割り当てることによって、伝統的なプロジェ アジャイルは、比較的高い重要性を割り当てます:
- プロセスとツールに対する個人と相互作用
- 包括的なドキュメントに対するプロジェクト実行
- 契約交渉に対する顧客コラボレーション
- プロジ さらに、プロジェクト計画の変更を開始するために、顧客からのフィードバックに依存しています。 この方法論は、プロジェクト成果物を策定し、ビジネスプロセスの実行ニーズを満たすために、適切なエンドユーザーとその目標を特定するアプローチを使 アジャイルメソッドを使用する利点には、顧客満足度の向上、欠陥率の低下、開発時間の短縮などがあります。 さらに、アジャイルメソッドは、プロジェクト成果物の技術機能に関する初期のフィードバックを使用するため、急速に変化する要件への答えです。 アジャイルメソッドは、要件が詰め込まれていないことを保証します。 アジャイルメソッドの主な特徴は、プロジェクトチーム内外の効果的なコミュニケーションであり、より多くの要件を追加する際の柔軟性を実証
これらの利点は、組織がより良い顧客サービスを提供するのに役立ちます。 さらに、グローバル化と自由なマーケティング哲学が、製品やサービスをより速く、より安く、より良く提供するための期待を高める上で、顧客の認識に影響を与えている現在の経済において、それらは関連しています。
しかし、アジャイルメソッドには、表1に見られるような欠点がないわけではありません。 頻繁に範囲を変更すると、プロジェクトの進捗状況を監視するのが困難になります。 また、学んだ教訓の形で暗黙の知識を捉えることは容易ではありません。 スコープ変更管理、文書化、包括的な計画、品質管理、およびリスク管理は、アジャイルな方法を採用するときに奪われることができる伝統的なプロジェクト管理の重要な利点です。
研究方法
私たちは、個人的なインタビューとアンケートの両方を使用してデータを収集しました。 二つのセクションからなる構造化アンケートを開発した。 最初のセクションでは、プロジェクトとその特性についての詳細をキャプチャするように設計されました。 このセクションでは、プロジェクトの人口統計とプロジェクト管理の実践に関連する13の質問で構成されています。 彼らは、必要に応じてオープンエンドの回答を提供するオプションで、研究の参加者に提示されました。
第二セクションでは、プロジェクト管理の実践に関する声明に焦点を当て、参加者はこれらの声明に1を”強く同意しない”、5を”強く同意する”と示す5点の尺度で回答するよう求められた。”次の文は、プロジェクト管理慣行の重要な共通の教義に対処するだけでなく、伝統的でアジャイルなプロジェクト管理慣行を対比するために役立
- プロジェクトの成功を測定するための基準は、プロジェクトの目的と目標に基づいています。
- プロジェクトは要件によって駆動されます。
- プロジェクトは変更に適応可能です。
- あなたの意見では、期待される結果を達成したプロジェクト管理の努力
- 対面の相互作用と短いコミュニケーションチェーンは、プロセスやツールよりも
- チームは包括的な文書化よりもプロジェクトの実行に焦点を当てています。
- 契約交渉に対する顧客のコラボレーションは、チームにとってより効果的です。
- プロジェクトには明確に定義されたプロジェクトスコープがあります。
- プロジェクト管理の実践PMBOK®Guideプロジェクトのライフサイクルに従ってください。
- プロジェクトについては、反復または段階的なプロジェクト計画が続きます。
- このプロジェクトには、ISO9000、OMB300などの規格への準拠などの文書要件があります。
- ユーザー受け入れテスト(UAT)の手順は、プロジェクト全体で実行されます。
- プロジェクトマネージャーは、顧客の介入なしにプロジェクト関連の意思決定を行う権限を与えられています。
これらの声明に対する回答は、13の質問の最初のセットからの適切な質問と組み合わせて分析されます。 一緒に、両方のセクションへの応答は、意味のある分析のためのプロジェクトの詳細な理解を提供しました。
研究結果
アンケートは、研究時に進行中の20のITコンサルティングプロジェクトに関するデータを収集するように構成されていました。 プロジェクトのうち、65%は時間および材料契約タイプのプロジェクトであり、残りは会社固定価格（FFP）タイプです。 時間と材料のプロジェクトの中で、55％が二年以上のプロジェクト期間を持っています。
ほとんどのプロジェクトチームは小規模で、15%だけが10人以上のメンバーを持っています。 プロジェクトチームメンバー間のコミュニケーションに関しては、回答者の60％がプロジェクトのニーズに正式なコミュニケーシ; 30%は正式なコミュニケーションと非公式のコミュニケーションの両方を使用し、残りの10%は非公式の方法だけに依存していました。
二つの回答者のうちの一つは、彼らのプロジェクトがプロジェクト計画を使用していることを示しました。 関連する質問では、プロジェクト計画を持っていなかったプロジェクトのうち、80％は反復計画も使用していませんでした。
スコープの変更は、この研究の重要な側面です。 プロジェクトのうち、70％が少なくとも一度はスコープの変更を経験しています。 プロジェクトの範囲の変更を経験した人のうち、60％が二度以上それを経験しました。 顧客が規模の変更を決定する間、コンサルタントは—顧客の同意を得て—プロジェクト管理の計画に品質管理の計画を含めることができる。 彼らが彼らのプロジェクトのための品質管理の計画を有するかどうか尋ねられたとき、回答者の65%は品質管理の計画を使用しなかったことを示
結果ディスカッションと分析
研究結果は、最初に結果を検証するために質問と他のすべての質問との間の相互関係を慎重に調べることによっ さらに、これらの結果を分析して、itコンサルティングプロジェクトの堅牢なプロジェクト管理アプローチを開発するために、アジャイルと伝統的なプ
その目的と目標に基づくプロジェクトの成功基準
プロジェクトは、その目的と目標を満たしたときに成功したとみなされます。 回答者のわずか60％が声明に同意した、”プロジェクトの成功を測定するための基準は、プロジェクトの目的と目標に基づいています。”回答者の約30％が反対した。 さらなる分析は、これらのプロジェクトが一定の変化する条件と要件を経験していたか、クライアントがプロジェクトについて明確ではなかった 最終的に、これらのプロジェクトは頻繁に範囲の変更を経験していました。 ある特定の例では、プロジェクトの目標と目的が変更されました。
興味深いことに、プロジェクトの成功基準は、その目的と範囲の変更、プロジェクトの種類、プロジェクト計画の存在から派生しているという事実との間には関連性がないことに注意することは重要である。 言い換えれば、組織の戦略計画からプロジェクト基準を導出することは、範囲の変更やプロジェクトに計画があるかどうかには関係ありません。
プロジェクト要件
通常、プロジェクトスポンサーの要件が明確に特定された後、詳細なプロジェクト計画が作成されます。 プロジェクト計画の策定とその実行は、原則として、これらの要件によって推進されるべきである。 したがって、プロジェクトマネージャーは、”プロジェクトは要件によって駆動されます。”調査結果は、回答者のわずか60％が自分のプロジェクトが要件によって駆動されていると述べたことを示しています。 この声明に同意しなかった回答者の約20％は、プロジェクト計画を使用せずにプロジェクトが実行されていることを示しました。
この声明に応じて中立であった回答者の約20％が、プロジェクトの範囲変更を経験していないプロジェクトマネージャーです。 他のすべての回答者は、声明に同意または同意しなかった人は、現在のプロジェクトで少なくとも一度は範囲の変更を経験しています。
一般に、プロジェクトがその計画に従って実装されていない場合、要件が特定されていないか、プロジェクトの実行中にプロジェクトの要件が変 しかし、本研究では、”プロジェクト計画を使用せずにプロジェクトを実施する”と”プロジェクトは要件によって駆動されない”との間に、このような関連性を確立することはできません。
変更への適応性
20のプロジェクトのうち十八は、プロジェクトの変更に正常に対応しています。 変更への適応性は、アジャイルプロジェクト管理方法論を使用するための候補であるプロジェクトの主な特徴と考えられています。 この研究に代表されるITコンサルティングプロジェクトは、スコープの変更に対処する適応性を持っていることを実証しています。
プロジェクト管理の努力が期待される結果を達成
結果は、クライアントがプロジェクトの大部分（70％）の結果に満足していることを示唆しています。 しかし、これらの回答は、プロジェクトマネージャーの視点から開発されたプロジェクトの進捗状況や製品に関する他の重要な調査質問への回答と関連 理由は明白です。 プロジェクトはまだ時間とコストの超過を経験していました。 ソフトウェア製品を提供する最終的な結果は満足のいくものですが、プロジェクト管理プロセスは正常に実行されませんでした。 推論は、このようなマイルストーンの開発、監視、および制御などの伝統的なプロジェクト管理慣行を採用することは、プロジェクトを正常に管理する
対面コミュニケーションとプロセスの重要性
コミュニケーションは、プロジェクトに関連する役割、責任、方針、手順を理解し、コラボレーションを奨励す 最終的に、コミュニケーションは凝集のプロジェクトチームに導き、チーム-メンバーが協力し、意思決定に加わるように励ます。 この調査に参加した10人のプロジェクトマネージャーのうち7人は、プロセスやツールよりも対面の相互作用と短いコミュニケーションチェーンの方が重要であることに同意しました。
の結果は、対面コミュニケーションの重要性とプロジェクトチームメンバー間のコミュニケーション手段との間に強い関連性を示しています。 対面コミュニケーションがプロジェクトプロセスよりも重要であることに反対した人は、プロジェクトチームメンバー間の非公式コミュニケーションを使用していましたが、対面コミュニケーションがより重要であると考えた人は、正式なコミュニケーションと非公式のコミュニケーションの両方を使用していました。
ドキュメントよりもプロジェクトの実行に焦点を当てる
プロジェクトのドキュメントは見落とされることが多く、その結果、組織はプロジェクトの計画と実行で学んだ重要な教訓を奪われています。 この調査で表されるすべてのプロジェクトが連邦政府のプロジェクトであることを考慮すると、対応するプロジェクトマネージャーの70％が、包括的なドキ プロジェクトマネージャーがプロジェクトの実行よりもドキュメントが重要であると考えているいくつかのケースでは、さらなる調査は、顧客がすべての
契約交渉を超える顧客のコラボレーション
契約交渉は、外部プロジェクトの不可欠な機能です。 交渉の間、両当事者は彼らの自己利益を保護することに焦点を当てるだろう。 契約の交渉は、プロジェクトのさまざまな段階で行うことができます。 これらの問題には、特にプロジェクトの実施中にコラボレーションを通じて対処することが望ましく、そうでなければ、契約の延長などの問題につな この調査で表されるすべてのプロジェクトが契約であることを考えると、回答しているプロジェクトマネージャーの半数以上（60％）が契約交渉よりも顧 彼らは、共同作業がプロジェクトチームにとってより効果的であることを提案しました。
意見の相違があり、協力が交渉ほど重要ではないことを示唆しているところでは、2つの興味深い事実がそれらのプロジェクトに関連していた。 他のすべてのプロジェクトは、プロジェクトの利害関係者とのコミュニケーションの手段として直接接触を使用しましたが、これらのプロジェクト これらの両方の要因は、協力のための困難な条件を意味します。
プロジェクトと明確に定義されたプロジェクトスコープ
プロジェクトは、通常、不確実性と未知の要因と関連しており、あいまいさにつながります。 そのため、プロジェクトの初期段階では、詳細な範囲と仕様を開発することはできません。 プロジェクトの範囲は、プロジェクト全体で継続的に変更されます。 時には、プロジェクトの当初の目的も変更されることがあります。 調査対象のプロジェクトのうち、40％は明確に定義された範囲を持っていますが、別の45％はそうではありませんでした。
しかし、プロジェクトの80%は少なくとも一度はスコープの変更を経験しており、これは以前に提示された議論を検証している。
プロジェクト管理の実践とPMBOK®Guideプロジェクトライフサイクル
PMBOK®Guideは、精巧なプロジェクト管理のライフサイクルプロセスを開発しました。 ただし、PMBOK®Guideプロジェクト管理ライフサイクルのすべてのプロセスをすべてのプロジェクトに適用する必要はありません。 その採用はプロジェクト固有のものでなければなりません。 予想通り、プロジェクトマネージャーの45％はPMBOK®Guideプロジェクトライフサイクルのプロジェクト管理慣行に従っており、別の45％はそうではありませんで
反復または段階的なプロジェクト計画
スコープ定義とプロジェクト管理計画は、プロジェクト計画の一部です。 先に説明したように、スコープと仕様の詳細な開発は、プロジェクトの早い段階で開発することはできません。 その結果、プロジェクトの範囲はプロジェクト全体で継続的に変化し、アジャイルメソッドの重要な特徴である反復的または段階的なプロジェクト計画の重要性を強調しています。 反復的または段階的なプロジェクト計画がプロジェクトのために続いているかどうかを尋ねられたとき、回答者の半分はイエスを示し、唯一の15％ 興味深いことに、反復的なプロジェクト計画の実践に反対したすべての人は、最初はプロジェクト計画を持っていなかったことに注意してください。
文書化と標準への準拠
プロジェクト文書は、履歴データの分析のための参照として機能し、組織がプロジェクト管理プロセスを継続的に改善し、標準 この文書は、学んだ教訓を特定し、プロジェクト管理の成熟につながるプロジェクト管理システムを変更するのにも役立ちます。 OMB300とISO9000は、プロジェクト文書システムの設計のガイドとして機能します。 具体的には、多くの政府プロジェクトはOMB300ガイドラインを遵守する必要があります。 回答者のうち、80％は、彼らが管理していたITプロジェクトは、ISO9000やOMB300のような基準への遵守などの文書要件を持っていたと言いました。 しかし、ITコンサルティングプロジェクトのためのこれらの要件は、限られた範囲で適用されます。
ユーザー受け入れテスト手順
顧客満足度は、プロジェクト成果物アイテムの品質と成功の主要な尺度です。 したがって、ユーザー受け入れテスト手順は重要であると考えられています。 サービスなどの具体的でないプロジェクト成果物の場合でも、プロジェクトの成功の基礎となる尺度は顧客満足度です。 しかし、それは主観的です。 回答者のわずか30％は、彼らがプロジェクト全体でユーザー受け入れテストの手順に従ったと回答し、回答者の45％がそうではありませんでした。
プロジェクト関連の意思決定を行うためのエンパワーメント
一般に、プロジェクト管理者は、プロジェクトの範囲やプロジェクト成果物に大きな影響を与えない場合、顧客の介入なしにプロジェクト関連の意思決定を行うための自由な手を与えられるべきである。 プロジェクトマネージャーが顧客の介入なしにプロジェクト関連の意思決定を行う権限を与えられていることに同意したのは15％だけです。 約40％が中立のままであり、残りの45％はプロジェクトマネージャーがこの力を持っていないと述べた。 これらのプロジェクトは、外部および政府のプロジェクトであることを考えると、これらの結果は理にかなっています。
結論
私たちの研究結果は、プロジェクトの大部分が要件によって駆動されていることを示しています。 この研究に代表されるほぼすべてのプロジェクトは、変化に適応可能であることを示しました。 非公式のコミュニケーションは、正式なプロセスやシステムよりも重要であると考えられています。 研究のプロジェクトが政府の仕事に関連していることを考慮すると、結果は、プロジェクトチームが包括的な文書よりもプロジェクトの実行に焦点を当てていることを示しています。 さらに、契約交渉上の顧客の共同作業は、プロジェクトチームのためのより良い作品。 頻繁なプロジェクトスコープの変更は、反復的または段階的なプロジェクト計画の重要性を意味します。 この調査で示されているすべてのITコンサルティングプロジェクトが契約であることを考えると、調査結果は、ITコンサルティングプロジェクトに機
プロジェクトに対するアジャイルメソッドの適合性は、プロジェクトの計画、監視、および制御に関する文書に関する契約上の義務です。 連邦政府に関連するプロジェクトには、通常、ISO9000やOMB300のような標準の遵守など、重要な文書要件があります。
課題は、従来のプロジェクト管理慣行の包括的なプロセスのいくつかを取り入れながら、俊敏性、変化への迅速な対応、柔軟でシンプルな計画、継続的