影響專案的因素及經驗總結

2021-03-31 08:56:59 字數 4296 閱讀 2222

我們都要學會從專案失敗中吸取教訓,只要我們能夠能有寬大的胸懷去面對它,那麼犯錯也不見是一件壞事。

其實影響我們專案失敗的因素主要分為

技術失敗:

1、領先技術的**

2、不完善的技術設計

3、為非技術問題提供了技術解決方案

4、依賴軟體包來滿足需求

5、在開發生命週期過程中沒有充分利用工具

6、以技術為導向進行開發

人為失敗:

1、缺少行政人員的支援

2、缺少領導

3、沒有敬業精神的專案團隊

4、功能不全的專案團隊

5、管理第三方失敗

6、缺少乙個專案精英

7、缺少專案所有權

8、相關人員衝突

9、拒絕變更

10、敵對的組織文化

11、經驗不足的專案經理

12、缺少商業理由

13、不清晰或模稜兩可的商業優先順序

14、缺少使用者培訓

15、相關人員動機不一致

過程失敗:

1、缺少專案管理方法體系

2、缺少系統開發方法體系

3、缺少收益管理方法體系

4、缺少質量管理方法體系

5、未能確定和轉移專案風險

6、未能管理需求

7、過長的專案時間表

8、測試不足

9、計算機化的」**「方法

從專案失敗中吸取教訓是不斷改進過程的重要組成部分,現在羅列一下一些主要的經驗教訓

1、管理使用者預期。

即是我們的專案人員要從一開始就明白需要交付什麼以及不要交付什麼。要在專案中確定使用者的需求和建立盡可能清晰的商業

所有權。即使在最好的情況下,使用者以前收到的資訊也是有限的。通常情況下,我們很難確定能夠提供反饋資訊的合適使用者。

在專案一開始就需要確定主要的使用者需求,並且為主要使用者提供時間,以便他們確定所在部門的需求,同時他們也有責任提供

和驗證資訊並投入相應的資源。

2、專案規格說明書中必須考慮商業要求和使用者需求。

首先要理清兩個概念。

第一,專案是因為可確定且可測量的商業要求而產生並發展的。在軟體專案初期確定的清晰目標將隨著專案的進展而逐漸變得

模糊,這是擁有過長的交付期限的專案所共有的特點。因此在專案開始之前,需要確定終端使用者,以便在軟體專案的設計和開

發過程中充分考慮到他們的需求,同時使用者也有責任而且需要採取相應的行動來幫助專案獲得成功,這一點非常重要。使用者需

求構成了專案的分析和設計階段中乙個至關重要的環節。需求確定後,就要為這些需求確定基線,並將它們引入到配置管理系

統中,同時使用變更控制對其進行管理。如果這些需求出現了變更或新增了新需求,則需要對專案進行影響分析,並對專案計

劃進行相應的修正。而像我們一些採用增量式和迭代方法開發軟體的組織而言,還需要凍結每個軟體版本的需求,並建立相應

的機制(在確定的時間點和功能點進行版本控制,詳細如專案的版本控制可以專門建乙個資料夾用於版本控制,然後專人每天

以該資料夾的更新檔案搜尋出來,以winrar儲存完整路徑進行打包,再解壓便得完整路徑下的每天更新的檔案),以便向開

發基線新增新的具有更高優先順序的需求(使用者需求反饋中確定優先順序)。

第二,專案規格說明書必須關注商業需求而不是技術解決方案。因此,即使從技術上講已經存在明確的解決方案,但在進行項

目評審時仍需將重點放在與商業相關的方面。

3、在批准資源以前測量和評估專案的規模和複雜度(重視實現性)。

技術力量的發展帶來了乙個不幸的後果,就是讓我們相信,許多以前不可能實現的目標如今不但可以實現了,而且可以輕而易

舉地實現。有時候這種思想在專案的早期階段通常表現為對專案的潛在收益過分誇大、過於龐大的專案範圍定義以及過分樂觀

卻相當危險且不夠詳細的專案規劃。因此我們需要明確確定的是:

a、提議的專案進度表是否現實可行;b、專案的商業案例是否可行;c、解決方案在技術上是否可行;

軟體專案的規模和複雜度是專案成功與否的乙個決定性因素。

4、軟體專案的引入必然會為組織帶來廣泛的變化。

新技術對使用新技術人員的角色和責任帶來的不少的影響,容易導致有關程式角色和責任的不明確。因此在專案計畫中納入培

訓成本和時間進度以確保員工知道如何使用和維護系統是至關重要的。沒有合理的培訓就是永遠不可能實現軟體投資的全部潛

在收益。更重要的是,缺少培訓可能會為專案帶來商業風險和運作風險,這些風險可能會最終威脅專案的長期可用性。

5、清晰可見的專案管理結構對專案至關重要。

在管理結構中必須存在定義清楚的角色、責任和義務。在專案的開始階段就應該確定正式的報告結構以及與高階管理層交流的

途徑,同時在專案的整個過程中予以保持。

6、首先處理好人員問題

永遠不要忘記,人才是專案成功的唯一最重要因素。人員開發計畫必須與組織中的專案管理框架同步進行,從而提供培訓、業

績評估、分派工作和職位晉公升相關的機制。(哈哈,誰都希望專案團隊裡都是高度主動性和熟練技能的員工)

7、接受風險,但要嚴格管理風險

it系統的成功實現需要有效風險管理所支援的創造性思維。風險處理和變革是提高競爭優勢的重要力量,但很大程度上還是取

決於組織文化對這些方面工作的鼓勵和支援阿。當然專案也要及時對一些影響專案進度的功能模組進行調查並重新審視風險分

析工作(以及後續的風險管理工作),從而對基線進行重新評估並相應的調整計畫。

8、始終評審專案的可行性

專案開始之後,時刻對專案成功的依賴條件進行監督是至關重要的。變更的影響可能導致最初的投資評估毫無意義。因此,商業案例應作為專案過程中乙個持續使用的參考。如果認為投資的專案無法實現預期收益,就應當毫不猶豫的終止該專案。一旦作出終止專案的決策,就不要將這個過程變成乙個冗長而麻煩的過程。放棄專案並繼續前進,確保我們可以從這個過程中學到有用的經驗。導致失敗專案耗費高額成本的乙個關鍵因素往往是由於終止專案本身這一過程過於冗長。

9、管理外部**商

應當對**商的質量管理系統予以足夠的關注,以確保這些系統有效並可在現有質量系統中進行評估。過多地依賴承包商對系統交付能力的保證,或者在專案遇到問題時忽略承包商的參與都會帶來巨大的風險。最重要的經驗是必須與**商建立親密的關係,但不要過於依賴他們。無論何時,客戶都必須保留他們對專案及其程序的所有權。也就是說,我們必須評審外部**商的能力和財政立場,將其視為獲取和履行過程的一部分。

10、為質量投資

引入質量系統並不便宜。但從長遠來看,質量投資的失敗將會嚴重影響整個專案的投資回報。缺少測試和缺陷預防措施仍然是造成專案失敗的主要原因之一。

11、始終準備乙份應急計畫

風險管理過程的基礎是確定和管理專案中的風險。因此,商業和it相關人員必須開發應急計畫,以便在真正發生無法交付的情況時採取措施。

12、確保高階管理層參與整個專案過程

有關it專案的決策應視為商業決策而不是技術決策,並獲得高階管理層的完全支援。高階管理層必須承擔責任,並且對專案進行控制和跟蹤。

13、專案必須擁有對其成功負責的所有者

專案必須有乙個單一而有力的所有者,尤其當多方都將同時從專案成果中獲得既定的收益時更是如此。在整個專案中,為滿足每個人的意願而做出了很多妥協,結果是未能滿足任何人的意願的。

14、確保所有新的軟體開發專案所採用的過程至少符合cmm等級2的要求

作為最低標準,專案中所採用的過程必須能夠支援配置管理、需求管理、軟體質量保證和專案計畫的基本要求。不要依賴交付專案的開發人員的敬業精神和專業知識,一旦他們離開,你的專案就會受到影響。

15、始終執行實現後評審並發布評審結果

沒能執行實現後評審的後果很簡單:即組織(更確切地說是個人)放棄了從錯誤中吸取教訓的機會。實現後評審的目的在於確定專案對商業目標的滿足程度。因此,評審的範圍應涵蓋專案的所有方面:商業目標、使用者期望、使用者滿意度、**的收益、技術需求、**商管理和質量保證。實現後評審通常是軟體專案中的最後一項任務,該任務通常會幫助我們提高對專案結果的認知並將其用於將來的專案改進。

16、專案管理經驗和領導氣質仍然很重要

成功交付軟體專案的過程不僅僅是制定專案計畫和書寫報告,而是關於人員處理、衝突處理、協商談判和影響組織中其他方面的過程。成功的專案的乙個特徵是有擔任「領導「而不是「管理「的個體。乙個成功的領導者會通過與願意「更進一步」的團隊的合作而贏得尊敬和回報。反過來,好的領導者將顯出勇氣、膽識、權威和領導人的風範。常言道,乙個好的領導者應當是「獲得屬下的欣賞和尊敬,但被老闆認為不夠理智的人」。哈哈,這就見仁見智了。注意,如果沒有行政人員的支援和商業所有權,即使領導者具有很強領導能力且經驗豐富,也可能無力挽救專案。然而,乙個成功的專案經理應有能力提前識別專案中的危險訊號並採取相應的措施。選用經驗豐富的專案經理對於及時交付軟體專案並保持預算平衡至關重要。專案管理是一項需要花費時間掌握的技能,不能通過在「工作中學習」而獲得。如果組織希望提高專案成功的可能性,他們必須投資進行管理培訓計畫,並制定有效且規範的專案管理框架。

關於大專案的經驗總結

幾年的工作中,經歷了2個幾十號人以上的大專案.深深體會了,乙個好的框架對專案的成成敗是多麼重要的.尤其是我上乙個專案.做的是乙個國內頂尖的醫療公司的乙個門戶專案.當時由於專案的時間比較緊,沒有過多時間去考慮和研究框架.於是就簡單引進公司的另外乙個框架,到最後的2年多使用時間,就逐漸感覺到了那框架的弊...

專案經驗總結

每乙個專案過後,我們總是有各種各樣的體會,這些體會就是我們的收穫,也是我們成長的源泉,也許過了一段時間我會忘記,但是,筆記能夠讓他們清晰的保留下來!綠網專案 寧肯走的慢一點,也要保證方向是正確的!注意 無論做什麼專案,首先,我們需要清晰的明確大的環境,如究竟是在哪台伺服器上 究竟連線的是哪個庫 究竟...

專案經驗總結

使用者需求就是能幫使用者解決實際問題的一套解決方案。在經歷過多年的企業專案之後,發現專案中最大的風險來自於使用者需求的變更。需求變更產生風險的最大原因在於未做好需求處理,所以在此希望和大家 下企業應用的需求處理。先給大家舉乙個未處理好需求的例子 使用者說要做乙個實時監控的功能,要監控網路中實時發生的...