A公司向該項目投入了3個人力：1個PM加2個工程師，另外考慮到工期及成本的因素，還找了3名在校實習生參與開發——這跟業界的普遍狀況也差不多。
檢查項目目前進行的狀況，把發現的問題抽一些列出來：
1.RISK: 使用AJAX，改變開發方式，增大了項目風險。
目前AJAX技術大熱，該項目又有部分UI的需求比較複雜，所以負責項目開發的工程師決定導入AJAX來實現。以公司現有的狀況，工程師大都習慣於傳統的JSP編程，而引入AJAX將改變其熟悉的開發方式，此外，AJAX引入後對於系統原有架構所具備的諸多特性倒底會有哪些影響還未可知。在未作過原型驗證的前提下即匆匆上馬，將給項目帶來不可預知的影響。
2.RISK: 使用在校學生開發，毫無經驗，增大了項目風險。
一羣懵懵懂懂的在校學生來公司實習，培訓2周後交出的測試答卷慘不忍睹。這種情況下老闆還是留下了大部分人來“補充兵力”。其中有3人加入了該項目的開發，從該項目的人力結構來看，這3名學生纔是開發代碼的主力軍。以這樣的開發隊伍來作系統開發，不禁要爲系統質量跟項目工期捏一把汗。
3.Bad Practise：項目策劃及系統設計時間相對過長，遲遲未進入開發階段。
項目進行數月，大量人力耗費在跟客戶及自動化系統提供商的確認會議中。需求一再改變，這本身應是正常狀況，然而項目組卻在需求問題上跟客戶及第三方廠商過多糾纏，並在系統架構確定上踟躇再三，又未實際作出架構原型進行驗證，以至耽誤了項目工期，至今未進入實質開發階段。2月後即需向客戶交付可用的系統，卻至今未交付一版可運行的系統，哪怕是初版。以上是不符合系統迭代開發的原則的。
如果說一個成功的項目是要在給定的時間及資源的條件下向客戶交付合乎功能與質量要求的應用的話，那麼依該項目目前的狀況來看，不能成功的風險是比較大的。2個月後該項目的進展究竟如何？QA拭目以待。