先把項目背景簡單說一下，項目A可以認為是在原有業務系統的基礎上衍生出來的新需求（派生的新業務），原有業務系統是一個比較大的系統，在公司也是一個拳頭產品，賣了幾十套，目前也有好幾個人在上面維護+二次開發+缺陷修復等（人力資源緊張）。早期公司高層只是說肯定要做這個項目，但由于人力資源的問題遲遲沒有決定要開工（還有一個重要原因是領導希望能夠簽下1-2個典型客戶再啟動項目A的開發），而僅僅是上銷售去那幾十家客戶那里兜售新業務，吹的天花亂墜的，比較市場有些競爭，需要先拉單子。這些事情是年中的事情。
等到下半年的時候，市場對這個新的業務反應比較強烈，已經有客戶說要看原型再簽合同，原因是競爭對手已經出原型了。而此刻，公司以為高層決定要即刻啟動項目開發，說先把原型做出來，限期一個月。而中層領導還是由于人手緊張，就隨便抽調了4個開發人員，一半是1年工作經驗以內的新手，就這樣匆忙上陣。由于人手有限、時間緊迫、業務需求雖然已經明確，但很多業務細節這4個開發人員都不清楚，只有一個懂業務的但也談不上精通。
項目計劃就定了一個月，基本上按天把計劃排好了，1個月后系統原型出來了。但比較粗糙，缺陷也比較多，設計基本沒有做，代碼質量也比較差。拿去客戶那里安裝后，客戶認為這個系統太粗糙了，【到客戶那里，客戶就不會認為這是個原型系統了】
至此，按常規項目管理的做法，應該重新梳理真實的客戶需求、業務流程和功能設計、架構設計、概要設計。。。。
但事情的發展卻不是這樣進行的。由于客戶迫切系統以周為單位看到項目的進展，于是領導決定就在原型系統上擴展和修改，其結果就是計劃制定后很難執行，變成了按周來排計劃，主要就是按客戶的需求來改。
好不容易在年底前把版本基本上穩定了，但只是業務流程和功能比較溫度，缺陷開始收斂了。
但元旦后到客戶現場安裝測試版本，客戶對此版本又提了很多需求變更和新模塊。此刻麻煩就比較大了，因為系統的架構靈活性比較差，改起來對原有代碼影響比較大，改動范圍大。于是又是時間緊張，又是工作量，剛把功能實現，客戶就開始催啥時候測試。缺陷一直居高不小，于是決定花2周時間專門修改缺陷。
到現在為止，開發基本完成了。但問題也比較突出：
系統的性能存在問題（有些模塊客戶的意見很大，但這個從技術上講，改動會比較大，不是1周能解決的）
系統的穩定性（與1相關）
功能的可用性（有些功能早期按照開發人員的思維來設計的，到客戶那里客戶提出新的想法，開發時把這種體驗需求壓住了，但在后續還是要改）
馬上要啟動二期的需求開發，這個更麻煩
---------------------
至此，整個項目風險還是比較大的，我總結有以下幾個原因：
1. 項目的目標、業務流程、大體需求是很明確的，但細節需求在項目中前期，整個項目組都是一知半解的，造成后續返工較大，客戶和開發人員包括公司領導對質量的意見都較大；
2. 項目從開始到現在領導和項目經理的分工不明確；由于人是湊起來的，大家之前沒有合作過不了解；
3. 原型系統出來后，項目經理大部分時間都去解決客戶的需求溝通和售前支持了，少部分時間在真正項目開發上；
4. 一直對項目的總體計劃和推進情況估計不足，造成項目計劃形同虛設，完全是開發人員做到哪算哪；
5. 中前期領導對這個項目不重視，等到元旦后發現問題比較嚴重，就臨時抽調人手進來協助，而剛進來的人一方面不是項目經理想要的人（仍然是新手），另外一方面由于系統的業務性比較強，新手加進來后1-2周內根本不起作用；
6. 測試工程師，派過來的2名測試工程師是后期加進來的，業務都不熟悉，培養的2周后才慢慢熟悉，而且在客戶現場，測試工程師根本應付不了客戶的問題，即客戶講的需求測試工程師根本不懂或不熟悉；
大致就這些吧。