對於軟體專案，無論是定製軟體，還是成品軟體，向客戶進行演示均是必不可少的。對於成品軟體，如果演示得不好，可能就不可能有後面的實施；對於定製軟體，如果演示得結結巴巴，就會影響客戶的信心，對你的能力、對你對專案的把握能力產生懷疑，對你的信心就要打折扣，這種折扣就要影響到客戶在後面對專案實施支援程度。
專案管理者聯盟
　　專案的演示是必不可少的，就像醜媳婦終究是要見公婆的。對於專案來說，使用者是就是公婆，專案就是醜媳婦。公婆當然對醜媳婦不滿意，公婆希望媳婦漂亮。怎麼面對這個矛盾呢？首先，我們希望這個媳婦要漂亮，就是專案要做得漂亮，做得完善。這樣這個媳婦就有了成為美女的潛質，但再美的女人也會有一些微不足道的缺陷，也可以叫缺陷美，但缺陷就是缺陷，不能變成美。也就是說，只要客戶對你挑剔，你的專案肯定會有問題。怎麼辦？其次就是醜媳婦要靠巧打扮。就像美女，有多少美女在素面的情況下還有那麼美的呢？專案的演示就是對素面美女的巧打扮。媳婦美不美，全靠打扮，打扮得好，醜媳婦也美，甚至缺陷也是缺陷美。如果打扮得不好，美女也因為變成醜女，可能我們不是掩蓋了缺陷，而是放大了缺陷。 專案管理者聯盟
blog.mypm.net
　　專案演示的重點不在專案演示本身，而是演示之前，這就是古人所說的功夫在詩外。這個“詩外”首先就是專案要做得好。專案做得不好，一切免談，你演示得再好也沒有用。如果專案本身做得不好，演示得好，或者花大的精力去策劃演示，那就是忽悠。忽悠客戶就是忽悠自己，最終的後果可想而知。只有對做得好的專案進行演示策劃，才是巧打扮。 專案管理者聯盟
專案管理者聯盟
　　專案做的好不好的首要標準就是實現客戶的目標。這個不用說，不能實現客戶的價值的專案根本就不能稱為專案。我這裡要說的是專案細節要做好。可以這樣說，細節才是體現專案水平的唯一尺度。只有注意專案細節，才能在演示過程中避免被客戶質疑。當然還有一個辦法避免被質疑，就是將專案演示得誰也不明白，讓客戶問不出問題。但我想任何一個專案經理也不會選擇這麼做。
專案經理圈子
　　但對於什麼是細節，卻不是一兩句話能夠說清楚的，甚至根本就說不清楚，因為不同的專案什麼是細節也不同。但細節也不是一點說不清，總有一些原則是可以作為標誌的。例如對於需要客戶輸入的時候一定要方便，要符合客戶的習慣。我們需要分析我們專案的操作流程，看看其中有沒有冗餘的動作，有沒有不經濟的動作？再舉一個更具體的例子，如果某個操作需要選擇多個記錄，那麼這時是讓客戶一個一個的選，還是一次可以選多條呢？我想客戶的選擇是毫無疑問的後者。但客戶對於專案需求說明書的確定往往是功能的實現，而不是這些細節，如果以客戶在專案需求中沒有提而拒絕實現，那就是有點強詞奪理，不把客戶當一回事了。還有，對於一次選中的多條記錄，不可避免會由於看錯或操作失誤，有個別記錄可能選錯。問題是萬一出現這種錯誤怎麼辦？在有的情況下，我感到讓客戶用滑鼠右擊錯誤的記錄刪除是最經濟的，因為錯誤不經常出現，操作可以複雜一些，但不能讓正確的操作因為可能出現的錯誤而變複雜。還有輸入某個代號以後直接帶出名稱，等等。對於這些細節，如果是C/S程式，可能比較簡單，但對於B/S程式，可能要複雜一點。但為了客戶需求，專案開發者多辛苦一點，為了專案的使用者更方便，完全是一筆合算的買賣。 專案管理者聯盟
專案管理者聯盟
　　專案演示的第二個重點就是演示流程要事先準備好。事先準備說得高調一點就是對客戶、對聽眾的尊重，說的實在一點，展現專案的優點，只有準備得充分，專案的優點才能展現得充分。只有將專案這個媳婦打扮得越靚，才能贏得公婆的歡心，才能在今後的生活中不被公婆刁難，至少刁難少一些，配合多一些。我們沒有專案經理人都需要想到，專案實施被刁難是正常的，不被刁難是少有的，因為新的專案必然會影響某些人的潛在利益，或者有可能影響某些人的潛在利益，你說他們能支援你嗎？但他們也不會公然反對，因為這個專案之所以存在，必然是因為某個比他們更高的權威的人需要這個專案，這個他們不想拿自己的飯碗開玩笑，不會公然反對。還有一個專案可能被質疑的原因是，每一個人都不希望接受自己笨，別人聰明的結論，但這個專案之所以是你做，而不是他做，某種意義上已經不證自明瞭你比他聰明，所以他心理肯定會不高興。當然我不敢肯定這些是普遍現象，但這至少是一種可能的存在，值得我們每個專案經理去面對。 專案管理者聯盟
PgMp.mypm.net
　　儘管專案推廣中不可避免會遇到這些困難，但作為專案經理，你可以在專案演示中用你對專案準確把握，對客戶需求的準確把握，對專案的熱情、對專案的信心、對客戶的熱情、對客戶的忠誠，去打動客戶。 專案管理者聯盟
專案管理者聯盟文章
　　專案演示過程中一定要按計劃準備好，不能信口開河，想到哪裡說到哪裡。這種準備要用書面的形式寫下來，並反覆推敲。每個演示細節、每個演示中作為例子的資料都要事先準備好，不能到時候掉鏈子。很多小公司的專案經理不願意做這類的事情，因為小公司這種準備只能用一次，很不合算。但我要說的是，如果沒有這種不合算的投入，你的公司可能永遠成不了大公司，甚至幾年以後還有沒有你這個公司都很難說。 專案管理者聯盟
專案管理者聯盟
　　對於專案演示的準備，還有需要詳細說的就是演示者一定要站在客戶的角度，不是專案經理的角度。專案演示不是專案經理的學術成果發表，而是為使用者解決問題的。因此一定要站在使用者的角度，按使用者的思考方法去思考，按使用者的操作流程去操作。只有這樣才能被使用者接受。不要指望使用者從軟體開發者的角度去思考問題。其實這種情況的存在也是合理的，但你也不要不服氣，如果不是為了實現客戶價值，哪會有你這個專案？沒有你這個專案，哪會有你專案經理？很多專案經理在演示過程中，不顧客戶感受，只顧自說自話，按設計的流程去說，把很多在設計人員是理所當然的問題當作在客戶那裡也是理所當然的，結果讓客戶聽得雲裡霧裡的。專案演示者必須具備對客戶的敬畏之心。 專案管理者聯盟
專案管理者聯盟
　　在演示過程中，要注意的就是，首先是演，然後才是示。通過演示者的表演將專案示給客戶。演示專案不是對著客戶朗讀事先準備好的演說稿，讀的聽者昏昏欲睡，當然也體不到演示作用。演示的核心是聽眾（客戶），而不是專案（的技術特徵），更不是專案開發者。我建議演示者移開電腦，用演講的態勢，用洪亮的聲音，抑揚頓挫的語調，流暢的講述向用戶介紹你的專案，更準備的說是告訴使用者如何用你的專案實現使用者的價值。當然光嘴說，沒有電腦投影的輔助，也不能說明問題。但電腦的演示畢竟是輔助，可以請助手協助操作電腦。 專案管理者聯盟
專案管理者聯盟
　　演示要有激情，並且要通過這個激情向客戶展示你的信心。只有客戶確信你對專案有了信心，才能在今後的實施過程主動協助你。只有你將這種激情傳遞給聽眾，才能幫助聽眾戰勝聽課過程中瞌睡的騷擾。將你對專案的信心準確的傳遞給客戶是十分重要的。 blog.mypm.net
專案管理者聯盟
　　專案開發過程中的每個環節都很重要，都必須認真對待。對於專案演示來說，必須要有像演員一樣的有“臺上一分鐘，臺下十年功”的決心和行動。這種行為的動力來源於對事業的執著，對工作的精益求精，對客戶的敬畏。 專案管理者聯盟

昨天完成了某國土局的兩個核心系統正式交付使用前的一個演示工作，整個過程與結果達到且超過了預期的效果。現就“如何做好正式交付使用前的專案演示“做一總結，也許對你會有幫助，同時也歡迎大家多提寶貴意見。本文非技術性文章，可歸類為專案管理方面，不過我想說的是，如果你是一位程式設計師，並且是一位做了數年還在做開發的程式設計師，是時候對自己的人生作出反思了。你不應該僅僅滿足於一至做一名程式設計師，雖然這是你的最愛沒錯。但請清楚，人是不斷進步的，不光要在技術上進步，在專案經驗與專案管理方面也有要所進步，如果你現在25歲以上了，是時候對自己的人生做一個全面的評估與規劃了（我們吃的可是青春飯呀！）。網上有一大堆的程式設計師人生規劃等文章，也許對你有幫助，請抽點時間看看吧。肺腑之言！

下面我先做這兩個核心專案做一個簡單介紹。

這兩個專案分別是“建設專案用地預審”和“建設專案用地審批”。對於國土部門來說是兩個非常非常非常重要的業務流程系統，基本上涉及到國土局的所有部門。

“建設專案用地預審”該系統作為金土工程的一核心系統組成部分，主要針對當前建設用地預審工作的特點，實現建設用地預審專案、規劃調整、基本農田調整等業務的申報、審查、會審、審批、備案等，並具有預審圖形輔助審查能力，加強建設用好預審專案的實質性審查，為落實最嚴格的土地管理制度把好第一道“閘門”。

“建設專案用地審批”該系統作為金土工程的一核心系統組成部分，實現了從接件、審查到批覆等全過程的管理，具有審批過程中的資料對比分析功能（如呼叫土地利用計劃臺帳、耕地佔卜平衡臺帳、土地供應資訊，與土地利用總體規劃、土地利用現狀進行圖形疊加分析等），對國土部下發的資料交換要求有很好的支援。

忙了三個月的時間，專案總算已經完成，昨天就兩個專案為局做了系統演示，專案方負責組織和對專案進行講解與演示，下一步就是正式投入使用。

專案在投入使用前為客戶主要領導人與業務骨幹進行投入使用前系統演示的重要意義，主要體現如下幾點：

一、         是對專案管理計劃中確定的“里程碑”的一個執行。

二、         得到客戶的寶貴意見（包括專案中已經確定下來的，還有待修改的），對專案正式投入使用做一鋪墊。

三、         投入使用前系統演示可增加專案雙方的感情（特別是高層領導），為以後的繼續合作做基礎。

四、         投入使用前的系統演示可使系統的正式投入使用順利進行。

五、         對於專案方標誌著一個專案即將結束，專案款項即將到位，合同即將收尾。

六、         還有其它一些標誌性的意義，歡迎補充。

必須明確系統投入前的演示至關重要，可以毫不誇張的說，這個工作做不好，可得吃大虧（系統後期推行困難，專案合同難以收尾，甚至可能導致兩方合作關係的破滅等）。

那麼如何更好的全面的做好系統投入前的演示工作。（本人的一些切身體會，不一定對，你可以批評與研論，如有考慮不全的，歡迎補充，謝謝！）

一、         做好充分的準備工作，專案方確定由誰（下文稱為：演示人）組織進行專案演示工作。

二、         演示人做好充分準備工作，如做好一份精細與完整的PPT，準備必要的專案進展報告和里程碑報告等，將對專案的演示起到非常好的效果。

三、         在到客戶現場演示前，我們內部先進行一次全面的系統演示，以確定無誤。要不到了現場給客戶演示時，出了差錯（那怕是一丁點）還了得呀，後果自己想。

四、         事先與客戶商訂系統演示時間和到會人員（建議雙方的核心領導、專案雙方老總、專案經理、核心業務人員和技術骨幹參與），一句話就是關鍵專案干係人必須到會。

五、         專案方內部對到會人員的溝通風格等做一個分析，以便使會上溝通更加容易。一句話就是，如何用別人喜歡的溝通方式進行溝通。

六、         提前到客戶方，進行現場演示環境準備，畢竟是把專案從自己內部搬到客戶方，別到時演示時，出現網路連線不通等低階錯誤。還演示個P呀。

七、         在系統演示前把必要的資料（與專案相關的核心資料：階段驗收報告，業務流程等）發到參會人員，方便討論。

八、         會上指定專門的會議記錄人員（建議各方至少兩名以上的記錄人員，原因簡單，一個人記錄難免出錯）。

九、         專案演示人注意專案的演示時間，別蹭在一個問題上浪費整體時間。

十、         系統演示完後要進行系統的討論，就係統還需完善的地方或不足的地方必須認真記錄，並會後實施。

十一、  系統演示過程中，盡力營造一個輕鬆的會議環境，同時要注意避免會議中衝突的發生。

十二、  會議結束了，雙方要在階段驗收報告上簽字。

十三、  演示結束後，要認真落實會議上的決定。