EPM: 集中型か、または分散型か?EPM: Centralized or decentralized?

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. プロジェクト管理システムの実装を決定する際に、解決しようとしている問題について、組織が理解しておく必要があることを説明します。It describes how organizations need to understand the problems they are trying to solve when deciding on implementing a project management system. 集中型プロジェクト マネジメント システムが最適な答えではない場合もあります。Sometimes deploying a centralized project management system may not be the best answer.

この記事の Word バージョンをダウンロードするには、「 EPM-一元管理または分散管理の概要」を参照してください。To download the Word version of this article, see EPM-Centralized or Decentralized?.

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

EPM-一元化または分散EPM - Centralized or Decentralized?

1980年代初頭には、最初にプロジェクト管理業界に入って以来、エンタープライズプロジェクト管理の proponent がありました。I've been a proponent of Enterprise Project Management since I first entered the project management industry in the early 1980s. その場合は、常に集中プロジェクト管理の側に投票することになりますが、必ずしもそうではありません。You'd think, then, that I would always vote on the side of centralized project management, but that isn't always the case. ここでは、エンタープライズプロジェクトの管理について説明します。Let's discuss for a moment just what we mean by Enterprise Project Management.

EPM は、さまざまな人々にとって多くのことを意味します。EPM can mean a lot of different things to different people. このコラムの他の記事では、EPM 展開の焦点が、1つの組織のドキュメント管理であるかどうか、および次のための統合されたスケジュールについて既に説明してきました。I've already discussed in other articles in this column how the focus of an EPM deployment might be document management for one organization and integrated schedules for the next. エンタープライズプロジェクト管理には、プロジェクト管理の課題でユーザーが互いに対話する必要があるという概念があります。Enterprise Project Management has at its core, however, the notion that people must interact with each other in the project management exercise. これは、プロジェクトマネージャーとプロジェクト管理チームがまったく同じように動作しないことを意味します。That means that the project manager and/or project management team don't work completely independently. しかし、この "相互作用" を実現する唯一の方法は、集中管理されたプロジェクトスケジューリングシステムであることを意味します。But does that mean that the only way to achieve this "interaction" is to have a centralized project scheduling system? 必ずしもそうではありません。Not necessarily. 一部の組織では、プロジェクト管理の課題は、プロジェクトがすべて ad-hoc で管理されているために、概要、企業全体のプロジェクト管理レポートを作成できない可能性があります。For some organizations, the project management challenge might be an inability to produce summary, enterprise-wide project management reports due to projects being all managed on an ad-hoc basis. この場合、プロジェクトの標準をすべてのプロジェクト管理担当者間で共有することによって、EPM を実現することができます。In this case, EPM might be achieved just by having project standards that are shared between all project management personnel. これは、すべてのユーザーが使用できるテンプレート、トレーニング資料、ドキュメント、レポート基準の中央プールで実現することが最善です。That might best be achieved with a central pool of templates, training materials, documents, and report standards that everyone can use. 単純な SharePoint サイトで十分な場合もあります。Perhaps a simple SharePoint site would suffice.

組織によっては、プロジェクト管理の課題が、作業中のリソースと次のフォーカスに関するリソース間のコミュニケーションが欠如しているために、個人的なスケジュールが効果的でないことがあります。For some organizations, the project management challenge might be ineffective personal schedules due to a lack of communication between resources about what they're working on and what their next focus is. この場合、チームとチーム間のコミュニケーションが向上することによって、EPM が実現する可能性があります。In this case, EPM might be achieved by improving team and inter-team communication. これらのツールは、共有の予定表、インスタントメッセージング、またはユーザーが優先度を一覧表示できる共有ポータルとして簡単なものにすることができます。The tools could be as simple as a shared calendar, Instant Messaging, or a shared portal where people could list what their priorities are.

組織によっては、プロジェクト管理の課題については、プログラミング開発プロジェクトの進行が進んでいることがあります。In some organizations, the project management challenge is just getting progress on the programming development projects. その場合は、Visual Studio Team Services のような製品に既に存在するツールがあれば十分です。If that's the case, then the tools already present in a product like Visual Studio Team Services might suffice. プログラミングプロジェクトでは、多くのタスクをほぼすべての順序で完了できることがわかっているので、実行する開発の種類によっては、クリティカルパスのスケジューリングの rigors が適切ではない場合もあります。It's quite common in programming projects to find that many tasks can be completed in almost any order, so the rigors of Critical Path Scheduling might not even be appropriate depending on the type of development being done.

過去数年前にエアラインのメンテナンス部門を使用していることを思い出してください。I can remember a number of years ago working with the maintenance department of an airline. スタッフは、各月の開始時に独自のスケジュールを選択することができ、それが調整されていない (場合によっては、多くの場合) ので、稼働しているユーザーがいないことを検出するためだけに、shift を管理することができました。The staff were allowed to choose their own schedules at the start of each month and if this wasn't coordinated (as was often the case), it was possible to arrive to manage a shift only to find out that no one was working. プロジェクト管理の課題は、「作業が完了する時期」ではありません。Their project management challenge wasn't "When will the work get complete?" 「だれかが仕事に出ていますか」it was "is anyone coming to work?" この場合は、シフトスケジュールツールを実装することによって EPM が実現されました。In this case, EPM was achieved by implementing a shift scheduling tool.

EPM の課題をプロジェクトのスケジュールに絞った場合でも、一元的なプロジェクト管理システムを展開することが唯一のことか、または最適な答えであることはすぐにはわかりません。Even when we focus the EPM challenge to project schedules, it's not immediately obvious that deploying a centralized project management system is the only or the best answer. プロジェクト管理の担当者が互いにどのような操作を行う必要があるかをたずねることができます。It's worthwhile to ask what interaction the project management personnel need to have with each other. リソースの競合を解決するために定期的に共同作業を行う必要がある場合、または組織内の他の優先度を確認する場合、またはプロジェクトの進行状況を確認する場合は、Project Server などのツールを使用した方がよい場合があります。If they must collaborate on a regular basis to resolve resource conflicts, to see what other priorities in the organization are coming up, or to see how the progress of one project will affect another, then looking at a tool like Project Server makes perfect sense, but often I end up interacting with organizations that have not even asked this question of themselves.

組織によっては、いくつかのスケジューラと多くのリソースが見つかります。In some organizations we find a tiny number of schedulers and a large number of resources. 適切な規模の組織であっても、これは、実施されている業界と種類のプロジェクトによっては、この構造になることがあります。Even in a good-sized organization, this can be the structure depending on the industry and type of projects being accomplished. 以前は、EPM の課題に適したソリューションを選択したことが確認されている組織では、それほど前にも達していませんでした。Not that long ago I met with an organization that was sure they had picked the right solution for their EPM challenge. ソリューションを明確にするように求められましたが、通常は、最初にプロジェクト管理の問題を明確に説明するように求められています。They asked to me to articulate the solution but, as usual, I asked that they first articulate their project management problem.

ホワイトボードでの環境の説明が終わってから、選択したソリューションで問題を解決できなかったことが明らかになりました。By the time they were done describing their environment on a white board it was apparent even to them that the solution they'd chosen wasn't going to solve their problem.

この場合、この問題は、大量の下請け業者によって報告されていたプロジェクトの進行が不足していました。In this case, the problem was a lack of project progress that was being reported by a large pool of subcontractors. クライアントは、自分の下請けにタイムシートの時間と請求の種類を課す必要があると判断しました。The client determined that what they'd really need to do would be to impose a time and billing type of timesheet on their subcontractors. プログラムディレクターは推奨されていません。The Program Director was discouraged. 「下請け業者のコントラクトにこれを取得することはできません」という話があります。"We'll never be able to get that into the subcontractor contracts," they said. 幸いなことに、財務部門のメンバーが存在していました。Fortunately, a member of the Finance Department was present. "その人物が返信しました" という、選択したタイムシートに記入する必要がある句は、既に下請業者の契約にあります。"You know," that person replied, "a clause that requires them to fill in the timesheet of our choice is already in the subcontractor contract." 問題が解決します。Problem solved.

この問題を解決する前に、ここでよく説明するのは1つだけですが、導入が難しいということです。The idea of walking through the problem before coming to the solution is one I talk about often around here but it's a tough one to adopt. 論理的な考え方によって、自動化されたソリューションを決定する順序は次のようになります。Logical thinking would dictate that the order of determining an automated solution would be:

  1. 問題を特定するIdentify the problem

  2. ソリューションを定義するDefine the solution

  3. ソリューションを自動化するかどうか (また、その場合は方法) を決定するDetermine whether to (and, if so, how to) automate the solution

Web サイト、ビデオ、その他の場所についての自動化されたソリューションデモンストレーションは、忘れないようにしてください。Automated solution demonstrations on web sites, videos, and elsewhere make us forget that. もちろん、何らかの問題が発生していない場合はソリューションを探しませんが、自動化されたソリューションでは、次のことを実現できるようになります。We don't look for a solution, of course, unless we have some kind of problem, but the automated solutions look and sound so compelling that we end up doing this:

  1. 自動化ソリューションを選択するChoose the automated solution

  2. ソリューションの展開に関する問題を発生させるMake the problem deploying the solution

  3. ソリューションに自動ツールを適用する方法を定義することにより、その問題を解決します。Solve that problem by defining how the automated tool can be applied to the solution

  4. 元の問題が何であったかを覚えておいてください。Try to remember what the original problem was

この新しい問題により、最初の問題が解決され、全員が驚かれることになることを確認するために、最初の問題を解決するために、時間をかけて、数週間、数か月、または数年間でソリューションを展開できます。The new problem becomes deploying the solution for quite some time and then weeks, months, or even a couple of years down the road someone from upper management asks when the original problem will be solved and everyone looks at each other rather surprised. これは忘れがちでした。It was easy to forget about.

何年もの間、あらゆる種類の自動化ソリューションを推奨していました。Over the years I've recommended all kinds of possible automated solutions. ああ、Project Server は、当然のオプションの1つですが、Microsoft Project Pro と SharePoint Server の組み合わせも推奨しています。Oh, Project Server has been one of the options of course, but I've also recommended a combination of Microsoft Project Pro and SharePoint Server. Excel と Outlook の組み合わせを使用することをお勧めします。I've recommended using a combination of Excel and Outlook. サードパーティ製のタイムシートを Project で使用することをお勧めします。I've recommended using third party timesheets with Project.

大規模なホワイトボードの使用をお勧めします。I even once recommended using a big white board. 率直.Honest. 組織は、何年もの間、ビジネスに携わってきました。The organization was one I'd done business with for years. 該当する人物は、不動産の役割を持っており、長期のリースを実際に更新する必要がありました。The person in question was in a real-estate role and had to renew long term leases in real estate. 問題が発生したことを確認すると、スケジュールの問題が明確になりました。When I asked what the problem was, it was clearly a scheduling issue. この人物は重要な納期を逃したので、エンタープライズプロジェクト管理ツールが問題を解決していることを確認しました。The person had missed a few deadlines that were important and was sure that an enterprise project management tool would fix the problem. 組織では、今後の納期が失われることがないように、複数のエグゼクティブにレポートを配布することが既に求められています。The organization had already asked for reports to be distributed to several executives so that future deadlines wouldn't be missed. 「何人のユーザーが必要になりますか?」"How many users would there be?" メッセージが表示されます。I asked. 「自分だけ」という応答がありました。"Just me," he replied. "これらのプロジェクトが一度にいくつあるか。"How many of these projects are there at a time?" 「7または8」というメッセージが表示されました。I asked "Seven or eight," he replied. "各プロジェクトに対して、これらの期限マイルストーンのいくつが管理されています。"And how many of these deadline milestones do you manage for each project "It's very complicated. 1つごとに約12分の期限があります。There are about a half-dozen deadlines for each one," he told me.

この不適切な同僚に対して、大規模な EPM システムをインストールしてはいけないということです。It was already clear to me that we shouldn't be installing a big centralized EPM system for this poor fellow.

「大規模な白いボードをブースに入れて、さまざまなマイルストーンに色のマーカーを使用するのはなぜですか?」"Why not just put up a big white board in your cubicle and use some colored markers for the different milestones?" メッセージが表示されます。I asked. "最初の1つには青、2番目の場合は緑、最後の場合は赤を使用することができます。""You could use blue for the first one, green for the second, red for the last, etc."

彼は、概念によって copious のメモを fascinated しました。He took copious notes, fascinated by the concept. その日のサービスまたは製品を販売していないのに、そのユーザーが envisaged のシステムを展開できなかったことをがっかりさせたままにしていることを、企業は聞いたままにしました。I left the firm knowing that I'd not sold any services or product that day but that I'd left the person disappointed that he couldn't deploy the system he'd envisaged. 自動車の自宅電話止まりましたの方法。On the way home my phone rang in the car. そのようになりました。It was him. 「ホワイトボードにさまざまな色を使用することができますか?」"Could you explain the different colors for the white board?" 求められました。he asked.

ソリューションを設計する前、またはソリューションをどのように自動化するかを選択する前に、どのような問題を解決しようとしているかを判断するだけでは、コストが節約されます。Figuring out what problems you're trying to solve before you design the solution and before you choose how to automate it doesn't just save money. 第1の場所で解決する必要がある問題が発生していない組織の要素の処理にかかる時間を大幅に節約できます。It can save an enormous amount of time spent working on elements of the organization that didn't have a problem that needed solving in the first place.

集中型のエンタープライズプロジェクト管理ソフトウェアを使用して解決しようとしている問題が最適な解決になる場合は、実際には何も実行されませんが、その問題を説明することによって得られるフォーカスは、それでも問題がある場合に役立ちます。When the problems you're trying to solve can be best solved with centralized enterprise project management software, then nothing else will really do, but the focus you'll have gained by articulating the problem will help even there. 展開チームは、問題が解決された場合に、プロジェクトを成功として宣言できる成功指標を作成できます。Your deployment team can create success metrics that allow the project to be declared a success when the problems have been resolved. 集中または分散化Centralize or decentralize? エンタープライズプロジェクト管理は、どちらかの方法で実現できます。Enterprise Project Management can be achieved with either.

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