トップダウンか、ボトムアップかTop-down or bottom-up

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. プロジェクト管理、ポートフォリオ管理、およびタスク管理について説明し、それらに関連するトップダウンおよびボトムアップ管理プラクティスを比較します。It discusses project management, portfolio management, and task management, and it compares the top-down and bottom-up management practices related to them.

この記事の Word バージョンをダウンロードするには、「 トップダウンまたはボトムアップ: ホワイトペーパー (Project Server 2010) 」を参照してください。To download the Word version of this article, see Top-down or bottom-up: white paper (Project Server 2010) .

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

トップダウンまたはボトムアップTop-down or bottom-up?

"プロジェクトの管理が必要です..."We need project management… 今回は、ポートフォリオ管理を想定していました。Ummm, I meant portfolio management… um では、実際にはタスク管理を意味しています。Ummm, I really mean task management… これは、すべてのユーザーが必要だということです。「は、よく耳にした戦い cry です。Oh heck, we need all of them," is a battle cry I hear often. 混乱を招くような3つの概念の定義が欠如しているわけではありませんが、その類似性が似ています。It's not a lack of definitions of these three concepts that causes confusion, it's their similarity.

IT 部門で多くのユーザーが何年も携わって作業している場合は、技術的な観点から物事を見る傾向があり、それでもうまく機能しないことがあります。Those of us who have worked in IT for many years tend to see things from a technical perspective and sometimes it doesn't serve us well. ポートフォリオ管理、プロジェクト管理、およびタスク管理からのデータを見ると、よく似ているかもしれません。If we look at data from Portfolio Management, Project Management, and Task Management, it might look very similar. ID フィールド、説明フィールド、および3つすべての開始日と終了日を取得しました。I've got an ID field, a description field, and a start and end date in all three. これらの3つすべてのリンクは自然である必要があります。Linking all three of these should be natural then.

おそらくありません。Perhaps not.

これら3つの概念を一度に1つずつ実行してみましょう。Let's take these three concepts one at a time. 類似点を簡単に確認できますが、3つの視点には根本的な違いがあります。It's easy to see their similarities, but there are fundamental differences in the three perspectives.

ポートフォリオ管理—トップダウンアプローチPortfolio Management — a top-down approach

"ポートフォリオ管理" によってさまざまなことがわかりますが、最も意味のある一般的なのはプロジェクトの選択と優先度設定です。People can mean a lot of different things by "portfolio management," but the most meaning common is probably project selection and prioritization. 原則は、最終的に組織内のすべてのユーザーに影響を与えますが、そのプロセスは上級管理職にとって非常に重要です。The principles ultimately affect everyone in the organization, but the process is of great interest to senior executives. 管理は、利用可能な予算の合計、質問への回答の必要性、「この金額で実現できることは何ですか」などの特定の制約事項から始まります。Management starts off with certain constraints, such as a total available budget and a need to answer the question, "What can we and should we accomplish with this amount of money?" ポートフォリオ管理プロセスが十分に成熟している場合、この分析には新しいアイデアだけでなく、既存のプロジェクトも含めることができます。If the portfolio management process is sufficiently mature, this analysis might include not just new ideas but also existing projects.


ポートフォリオ選択と優先順位付けプロセスを作成するには、経営陣が会社を confront し、新しいプロジェクトと既存のプロジェクトを検索する際に考慮される指標を事前に同意する必要があります。To create a portfolio selection and prioritization process, management must confront what business criteria drive the company and agree in advance on the metrics that will be considered when looking at new and existing projects. 投資収益率は重要な指標である必要がありますか?Should return on investment be a key metric? 場合によっては、顧客の満足度やスタッフの保持や戦略的な目標への適合に対する影響を考慮する必要があります。Perhaps we should consider effects on client satisfaction or staff retention or alignment with strategic objectives. 重要な測定基準が何であっても、管理は各プロジェクトイニシアチブをビューで検討し、プロジェクトがこれらの目標をどのように進めることができるか、および各プロジェクトと各プロジェクトと資金が支出される代替イニシアチブとの比較について考慮する必要があります。Whatever the key metrics are, management has to weigh each project initiative with a view to how that project can advance those objectives and how each project compares with alternate initiatives on which the money could be spent.

これは、1つのヘッドで行われた場合でも、高度な分析プロセスになります。This is a highly analytic process even if it's done in one's head. プロジェクトポートフォリオ管理ソフトウェアを使用している場合は、確かに高度な分析ができます。It's certainly highly analytic when you are using project portfolio management software. ソフトウェアからの分析がレポートまたはビューで受信された場合でも、ほぼ常に、優先度を決定する最終的な決定を行う管理レベルの監視があります。Even once the analysis from software arrives in a report or a view, there is virtually always some management-level oversight where a final decision on priorities gets made. 完了したら、各プロジェクトのプロジェクト管理を担当するユーザーに最終的な結果を送信する必要があります。When that is complete, the final results must be transmitted to those who will do project management of each of the projects. これらの決定による影響は、一部のプロジェクトに資金を提供したり、他のプロジェクトに対しては使用できないリソースをより高い優先度で利用したり、プロジェクトのスケジュールを進めたり、その他のプロジェクトを延期したりすることです。The effects of these decisions will be to fund some projects and not to fund others, to make available resources on a higher priority to some projects and not to others, and to advance the schedule of some projects and to delay others.

プロジェクト管理—トップダウンとボトムアップProject Management — top-down and bottom-up

承認されたプロジェクトは、別の領域に完全に移動します。Once a project is approved, it moves into a different realm altogether. これで、従来のプロジェクトスケジュールのビューがフォーカスされるようになりました。Now the more classic view of project scheduling comes into focus. 承認される前に、ビジネス上の理由について説明した事柄を実際に構築する必要があります。Now we have to actually build the thing we described in our business justification before it was approved.

プロジェクトマネージャーは、プロジェクトの範囲と成果物の観点から考察を開始します。A project manager starts thinking in terms of project scope and deliverables. プロジェクトマネージャーは、ソフトウェアの一部であるか、または居住する準備が整っているかにかかわらず、作成する必要がある最終的な製品を認識しています。The project manager knows the final product that must be created, whether it is a piece of software or a building ready for occupancy. そのプロジェクトの主要なフェーズを検討して、作業分解構造を作成することができます。They may think of the major phases of that project and create a work breakdown structure.


プロジェクトを完了するために必要な論理手順のクリティカルパスが設計されています。A critical path of logical steps required to complete the project gets designed. プロジェクトマネージャーは、生成されたスケジュールについて、自分またはユーザーが保持していることを認識しているので、プロジェクトの特定分野の専門家の範囲を調べます。The project manager also knows that he or she will be held to account for the schedule that is produced, so he or she consults a range of subject matter experts in the project. プロジェクトマネージャーは、タスクでタスクを検索し、そのタスクをプロジェクトフェーズまで要約し、最終的にプロジェクト自体に集約することによって、プロジェクトのボトムアップビューを作成します。The project manager creates a bottom-up view of the project by looking task by task and summarizing those tasks up to project phases and eventually to the project itself. この時点で、プロジェクトマネージャーは、スキル、部署、または名前によってもリソースの割り当てを開始する場合があります。At this time the project manager might also start allocating resources by skill, by department, or even by name. これらのリソースには、コストが関連付けられている場合があります。These resources might have costs associated with them. タスクの期間、必要なリソース、およびそれらの単価が計算されると、プロジェクトの下位の見積もりが得られます。The result of calculating the duration of the tasks, the resources required, and their rates gives us a bottom-up estimate of the project.

今のところ大丈夫です。So far, so good.


しかし、プロジェクトポートフォリオ選択プロセスのトップダウンアプローチを考えると、コストもかかります。But when we look at the top-down approach of the project portfolio selection process, there was a cost, too. 実際には、プロジェクトの見積もりコストは、プロジェクトを承認したときに管理されたビジネスの正当な理由に含まれていました。In fact, the estimated cost of the project was part of the business justification that management considered when it approved the project. 特定分野の専門家の専門知識を基にしてプロジェクトのボトムアップの見積もりを取得しただけでは、エグゼクティブスイートのプロジェクトの選択でどのように使用されたか。If we're just getting the bottom-up estimate of the project from combined expertise of the subject matter experts now, what did they use in the project selection up in the executive suite?

これはよい質問です。It's a good question. 組織によっては、プロジェクトの業務上の理由を作成するために、プロジェクトの部署からの大まかな見積もりが提供されます。In some organizations, the project will be given a rough estimate from the project department in order to create a business justification for the project. その他の組織では、ポートフォリオプロセスのプロジェクトを考慮する前に、完全なボトムアップ見積もりが作成されます。In other organizations, a complete bottom-up estimate is created prior to considering the project in the portfolio process. どちらの方法でも問題がありますが、それは努力を要することです。The problem with both of these approaches is that they take effort. 完全な見積もりには多くの労力がかかる可能性がありますが、プロジェクトはまだ努力するための承認を受けることができます。A complete estimate may take a lot of effort and yet the project has yet to receive approval for funding any effort. そのため、多くの組織では、管理者がこのプロジェクトのコストを推定するだけで済みます。So, in many organizations, someone in management simply makes a guess as to what the costs of this project will be.

そのため、プロセスはすべて統合されているように見えますが、ここでは1つの落とし穴があるかもしれません。So the process looks all integrated but there may be a bit of a catch-22 here. 最初に、プロジェクトの時間を費やすために、見積もりまたはプロジェクトの選択に費やした作業があります。Which comes first, the work spent on doing the estimate or the selection of the project in order to be able to spend time on the project?

さらに、ボトムアップ予測がポートフォリオ選択プロセスの予測と一致しない場合はどうなりますか。Moreover, what happens if the bottom-up estimate doesn't match the estimate of the portfolio selection process? 推定が少ない場合は、問題がない可能性がありますが、ポートフォリオ選択ユーザーが見積もった時間または予算の見積もりで作業を完了できない場合は、競合が発生します。If the estimate is less, there's probably no issue, but if the work can't possibly be completed in the time or budget estimated by the portfolio selection people, there is a conflict.

本来の目的は、上級管理職を reconvene し、問題について話しただけではなく、それほど簡単ではない状況も多くあります。You might think that the natural thing to do would be to reconvene senior management and just discuss the problem, but there are a lot of situations where that isn't as easy as it seems.

最初に、ポートフォリオ選択委員会がプロジェクト管理スタッフであることはめったにありません。First of all, the portfolio selection committee is rarely the project management staff. シニアプロジェクト管理スタッフのメンバーは、ほとんどの場合、ポートフォリオ選択委員会に含まれていますが、グループ自体は、多くの場合、すべての時間をまとめることが困難な上級幹部です。Senior project management staff members are almost always included in the portfolio selection committee, but the group itself is usually very senior executives who find it challenging to organize time to all be together. 2番目に、選択委員会が不規則に一致している可能性があるので、1つのプロジェクトのコストの不一致による影響のすべてについて話し合うことが大きな課題になる可能性があります。Secondly, the selection committee may meet irregularly, so getting them back together to discuss all the ramifications of a mismatched cost for one project versus the estimate might be a big challenge. 最後に、このプロジェクトの適切なスケジュールと予算に関して、その推測が完全に正しくないという、上級幹部にニュースを配信する必要がある企業の文化があります。Finally, there are some corporate cultures where it will not be a career-advancing move to have to deliver the news to the senior executive that their guess is completely wrong on what the appropriate schedule and budget for this project is.

タスク管理-ボトムアップ方式Task management — a bottom-up approach

タスク管理を考えると、運用が非常に高いと考えられ、多くの場合、毎日の議題と Outlook のような製品になります。When we think of task management, we tend to think very operationally, and that most often brings us to our daily agenda and a product like Outlook.


これで、個人または少人数のチームメンバーレベルで作業しています。Now we're working at an individual or a small team member level. コンテキストでタスクは表示されません。We don't see the tasks in context. お客様がコミットしたことがあるかどうか、または、チームメンバーにコミットするよう求めてきた事柄を確認できます。We see those things we've committed to or perhaps those things we've asked a team member to commit to. これは分析ビューではありません。This is not an analytic view at all. 実行するタスクがあり、個人が自分の作業を約束している。There are tasks to do and the individual has promised to do them.

中核となるのは、タスク管理が非常に簡単であることです。At its core, task management is very straightforward. タスクを実行して、完了したタスクを実行したことをユーザーに通知します。You do the task and when you're done you tell the person who gave you the task to do that it is complete. この機能のすべての機能は、既に Outlook にあります。All the functionality for this is already in Outlook.

類似データの悪戯The mischief of similar data

「アヒルのように見えて、アヒルとして見られる場合は、アヒルでなければなりません」という言い方があります。There's a saying, "If it looks like a duck and quacks like a duck, it must be a duck." Ducks の場合は true ですが、タスクベースのデータには必ずしも当てはまりません。That's true for ducks, but it isn't always true for task-based data.

次の3つのレベルのプロジェクト指向データを考えてみましょう。Let's consider these three levels of project-oriented data:

  • ポートフォリオレベルでは、プロジェクトとそのプロジェクトの下にあるフェーズがあります。At the portfolio level, we have a project and perhaps phases below that project. フェーズ情報には、コード番号、説明、期間、開始日、および終了日が含まれることがあります。The phase information might have a code number, a description, a duration, a start date, and an end date.

  • プロジェクトレベルで、プロジェクトの下にプロジェクトとタスクがあります。At the project level, we have a project and tasks below the project. タスク情報には、コード番号、説明、期間、開始日、および終了日を含めることができます。The task information might have a code number, a description, a duration, a start date, and an end date.

  • そのタスク管理レベルでは、タスクがあり、タスク情報にコード番号、説明、期間、開始日、終了日が含まれることがあります。At that task management level, we have a task and the task information might have a code number, a description, a duration, a start date, and an end date.

同じように表示されますが、実際にはデータの観点から、これらの各共通レコードがそれぞれ異なる目的を果たしています。They sure look the same, but in fact, the perspective of the data makes each of these rather common records serve a very different purpose.

「ポートフォリオビューからプロジェクトビューにデータを移動して、Outlook に戻ることができます。」というメッセージが頻繁に表示されます。I'm often asked, "Can I move data from the portfolio view to the project view to Outlook and back."

その質問に対する短い答えは、"はい" です。The short answer to that question is "Yes."

しかし、この企業では、技術的なアドバイスを提供しているときに、"どうすればいいのかを教えてくれません" という mantra があります。But in our firm we have a mantra we say to ourselves when we're giving technical advice: "Don't tell me how to do it, tell me why you should do it."

  1. その点を考えると、この例を想像してください。To make the point, imagine this example. 完全に統合された環境を作成します。We make an entirely integrated environment. スケールの上部には、ポートフォリオ別に編成されたプロジェクトの一覧があります。At the top end of the scale we have a list of projects organized by portfolio. これらのプロジェクトを選択するだけでなく、EPM システムからライブプロジェクトにアクティブ化した後は、さらに統合されます。Not only do we select these projects, but we integrate even further, following them after they've been activated into live projects from the EPM system. これを行うには、既に使用可能な機能を使用して、プロジェクトとフェーズの定義を統合システムのポートフォリオ側からシステムのプロジェクト側に移行します。To do this, we use functionality already available to us to move the project and phase definitions from the Portfolio side of our integrated system to the project side of the system. データは同じように表示されます。The data looks identical.

  2. エンタープライズプロジェクト管理システムでは、トップダウンからプッシュされたポートフォリオ定義の元のフェーズを使用して、より詳細な定義を作成しました。In our enterprise project management system we now make a more detailed definition, using the original phases from the portfolio definition that was pushed from the top down. これにより、プロジェクトを更新するときにポートフォリオシステムでそのサマリーを更新できるようになります。Doing this allows that summary to be updated in the portfolio system when we update our projects. 多くのタスクを行い、多くのリソースを割り当てています。We make many tasks and assign many resources. リソースの平準化を行って、多くのプロジェクトにわたる容量を特定しました。We now do a resource-leveling analysis to determine our capacity across many projects.

  3. リソースの割り当てを使用して、Outlook のタスクまたはカレンダーイベントとして、タスクおよび割り当てのデータを各ユーザーにプッシュします。We use our resource assignments to push task and assignment data to each user as an Outlook task or calendar event. ユーザーが "プロジェクト管理システム" に移動する必要がなくなりました。Users no longer need to go to a "project management system". これで、毎日の議題にデータを表示できるようになりました。They are now able to see their data in their daily agenda. データはプロジェクトリストの場合と同じように表示され、さらに上流のポートフォリオビューにリンクされています。The data looks just like it does in the project list and is linked further upstream to the portfolio view.

  4. これらのタスクと可用性から、Outlook からの進捗状況は、この作業が完了した時点での見積もりと共に、個々のユーザーからプロジェクト管理システムに戻されます。Progress from these tasks and availability from Outlook is moved back from the individual to the project management system along with estimates on when this work will be completed. データは、他の2つのシステムの場合と同じように表示されるので、データの移動は比較的簡単です。The data looks just like it does in the other two systems, so moving the data is relatively easy.

このようなシステムを作成することにより、今日で利用可能なツールを使用して技術的に非常に簡単に構成と開発を行うことができます。Creating such a system is technically very straightforward using the tools available to us today along with a bit of configuration and development. これで、美しいがデモンストレーションされます。And it would demonstrate beautifully.

定期的にこの種類の構造を確認するよう求められます。We get asked for exactly this type of structure on a regular basis. しかし、可能な場合でも可能です。But, even though we can do it, should we?

タスクレベルでは、ある人が緊急通報の訪問に対して朝オフになり、翌朝には利用できなくなるように Outlook が更新されるとします。Imagine that at the task level, an individual takes the morning off for an emergency dental visit and updates her Outlook that she will not be available this morning. 彼にとっては悪い知らせですが、プロジェクトに対する ripple の影響は大規模な場合があります。That's bad news for him but the ripple effects to the project could be massive. これで、この朝に予定されていたタスクが今日完了しないことがプロジェクトシステムによって計算されます。この操作は、翌日の明日のみで完了します。Now, the project system calculates that the task that was scheduled to be done this morning won't be completed today; it will be completed only at mid-day tomorrow. この dutifully は、このクリティカルパスとすべてのタスクをこの1から下流まで調べ、4時間で前方にプッシュします。It dutifully looks at the critical path and all tasks downstream from this one and pushes them forward by four hours. おそらく数百のタスクが影響を受けました。Perhaps hundreds of tasks were affected. その結果、プロジェクトの終了日が翌日になった場合があります。The result might be pushing the end date of the project a half day later. このプロジェクトで作業している他のユーザーは、他のプロジェクトにも影響を与えます。この時点で、タスクを再配置し、ポートフォリオビュー自体が数ピクセルずつ前に移動する必要があります。Other projects are also affected as other people working on this project must now have their tasks re-arranged and the portfolio view itself slides forward a few pixels.

リアルタイムでこのことを考えると、問題が拡大しています。If we imagine this in real time, the problem is magnified. 1日で数百または数千のユーザーが変更を行っていて、EPM ビュー、リソースの平準化ビュー、およびポートフォリオビューが、その効果に対して前後にアニメーションを適用します。Hundreds or thousands of people are making changes all through the day, and the EPM view, the resource leveling view, and the portfolio view animate back and forth with the effects.

実際には、これは発生しません。In reality this doesn't happen. 最初に、hapless 歯科患者は正午に戻ってきて、後から数時間で作業することができます。これで、このクリティカルパスが確実にキャッチされ、朝のすべてのトラックに戻るようになります。First of all, the hapless dental patient will be back at her post at noon and may just work a few hours later tonight to make sure this critical path is caught up and all will be back on track in the morning.

さらに、データは同じように見えますが、まったく同じ効果があるため、この方法では統合されません。Plus, even though the data looks the same, it is never integrated this way because of exactly this effect.

データコンテキスト-視点が重要Data Context — the perspective matters

データを参照すると、データのコンテキストは重要です。When we look at data, the context of the data is critical. レコード間スキーマの場合と同じように見えるデータは、アプリケーションの観点から、非常に異なる目的で使用されます。Data that may look the same from a record-to-record schema is used for very different purposes based on the perspective of the application.

トップダウンのポートフォリオ表示では、投資収益を最大化するためのリソースをどこに配置するかについて、戦略的な意思決定を行っています。In a top-down portfolio view, we are making strategic decisions of where to put our resources to maximize our return on investment. プロジェクトマネージャーの選択を行うことができます。We might make choices that a project manager wouldn't make. 自分の組織では、既存のスキルセットの外部にあるプロジェクトを選択していることがありますが、そのような場合には、これらのスキルの向上を期待しています。In my own organization, we have sometimes chosen projects that are completely outside our existing skill set, knowing that we would be terribly ineffective at accomplishing them but doing so because we wanted to improve those very skills. 投資収益率は効果的なインストールではないため、熟練したインストーラーでした。The return on investment wasn't an effective installation, it was trained installers. これは分析ビューです。This is an analytic view.

戦術プロジェクトビューでは、担当者にとって最適なスループットを得るための意思決定を行い、プロジェクトを迅速かつ効率的に完了できるようにしています。In a tactical project view, we are making operational decisions about where to get the best throughput of our personnel and to get our projects completed as quickly and efficiently as possible. プロジェクトマネージャーの視点は常に未来になります。A project manager's eye is always to the future. 過去に起こったことは、将来のビューが改善されたときに、プロジェクトマネージャーにのみ関係しています。What happened in the past is only of interest to the project manager insofar as it improves his or her view of the future. これは、高度な分析ビューでもあります。This is also a highly analytic view.

議題のようなタスク管理ビューでは、分析は行われません。In a task management view like an agenda, we are not analytic. 議題はコミットメントシステムです。An agenda is a commitment system. 特定の時間に特定のことを行うことをお約束します。We promise ourselves or others that we will do a particular thing at a particular time. 分析ビューに一致している可能性があります。This might fit the analytic view. そうでない場合もあります。And it might not.

これらの視点とコンテキストを使用して影響を理解しないと、混乱が生じる可能性があります。Mixing these perspectives and contexts without understanding the impact can cause chaos.

トップダウンまたはボトムアップTop-down or bottom-up?

通常、正しい答えはありません。There is, as usual, no right answer. プロジェクト管理システムのいくつかの側面は、実際にはボトムアップになる必要があります。Some aspects of your project management system really need to come from the bottom-up. 最終的には、プロジェクトが何であるかを開発者にすることができます。After all, in the end, it is individuals who will build whatever your project is about. ただし、いくつかの決定は、非常に上から行い、必要に応じてトップダウンで行われるものです。But some decisions are, and should be, made from the very top and are, as a necessity, top-down.

プロジェクト管理パラダイムの各レベルの違いを維持すると、これらのシステムの一部が実際に統合されているかどうかを確認するのがわかりやすくなります。When you keep the distinctions of what each level of the project management paradigm is for, it does become clearer to see if some of these systems should really be integrated or not. 他のレベルから完全に統合されたことによって、1つのレベルの思考に直接的なメリットが得られない場合、統合は最適なアプローチではありません。If the process and thinking of one level doesn't have direct benefit by being fully integrated from another level, then integration is not the best play. このような統合が現実のコンテキストでどのように機能するか、および1つのレベルの周波数と詳細が他のレベルにどのような値を提供するかを確認することが重要です。It's important to walk through how such integration would work in a real-world context and whether the frequency and detail from one level delivers any value to the other.


たとえば、ステアリング委員会が四半期にのみ一致するようにして、どのプロジェクトを先に移動するかを決定します。どちらの場合でも、いつでも、毎週、または毎月何を更新するのかについては、どのようなメリットがありますか。If, for example, a steering committee only meets once a quarter to make big-play decisions about which projects to move forward and which not, then what is the benefit to updating their view every day, every week, or even every month?

エンタープライズプロジェクト管理リソースの調整アルゴリズムは、実際に個人の歯科予定を確認する必要があるか、または個人のおおよその可用性を知るのに十分なものであるか。Does the enterprise project management resource-leveling algorithm really need to see the dental appointment of an individual or is it enough to know the approximate availability of that individual?

また、個人の議題またはタイムシート画面に直接割り当てを送信した場合は、同じデータを表示するために異なるシステムおよびインターフェイスに移動するために、毎日数分の時間を節約することになります。And yet, if we could send an assignment to an individual's agenda or timesheet screen directly, would that save them a few minutes each day having to go into a different system and interface to see the same data?

そのため、環境によっては、トップダウンが適切な場合があります。So, top-down is right in some circumstances and bottom-up is right in others. これらのツールと概念を統合して、それらを結びつける前に適切な配当を払うことができるかどうかを確認するには、自分の状況を調べる必要があります。You have to look at your own situation to see where integrating these tools and concepts can pay back the right dividends before tying them together.

著者について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).