EPM 開発のロードマップ作成における GPS アシストGPS assistance in roadmapping an EPM deployment

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. EPM の実装を計画するときに、エンタープライズプロジェクト管理を展開するための「ロードマップ」を作成する方法について説明します。It describes how to make an Enterprise Project Management deployment "roadmap" when you plan to implement EPM. 展開パスを計画する際に考慮すべき要因について、一意に説明します。It uniquely describes factors to consider when you plan your deployment path.

その他の記事については、 ホワイトペーパー「Trenches」を参照してください。To see more articles, see "From the Trenches" white papers.

G.P.S.G.P.S. EPM 展開のロードマッピングのサポートAssistance in Roadmapping an EPM Deployment

前回のコラムでは、Microsoft の Enterprise Project Management (EPM) ソリューションの展開を計画するための段階的なアプローチを使用することについて説明してきました。In my last column, I talked about using a phased approach to making your plans for a deployment of Microsoft's Enterprise Project Management (EPM) Solution. 本日は、プロジェクト計画の一環として、EPM 展開のロードマップの作成に取り組みます。Today we'll tackle making an EPM deployment roadmap as part of your project plan.

Microsoft Live Maps を使用している場合は、宛先と原産点の2つが必要です。If you've been to Microsoft Live Maps you know that directions require two things: A destination and a point of origin. この比喩を EPM 展開に適用する場合は、次のような用語を考える必要があります。When we apply this analogy to an EPM deployment we have to think in similar terms:

  1. テクノロジ、プロセス、および個人の用語で定義された出発点Point of origin defined in technology, process, and personnel terms

  2. ビジネス用語で定義された送信先と優先順位付けDestination defined in business terms and prioritized

また、再グループ化、写真の撮影、シーナリーを楽しんで、voyage の次の区間でサプライを補充するために、いくつかの方法でいくつかの方法を定義することもできます。We may also want to define some 'way stations' or interim stops where you can regroup, take pictures, enjoy the scenery for awhile and replenish your supplies for the next leg of the voyage.

ロードマップまたは道順の作成時には、2つのスケールを用意することが非常によくあります。When making a roadmap or directions, it's pretty common to have two scales. 次の旅行の旅行は、ターンツーターンルートにまで深くしています。We keep the next leg of the trip in great detail, down to a turn-by-turn route. ただし、旅行全体の上位レベルのマップを詳細に表示しないようにすることもできます。これにより、旅行全体のコンテキストに現在の区間を維持できます。We might also, however, keep a higher level map of the entire trip in less detail to keep our current leg in the context of the entire trip. プロジェクト管理の用語では、この「ローリングウェーブ計画」を呼び出します。In project management terms, we call this "rolling-wave planning."

方向性"Directions"

EPM の展開のロードマップを作成する場合は、常に、EPM の取り組みの観点から、会社が針路を示しているビジョンまたは目標から始めます。When making an EPM deployment roadmap, we always start with the vision or intention of where the company is heading in terms of its EPM efforts. これにより、Microsoft Live Maps と同じように指示を行う必要があります。This gives us the destination we'll need to make directions just like Microsoft Live Maps would.

シアトルから Montreal へのルートを示すマップ

「何をすればよいですか」と尋ねられた場合は、If we were just to ask, "What do you want?" この答えは、ほとんどの場合、ソリューションの面から見てきます。the answer almost invariably comes in terms of a solution. "" と表示されているレポートが必要です "または" 企業がポートフォリオ分析を必要としています "と言っている可能性があります。People are likely to say "I need a report that looks like this" or "Our firm needs portfolio analysis."

ソリューションのビジネスにおいては、このような設計メモにはリスクが fraught あることがわかっています。For those of us in the solutions business, we know these kinds of design notes are fraught with risk. お客様の問題を解決するために、お客様をリッスンするコンサルタントを教育しています。We train our consultants to be listening for clients who describe their problem as a solution. "これは問題の解決策です" とは言いますが、これは問題ではありません。"That's a solution to a problem," we'll say, "not the problem. 問題を定義してみましょう。Let's define the problem."

そのため、「何をすればよいですか」という質問は表示されない傾向があります。So we tend not to ask "What do you want?" 代わりに、構想の際に役に立つ可能性のある質問には、次のようなものがあります。Instead, questions that may be useful during an envisioning might include:

「ビジネス上の意思決定を行うことができなくなりましたが、非常に難しいのは、この EPM の展開の結果としての方が簡単になってしまいます。"What business decision are you now unable to make or are able to make only with great difficulty, the making of which would be made easier as a result of this EPM deployment?"

またはOr:

「スループットが向上するか、またはこの EPM 展開の労力が減少することによって、組織のどのような側面がより効率的になりますか?」"What aspect of the organization do you believe could be made more efficient either through an increase in throughput or a decrease in effort through this EPM Deployment?"

このような質問に答えるべきではありませんか。Now, who should we be asking these questions of? なぜこのような決定を行うのか、もちろんです。Why, the people who make these decisions, of course! すべての子供がいっぱいになっていて、宛先として移動する必要があるという質問をしたことがある場合は、50の回答を得ることができます。If you've ever had a minivan full of kids and turned to ask them where you should go as a destination, you know that you'll get 50 answers.

同じトークンを使用して、組織の意思決定者がこのプロセスの重要な部分であることを確認するか、または "ドライバー" が転送されないようにするというリスクを負う必要があります。By the same token, we need to make sure that the organization's decision makers are a key part of this process or we run the risk of picking a direction that the "driver" isn't prepared to travel to. この時点で、上級管理を EPM のロードマッピングプロセスに追加することには、さらにメリットがあります。There's an additional benefit to bringing senior management into the EPM roadmapping process at this time. EPM の展開によって得られる方向を選択する際の重要な要素とは別に、プロジェクトの規模を理解することもできます。Aside from being a critical participant in choosing the direction the EPM deployment should go, they are also able to get a sense of the magnitude of the project. EPM の展開を成功させるための最も一般的で困難な課題の1つは、長期的な管理サポートです。One of the most common and difficult challenges to a successful EPM deployment is long-term management support. 一部の上級管理職は、この方法によって、既存のプラクティスと手順がどの程度変更される可能性があるかということ、また、一時的に中断している場合もあります。Some senior executives have not considered just how much this might change existing practices and procedures and how disruptive, even temporarily, this might be. また、EPM のようなカルチャ変更プロジェクトの工数を認識していない場合もあります。They may also not have an appreciation of how much effort a culture-change project like EPM may be.

上級管理とプロジェクト管理、および場合によってはライン担当者との作業中に、ビジネス上の意思決定またはビジネスの効率をプロセスとテクノロジと結び付けることに努めます。During our work with senior management as well as project management and perhaps line personnel, we try to connect business decisions or business efficiency with process and technology. この要件を満たすために作成する必要があるプロセスはありますか。Is there a process that must be created in order to fulfill this requirement? 何を行う必要があるか。What would it need to accomplish? そのビジネス上の意思決定を行うために、存在しているか、または作成する必要があるシステム関数があるか。Is there a system function that either exists or must be created to serve that business decision? 提供する必要があることWhat would it need to deliver?

このフェーズでは、基本的なシステム分析が重要です。Basic systems analysis is key in this phase. ビジネス意思決定 "出力" から始めて、これらの決定を行うために必要なデータ要素に戻ることができます。We start from the business decision "output" and work our way back to the data elements required to make those decisions. 場合によっては、基本的なデータがそこにないことがわかります。この結果、ロードマップのその要素が「高リスク」としてフラグ設定されます。In some cases, we find that the basic data simply isn't there and this results in that element of the roadmap being flagged as "high risk." それでは、より優れたビジネスプロセスを実現することを考える前に、新しい形式または構造にデータ収集を追加して、場合によっては高い順序で行うことができるようになります。After all, we'll now need to include collecting data in a new format or structure to capture those new data elements before we can even think of delivering the better business process, and that can be a tall order in some cases.

宛先のプロセスを閉じる前にもう1つのことができます。また、最終的なビジョンのさまざまな要素に優先順位を付けています。We have one more thing to do before we close off the destination process and that's prioritizing the different elements of the final vision. ロードマッピングプロセスの開始時には、優先度が1つの方法になると考えていますが、実際には異なることを記録していることを確認してください。It is very common to think at the beginning of the roadmapping process that the priorities will go one way but find that as you go to actually record them that they go very differently. 興味深いことに、宛先に含まれている対象について全員が合意した時間によって、優先度の高いものについて合意が得られます。Interestingly, by the time everyone has agreed on what targets are included in our destination, there is remarkable consensus on what the top priorities should be.

次に、指示に必要なことは、起点として、選択した目標に関連した組織の現在の場所のインベントリを通じて管理します。The next thing we need for directions is a point of origin and we manage that through an inventory of where the organization is now in relation to the goals we've chosen.

シアトルから Montreal へのルートを示すマップ

既存の担当者を探します。We look at existing personnel. 特定の役割についてプロジェクト管理でトレーニングを受けているか。Are they trained in project management for their particular roles? 設定された目標を達成するのに十分な経験を持つ担当者がいますか?Do we have sufficient personnel with sufficient experience to accomplish the goals that have been set? 最終的なエンタープライズプロジェクト管理プロセスでは、ユーザーごとに役割が異なるため、複数の手段を検討する必要があることに注意してください。Remember that we have to look at multiple measures here because different people will have a different role in the eventual enterprise project management process. 実際には、スケジュールを作成する責任を負わない場合は、すべての従業員をプロジェクトスケジューラとしてトレーニングすることは無意味です。It makes no sense to train every employee to be a project scheduler if, in fact, they'll never be responsible to create schedules. 既定では、管理者、プロジェクトマネージャー、個々のリソース、および重役という4つのロールがあると考えられます。By default, we think of four roles: Administrator, Project Manager, Individual Resource, and Executive. タイムシートが関係している場合、監修者は5番目の役割でもあると考えられます。If timesheets are involved, we think also of Supervisors as fifth role. もちろん、元の構想プロセスで定義されている場所によっては、役割がまったく異なる場合があります。Of course, depending on what destination we've defined in our original envisioning process, the roles may be quite different. これにより、スキルインベントリプロセス profoundly が変更されます。このため、起点を考える前に、常に対象を定義することから始めます。That changes the skills inventory process profoundly, which is why we always start by defining the destination before thinking about the point of origin.

また、既存のプロセスも参照してください。We also look at existing process. 記載されている、または文書化されたプロジェクト管理プロセスはありますか。Is there a stated or documented project management process? どのように管理されますか。How is it maintained? 担当者は誰ですか。Who is in charge of it? プロジェクト管理オフィスが既に確立されている場合、この作業の多くは、それに焦点を絞っています。If there is a Project Management Office already established, then a lot of this effort is focused there. すでに、既存のプロシージャとプロセスが既に有効になっている場合は、新しいプロシージャを作成するポイントはありません。After all, there's no point in creating new procedures if there are existing procedures and processes that are already effective. EPM 環境の最終的な目標に応じて、現在のプロジェクト管理プロセスの内部と外部の両方の既存のプロセスをインベントリに含めることができます。We may inventory existing processes that are both inside the current project management process and outside, depending on what the ultimate goals of the EPM environment will be.

たとえば、契約管理が新しい EPM 環境の重要な要素であると判断し、この組織内のプロジェクト管理プロセスの一部になっていないことがわかります。For example, we may have decided that contract management is going to be a significant element of our new EPM environment, and that this has never before been part of the project management processes within this organization. しかし、フィールドの位置が少し離れている場合は、SharePoint などでドキュメントを管理するための厳密なコントロールセットが組織に存在することがわかります。Yet, if we look a little farther afield, we may find that the organization has a strong set of controls for managing documents and existing workflow already moving documents, perhaps in SharePoint. これは、採用するのに最適なプロセスであり、必要に応じて調整して、新しいエンタープライズプロジェクト管理環境のこの側面を確実に強化するようにします。This would be an ideal process for us to adopt and, if need be, adjust to make sure it will empower this aspect of the new enterprise project management environment. これにより、3本のエッジのメリットが得られます。Doing so carries a triple-edged benefit. 最初に、新しいプロセスを作成するための労力を費やす必要はありません。First, we don't need to expend the effort creating a new process. 2番目に、このプロセスをこの方法で使用するためのスキルと習慣が担当者に既に与えられていること、つまり、お客様に準拠するためのトレーニング作業や労力がないことがわかっています。Second, we know that the personnel already have the skills and habits to use the process in this way, which means no training effort or effort to get the personnel to comply. 最後に、契約書などのドキュメントを管理するための既存のプロセスで問題が発生する可能性がある別のプロセスを作成しようとするのは困難な状況ではありません。Finally we don't have the difficult situation of trying to create a separate process that might be at odds with an existing process for managing documents, such as contracts.

最大の課題の1つはコンプライアンスになるということです。We know that one of our biggest challenges is going to be compliance. システムを構築するのではなく、すべてのユーザーがそのシステムを使用して一貫して使用できるようにします。Not building the system, but getting everyone to use it and to use it consistently. 組織に埋め込まれている既存の習慣、プラクティス、手順を採用することができるようになるほど、コンプライアンスが容易になります。The more we can adopt existing habits, practices, and procedures that are embedded in the organization, the easier compliance becomes.

最後に、テクノロジプラットフォームのインベントリが必要です。Finally, you need an inventory of the technology platform. Microsoft EPM ソリューションはテクノロジのプラットフォームに基づいて構築されているため、そのテクノロジの一部が既に導入されている可能性がありますが、機能するように設計しているソリューションを使用するために、組織はそのプラットフォームの一部をアップグレードする必要があります。Since the Microsoft EPM Solution is built on a platform of technology, it is likely to find some of that technology already in place, but it's also possible the organization will have to upgrade some of its platform in order for the solution you're designing to function. SharePoint と SQL Server は、Microsoft Office Project Server の展開における明白な要素ですが、ブラウザーの互換性 (「Internet Explorer の最新バージョンを使用している場合がありますか?)」、「セキュリティの状態 (システムは外部に接していますか?)」、「どのバージョンの SQL Server が展開されていますか?SharePoint and SQL Server are obvious elements of deploying Microsoft Office Project Server, but you may also need to check on browser compatibility (is everyone using the latest version of Internet Explorer?), security status (will the system be outward facing?), what version of SQL Server is deployed (is OLAP Services or SQL Server Reporting Services already being used?). また、他のシステムについても、インターフェイスまたは統合する必要がある場合があります。You may also need to consider other systems with which you'll need to interface or integrate. 運用環境でこれらのシステムにアクセスするには、どのような方法がありますか。How will you get access to those systems in production?

また、計画されたシステムの規模によっては、ハードウェア、ネットワーク、その他のインフラストラクチャ要素を調べて、システムが到着したときに必要となる構造を確保する必要があります。The size of the planned system may also necessitate looking at hardware, network, and other infrastructure elements to ensure the system will have the structure it requires when it arrives.

他のエンタープライズシステムと同様に、運用環境とステージング領域の両方を計画して、ライブシステムではなく、更新と拡張機能をラボで作成できるようにする必要があります。As with any enterprise system, you'll want to plan both a production and staging area so that updates and enhancements can be created in the lab rather than on the live system over time. パイロットまたは概念実証フェーズのプランを作成する必要がある場合もあります。次の列で詳しく説明します。You may also have to make plans for a Pilot or Proof of Concept phase; something I'll talk more about in my next column.

"ルートの再計算""Recalculating Route"

G.P.S.When the G.P.S. 車のユニットで、旋回が欠落したことがわかります。「ルートを再計算する」という音声がわかります。unit in my car discovers that I've missed a turn, a very nice lady's voice says "Recalculating route". その後、地図の行が変更され、新しい道順が表示されました。Moments later, the line through my map changes and I've got new directions. EPM 展開では、detour または修理がブロックされているターンの準備が整っている必要があります。In an EPM deployment we need to be ready for a detour or a turn that's blocked for repairs. その場合、高速道路の出口を見逃したことがあります。Perhaps we missed that freeway exit. どのようにして replanning 処理しますか?How do we deal with replanning? コースを終了するときに、次の2つの点を確認する必要があります。最初に、同じ場所に移動しますか?There are two things to ask when you go off course: First, are you still going to the same place? 2番目に、ここから取得する方法Second, how do we get there from here? この話題に関するお気に入りのプロジェクト管理見積もりの1つとして、ナポレオン Bonaparte (「敵プランは敵に接触するまで)」と言われています。One of my favorite project management quotes on this subject comes from Napoleon Bonaparte, who once said, "A battle plan lasts until contact with the enemy."

シアトルから Redmond へのルートを示すマップ

EPM 展開では、この原則を適用する方法を教えてください。In an EPM deployment how do we apply this same principle? 最初に、コースが終了しているかどうかを判断するための測定を行う必要があります。First of all, you need a measure to determine if you're no longer on course. 1つのチームメンバーに明日の緊急歯科医の予定があり、4時間以内に不在になっている場合は、その不一致をすべての下流のタスクに変更し、正午からプロジェクトの終わりまですべてのユーザーを再スケジュールして、すべてのユーザーに新しい割り当て時間を送信しますか。If one team member has an emergency dentist's appointment tomorrow and is absent from the office for four hours, should we then let that discrepancy change all downstream tasks, reschedule everyone from tomorrow at noon through the end of the project, and then e-mail everyone with their new assignment times?

もちろん、ありません。Of course not.

1人のリソースに対して、6か月にわたる1つのリソースについての相違がある場合は、パスの変更を十分に確保するには、多数のユーザーが関与するだけでは不十分です。A discrepancy of four hours for one resource over the six-month lifetime of a project involving dozens of people isn't enough of an interruption to warrant changing our path. あらゆる種類のエンタープライズプロジェクトを開始するには、許容できる進捗状況のしきい値を設定する必要があります。What we need to do in starting any kind of enterprise project is to set thresholds of acceptable progress. 航空宇宙および防衛局は、この最近の "Tripwires" に関する新しい用語を示しています。これは、非常にわかりやすいものです。The aerospace and defense world is finding a new term for this lately, "Tripwires," which is very descriptive. ルートを再計算する必要があると判断する基準を決めることができます。We can establish what criteria would indicate to us that our route needs to be recalculated. 考慮すべき一般的な指標または手段がいくつかあります。There are several typical metrics or measures to consider. 最初に、予想される完了コストが元の予算から X% を超える場合は、プロジェクト計画のレビューを構成する可能性があります。First, if the projected completion cost varies by more than X percent from the original budget, then that might constitute a project plan review. 人件費または金額の測定を行うことができます。You might do the measure of cost in labor hours or money. どちらも有効です。Either is effective. 予想終了日が、最初に予定された終了日から X 日を超えて変化する場合は、プロジェクト計画のレビューを構成する可能性があります。Perhaps if the forecasted finish date varies by more than X days from the originally planned finish date, then that might constitute a project plan review.

特定の日数よりも多くの特定の重要なマイルストーンが tripwire にないことや、tripwire として認識されている特定のリスクを特定したり、エグゼクティブスポンサーなどの主要なプロジェクトチームメンバーの変更が tripwire であると判断することもあります。You might also decide that missing certain key milestones by more than a certain number of days is a tripwire, or you might identify certain risks being realized as a tripwire, or you might determine that a change of certain key project team members such as the executive sponsor is a tripwire. 条件を正確に取得するよりも、いくつかの条件を設定することが重要です。It's more important to set some criteria than to get the criteria exactly right. また、プロジェクトの有効期間全体にわたってこれらの条件について測定する必要があることに注意してください。50または100の異なる測定基準を選択すると、プロジェクトを実行するよりも多くの時間を費やすことになります。Also, remember you're going to need to measure against these criteria throughout the lifetime of the project, so if you choose 50 or 100 different metrics, you could end up spending more time measuring the project than doing the project!

コースがオフになっていることを確認したら、プロジェクト計画レビューを実施することをお勧めします。Once you've determined you're off course, the best way to get back on track is to conduct a project plan review. 元のインベントリの作成を支援した、プロジェクト管理チームのグループから、最初の場所に移行先を確立した経験を持つ上級管理グループの両方からの表現を含めることをお勧めします。We recommend including representation from both the original group of senior management who helped establish our destination in the first place and from the group within the project management team who helped do the original inventory. プロジェクト計画のレビューでは、プロジェクトが停止している理由や、特定の tripwire がトリガーされた理由に関する mired を回避することができます。Project Plan reviews can get mired down in assigning blame for why the project is off track and why a certain tripwire has been triggered. このような作業には、hugely の逆効果があります。Such effort can be hugely counterproductive. 次の質問に絞っておくことをお勧めします。We recommend focusing on the following questions:

  1. 何が起こったのでしょうか?What happened?

  2. 終了した場所Where have we ended up? 現在の出発点は何ですか。What's our current point of origin?

  3. 今でも元の場所にコミットされているか、またはそのプロセスを確認したり、構想プロセスをやり直したりするための説得力のある理由がありますか。Are we still committed to our original destination or is there a compelling reason to review that process or even redo the envisioning process?

  4. 中間のマイルストーンまたはフェーズをリセットする必要がありますか?Do we need to reset any of our intermediate milestones or phases?

  5. プロジェクトチームを変更する必要があるかどうか。Do we need to change any of our project team?

  6. すべての tripwire 指標をリセットする必要がありますか?Do we need to reset any of our tripwire metrics?

ここでは、生産性を低くするために、次のような質問があります。Questions which we've found to be less productive include:

  • エラーが発生していますか?Whose fault is it that we're here? 誰が責任を持つかWho's responsible? 対象読者Who's to blame?

  • どのような方法でトラックの "戻る" を取得しますか。古いプランに戻るHow do we get "back" on track; back to the old plan?

プロジェクト計画のレビューを行う最も一般的な理由は、組織の優先度が変化することです。The most common reason for a project plan review is that the organization's priorities shift. たとえば、フェーズ3で使用するように設計されたアイテムは、フェーズ2で要求されています。For example, items that were designed to be in Phase 3 are being demanded in Phase 2. これは通常、組織内での正常な動的の兆候です。また、EPM システムの展開の影響について真剣に検討を開始した人々の結果になります。This is usually a sign of a healthy dynamic within the organization and the result of people starting to think seriously about the implications of the EPM System's deployment.

不適切な天気Bad Weather

長いドライブに設定する前に、天気予報チャネル (または weather.msn.com) をチェックして、inclement 天候が voyage に影響しないことを確認してください。Before you set out on a long drive you probably check the Weather Channel (or weather.msn.com) to make sure no inclement weather will affect your voyage. リスクは、ライフサイクルの一部です。Risks are a part of life. リスクがない場合は、プロジェクト管理者が必要ないことに注意してください。Remember, if there were no risks, there'd be no need for project managers! 最も glaring リスクを計画することは、複雑なプロセスではありません。Planning for the most glaring risks is not a complicated process. 構想プロセスの開始時に開始し、設計する展開先の各要素を調べながら、グループに、考えられる、この送信先に到達する障壁を問い合わせます。Start at the beginning of the envisioning process, and as you look at each of the elements of the destination you are designing, ask the group what barriers to reaching this destination they can think of. リスクが大きくなる場合があります。In some cases the risks will be significant. 組織で特定の結果が求められることは珍しくありません。その結果を提供するために必要な生データが収集されたことがなく、そのデータの収集に対してかなりの抵抗があるかもしれません。It's not uncommon for an organization to desire a particular result, only to find that the raw data required to deliver that result has never been gathered and that there may be considerable resistance to the collecting of that data.

Montreal の天気予報を示す MSN ページ

1つの例では、リソースの容量計画を必要とする組織が見つかりました。In one example, we found an organization that wanted resource capacity planning. これには、すべてのプロジェクト担当者のすべてのリソースの利用可能時間の完全な会計と、それらのスタッフに適用される可能性のあるすべてのワークロードを完全に会計する必要がありました。That was going to require a complete accounting of all of the resource availability of all project personnel and a complete accounting of all of the possible workloads that could be applied to those staff. 両方が利用可能であるかどうかが確認されたときに、それらが使用可能であったのは、組織の fifths の場合のみであることが伝えられました。When we asked if both of those were available, we were told that sure, they were available but only for two-fifths of the organization. Fifths が構想会議でさえも表示されていないためにデータが利用できなかったという組織の3つのが見つかった場合は、「推測してみましょう」と言います。When we then discovered that the three-fifths of the organization that the data was not available for weren't even represented at the envisioning meeting, we said, "Let us guess. リソースの処理能力の計画で発生している問題は、これらの3つの部門にあります。The problems you're experiencing with resource capacity planning are in those three divisions." 当然のことですが、プロジェクトの別のフェーズとしてこれらの区分の部門リーダーを登録し、リスクを非常に高くすることを特定する必要がありました。Naturally they were, and we had to identify enrolling the division leaders of those divisions as a separate phase of the project and very high risk.

在庫プロセスのプロジェクト管理およびライン担当者と連携するようになると、これらの担当者が特定できるリスクがあるかどうかについて、インタビュー中に確認してください。As you move on to work with the project management and line personnel in the inventory process, ask during the interviews for any risks these personnel might be able to identify.

リスクを特定したら、それらを整理することが重要です。Once the risks have been identified, it's important to organize them. これまで行っていない場合は、最も基本的な情報が最も重要です。If you've not done this before, the most basic information will be the most valuable. 次の内容を含めます。Include:

  1. リスクの簡単な説明A short description of the risk

  2. プロジェクトの領域またはフェーズが影響を与える可能性があるThe area or phase of the project which it may impact

  3. 基準が実現された場合のリスクの重大度The severity of the risk if the criteria is realized

最後に、リスクを軽減するための詳細を追加することをお勧めします。Finally, one of the most important things you can do is to add some details on risk mitigation. リスクについて検討することは、非常に緩和された要因ですが、EPM の展開は infancy であり、プロジェクト中の特定のリスクをどのように処理するかについての注意を入力します。Just thinking about a risk is a huge mitigating factor, but while the EPM deployment is in its infancy, entering some notes on how you might deal with a particular risk during the project can be invaluable. リスクが実現したときに感情的なコンテキストで haste で決定されることはよくあります。It's common for decisions to be made in haste in an emotional context when risks are realized. 「いいね!」の「prevailed」のように、考慮すべきメモが役に立つ場合があります。Having some notes that were thought out while cooler heads prevailed may be useful.

作成している自動車を推進しましょうLet's drive the car we're building

大きな配当を払うようなロードマップを作成するためのヒントを次に示します。「Project Server」および「Microsoft EPM Solution」を使用して、ロードマップ計画を作成して管理します。Here's a tip on making your roadmap that may pay huge dividends: Use Project Server and the Microsoft EPM Solution to help make and manage your roadmap plan. よくあるように思えますが、ここで言及しているのは組織にとって十分なことです。It seems obvious perhaps, but it's rare enough for organizations to do that we mention it here.

プロジェクトの成果物の一覧が表示されている SharePoint サイト

Microsoft epm ソリューションを使用して Microsoft EPM ソリューションを展開することを検討していた場合、シニアマネージャーは、自分のプロジェクト担当者に依頼されたことを示しています。I had a senior manager once tell me that his project staff had asked him if he thought using the Microsoft EPM solution to deploy the Microsoft EPM Solution wasn't overkill. 「生きたときにジェット機を構築した場合、その飛行機は動きません」という話があります。"If we built jet planes for a living, we wouldn't fly them to work," they said. 「冗談ですか?」"Are you kidding?" 返信しました。he replied. 「ジェット機を使用して作業することができますが、毎日実行しています。"If I could fly a jet plane to work, I'd do it every day!"

実際には、EPM 展開チーム向けに Microsoft EPM ソリューションを使用することをお勧めします。In fact, using the Microsoft EPM Solution for the EPM deployment team is a great idea.

Project Server および Microsoft EPM ソリューションの他の要素をインストールすることは、非常に大きな技術的な課題ではありません。構成の最小要件では、少数のユーザーとして小規模な展開チームで稼働させることができます。Installing Project Server and the other elements of the Microsoft EPM Solution isn't a huge technical challenge, and with the absolute minimum of configuration you can be up and running with a small deployment team as the users within a couple of days. これは、展開エキスパートになるユーザーが、大量のスタッフのデスクに到着する前に、システムの使用と利点について理解を深められるようになる便利な方法です。This is a great way for those users who will become your deployment champions to become familiar with the use and benefits of the system before it arrives at the desks of the bulk of the staff.

この展開は、運用環境であってはなりません。This deployment shouldn't be your production environment. ほぼ確実に、元の場所のビジョンを満たすように構成し、カスタマイズすることができます。You'll almost certainly be configuring that and customizing it to fulfill the vision of the original destination. Project Server の EPM 展開イテレーションでは、複数プロジェクトのスケジュール設定やリソースの容量計画、ポートフォリオの最適化などの作業を行うのはほぼ間違いありませんが、大きなメリットを提供できるシステムを提供することができます。You almost certainly won't be working on things like multi-project scheduling or resource capacity planning or portfolio optimization in your EPM deployment iteration of Project Server, but you'll be able to deliver a system that can deliver great benefits. 次のことをお勧めします。We'd recommend:

  1. パブリッシュされたプロジェクトとして、ローリングウェーブスケジュールを実行します。Do a rolling wave schedule as a published project.

    ローリング wave スケジュールは、概要の詳細として、現在のフェーズを詳細で、今後のフェーズで強調します。A rolling wave schedule highlights the current phase in great detail and future phases as more of a summary. これにより、チームメンバーは、今すぐに作業する必要があることを把握できます。また、プロジェクトをより大きなコンテキストで表示することもできます。This lets the team members know what they need to be working on now and still lets them see the project in a larger context.

  2. プロジェクトワークスペースのビジョンドキュメントを管理します。Manage the vision document in the Project Workspace.

    プロジェクトワークスペースは、プロジェクトに関連付けられた SharePoint サイトで、既定では、懸案事項、リスク、およびドキュメントの領域が含まれています。The Project Workspace is a SharePoint site tied to the project which by default includes an area for Issues, Risks, and Documents. EPM 展開プロジェクトにすべてのプロジェクトドキュメントを配置し、SharePoint のバージョン管理を作成して、元のバージョンにいつでも戻ることができないのはなぜですか。Why not put all your project documents here for the EPM deployment project and institute SharePoint's version control so that you can always get back to the original version?

  3. プロジェクトワークスペースの成果物に、マイルストーンのサインオフと "ゲート" を追加します。Put your milestone sign-offs and "gates" in the Project Workspace deliverables.

    これは、Project Server のタスクにリンクできる簡単なタスクリストです。This is a simple task list that you can link into tasks in Project Server. これにより、プロジェクトが非常にハイエンドに表示され、しきい値の管理を使用して "オフコース" に進むタイミングを判断するための簡単なツールとなります。It will give a very high-end view of the project and is an easy tool to use for threshold management to determine when you go "off course."

  4. 変更管理をプロジェクトワークスペースに懸案事項として配置します。Put change management into the Project Workspace as issues.

    変更管理は、テクノロジプロジェクトの大きな課題の1つです。Change management is one of the great challenges of technology projects. プロジェクトへの変更に関する新しい提案が発生した場合は、管理される可能性のある変更点として、懸案事項領域に追加します。As new suggestions for changes to the project arise, get them into the Issue area as a potential change to be managed. この領域にいくつかのフィールドを追加することで、優先度の高いアイテムのリストを取得し、いつでもそのアイテムの責任者を取得することができます。By adding a few fields to this area you can get a list of high-priority items and who is responsible for them at any time.

  5. プロジェクトのリスクをプロジェクトワークスペースに追加します。Put the project risks into the Project Workspace.

    ドキュメントや問題とは別に、ワークスペースのリスク領域は、リスクと軽減計画を追加するのに最適な場所です。Aside from documents and issues, the risk area of the Workspace is the ideal spot to add your risks and mitigation plans. 実際には、既定の画面にすべてのフィールドが用意されており、これを使用することができます。In fact, the default screen has all the fields there ready for you to use.

目的地に着きましたか?Are we there yet?

許容."Almost. すぐにご利用いただくことができます。」We'll be there soon."

EPM を展開すると、組織はさまざまな場所に配置できるため、すべてのユーザーの既定のスケジュールを単純に公開することはできません。An EPM deployment can bring an organization to so many different places that there's no way to simply publish the default schedule for everyone. ただし、インターネットの検索には数分で、プロジェクトのさまざまな部分について多くの例が用意されています。But a few minutes searching the Internet may provide you with lots of possible examples for different parts of the project. 上記のロードマップの手順を要約した場合、次のようないくつかの明確なフェーズを備えたプロジェクトが完了する可能性があります。If I summarize the roadmap exercise above, you are likely to end up with a project that has a few obvious phases:

  1. ロードマップの手順Roadmap exercise

  2. 構想 (移行先の選択)Envisioning (Choose the destination)

  3. 既存のプロセスのインベントリ (出発点の特定)Inventory of existing processes (Identify the point of origin)

  4. 既存の担当者のインベントリ (出発点の特定)Inventory of existing personnel (Identify the point of origin)

  5. テクノロジのインベントリ (出発点を特定する)Inventory of technology (Identify the point of origin)

  6. Epm チームの EPM ソリューションの展開Deployment of EPM solution for EPM team

  7. フェーズ 1Phase 1

  8. デザインDesign

  9. 構成、カスタマイズ、ドキュメントConfiguration, Customization, Documentation

  10. パイロットPilot

  11. トレーニングTraining

  12. ロールアウトRoll-out

  13. フェーズ1を確認し、必要に応じてフェーズ2を調整するReview of Phase 1 and adjust Phase 2 as required

  14. フェーズ 2Phase 2

  15. フェーズ 3Phase 3

  16. フェーズ 4Phase 4

  17. プロジェクトの折り返しProject wrap up

ロードマップの手順を EPM 展開に適用することで、環境を無秩序なものから管理しやすいものに変更することができます。Applying a roadmap exercise to your EPM deployment can change the experience from chaotic to manageable very quickly. 最初にコピー先を選択してから、元の場所を確認し、その間のパスを描画することを忘れないでください。Just remember to pick your destination first, figure out your point of origin next, and draw the path between them.

ハッピー旅行!Happy traveling!

著者についてAbout the Author

Chris Vandersluis 氏は、Microsoft 認定パートナーである、カナダベースの HMS ソフトウェアである Montreal、創設者の社長およびです。Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. McGill 大学と30年以上のプロジェクト管理システムの自動化において、経済の学位が得られています。He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. プロジェクト管理協会 (PMI) の長期のメンバーであり、Microsoft Project ユーザーグループ (MPUG) の Montreal、トロント、およびケベックの章を見つけました。He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Chris が執筆した刊行物には、フォーチュン、ヘビー建設ニュース、コンピューティングカナダ雑誌、PMI の PMNetwork などが含まれており、彼はプロジェクトの時間の正規の columnist です。Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. McGill 大学の高度なプロジェクト管理を指導しており、北アメリカと世界各地のプロジェクト管理関連機能で講演していることがよくあります。He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software は、TimeControl のプロジェクト指向の timekeeping システムの発行者であり、1995以降の Microsoft Project Solution Partner になっています。HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis 氏は、次の場所に電子メールで連絡することができます。 chris.vandersluis@hms.caChris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

Chris Vandersluis 氏がより多くの EPM 関連記事を読む場合は、「HMS の EPM ガイダンスサイト (」を参照してください https://www.epmguidance.com/?page_id=39) 。If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (https://www.epmguidance.com/?page_id=39).