Preventing, Recovering, and Managing Troubled Projects
B. D. Barnes, PhD, PMP, PE
翻譯: 朱良臣 PMP

Tip #1:Trouble may be defined as deviation from expectations. Don’t forget to carefully define and dimension what will constitute success!
技巧1: 問題可以定義為達不到期望的要求. 因此不要忘記仔細地定義和識別那些通向項目成功的因素!
Organizations do not authorize projects "just for fun"!!! Projects cost real money and consume real resources, so before going too far make sure the project team and the customer concur on how success is defined and will be measured.
組織不會批準一個”項目游戲”, 項目需要真正地花費金錢和其他資源, 因此在項目開始時,應該確?？蛻艉晚椖繄F隊對項目的成功標準的定義及測量方法達成共識.

Tip #2:A project life cycle is an essential communication tool. It is especially important with potentially troubled projects, indicating defined expectations and deviations at each step in the project.
技巧2: 一個項目的生命周期是一個項目的基本溝通工具. 這對于有潛在問題的項目由為重要, 他揭示了在每個項目階段對期望的定義及實際背離.
A project life cycle has many uses. A key objective is to define the deliverables to be generated in each phase... and how each is to be reviewed, verified, validated; leading to approval to continue the next phase.
項目的生命周期具有很多用途, 一個關鍵的目標就是定義項目在每個階段應該產(chǎn)生的交付物…..以及怎樣對這些交付物進行評審, 驗證,確認和批準進入下一階段.

Tip #3:Often troubled projects come from troubled teams. Don’t forget the Team Charter... and keep it up-to-date!
技巧3:問題項目往往來自問題團隊, 不要忘記項目團隊章程,要及時更新項目團隊章程!
A team charter is a code of conduct developed by the project management team and later adopted or modified by the project team. It defines the mutual expectations of each team member of one another. Project managers must hold themselves and others accountable consistent with this code.
項目團隊章程是項目團隊制定,更新和采用的項目團隊行為規(guī)范, 他定義了項目團隊中每個成員共同的和相互間的期望, 項目經(jīng)理和其他項目成員必須持續(xù)地遵守該章程.

Tip #4:Don’t forget projects are subject to many requirements; users perceive "trouble" only associated with the "functional" ones!
技巧4:不要忘記項目的起決定于一系列的要求的達成; 用戶所感知的”問題” 往往是”功能上”的問題!
Functional requirements clearly define what the user will be able to do or do better or more efficiently as a result of the project.
功能上的要求清楚地定義了什么是用戶希望從項目中得到的更好的和更加有效的結(jié)果.

Tip #5:Functional requirements may be all the user "cares about", nonetheless, inability to deliver the non-functional ones can cause substantial trouble.
技巧5: 功能上的要求可能是所有用戶都關心的, 雖然如此, 但是對應非功能性要求的忽視往往也會使項目陷入困境.
Non-functional requirements include the constraints under which the project must be delivered and the resulting product must perform. Qualities represent those attributes the stakeholders expect but do not necessary give "voice" to, e.g. comfort, beauty, pride ...
非功能性要求包括一些限制性要求,項目必須在這些限制下完成交付和達到希望的結(jié)果. 質(zhì)量概括了這些項目干系人所期望的但隱含的特性,如舒適,漂亮, 精致……

Tip #6:The "voice of the customer" establishes what users expect, so don’t forget to ask "what do they want to be able to do?"
技巧6: “客戶的心聲” 確定了用戶的期望, 因此不要忘記詢問”客戶想要和能為項目做些什么”
Non-functional requirements include the constraints under which the project must be delivered and the resulting product must perform. Qualities represent those attributes the stakeholders expect but do not necessary give "voice" to, e.g. comfort, beauty, pride...
非功能性要求包括一些限制性要求,項目必須在這些限制下完成交付和達到希望的結(jié)果. 質(zhì)量概括了這些項目干系人所期望的但隱含的特性,如舒適,漂亮, 精致……

Tip #7:Many teams waste substantial effort attempting to produce an exhaustive list of risk events for consideration, often trouble stems from the risk events that the team failed to identify so why not use a risk checklist?
技巧7: 許多項目團隊浪費了大量的工作試圖制作一份詳細的風險事件清單,但是問題往往就產(chǎn)生于那些被遺漏了的風險事件. 為什么不采用風險檢查表呢?
A number of years ago the Software Engineering Institute published a document entitled, ?Taxonomy Based Risk Identification?. The document is free and can be downloaded at SEI.CMU.EDU. Appendix B provides a list of approximately 200 questions that help identify and define key risk events ? many of which may be readily adapted to domains other than software development.
很多年前, 軟件工程協(xié)會就發(fā)布了一份命名為風險識別分類的文件,該文件可以免費從SEI.CMU.EDU上下載. 附錄B 提供了一大約200個問題的清單以幫助定義和識別風險事件. 其中很多可以容易地被應用到除了軟件開發(fā)外的其他領域.

Tip #8:Trouble sometimes stems from omissions. It is easy to ?forget? key components of a work package. A checklist reduces the potential of leaving out important considerations.
技巧8: 問題有時來自疏忽. 一些工作包中的關鍵任務也容易被忽略, 采用檢查清單能夠減少這些潛在的疏忽.
allPM.com provides a WBS Dictionary Job Aid, download it now and modify I to meet your organization?s specific situation.allPM.com
提供一個工作分解結(jié)構(WBS)工作輔助辭典, 現(xiàn)在就下載并根據(jù)你的組織的實際情況來進行修改使用吧.

Tip #9:Many change control systems are difficult and time-consuming to use. Stakeholders often ?go around the system? causing substantive trouble. Why not make it easy t o accommodate desirable changes.
技巧9: 很多變更控制系統(tǒng)使用起來費時費力. 項目干系人常常在這些系統(tǒng)之間徘徊從而導致很多問題, 為什么不使它變得容易與我們所期望的變更相結(jié)合?
The objective of effective change control should be to expedite, enhance, and enable desirable change. Make change control request forms easy to complete and to evaluate. Include sections that address the requestor?s willingness to accept trade-offs as well as expected benefits and pay-off!
有效變更控制系統(tǒng)的目標應該是快速, 增值并能實現(xiàn)期望的變更. 制定一份容易完成和評估的變更控制要求表. 其中應包括從變更中變更要求者接受妥協(xié)的意愿和期望的受益!

Tip #10:Trouble often stems from a project life cycle with just a design phase. Make sure it contains a design and plan phase!
技巧10: 問題往往來自項目生命周期只有一個設計階段, 確保項目的生命周期包括了一個設計和計劃階段!
Too often development teams address ?design and construction? phases with little or no emphasis on planning. The design phase must include planning for delivering the functional requirements within the expressed constraints of quality, time, budget, and risk.
非常常見的現(xiàn)象是開發(fā)團對在設計和建造階段很少甚至沒有重視計劃, 設計階段應該在期望的質(zhì)量,時間,預算和風險等限制下對功能性的交付進行計劃.

Tip #11:Cost effective testing is not something that is done once the software or the building or the new product, etc., has been produced. Trouble is often revealed in the Testing Phase, usually sequenced after construction. Move testing forward in the life cycle for more effective cost savings and customer satisfaction.
技巧11: 經(jīng)濟的測試對于已經(jīng)完成測試的軟件,建筑和新產(chǎn)品等項目不是什么問題, 問題往往在建造后的測試階段被發(fā)現(xiàn).將測試盡可能地移到項目生命周期的前段能有效地節(jié)約測試成本和使客戶滿意
Plan for testing, evaluation, and modification as part and parcel of the execution or construction phase of the project life cycle. It is far more costly to identify and remove defects from a nearly completed system than from and in-process component.
對測試,試驗和變更進行計劃是項目生命周期中執(zhí)行或建造階段的一部分.在系統(tǒng)即將完成階段識別和消除缺陷比在過程中成本要高很多.

Tip #12:When dealing with team member motivation problems, i.e. "trouble", ask three questions.
技巧12: 當處理項目成員激勵問題,也就是”麻煩”時, 問以下三個問題:
Vroom and Yetton in their work of 1974 identified three questions that individuals must be able to ask and answer in the affirmative if they are to be motivated: (1) Do I know what is expected of me? (2) Do I expect I can perform that which is expected of me? (3) Do I expect a reward of value to me personally?
Vroom 和 Yetton 在1974年明確了如果項目成員受到激勵,他們能夠自問并肯定地回答三個問題:(1) 我知道對我的期望是什么嗎? (2) 我期望我能達到對我的期望嗎? (3) 我期望對我的個人價值的肯定嗎?

Tip #13:Many troubles are nothing more than risk events that have unexpectedly manifested themselves, monitor the triggers or symptoms to reduce the potential for surprise!
技巧13: 多數(shù)問題都出現(xiàn)在非預期的風險事件的發(fā)生, 監(jiān)控風險的前兆或信號以減少潛在的意外.
Failure mode effects analysis (FMEA) requires assessment of risk detectability. The PM analogy of this is the "trigger". Make sure that those "owning" the risk work packages have identified triggers, where possible, for each risk and that these receive attention as part of each status, progress, and forecast report.
失效模式及影響分析(FMEA)要求對風險的可探測性進行評估. 項目管理稱為”觸發(fā)器”. 確保對那些有風險的工作包的風險觸發(fā)器進行了識別, 每個風險事件可能發(fā)生的地點, 以即在不同情況,進展和預測方面得到足夠的關注.

Tip #14:When requirements continue to change prior to "baselining", monitor the number of change requests per week to determine potential troubles.
技巧14: 當在確定項目基線之前要求不斷改變時,每周監(jiān)控變更的數(shù)量以確定潛在的問題
Requirements may converge or diverge during the planning phases of the project. Monitoring the number of change requests per week should indicate whether the rate of requests is growing or diminishing to some stable number. If certain of the requirements appear to remain stable while others are volatile, perhaps a phased delivery approach is advisable.
要求可能集中或者分散在項目的計劃階段, 每周監(jiān)控變更的數(shù)量應該可以顯示出變更率是增長還是在逐漸減小到一個穩(wěn)定的數(shù)量上.如果某些要求穩(wěn)定而另一些要求不穩(wěn)定, 則預示著應該采取階段性的交付方法.

Tip #15:When most of the lower weighted or prioritized requirements have been deferred in lieu of extending the schedule or increasing the budget, the project is troubled.
技巧15: 當大多數(shù)較低權重和優(yōu)先級被推遲以替代項目延期或者項目預算增加時, 項目就陷入困境
If all of the deferrable requirements have been deferred and only "must" requirements remain while schedule, cost, and quality pressures build, the project may be said to be desperate. Stakeholders who have been kept well informed may not "like" these results but they definitely should be in a position to act responsively.
如果當項目日程,成本和質(zhì)量壓力來臨時,所有可以推遲的要求被推遲并且只有那些必須的要求被保留,項目可能是令人絕望的. 那些對項目信息很了解的干系人可能不希望出現(xiàn)這樣的結(jié)果,但是他們的確應該對這樣的結(jié)果承擔責任

Tip #16:When stakeholders do not respond to information or do not respond in an expected manner, alternative, proactive communication mechanisms may be necessary to avert trouble.
技巧16: 當項目干系人對項目信息沒有回應或者不以希望的方式進行回應時, 應該建立積極的,選擇性的溝通機制以轉(zhuǎn)移這些問題
Most project managers have been exposed to Meyers Briggs Types. Recall that some (1) perceive by sensing or intuition and some (2) judge by thinking or feeling. Understanding your MBTI and the "type" of key stakeholders, i.e. key decision makers, may explain why some of the "messages" sent by the PM are not perceived and acted upon consistent with expectations.
多數(shù)項目經(jīng)理成天和邁爾斯-布里格斯心理類型(MBTI)的人打交道, 回憶一下有些人(1) 靠感覺和直覺來感知,而有些人(2)靠想當然來感知. 了解你的那些MBTI們和你的那些”典型”的項目胳干系人,也就是那些決策者們,你就會明白為什么項目經(jīng)理送出的信息不能被感知和按照項目經(jīng)理的期望得到貫徹執(zhí)行.

Tip #17:When a project is recognized as desperately troubled, first take action to contain the damage then worry about recovery!
技巧17: 當項目陷入困境時,首先要采取措施防止危害的蔓延,然后才來考慮補救措施.
Medics and rescue personnel confronted with truly desperate situations are trained first to "contain the damage" and once stabilized to then consider other options. This same approach must be applied to troubled projects having no remaining flexibility.
醫(yī)生和拯救人員面臨危難情景時進行的訓練是首先”限制傷害擴散”,一旦情況得到穩(wěn)定再考慮其它補救措施. 這種方法也應該毫無保留地被應用到出現(xiàn)問題的項目中.

Tip #18:When a project is identified as troubled, don’t wait for it to get better on its own, take action!
技巧18: 當項目確定陷入困境時,不要等待項目自己會好轉(zhuǎn), 立即采取行動!
There are three or four options for dealing with trouble - it depends
根據(jù)具體情況, 采取以下3到4種方法解決問題
1. Reduce the requirements so that execution can be completed within the approved constraints of time and resources
1. 減少要求以便在批準的時間及資源限制下完成項目
2. Increase process productivity by focusing on short-term improvements 2. 通過關注短期的改善措施的實施提高項目執(zhí)行過程的生產(chǎn)效率
3. Face the fact that the requirements will not be delivered on time; slip the schedule, and proceed with damage control, possibly including canceling the project. or Pursue a combination of all three; drop a few features, increase productivity, and slip the schedule again it depends
3. 面對項目的要求不能按期交付的現(xiàn)實; 調(diào)整日程,實施損害控制措施,可能時包括終止項目,或者嘗試以下三者措施相結(jié)合; 放棄一些項目要求,提高工作效率和根據(jù)具體情況再次調(diào)整項目日程.

Tip #19:When a project is identified as troubled, there are three areas of focus that can yield short term results: people, process, and product.
技巧19: 當確定項目陷入困境時, 可以關注以下三方面以獲得短期的效果:人員,過程和產(chǎn)品.
The first focus should be on people
首先應該關注的是人的因素
●Do whatever is needed to restore the group?s morale
●盡可能采取一切措施回復項目團隊士氣
●Clean-up major personnel problems
●清除主要的人員問題
●Clean-up major leadership problems
●清除主要的領導問題
●Add people carefully, if at all
●增加確實要增加人員也要十分小心
●Focus people?s time
●關注人員的時間
●Allow team members to be different
●承認項目成員的差異
●See that key players pace themselves
●留心項目關鍵成員的表率作用

Tip #20: Delivering the product of the project is the beginning of the end. Mitigating trouble depends upon an effective transition.
技巧20: 項目產(chǎn)品的交付是項目結(jié)束的先兆. 減少問題取決于有效的項目交接

Successful project conclusion is marked by:
項目成功結(jié)束的標志是:
●Achieving user self-supportability
●使得用戶能夠進行自我維持項目
●Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria
●使得項目干系人認可項目基線以完成并符合評價標準
●Achieving final product baselines as rapidly and cost-effectively as practical
●按實際情況快速而經(jīng)濟地達成項目產(chǎn)品基線
●Achieving implementation with no “catastrophic” incidents
●項目成功實施而沒有”災難性”事故

by B. D. Barnes, PhD, PMP, PE
Senior Consultant
International Institute for Learning, Inc.

【?發(fā)表評論?0條?】