[RISK DOCTOR BRIEFING] 76 Prerequisites for ERM 企業風險管理有效的必要條件

詳細內容

分類：社群知識庫

發佈於：2013-05-20, 週一 10:00

點擊數：0

RISK DOCTOR BRIEFING

PREREQUISITES FOR EFFECTIVE

ENTERPRISE RISK MANAGEMENT

© September 2012,  Dr David Hillson FIRM, HonFAPM, PMI Fellow

Email住址會使用灌水程式保護機制。你需要啟動Javascript才能觀看它

The term Enterprise Risk Management (ERM) describes a comprehensive and integrated framework for managing risk at all levels within an organisation. Four organisational characteristics are required if ERM is to work properly:

1.    Defined objectives at all levels. Risk is defined in terms of objectives and without clearly defined objectives it is not possible to identify or manage risk. Objectives exist at various levels in an organisation, forming a hierarchical structure. ERM requires these objectives to be clear (everyone knows and agrees what they are), aligned (all objectives contribute to the overall goal) and coherent (fitting together as a set, both top-down and bottom-up).

2.    Matching organisation to objectives. Effective organisations have structures that mirror the hierarchy of objectives, with clear mapping between levels. Senior management are responsible for achieving strategic objectives, and front-line staff (project teams, operational groups, supply chain partners etc.) must meet operational and delivery objectives. The levels in between are covered by middle management, and it is often here that objectives lose clarity, alignment and coherence.

3.    Clear boundaries. Effective ERM requires clear interfaces between levels, for both objectives and the organisation. There must be no uncertainty about whether a particular objective belongs at a particular level or to the level above or below. The organisational hierarchy must be equally clear, with defined lines of responsibility, communication and decision-making authority.

4.    Risk-aware culture. The organisation needs a fully mature risk-aware culture at all levels, with a commitment to manage risk wherever it is found, and this must be properly resourced and supported. ERM cannot operate effectively if any level within the organisation denies the existence of risk or refuses to take responsibility for managing risk in their area of authority.

What happens if one or more of these four elements are missing in your organisation? Perhaps there are no clear overall objectives, or your organisation is unstructured or has inconsistent boundaries, or the risk culture is immature? Is it possible to implement ERM in these circumstances?

An organisation that is deficient in one or more of these characteristics should take steps to develop them. Objectives can be put in place at the various levels across the business quite quickly, but it might take some time to implement structural changes to the organisation with clear boundaries and thresholds, and developing a risk-aware culture takes much longer.

In the meantime, it should be possible to get started. Why not use your part of your organisation as a pilot or demonstrator? First ensure that your objectives are clear and understood, and begin to develop risk awareness among your team. Then start to implement a cut-down version of ERM in your own “mini-enterprise”. When this starts to make a difference, communicate and celebrate your achievements, telling your colleagues what you have discovered. Success stories will encourage others to follow in your footsteps and will lead to a wider take-up of the principles and practice of ERM. If you have the courage and determination to act as a pioneer for ERM, others will follow, and eventually the whole organisation will change.

企業風險管理有效的必要條件

企業風險管理(ERM)這個名詞是描述一個完整且整合的架構，於組織內所有階層上用以管理風險。如果要使ERM正確地運作，需要下述四個組織特性:

1.      在所有階層定義目標。風險須依據目標而定義，缺乏明確的目標定義是不可能辨識或管理風險的。在一個組織中，目標存在於不同階層，形成了一個層級結構。ERM需要這些目標是明確的(每個人都知道且認同)、一致的(所有個別目標都有助於整體目標)、以及調和的(不論由上而下或由下而上都是互相搭配成一個群組)。

2.      組織配合目標。有效的組織其結構能經由明確的層級間對照反映出目標的層級。高層管理負責達成策略性目標，而第一線幕僚則必須完成作業及交付的目標，介於其間的則由中階管理來負責，通常在這個階層，目標會失去其明確性、一致性、以及調和性。

3.      明確的範疇。有效的ERM，不論是在目標或是組織的階層間，需要有明確的界面。對於某一個特定的目標是屬於哪一個特定的階層，必須沒有不確定性，組織層級也必須是一樣的明確，其權責、溝通及決策權限必須明確劃分。

4.      風險意識的文化。在組織的各個階層上都需要具有完全成熟的風險意識文化，並願意承諾管理無論在何處發生的風險，且這必須得到適當的資源與支援。若組織中的任何階層否認風險的存在、或拒絕在其權責範圍內管理風險，則ERM無法有效運作。

如果以上四者中的一個或幾個不存在於你的組織中會如何？或許是沒有明確的整體目標、又或是你的組織不結構化或範疇不一致、還是風險文化不成熟？在這樣的環境下有可能實施ERM嗎？

一個組織缺乏一個或多個上述特性時，應採取行動發展之。將目標設置於事業內的不同層級上很快即可達成，但要實施組織結構改變將範疇與疆界明確化則需要花一些時間，至於發展出風險意識文化那就得花更多時間了。

然而，開始實施應該是可能的，何不在你的組織中用你所在的位置作為先導者或展示者？首先確定你的目標是明確且被了解的，並開始在你的團隊中發展風險意識，然後開始在你所屬的「迷你企業」中採用縮小版的ERM，當這個行動開始造成了一些差異時，傳播並慶祝你的成就，告訴你的同事們你的發現，成功的故事將鼓勵其他人跟隨你的步伐，並將導致對ERM原則與實務的廣泛採用。如果你有勇氣與決心作為ERM的先驅，其他人將會追隨，而最終整個組織將會改變。

To provide feedback on this Briefing Note, or for more details on how to develop effective risk management, contact the Risk Doctor( Email住址會使用灌水程式保護機制。你需要啟動Javascript才能觀看它 ), or visit the Risk Doctor website(www.risk-doctor.com). 

[RISK DOCTOR BRIEFING] 75 RESOLVING COBB’S PARADOX? 解決COBB悖論？

詳細內容

分類：社群知識庫

發佈於：2013-05-06, 週一 10:00

點擊數：53

RISK DOCTOR BRIEFING

RESOLVING COBB’S PARADOX?

© September 2012,  Dr David Hillson FIRM, HonFAPM, PMI Fellow

Email住址會使用灌水程式保護機制。你需要啟動Javascript才能觀看它

When Martin Cobb was CIO for the Secretariat of the Treasury Board of Canada in 1995, he asked a question which has become known as Cobb’s Paradox: “We know why projects fail; we know how to prevent their failure – so why do they still fail?” Speaking at a recent UK conference, the UK Government’s adviser on efficiency Sir Peter Gershon laid down a challenge to the project management profession: “Projects and programmes should be delivered within cost, on time, delivering the anticipated benefits.” Taking up the Gershon Challenge, the UK Association for Project Management (APM) has defined its 2020 Vision as “A world in which all projects succeed.”

This sounds good, but is it really possible? And is it even desirable? Do we want to limit the scope and ambition of our projects to only those that we are certain can succeed? Or will this reduce innovation, creativity and appropriate risk-taking? A spectator at a recent Cirque de Soleil performance was heard to say: “I want to see them do things that they can only do half the time.” Isn’t this what every project sponsor or portfolio manager should be saying?!

There are several reasons why it might be impossible to resolve Cobb’s Paradox or to meet the Gershon Challenge or to achieve APM’s 2020 Vision.

·         All projects are risky. Uncertainty is built into every project, since each one is unique and complex, based on assumptions and dependencies, delivering change through people. Although the degree of risk might vary, the zero-risk project does not exist. This means that the probability of success for any project is less than 100%, so there is always the possibility of failure.

·         Most projects include unmanageable risk. Of course we aim to manage risk in our projects, but risk management can never be 100% effective, and each project will carry some residual risk. As a result, some unmanageable risks will occur on every project, challenging our ability to meet schedules, budgets or performance requirements. On some projects the effect of unmanaged risk will be so significant that these projects will fail.

·         Risk management is not always done well. Even though we have been managing risk on projects for centuries, there are still weaknesses in how we do it on many projects. Ineffective risk management leaves our projects exposed to unacceptable levels of risk and causes failure.

·         Project charters often omit risk thresholds. When project sponsors commission projects, they should define risk thresholds against each objective in the project charter or business case. This tells the project team know how much risk is acceptable in their project, and provides the target for risk management. But if project sponsors do not understand their risk appetite they will not set risk thresholds, leaving the project manager unable to manage risk effectively.

·         Projects should exist in a risk-balanced portfolio. The concept of risk efficiency should be built into the way a portfolio of projects is built, with a balance between risk and reward. This will normally include some high-risk/high-reward projects, and it would not be surprising if some of these fail to deliver the expected value.

·         Innovation is built on failure. For research and development projects or those with a high innovation content, failure is an expected and natural part of the process. Edison failed many times before he invented a working light-bulb, and creative organisations expect to do the same.

·         Failure to learn.We don’t examine past failures to learn lessons for future projects. Too often we repeat our mistakes and fail again for the same reasons. Cobb was wrong – we don’t always know why our project has failed, so we can’t learn how to prevent the same type of failure happening in future, so we fail again.

How should project-based organisations respond to the challenges laid down by Cobb, Gershon and APM? Should we accept unrealistic targets and be branded as failures if some of our projects do not succeed? Those of us in the project management community should help our stakeholders to understand that no project is without risk, and project failure will occasionally happen. We also need to make sure that our risk processes are fully effective, so that we minimise the chances of failure, but even with the best risk management, we cannot guarantee 100% success for every project.

Despite our best efforts, it seems that Cobb’s Paradox cannot be resolved, the Gershon Challenge is unrealistic, and the APM 2020 Vision may be unachievable.

解決COBB悖論？

當Martin Cobb於1995年在加拿大財政委員會秘書處擔任資訊長時，他提出了一個後來稱為Cobb悖論的問題：「我們知道專案為何失敗、我們知道如何防止專案失敗-但為何專案還是失敗？」，在英國最近的一場演講中，英國中府的效率顧問，Peter Gershon爵士對專案管理專家們拋出了這個挑戰：「專案及計畫應該在如成本、如期、並達成預期效益下交付。」在Gershon的挑戰下，英國專案管理協會(APM)定義其2020年的願景為：「所有專案都成功的世界」。

這聽起來不錯，但真有此可能嗎？甚或這是該期待的嗎？我們要把專案的範疇與企圖僅侷限於我們確定可以成功嗎？或是這將會降低創新、創意、以及適度地承擔風險呢？聽說一位最近觀賞太陽馬戲團演出的觀眾這樣說：「我想要看到他們作僅用一半時間就可以做到的事。」這不是每個專案業主或專案組合管理者應該要說的嗎？！

有數個原因使得解決Cobb悖論或克服Gershon挑戰或達成APM願景是不可能的。

Ÿ   所有專案都有風險。不確定性植基於每個專案中，因為每個專案都是獨特且複雜的、是建立在假定與相依性上的、且是因人而異的。雖然風險程度可能不同，然而零風險的專案是不存在的，這意味著任何專案成功機率皆小於100%，所以永遠有失敗的可能。

Ÿ   大部分專案包含無法管理的風險。我們當然想在我們的專案中管理風險，但風險管理不可能100%有效，且每個專案都會帶有殘留風險，因此，每個專案中都會發生一些無法管理的風險，挑戰著我們符合時程、預算、或性能要求的能力。在某些專案中，無法管理的風險其影響會嚴重到導致專案失敗。

Ÿ   風險管理不是永遠都可以作得完善。雖然我們已經管理專案中的風險很長一段時間了，但在許多專案中的作法上仍然有所缺失。無效的風險管理會使得我們的專案暴露在無法接受的風險水準下而導致失敗。

Ÿ   專案章程中經常省略了風險門檻。當專案業主委託專案時，他們應該在專案章程或事業委員會中針對每個目標定義其風險門檻，這可以讓專案團隊知道在他們的專案中可以接受多少的風險，並提供風險管理的目標。但如果專案業主不瞭解他們的風險偏好，他們將不會設定風險門檻，導致專案經理無法有效管理風險。

Ÿ   專案應存在於一個風險平衡的專案組合中。風險效率的概念，應該和取得風險與報酬平衡一起建立在設定專案組合的方式中，這通常會包含了一些高風險/高報酬的專案在內，因此如果有一些這類的專案無法獲致其被期待的價值時也不意外。

Ÿ   創新是植基於失敗上的。對研究發展或高度創新內容的專案而言，失敗是過程中可預料且自然的事，愛迪生在發明可用的電燈泡前經歷了無數次失敗，而有創意的組織也希望做相同的事。

Ÿ   無法學習。我們不檢討過去的失敗做為未來專案的教訓，因此重蹈覆轍是非常常見的。Cobb是錯的-我們不一定會知道我們的專案為何失敗，所以我們學不會如何在未來避免發生相同類型的失敗，因此，我們又失敗了。

專案導向的組織應如何回應Cobb、Gershon、及APM所設下的挑戰呢？我們應否接受不切實際的目標，且在某些我們的專案不成功時背上失敗的罪名？身為專案管理社群成員的我們，應該要幫助我們的利害關係人瞭解沒有專案是沒有風險的，專案失敗偶而會發生。我們也應該確保我們的風險流程全然有效，因此可以使失敗的可能性降至最低，但即使是有最佳的風險管理，我們也無法保證每個專案100%成功。

縱使我們付出最大的努力，Cobb的悖論似乎是無解的、Gershon的挑戰似乎是不切實際的、而APM 設下2020年的願景似乎也是無法達成的。

To provide feedback on this Briefing Note, or for more details on how to develop effective risk management, contact the Risk Doctor( Email住址會使用灌水程式保護機制。你需要啟動Javascript才能觀看它 ), or visit the Risk Doctor website(www.risk-doctor.com). 

[電子發票推動小組] 電子發票三月號文章

詳細內容

分類：社群知識庫

發佈於：2013-04-22, 週一 17:00

點擊數：111

電子發票三月號文章

財政部財稅資料中心電子發票專案辦公室

電子發票推動小組推動消費者B2C持載具索取電子發票自101年7月起至今年3月已經將近1.3億張，以此趨勢觀察，不索取紙本電子發票取而代之索取本電子發票的電子檔，已經開始被消費者接受。人手一隻智慧型手機的世代，人們已經十分習慣分秒必爭，一有時間就拿起手機划一划，看看朋友的新訊息，連一連全世界的新消息。與其說是智慧型手機普遍，還不如說是人們的生活習慣已經改變了，而且也更容易接受改變。統一發票的電子化形式的電子發票已經開始貼近消費者的真實生活。

企業B2B試辦過程中必須均衡利害關係者的利益，透過電子發票推動小組將合理的條件資源整合，使資源較佳者可以期待資源較薄弱的中小企業共同合作，互利互惠，共同加入電子發票的共同體分享電子發票帶來的效益。

試辦過程中的每一個標準定義都透過程序正義完成，將每一道程序步驟訴諸文字作為「行動」依據，讓營業人「看清事實電子發票政策真相」政府的美意，透過分析程序正義而直

接「探究事實」，瞭解到導入電子發票對於營業人直接帶來的好處。

團隊在有限資源的限制之下還需要兼顧所有利害關係人的利益，規劃並邀請共同加入試辦，以試辦過程為核心、以可衡量的績效為基礎、以利害關係者需求為根本，在專案進行的過程中需要充分地整合。

每一個試辦過程建立符合程序正義的標準，這些執行過程中的智慧經驗累積的組織過程資產（organizational process asserts）文件標準化成專案的經驗學習(Lessons Learned)檔案，儲存於知識庫中，對新專案的啟發與專案的下一個階段都極具參考價值。

承上，引用宋末，文天祥的【正氣歌】其中一小段文句『哲人日已遠，典範在夙昔』，原意是古代高風亮節的聖賢雖然已經遠離我們很久了，然而他們過去所立下良好的典範卻一直是後人學習的標竿。

知識庫的資料並非靜態，未來啟動知識庫的資料也等於將『溝通』動起來，串連時空對照當下新專案或是專案的下一個階段為「最佳實務」借鏡，再根據不同專案性質予以最適化，將專案的風險降到最低。

集網際網路應用、產品創意開發、節能減碳等多重功能於一身電子發票，帶給人們的不只是酷炫的消費模式，還有對生活新態度的啟發，也重新演繹了對於統一發票的索取、理財記帳及兌領獎等功能的提升，財政部資訊中心這一次的創新革命，向全世界展示了台灣獨有的統一發票制度應用的寬度，也鼓舞了台灣新生代網路創業視野新高度。

[大前研一NEWS視點] 靠智慧型手機大賺的三星vs.未搭上熱潮的日本公司

詳細內容

分類：社群知識庫

發佈於：2013-04-22, 週一 10:00

點擊數：125

大前研一NEWS視點: 靠智慧型手機大賺的三星vs.未搭上熱潮的日本公司

南韓三星電子在8日公布，該公司2012年營收達到16.5兆日圓（約5.5兆台幣），較前年度成長約22％，營利則為2.4兆日圓（約8000億台幣），較前年度成長86％。營收營利都達到1969年該公司建立以來的歷史新高。營收在IT企業中超越了美國的蘋果公司（Apple），預估將連續第三年蟬連世界第一。

另一方面，業績同樣穩健的鴻海集團，營收大約是10兆日圓（約3300億台幣），其中50%左右靠的卻是蘋果的訂單。三星的強項是以自有通路拓展自有品牌版圖。從季度資料來看，近兩年其成長快速，目前僅年營利就達2.4兆日圓（約8000億台幣）規模。整個日本電子業的營利加總起來，仍然不及這個數字。日本公司根本難以追趕。夏普（SHARP）、松下電器（Panasonic）、索尼（Sony）在2007年4月至2012年11月間減少的總市值，高達14兆日圓（約4.6兆台幣）。日本公司可說已經無力再參戰世界市場了。

三星的營利絕大多數來自於半導體與智慧型手機。不過，TV的情況就沒那麼樂觀。能夠以規模超過10兆日圓（3.3兆台幣）的營收，同時創造營利成長86％的原因，主要歸功於高毛利的智慧型手機事業。從這點來看，未能趕上智慧型手機熱潮的日本公司，要扭轉頽勢實屬困難。日本業者的狀況可說深陷在難以脫身的泥沼中。

以上文章由大前研一博士撰寫並授權由SBTT(Strategic Break Through Taiwan, Inc.)柯宗余翻譯編修，SBTT對以上文章負完全之責任，歡迎轉載，但請註明出處http://www.sbtt.com.tw。文章原文出處:http://www.lt-empower.com/koblog/

[RISK DOCTOR BRIEFING] 74 One size of risk process does not fit all projects 一種風險流程無法適用於所有專案

詳細內容

分類：社群知識庫

發佈於：2013-04-22, 週一 10:00

點擊數：96

RISK DOCTOR BRIEFING

ONE SIZE OF RISK PROCESS

© September 2012,  Dr David Hillson FIRM, HonFAPM, PMI Fellow

Email住址會使用灌水程式保護機制。你需要啟動Javascript才能觀看它

Different projects are exposed to different levels of risk, so the project risk management process must be scaleable to meet the varying degrees of risk challenge. While we can apply a common risk process to any project, that process can be implemented at different levels, from a few simple informal steps to a fully rigorous and integrated process.

A typical risk process should include the following eight steps:

1.     Risk Process Initiation: Define the scope, objectives and parameters of the risk process.

2.     Risk Identification: Identify all currently knowable risks, including both threats and opportunities.

3.     Risk Assessment: Evaluate key characteristics of individual risks, prioritise them for further action, and find any patterns of risk exposure. Optionally use quantitative techniques to evaluate the combined effect of risks on the project outcome.

4.     Risk Response Planning: Determine appropriate response strategies and actions for each risk.

5.     Risk Response Implementation: Implement agreed actions, determine whether they are working, and identify any secondary risks.

6.     Risk Communication: Inform stakeholders about the current risk exposure and its implications for project success

7.     Risk Review: Review changes in risk exposure, identify additional actions as required, identify new risks, and assess the effectiveness of the project risk process

8.     Lessons-Learned Review: Identify risk-related lessons to be learned for future projects

How can we scale this process to fit the risk challenge of a particular project? Scaleable elements include:

·         Risk responsibilities. In the simplest case the project manager may undertake all the elements of the risk process as part of their overall responsibility for managing the project, without using a risk specialist such as a Risk Champion or Risk Coordinator. At the other extreme a complex risky project may require input from people with particular risk skills, and a dedicated risk team may be employed, either from within the organisation or from outside.

·         Methodology and processes. A low-risk project may be able to incorporate the risk process within the overall project management process, without the need for specific risk management activities. A more risky project may need to use a defined risk process, perhaps following a recognised risk methodology.

·         Tools and techniques. The simplest risk process might involve a team brainstorm as part of another project meeting, recording risks in a spreadsheet, and monitoring actions through the regular project review meetings. The most risky projects may require a wide range of techniques for risk identification, assessment and control, to ensure that all aspects of risk exposure are captured and dealt with appropriately.

·         Supporting infrastructure. The lowest-risk projects may require no dedicated risk infrastructure, whereas high-risk projects demand robust support from integrated toolkits with high levels of functionality. It is important to get the level of infrastructure right as too much support can strangle the risk process and too little support can leave it unable to function.

·         Reporting requirement. For some projects the risk reporting can be incorporated into routine project reports, whereas others may demand a variety of specific risk reports targeted to the needs of different stakeholders, providing each group of stakeholders with risk information that matches their interest in the project.

·         Review and update frequency. It may be sufficient on low-risk or short duration projects to update the risk assessment only once or twice during the life of the project. Other projects which are more risky or of longer duration may need a regular risk update cycle, say monthly or quarterly, depending on the project’s complexity and rate of change.

Decisions on each of these scaleable aspects should be documented in the project’s Risk Management Plan, as part of the Risk Process Initiation step. Projects are not equally risky, and the risk process must be scaleable to match the level of risk challenge faced by each project.

一種風險流程無法適用於所有專案

不同的專案有不同程度的風險，所以專案風險流程必須是可調整的以適應不同等級之風險挑戰。一旦我們要將一個通用的風險流程應用於任何專案，則此一流程必須有不同的實施等級；從只有幾個簡單而非正式的步驟，到一個完整嚴謹且整合的流程。

一個典型的風險流程應該包括以下八個步驟：

1.  風險流程啟動：定義風險流程的範疇、目標、以及參數。

2.  風險辨識：辨識出所有目前已知的風險，包括威脅與機會。

3.  風險評估：評估個別風險的關鍵特徵、建立進一步行動的優先等級、以及找出風險暴露的所有型態。視情況使用量化分析技術評估風險對專案產出的綜合影響。

4.  風險回應計畫：對每個風險決定適合的回應策略及行動。

5.  風險回應之執行：執行核定的行動、判斷其是否有效，並辨識任何次級風險。

6.  風險溝通：知會利害關係人目前的風險暴露情況，及其對專案成功的影響。

7.  風險審查：檢視風險暴露程度的改變、辨識必要時所需的額外行動、辨識新風險、審查專案風險流程的效果。

8.  教訓回顧：辨識所需記取的風險教訓備未來專案使用。

我們能如何調整這個流程以適應某特定專案的風險挑戰？可調整的因素包括：

Ÿ  風險責任最單純的狀況下，專案經理承擔所有風險流程中的工作，並視為他們管理專案整體責任的一部份，不需使用如風險組長、風險協調人之類的風險專家。而對極端複雜風險的專案而言，可能就需要投入有特定風險技術的人員、且需雇用專屬的風險團隊；可以是組織內部或是外部。

Ÿ  方法論與流程一個低度風險的專案可以將風險流程含括在整體專案管理流程中，無須特定的風險管理活動。一個風險較高的專案，就可能需要經定義的風險流程，並且可能需伴隨著認定一種風險方法論。

Ÿ  工具及技巧最簡單的風險流程，可以將團隊腦力激盪會議合併在其他專案會議中、用試算表記錄風險、以及在一般的專案審查會議中監督風險行動。風險極高的專案則可能會需要範圍擴及風險辨識、評估、以及監控等技術，以確保所有風險的面向都被納入且做了適當的處置。

Ÿ  支援性的基礎建設低風險的專案也許不需要專屬的風險基礎建設，但是高風險專案需要整合了工具組與高階功能的穩健支援。建立正確的基礎建設是很重要的；支援過度會壓抑風險流程，而支援不足則會無法運作。

Ÿ  報告的需求對某些專案而言風險報告可以合併在例行性的專案報告中，但也有些專案會需要針對不同利害關係人的需要，製作各種不同的專屬風險報告，提供每個利害關係人團體符合他們專案利益的風險資訊。

Ÿ  審查與更新的頻率對低度風險或短期程的專案而言，在專案全期中更新風險評估一或兩次便已足夠，而其他風險較高或期程較長的專案，可能就會需要常態性的風險更新週期，如每月或每季一次，其週期取決於專案的複雜度及變更率。

這些可調整因素的決定應記載在專案風險管理計畫中，作為風險流程啟動步驟的一部份。每個專案的風險程度不盡相同，風險流程必須是可調整的以符合每個專案所面臨不同程度的風險挑戰。

To provide feedback on this Briefing Note, or for more details on how to develop effective risk management, contact the Risk Doctor( Email住址會使用灌水程式保護機制。你需要啟動Javascript才能觀看它 ), or visit the Risk Doctor website(www.risk-doctor.com).