2010年3月31日 星期三

如何融會貫通PMBOK的T&T(續)


自從上週肥蝦不慚的發表了自己以對應於PMBOK架構的Tools and Techniques整合瞭解法之後,有幾位朋友紛紛鼓勵我繼續TT分類的工作。肥蝦不得不再三解釋:「此觀念其實是因為肥蝦已經年老體胖,對於記憶性的背頌已是力有未逮,因此當初於閱覽PMBOK之際,所想出的笨方法。」因此就如上篇所強調的:「這Infrastructure是一個概括性的輪廓,TT的六個分類也不是絕對區別。???協助在有限的時間之下,減少所耗費的精力,通過PMP的考試。」方法是藉由TT的屬性設法跟Process連結,強調理解的能力,而不是記憶。目標僅只是強調通過考試,而不是拿高分。只是後來在不斷充實自我的專案管理技能與知識之時,發現這架構也有可取的一面。
以下,肥蝦就稍為將-判斷、分析、估算、圖化、計算、檢核-這六個TT分類的內容與項目,加以概括的說明。以免讓朋友們誤以為肥蝦真的是一個只會【唬爛】的Franklin。不過說真格的,肥蝦是定義TT的六個分類是針對實作的部份,真正完整的架構應該是如下圖啦!(被激的吐出來了)
就如PMBOK所闡述的專案管理的progressive elaboration特性,以及PMBOK對每種工具和技術的基本說明,對應到個人以往有限的經驗與知識,當然再配合點肥蝦的【唬爛】功力,把六個分類進行自我擴展的解釋,而其目的不外是設法減少分類的類別,以便於融入至PMBOK的五大流程。但是因為溝通(包含對利害關係人、專案團隊)的工具和技術,就是人家所謂的「專案管理百分之九十的時間都在溝通。」印證肥蝦個人的淺薄經驗,溝通的進行可說貫穿整體的專案流程,因此把它們單獨獨立出來。
肥蝦對於六個類別的解釋與Tools and Techniques如下表,還請各位看倌不要以嚴謹的定義看待肥蝦的分類。
類別 解釋
判斷 人為主觀的認知,憑藉特定人已有的經驗、知識、技能,進行專案目標的釐清與統整的工作。
分析 應用理論的架構與工具,將【判斷】所得的資料,進一步進行專案目標與內涵的確認。
估算 利用數量化工具與模型,將專案內涵進一步予以量化的概估。
圖化 利用圖形工具,根據量化資料予以圖形表示。
計算 利用特定數學公式,進行運算後得出專案的過去、現在、未來可能的狀態。
檢核 重點在於根據特定的標準,驗證專案特定或整合的狀態。
根據以上的TT,加上唬爛為促進的動力,推使專案往完成目標邁進。
以下分別說明工具和技術類別的重點與包含項目,但必須再次強調:「這僅是肥蝦自我理解的方法。」
(一)判斷類
在整合知識領域(第四章),都要有專案全貌的去思考。此外,需求因人而生,也需要有人去滿足需求。專案經理必須以經驗、知識、技能,進行判斷,因此如何找到對的人(第十章),問到對的話(第五章),知道要的基本要求(第八章),判別可能的風險(第十一章),再設法找到對的人去完成(第九章),
4.1.2.1 Expert Judgment
10.1.2.1 Stakeholder Analysis
10.1.2.2 Expert Judgment
4.2.2.1 Expert Judgment
5.1.2.1 Interviews
5.1.2.2 Focus Groups
5.1.2.3 Facilitated Workshops
5.1.2.4 Group Creativity Techniques
5.1.2.5 Group Decision Making Techniques
5.1.2.6 Questionnaires and Surveys
5.1.2.7 Observations
5.2.2.1 Expert Judgment
5.2.2.4 Facilitated Workshops
6.1.2.4 Expert Judgment
6.3.2.1 Expert Judgment
6.4.2.1 Expert Judgment
7.1.2.1 Expert Judgment
7.2.2.3 Expert Judgment
8.1.2.8 Proprietary Quality Management Methodologies
8.1.2.9 Additional Quality Planning Tools
9.1.2.2 Networking
9.1.2.3 Organizational Theory
11.2.2.7 Expert Judgment
11.3.2.6 Expert Judgment
11.4.2.3 Expert Judgment
11.5.2.4 Expert Judgment
12.1.2.2 Expert Judgment
4.3.2.1 Expert Judgment
9.2.2.1 Pre-Assignment
9.2.2.3 Acquisition
9.2.2.4 Virtual Teams
9.3.2.5 Co-Location
12.2.2.4 Expert Judgment
12.2.2.6 Internet Search
4.4.2.1 Expert Judgment
4.5.2.1 Expert Judgment
4.6.2.1 Expert Judgment
(二)分析類
分析的重點就在設法把判斷轉換為實際可執行的專案管理計畫,因此除了第四章整合知識領域不會有之外,其他各知識領域都會有,在五大程序中主要落在planning程序大類。此外,專案的執行結果也必須用分析進一步了解專案的狀態-範圍、時間、成本、風險-並將分析結果呈現給利害關係人。
5.1.2.8 Prototypes
5.2.2.2 Product Analysis
5.2.2.3 Alternatives Identification
5.3.2.1 Decomposition
6.1.2.1 Decomposition
6.1.2.2 Rolling Wave Planning
6.1.2.3 Templates
6.2.2.2 Dependency Determination
6.2.2.3 Applying Leads and Lags
6.2.2.4 Schedule Network Templates
6.3.2.2 Alternatives Analysis
6.4.2.5 Reserve Analysis
6.5.2.1 Schedule Network Analysis
6.5.2.2 Critical Path Method
6.5.2.3 Critical Chain Method
6.5.2.5 What-If Scenario Analysis
6.5.2.6 Applying Leads and Lags
6.5.2.7 Schedule Compression
7.1.2.6 Reserve Analysis
7.1.2.9 Vendor Bid Analysis
7.2.2.2 Reserve Analysis
8.1.2.1 Cost-Benefit Analysis
8.1.2.4 Benchmarking
8.1.2.5 Design of Experiments
8.1.2.6 Statistical Sampling
9.1.2.1 Organization Charts and Position Descriptions
10.2.2.1 Communications Requirements Analysis
11.1.2.1 Planning Meetings and Analysis
11.2.2.1 Documentation Reviews
11.2.2.2 Information Gathering Techniques
11.2.2.3 Checklist analysis
11.2.2.4 Assumptions Analysis
11.2.2.6 SWOT analysis
11.3.2.1 Risk Probability and Impact Assessment
11.3.2.2 Probability and Impact Matrix
11.3.2.3 Risk Data Quality Assessment
11.3.2.4 Risk Categorization
11.3.2.5 Risk Urgency Assessment
11.4.2.2 Quantitative Risk Analysis and Modeling Techniques
12.1.2.1 Make-or-Buy Analysis
12.1.2.3 Contract Types
8.2.2.3 Process Analysis
12.2.2.2 Proposal Evaluation Techniques
5.5.2.1 Variance Analysis
6.6.2.2 Variance Analysis
6.6.2.5 What-If Scenario Analysis
7.3.2.5 Variance Analysis
10.5.2.1 Variance Analysis
11.6.2.3 Variance and Trend Analysis
11.6.2.5 Reserve Analysis
(三)估算類
分析完後當然就要進一步根據分析結果,考量所需要的時間跟成本(必須提醒您品質是要花錢的,風險更是要花錢的。)
6.3.2.3 Published Estimating Data
6.3.2.4 Bottom-Up Estimating
6.3.2.5 Project Management Software
6.4.2.2 Analogous Estimating
6.4.2.3 Parametric Estimating
6.4.2.4 Three-Point Estimates
6.5.2.4 Resource Leveling
6.5.2.8 Scheduling Tool
7.1.2.2 Analogous Estimating
7.1.2.3 Parametric Estimating
7.1.2.4 Bottom-Up Estimating
7.1.2.5 Three-Point Estimates
7.1.2.7 Cost of Quality
7.1.2.8 Project Management Estimating Software
7.2.2.1 Cost Aggregation
7.2.2.4 Historical Relationships
8.1.2.2 Cost of Quality
11.5.2.1 Strategies for Negative Risks or Threats
11.5.2.2 Strategies for Positive Risks or Opportunities
11.5.2.3 Contingent Response Strategy
12.2.2.3 Independent Estimates
6.6.2.4 Resource Leveling
(四)圖化類
人說「文不如表,表不如圖。」因此以圖形顯示專案的估算與進度,才能顯示出專案經理的價值。(附帶一點,PMBOK的圖化工具重點落在Project schedule network diagram跟品質管控的部份。)
6.2.2.1 Precedence Diagramming Method
8.1.2.3 Control Charts
8.1.2.7 Flowcharting
11.2.2.5 Diagramming Techniques
8.3.2.1 Cause And Effect Diagram
8.3.2.2 Control Charts
8.3.2.3 Flowcharting
8.3.2.4 Histrogram
8.3.2.5 Pareto Chart
8.3.2.6 Run Chart
8.3.2.7 Scatter Diagram
(五)計算類
莫忘earned value可是PMI大力吹捧的以金錢表示專案狀態、進度、預測與風險管控的計算工具,計算的結果當然要給利害關係人看囉!
7.3.2.1 Earned Value Management
7.3.2.2 Forecasting
7.3.2.3 To-Complete Performance Index
10.5.2.2 Forecasting Methods
11.6.2.4 Technical Performance Measurement
(六)檢核類
檢核當然就是Monitoring and Controlling的重要工具了!
4.3.2.2 Project Management Information System
8.2.2.1 Plan Quality and Perform Quality Control Tools and Techniques
8.2.2.2 Quality Audits
9.4.2.4 Issue Log
5.4.2.1 Inspection
6.6.2.1 Performance Reviews
6.6.2.3 Project Management Software
6.6.2.6 Adjusting Leads and Lags
6.6.2.7 Schedule Compression
6.6.2.8 Scheduling Tool
7.3.2.4 Performance Reviews
7.3.2.6 Project Management Software
8.3.2.8 Statistical Sampling
8.3.2.9 Inspection
8.3.2.10 Approved Change Requests Review
10.5.2.4 Reporting System
11.6.2.1 Risk Reassessment
11.6.2.2 Risk Audits
11.6.2.6 Status Meetings
12.3.2.1 Contract Change Control System
12.3.2.2 Procurement Performance Reviews
12.3.2.3 Inspections and Audits
12.3.2.4 Performance Reporting
12.3.2.5 Payment Systems
12.3.2.6 Claims Administration
12.3.2.7 Records Management System
4.5.2.2 Change Control Meetings
12.4.2.1 Procurement Audits
12.4.2.2 Negotiated Settlements
12.4.2.3 Records Management System
再加上唬爛一類:唬爛的先決條件是要知道唬爛的對象,對象的種類包含利害關係人(第十章),專案團隊成員(第九章),外包協力廠商(第九章)。
7.2.2.5 Funding Limit Reconciliation
10.2.2.2 Communications Technology
10.2.2.3 Communication Models
10.2.2.4 Communication Methods
11.4.2.1 Data Gathering and Representation Techniques
9.2.2.2 Negotiation
9.3.2.1 Interpersonal Skills
9.3.2.2 Training
9.3.2.3 Team-Building Activities
9.3.2.4 Ground Rules
9.3.2.6 Recognition and Rewards
9.4.2.1 Observation and Conversation
9.4.2.2 Project Performance Appraisals
9.4.2.3 Conflict Management
9.4.2.5 Interpersonal Skills
10.3.2.1 Communication Methods
10.3.2.2 Information Distribution Tools
10.4.2.1 Communication Methods
10.4.2.2 Interpersonal Skills
10.4.2.3 Management Skills
12.2.2.1 Bidder Conferences
12.2.2.5 Advertising
12.2.2.7 Procurement Negotiations
10.5.2.3 Communication Methods
以上是基於自己的體會,初淺的作了TT分類,若再加上對每個Process的目地,想想可能需要的工具,依肥蝦的經驗,TT項目在一眼中可判別落在那一個Process的正確率有九十%或以上,反正PMP的考試全部都是選擇題,又是單選,因此理解比背誦,在應付考題上會有更大的成功機率。

2010年3月24日 星期三

如何融會貫通PMBOK的T&T



昨日肥蝦與MATT 、小歆、EVA、BEN,齊約在鍋大爺大快朵頤一番,想想這滿桌肥滋滋的肉,吃入蝦口之後,血壓真是即刻破表。唉!不過這關於肥蝦自身不知檢點的問題是暫且不表,席中MATT提到了一個PMP準備考試的問題,倒是蠻有趣的。

MATT說很多大師會要求學生背好PMBOK 42 Processes的ITTO的Data Flow Char考試就沒問題。而肥蝦自己倒是跟MATT有志一同,現在第四版PMP的考題都是以情境題為主,死背可不是必上的保證囉!想當初肥蝦在構思PMP的複習教材資料之時便不再強調"死記",而是從PMBOK的第一、二、三前半章入手,先說明整個專案管理的Underlying ,接著以專案管理的Flow貫通42 Processes Input與Output,最後再以專案管理工具與技術的自身特性,嵌入了42 Processes的Flow,完整交代了PMBOK的Infrastructure。肥蝦不敢自誇這種方式是獨一無二、全球首創,但是對沒有時間的上班族與記憶能力弱於理解能力的學員,我想應該還蠻合用的,當學員瞭解了PMBOK的全貌,再多看幾次,認真做些題目,很多該背的東西,也不用特別記憶就錄入腦袋了。

以下肥蝦就概略的闡述個人如何整理與歸納專案管理工具與技術(TT)的特性,並進一步嵌入專案管理42 Processes的主軸,當然完整介紹是需要花點時間的,而且肥蝦也不可掠人之美呀。

PMBOK內明文記載的TT共有179個,扣除了重複的,也有130個,這光瞭解每個TT的目標與概說,就要花費不少時間,更遑論是每個TT的詳細內容與操作指引了。因此肥蝦是將TT以:(一)綜觀與局部。(二)質性與量性。以專案管理計畫的progressive elaboration特性,界定TT的使用是由綜觀到局部,由質性到量性的趨勢,大約劃分了-判斷、分析、估算、圖化、計算、檢核-六個TT分類,再配合IPEMC的五大流程特性,而嵌入到42 Processes之中。

肥蝦基於自己的認識繪製了如上圖的PMBOK Infrastructure:當然這Infrastructure是一個概括性的輪廓,TT的六個分類也不是絕對區別。因為此Infrastructure圖形的目的,只是期盼藉由圖化式的基礎描述,進一步幫助學員在閱覽42個Process的目標暨內涵,以及對應的ITTO之時能不忘全貌,加深學員的印象,協助學員在有限的時間之下,減少所耗費的精力,通過PMP的考試。

2010年3月14日 星期日

現在才深刻的體會到何為「愛之深、責之切」!

肥蝦年已逾不惑,加上兩年前的一場病,對工作職場的「官場現形」,雖有不平之感,若非直接切身相害,也難以鳴叫,學習到經由職能知識的追求或者閱覽其他書籍,轉移自我的專注力,雖還不能到超凡入聖的境地,但至少每晚都能享有一夜好眠。現在週遭雖然有著工作、學業與社區的事務干擾,但多少還能從容以對。
但是昨天失眠了,多年來已未有無法入眠之困擾,昨晚一閉上眼睛,蝦腦裏就是不斷浮現我家大女兒今天在動物園昆蟲館的蝴蝶區裏受驚害怕的樣貌。說實話,要不是她是女生,肥蝦真得會一腳踹下去。頓時帶小孩遊園的興致一下子灰飛煙滅,回到家也是悶到了極點,晚上與社區委員討論事務也是一臉鬱鬱。回到家,我老婆說:「她畢竟小二的小女生啊,如果是發生在小女兒身上,你就不會生氣了」。副主委說:「我給小孩壓力太大了,小孩本來就會有害怕的東西。」

沒錯,肥蝦知道自己的想法是不對,但是她是我生的啊!我所能付出的心力、金錢,都是盡力的付出!(不可否認,時間是少了一些。)我也想過,我到底期望她變成什樣一個女生?我也衷心希望她快快樂樂!但是她就是我的長女啊!我一直要求她要有個大姊姊的風範,對自己的妹妹或表弟妹們,要捨得、要分享、要大方、要自制、要聰明、要懂事、要會照顧弟妹們、要能體貼媽媽的辛勞、要跟爺爺多親近…。另一方面,我能給她的,我會盡力付出,旅遊、圖書、表演、玩具…。

真的就像我老婆跟我妹說的:「我偏心。」但我總是拿她是"最大的"當理由,身為長女與長孫,她就不得不承擔某些責任與壓力。雖然明知道我的想法不對,但她不是我面對的工作、學業與社區上的利害關係人啊!"情"字看不破,真得是看不破!

2010年3月8日 星期一

煮萎日誌-衝突管理(延伸討論)


問題的處置與感受的衡量

肥蝦轉貼了【IT邦幫忙】上一個朋友(XXXXX)的回應與肥蝦進一步的說明,肥蝦並不是認為XXXXX的方式不對,而是問題對策似乎與問題發生的時間與專案進行的期間無法契合,另外針對XXXXX的回應中有兩個關鍵點可以進一步的討論。
============
第一次應對:
============
XXXXX的回應:
說老實話
這也不過是另外一種逼人搬走的方法而已
有的人可能就是看到這個社區可以養寵物才搬進來
拜您修改所賜
不過就是有人會賭爛罷了
因為搬家不是能說搬就搬的 不像垃圾可以說丟就丟

肥蝦的回應:
是ㄚ!
所以才限定在特定棟!而且也針對該棟大部份住戶溝通過!!加上規約的變更需要經過區權大會,還有一段時間,藉由此法進一步把問題縮小,強迫兩戶去溝通,免得住樓上的人就可以為所欲為,住樓下的要自認倒霉!!
如果養狗人士是我行我素,不去取得對門與樓下住戶的諒解或是妥協,那會導致社區大亂.
就社區而言,依據公寓大廈管理條例,社區規約是可以訂定禁養寵物.但個人養寵物的自由如果影響到別人,去取得別人的諒解跟設法妥協,那也是應該的呀!!!
另外考慮到社區養狗住戶並不是多數(不到十分之一),而且大都別人也不講話,如果強推到整個社區,對現有養狗人也不公平.但如果住戶間彼此不能諒解,對被搔擾的住戶也不公平(尤其是放任寵物於家中亂跑的住戶)!
因此不管怎麼作都會有人不高興!!!
如果是您,您有什麼好辦法嗎?還請 指教!
============
第二次應對:
============
XXXXX的回應:
我的處理方法上一篇已經打過了
(人與人的互相體諒才是解決問題的方法
說老實話 七樓跟八樓的作息時間不同
我是覺得可以養狗但是也不應該吵到人家 尤其是人家休息的時候
建議是 八樓出門前 幫狗的四隻腳裝上類似桌腳墊的東西
減少七樓在家的時候 抓出來的聲音
但是整天綁著對狗太慘忍 所以八樓下班的時候可以把裝的拿下來
至於八樓如果這樣作 七樓應該給予肯定
並對於八樓下班時間的抓聲忍耐一下
彼此體諒 為對方著想 才能解決彼此的問題)
既不用逼走人家
也不會違反當初可以養寵物的情況
單純的減少噪音而已
你這種方法 下面的根本不可能同意上面的養寵物

肥蝦的回應:
Hi:
我知道您的用意,您的方法就是先設法讓兩造進行溝通,就雙方的底限進行協調,是衝突管理的前、中期作法.
但是肥蝦前文已說明:此衝突已有三年之久,如果雙方都能互相體諒,那早就圓滿解決了!現在問題擴大已演變成整棟的問題.
身為管委會主委,依據前文的說明,我們沒有任何權力強迫彼此雙方要作任何讓步(況且雙方的主觀沒有評量的標準)!一年來公告貼了不次十數次,希望大家互相體諒.到年初更用上主委的身份,要求兩者再進行面對面溝通.但成效均無,更是越演越烈,兩者互訴對方背信.
這情況就好像軟體開發團隊,成員間因作為不同引發衝突,起初雙方進行溝通,但溝通不良.再來藉由專案經理與其他成員介入勸導與調解,但爭執雙方都說專案經理偏袒對方.更進一步兩造更故意留下錯誤碼或捅婁子,讓整個團隊都身受其害.身為一個專案經理,您在這個時候要作如何處置?
再加上您專案的核心份子的處境各與爭執一方相同(肥蝦社區前主委是愛狗跟養狗人士,副主委不養狗且對七樓住戶有深切的同情)您又要如何斟酌,避免您的處置傷害更多的人,並維持核心團隊的向心力?
只能抱歉的說,您的方法不是不良善,只是實施的衝突過程的時間點不同(前、中期較佳),而且肥蝦也作過了(但是無法強迫一方要體諒,一方要容忍,這是爭執雙方的主觀,外人無法客觀評斷)!
因此再請教 您的看法!

不知如果各位先進身處肥蝦的角色會如何處理呢?
根據XXXXX的回應,肥蝦以為有兩個問題值得進一步延伸討論:
(1) XXXXX所陳述的方法:要求雙方體諒,但要如何測量雙方的體諒?如何判定雙方的諒解是否達到一定的水準?彼此相互的作為在自我的感受與對方感受上如何確認是否相同?
(2) XXXXX所說:要七樓因八樓的措施去主動肯定八樓。溝通一個重要的過程是回饋 (feedback),這要求接收訊息者必須能展示出對訊息的理解與同意,才有可能肯定對方。那我們如何在溝通過程中去獲得一方的理解與同意呢?如果專案經理是身為第三者,您能強迫溝通的一方去理解與同意對方嗎?
上述兩個問題,以肥蝦個人的經驗認為常是溝通中易引起衝突的癥結點。溝通雙方都以為自己已經「作到底了,忍耐到極限了,對方卻絲毫不為所動,甚者更軟土深掘。」對於主觀的感受度如何去客觀衡量?如果可以衡量的話,又要用什麼標準與尺度去衡量對方的感受與體會呢?

2010年3月7日 星期日

煮萎日誌-衝突管理(下)


問題的處置與權力資源的運用

經由昨天與副主任委員與前主任委員商討後,並取得一些住戶的諒解後,決定在本棟電梯的公告欄張貼了以下的通告:
「本棟住戶多次向管委會嚴正抗議:「中間樓層夜間屢次傳出撞擊聲、狗吠聲與辱罵聲,嚴重妨礙住戶安寧。」更甚者,有住戶因不堪其擾,而賣屋他遷。管委會視此為對社區之最大侮辱與挑釁。
本人將修改社區規約,要求X棟住戶豢養寵物犬須取得樓下與對門住戶之同意書,以及禁止於專有區域內大聲辱罵與侵犯社區安寧之行為,以提升社區品質。
此外,也請住戶們一起合作,如聽到不當聲響,立即向保全人員登記概略方位與時間。如發現明確事證一定依法論處,一同阻止特定住戶之不當行為,維護居住品質與社區經濟價值。」

以上這篇通告,是肥蝦就前一篇所述的目標與限制下,所採行的方法,該篇通告除經主委簽章外,並特地要求副主任委員同時簽署,以加重宣示的效果。

就問題進一步來分析:
(1)問題的真正源頭:「樓地板隔音不佳」,已經可說是無法補救,除非結構安全有問題,不然要建商來處理是不可能了,若要住戶自行裝潢隔音設備更是緣木求魚,管委會更不可能要求住戶的生活作習時間。
(2)對策的限制:因為問題產生者已經無法自行進行良善溝通,任何他方的善意勸導當被當事人認知為侵犯個人已有的權益,管委會的介入,更使得一方進而擴大事端。而肥蝦雖然身為社區主任委員,但本身仍是住戶之一,一切依據的權責均須依照法令與社區規約的規定。若是考慮透過政府的司法力量,也因罪責不重、取締不易,警方與環保人員也是愛莫能助。
(3)減緩對策的不良影響:除本棟外之其他棟數,其間雖有些微糾紛,但確未造成整棟的問題,因此在作為上也需要設定範圍,避免可能衍出的其他問題。
(4)對策的成本考量:管委會本身之經費有限,更不可能強制要求住戶自行出資解決非本身所造成的問題。

因此肥蝦所採行的作為,就實質意義來說,這警告大於強制的意味。本次對策的目的是期望藉由整棟住戶的力量一同維護居住的品質。
(1)在手段上,首先告知了其他住戶問題來源的大約區位,也向特定住戶告知其他住戶的反應。
(2)在作為上,藉由規約的修改,取得後續作為的合法性,但因為社區規約需待區權人會議通過,因此短期間是以全棟通報保全的方式威嚇特定的住戶。
(3)在成本的考量上,藉由將豢養寵物犬的外溢效果內生化,將養狗所能造成的負面影響,經由取得對門與樓下住戶的同意書,將防範的成本內加於飼養的住戶。
(4)在舉報問題的確定上,則明文禁止大聲辱罵,因每人的辱罵聲較之敲擊聲響更能明確化來源所在。
(5)此外,為避免因為本棟的應對作為牽涉到其他棟之住戶,引發不必要之問題,因此標明為規約修改僅針對本棟,而本棟的其他利害關係人則先予溝通與說明。

至於通告貼出後的效果則有待觀察,各位先進如有其他建議,還請 不吝指教。

2010年3月2日 星期二

煮萎日誌-衝突管理(上)


您該怎麼解決衝突-兩戶間的紛擾影響到整棟安寧(問題的處置與權力資源的運用)

昨天晚上十一點前後可說是非常精彩,本棟七、八樓之間因為長久的恩怨,引發了特定住戶藉由惡意連續撞擊牆壁產生的噪音(含大聲辱罵聲音),干擾了整棟大樓(並殃及了社區鄰棟大樓)。之前已有諸多鄰居紛紛向肥蝦反應,無奈這種撞擊根本無法人贓俱獲,相關搜證也亟其困難,而且就算當場逮住,社會相關法規與社區規約也無對應規範,以環保法規中噪音管制也難以認定。但昨日更擴大為兩戶對立,彼此互相敲撞,此起彼落,逼得肥蝦在住戶的壓力之下不得不請保全報警,但警方到來,雙方都是矢口否認,並強烈指責對方,加上八樓為法學背景,更是堅持不下來協商。

就專案管理的角度來思考,這可以說是衝突管理(conflict management)的典型範例,更因為衝突無法化解,進而加劇危害到整個團隊。在PMBOK 2008第九章第四節管理專案團隊中針對衝突管理有言簡意駭的說明。衝突的解決方式在PMBOK中共寫了六種方式-撤離/回避(withdrawing/avoiding)、圓融/包容(smoothing/accommodating)、妥協(compromising)、強制(forcing)、合作(collaborating)、面對/解決問題(confronting/problem solving)。基本上面對問題是先決條件,至於應採用何種方式?則需要視目標與專案經理的權力類型(正式、賄賂、處罰、專家、參考)中在兩者之間的影響而定。

在人所組成的集合體中,因為每人的文化、生理、心理、習慣、知識、能力…等差異,在互動之中難免有所磨擦,而一般人多可基於自我修養與自我控制,保持一定的關係。但是如果衍生到了影響整個專案的運作,身為一個專案經理應要如何作為?在PMBOK 2004中對衝突管理的過程,建議衝突雙方應先自行調解紛爭,若爭議有擴大延燒的趨勢之時,專案經理就應介入尋求一個適當的解決之道。衝突則必須亟早的釐清,並一般會使用私下、直接、合作的方式。當衝突持續之時,得必要引入正式的程序,甚至包含懲罰性的處置。此外,衝突大多導致於一些特定的問題,因此針對問題的處理也可仿行變更控管或風險管理的程序進行-鑑別問題、評估與分析問題、提出對策、解決問題、追蹤問題-問題的處理最上上之策,當然希望制敵機先、消弭於無形。

但現在遇到這種困境,肥蝦究竟應該採行何種作為呢?如果是您,您又會採取何種方法呢?
首先,肥蝦先交代整個的衝突現況
(一)糾紛的起因:
(1)大樓樓地板隔音不佳。八樓住戶養狗,因此狗走路的爪聲與碰撞聲,導致七樓不滿。
(2)兩戶生活作習不一。八樓為一般上班女子,早出晚歸,而七樓為自營生意人,早歸晚出。
(3)溝通不良。兩人對於聲音都非常敏感,且過於自我,都自認為自己已作到極限或忍受到極限。
(4)冰凍三尺非一日之寒。該糾紛從社區成立以來即以存在,逾時已三年之久,雙方心結甚深。

(二)需要解決的問題為:惡意短暫、連續的大力撞擊聲響,影響整棟住戶。

(三)限制:
(1)主任委員只能對內、對外代表整個社區,無法定的司法權,任何要求必須遵循法規或社區規約。
(2)主任委員所代表的管理委員會只是受託管理公用部份,不可任意闖入專用區域(民宅)。
(3)因為敲擊聲音短暫、突然,搜證不易,更難以作為呈堂證供。
(4)本棟住戶間雖有一定共識,但敢於自行當面質疑問題者不多。
(5)社區規約允許住戶養狗,社區中已有十幾戶養取寵物犬,本棟即有三戶。
(6)要求建商改良隔音已屬不可能。
(7)八樓為法學背景,對法律觀念甚為熟稔;七樓為營利商人,人前人後差異甚大。

(四)資源
(1)本棟另一位委員與我關係甚佳,立場與行動均能一致。
(2)主任委員對於社區規約有一定的影響力,並能張貼通告。
(3)本棟除七、八樓住戶間不合外,其他多能和睦相處。
(4)主任委員可要求社區保全人員執行一定合法的任務。

(五)先前肥蝦的處理:
(1)目標:協助建立雙方直接溝通的管道。
(2)作為:(i)單獨與雙方分別見面,瞭解雙方的需求與底限。
(ii)透過雙方友好的鄰居一起促進雙方進行溝通。
(iii)表明我個人的中立立場。
(3)結果:彼此間溝通了一個多月,過程中其他住戶獲得了短暫的安寧,但終歸無效。

如果以一般解決問題的程序:(一)鑑別問題。(二)分析問題。(三)影響評估。。(四)提出對策。(五)對策評估。(六)實行對策。(七)實行評估。(八)結果回饋。您會如何去解決此問題呢?

針對上述諸種情況,不知諸位先進有何建議?至於肥蝦的思考與解決之道,就待今晚回去與核心團隊(副主任委員、前主任委員、總幹事、夜間保全)談過之後,再請各位指教!