ITプロジェクトの予算管理

プロジェクトの深刻な問題の1つが期限と予算を超えていることは周知の事実です。請負業者と顧客の両方がこれに苦しんでいます。顧客は期待される結果を受け取りませんし、請負業者は期待されるお金を受け取りません。共通の問題は団結すべきであるように思えますが、それは多くの場合、当事者間の不和の余分なくさびを駆り立てるだけです。締め切りと予算が常に満たされるようにする方法を知っていますか？しません。しかし、私たちはこの方向で何かを達成することができました。私の経験を話す前に、いくつかの基本的な質問に答えたいと思います。顧客が何を望み、プロジェクトを実施するときに請負業者が何を望んでいますか？

私たちのケースでは、顧客が本当にプロジェクトを作りたいという事実から進みます。彼には一定の予算があり、「投げる」つもりはありませんが、結果に対して合意したお金を支払う準備ができています。彼がお金のためにできるだけ多くのことをしたいのは明らかです。そして、あなたが家の修理をするとき、あなたはこれが欲しくないのですか？そして、ビルダーのチームを雇うすべての所有者と同様に、顧客は請負業者が~~それを~~膨らませ、予算を~~膨らませると~~疑うかもしれません。何をすべきかは私たちの現実です。

請負業者は何を望んでいますか？これが詐欺ではない場合、ほとんどの場合、プロジェクトチームはプロジェクトを作成し、経営陣は契約金を得たいと考えています。しかし、経験豊富な請負業者は顧客の希望を知っており（上記参照）、予算が彼の欲求の中で終わる傾向があることも知っているため、請負業者は可能な限り予算を膨らませようとします。

各当事者は、独自の方法で正しいです。これに我慢する必要があり、そのような条件で、最終的に同意することなく、プロジェクトを開始します。しかし、プロジェクトの最初に生じた誤解は、原則として、プロジェクト中にのみ増加し、リードします...悲しいことについては話さないでください。私たちが使用しているプロジェクト管理の原則と方法について説明します。これらはいずれにせよ、期限と予算を満たすことに関連しています。おそらくこれは、誰かが自分のプロジェクトの品質を改善するのに役立つでしょう。当社の専門分野は、EMC Documentum、AlfrescoなどのECMプラットフォームでのワークフロー自動化プロジェクトの実装です。おそらくこれにはある種の特異性がありますが、ここで検討しているトピックについては原則にとらわれないことを望みます。

プロジェクト範囲

最初の重要なポイントは、プロジェクトフレームワークの詳細です（GOSTに準拠-「戦術と技術の割り当て」）。プロジェクトの範囲は、システムに対する顧客の要件が記述されたドキュメントですが、参照条件ほど基本的ではありません。プロジェクトの機能フレームワーク（ビジネス要件定義、BRD）は、コンサルタント/アナリスト-請負業者のプロジェクトチームの従業員-の主要な専門家とのインタビューに基づいて編集されます。プロジェクトの範囲は、プロジェクト中に解決する必要があるすべてのタスクの完全な理解ですが、詳細はありません。プロジェクトの範囲は、プロジェクト中に解決されないタスクのリストでもあります。プロジェクトフレームワークの作成には1〜2週間かかります。調整と洗練は同じくらいかかるかもしれません。現時点では、契約もプロジェクトもないという事実に注目します。そしてこれはリスクです、なぜならプロジェクトが開始されない可能性があります。起草、評価、計画、予算の準備に関する請負業者の作業に対して誰が支払いますか？この質問に自分で答えることをお勧めします。おそらく、上記の質問への回答は、請負業者と顧客があなたのケースで何を望んでいるかを助けるでしょう。私は、プロジェクトフレームワークの詳細なしで得られた用語と予算の見積もりは、現実とは関係のない空想であると断言できます。プロジェクト中に予算と締め切りがい、旅行し、飛ぶことは驚くことではありません。

建築設計

機能フレームワークを顧客と調整した後、コンサルタントはそれらをアーキテクトに渡します。後でプロジェクトを行う建築家に。アーキテクトはプロジェクトの範囲を調査し、コンサルタントに質問し、ソリューション全体のアーキテクチャを検討します。 各特定の要件の実装が2番目の重要なポイントです。その結果、一般的なアーキテクチャのテキストのいくつかの段落が表示されます-使用されるはずのテクノロジー-各要件に対するいくつかの文-開発が提案されているコンポーネントと数日で予想される労働集約度。本質的に、これは「ドラフトデザイン」です。しかし、 GOSTの「Stage 4. Sketch design」が「Stage 3. Reference of Reference」の後に続く場合、この場合、場所を段階的に変更します。アーキテクチャの研究がなければ、複雑さの信頼できる推定を行うことはできません。時には、それを別の文書、つまり「評価」にして、評価と実装案を修正します。これは、Project Frameworkドキュメントの各要件に関するコメントの形で行われる場合があります。建築家の評価には、通常2〜5日かかります。アーキテクトから生じる質問は、コンサルタントが解決しなかった側面を明らかにする可能性があり、追加の調査が必要です。これは素晴らしいプロジェクト中のこれらの問題のリスクは軽減されます。建築家は、建築の精緻化と質問の形成を自分で行うことができます。ただし、プロジェクトチームは、少なくとも構成で、要件の議論と評価に関する最終会議を開催します：コンサルタント、アーキテクト、プロジェクトマネージャー。

ソリューションから生じるシステムのアーキテクチャ上の制限も、ドキュメント「プロジェクトフレームワーク」で修正されています。さらに、ドキュメントには、プロジェクトにとって重要なイベント（顧客が提供する必要のあるリソース、機器の準備のタイミング、トレーニングクラスなど）が記録されます。

プロジェクトフレームワークテンプレートは、 http ： //www.sinera.ru/methodsで確認できます。

作業計画

要件の詳細と実装の理解の後、作業とリソースの予備計画が実行されます。アーキテクトは、特定の要件の実装に関与できる実行者、要件を満たすことが重要な順序、要件間に存在する相互依存関係を決定します。すべての情報はプロジェクトマネージャーによって蓄積され、プロジェクト計画に転送されます。 この時点で、プロジェクトの日付が生まれます。最初は、すべての作品が直線的に並んでいます。次に、タスクはリソースによって分散されます。顧客がタイミングに関して表明した希望に基づいて、また引き付けられたリソースの最適な組み合わせから、プロジェクトの期間が決定されます。「集められたリソースの最適な組み合わせ」とは、単純なアイデアを意味します-プロジェクトのタイムラインは最小限に抑え、できる限り少ない人が参加する必要がありますが、完全に参加する必要があります。そのため、プロジェクトに人々が滞在する期間の推定値があり、これがプロジェクトの予算編成の基礎となります。

MS Projectで作業計画を立てます。

重要な点をほとんど忘れていました。

作業面では、特定のタスクを実行する複雑さを抑えています。アーキテクトによって発行された評価は、これらの要件を誰が実装するかを理解する場合にのみ使用できます。特定の人の名前が必要です。そして、誰がまさにこのタスクに惹かれているのか、アーキテクトによって以前に発行されたこのタスクの評価の修正は、依存します。スコアを調整するには、各特定の開発者の生産性を知ることが重要です。これが3番目の重要なポイントです。生産性を判断する方法については、たとえば、 Joel on Programming and Joelの書籍でJoel Spolskyを参照してください。またプログラミングについて」（第20章同じ結果の計画（EBS）。

システムのインストール、技術仕様の準備、テストなど、作業の残りの部分にも同じことが当てはまります。どのくらいの作業に時間がかかるかを知るために、誰がこの作業を行うかを知る必要があります。実際、プロジェクトを計画および評価するには、プロジェクトチームを編成する必要があります。

予算見積もり

作業計画の結果、プロジェクトに参加している役割と人員、およびプロジェクトに滞在する期間が表示されます。プロジェクトマネージャーとして、Excelスプレッドシートでさらに計算を行います。このようなもの：

RP（パシニン）	5	0.5	2,5	420	2000頁	336 000 p。	840 000 p。
リーディングコンサルタント（Pleshkova）	4	1	4	672	1400 p。	235200 p。	940800 p。
建築家（シャポワロフ）	5	1	5	840	1400 p。	235200 p。	1 176 000 p。
コンサルタント（Korch）	4	1	4	672	1100 p。	184800 p。	739 200 p。
開発主任（ハリトノフ）	3	1	3	504	1400 p。	235200 p。	705 600 p。
開発者（Kolesnikov）	3	1	3	504	1100 p。	184800 p。	554,400 p。
							4 956 000 p。

その結果、 プロジェクトの予算が表示されます。計画と予算編成にはさらに2〜3日かかります。

予算編成の4番目の重要な点は、計画で設定されたタスクの複雑さから、 リソース を引き付ける期間に移行しているということです。ロジックは簡単です。請負業者の費用の主な項目は、スタッフの報酬です。人々が支払った時間よりも長くプロジェクトに参加している場合、請負業者の会社は直接的な損失を被ります。したがって、正確に計画および制御する必要があるのはこのパラメーターです。プロジェクトの予算編成とその管理が、在留期間ではなく、タスクの評価に基づいて実行される場合、専門家の割合には実際のリソース計画を心配しないように高すぎるリスクが含まれることを確認できます。

範囲、期間、予算の明確化

行われた作業の結果、文書を受け取りました。

顧客と合意したプロジェクト範囲
提案されたアーキテクチャと要件の複雑さによるプロジェクトの評価
プロジェクト計画
プロジェクト予算

これは、何をする必要があるか、どのように行われるべきか、どれくらいの時間を要し、どれくらいの費用がかかるかを完全に理解しています。

4つの結果すべてを顧客に提示する必要があります。プロジェクトの予算と期限は、顧客が決定する際の基準となるパラメーターです。要件は、顧客と請負業者が予算と期限を調整するために管理するパラメーターです。予算の見積もりは完全に透過的であるため、時間と予算を削減するために、要件をスローまたは下げることができます。各要件の評価はないため、アーキテクトが推定する実装の複雑さに焦点を当てています。要件を確認した後、プロジェクトマネージャーは同じ原則（最短時間-リソースの最適な負荷）に基づいて、スケジュールを変更します。スケジュール変更後、予算が調整されます。範囲、タイミング、予算は契約の対象です。

フレームワークの形成、計画、評価に関するすべての作業に2〜6週間かかりました。あなたはすでに質問に答えましたか？私の意見では、請負業者と顧客の両方が支払う必要があります。評価の費用を負担する顧客の意欲は、プロジェクトの実施における意図の深刻さを示しています。請負業者のコスト、またはコスト以下の作業のパフォーマンスは、プロジェクトへの関心を示しています。これにより、彼はできるだけ早く評価を行うようになります。これは今や損失のある仕事ですが、最大限の研究が必要です。これらは将来の彼のリスクです。いずれの場合も、状況は異なる場合があります。

時間と予算の管理

アセスメントを実施し、予算と期限に合意しました。契約と仕事の準備ができています。しかし、もう1つの質問に答える必要があります-請負業者は顧客に何を売りますか？一方で、彼は結果を売ります。なぜなら、契約には、請負業者が実行することを約束する作業範囲が含まれています。これは「固定価格」タイプの契約です。一方、彼はリソースを販売しています。予算は、リソースの魅力の持続時間に基づいて編集されます。「時間と材料」。これらはさまざまなタイプの関係です。しかし、評価の徹底、予算を超えることに対する顧客の懸念、および要件の変更の可能性に関する請負業者が消えていないことを理解する必要があります。 変更管理 の原則に関する顧客または請負業者間の特定の合意は、不安を取り除き、契約上の矛盾を解決するのに役立ちます。その本質は次のとおりです。

請負業者は、プロジェクトの範囲が変更されない場合、合意された時間と予算内でプロジェクトの実施を保証します。
請負業者は、作業が予定より早く完了した場合、請負業者の従業員が必要に応じて、追加のタスクの支払予算の枠内でプロジェクトに取り組み続けることを保証します。
プロジェクト中にプロジェクトフレームワークの変更または不遵守があり、条件と予算の変更を伴わない場合、顧客と請負業者の義務は契約の下に残ります。
プロジェクトフレームワークに加えられた変更がリソースの追加の誘引を必要とする場合、追加の契約が作成され、顧客は初期予算を超える作業に対して支払います。

このアプローチでは、請負業者は予算を節約するため、追加の利益を得ることはできません。同時に、お客様には、フレームワークを維持するための追加の明確なインセンティブがあります。変更があり、それに応じてプロジェクトの期限を超過した場合、彼は請負業者のスペシャリストに余分な時間を支払います。請負業者がリソースの割り当てに関する義務を誠実に果たす場合、顧客満足の主な基準は請負業者の専門家の資格です。同じ要因は、プロジェクトの成功にとって最も重要なものの1つです。

まとめると。予算の遵守と期限の重要なポイントは、評価中のプロジェクトの最初に設定され、契約で修正されます。

時間と予算を評価するには、プロジェクトの範囲を慎重に検討する必要があります。時間がかかります。
タスクの複雑さの評価中に、提案されたソリューションのアーキテクチャが作成され、書面で記録されます。
タスクの複雑さの計画は、これらのタスクを実行するスペシャリストの生産性に基づいています。生産性は、各専門家の以前のプロジェクトから計算されたパラメーターです。
予算の計算は、プロジェクトのリソースの期間に基づいています。
このプロジェクトには、契約者によるプロジェクトの期限内の実行に不可欠な機能要件、アーキテクチャ上の制限、および顧客の義務が含まれます。
請負業者は、プロジェクトフレームワークの実施に関する契約に規定されている条件に対して、高品質のリソースをタイムリーに完全に割り当てる義務を負います。顧客は、プロジェクトの過程における変更が条件と予算の増加につながる場合に、追加の予算を割り当てる義務を引き受けます。

将来的には、技術仕様の開発中に、システムを設計および実装する際に、プロジェクトフレームワークの遵守と相互の義務の遵守を明確に監視することのみが残っています。

プロジェクトで頑張ってください！

All Articles