成本需求為什麼不屬於項目需求

⑴ 項目需求 該 怎麼寫

主要包括以下內容： 1、項目概要（扼要說明項目的內容、技術特點等，限100字）。 2、項目的目的、意義及必要性。 項目在全國（省、行業）科技與經濟發展的地位和作用，要解決的關鍵技術、工藝。項目的創新性和先進性分析，對專題的響應程度分析。 3、國際水平、現狀及發展趨勢。 4、國內相關產品與技術發展水平、現狀。 說明相關產品與技術現狀、發展趨勢。 5、項目前期研製開發及技術准備情況。 發展該項目前期研發及相關技術准備工作情況，是否有階段性成果等。 6、項目產業化實施方案。 1) 實施方式、技術路線（自主開發、消化吸收、國際合作等），技術風險和知識產權情況。 2) 與原有同類型產品技術、性能指標和參數對比。 3) 項目開發內容與方式（包括主要研製開發、實施內容及考核目標）。 4) 開發後產業化目標及生產能力情況。 7、項目進度安排與實施期限。 8、技術經濟效益分析。 包括生產效益指標、生產成本分析、不確定性分析、項目的經濟效益分析。 9、項目資金安排、資金來源與落實情況。 10、 社會、經濟效益分析。 包括能源利用效率分析、環境保護和資源利用效益分析、促進產業發展作用分析，提供主要分析指標及演算方式，投資回收期，投資利潤率；投資利稅率，盈虧平衡點，凈現率，內部收益率等。 11、 項目申報單位及項目協作單位概況。 項目申報單位以及合作單位的技術力量和人員結構。技術創新條件（創新機構與設施，試驗檢測條件，中試）及生產條件等。財務基本狀況，各自承擔的主要工作或有關協議合同復印件。項目主要承擔人員的姓名，職稱，職務，專業與特長。 12、 其他需要說明的問題。 在其他條款中未能說明的情況，如：是否涉及環境評估。土地購置、消防評估等。 13、 項目申報單位簽章。 必須由項目申報單位法人代表簽字，並加蓋公章。 14、 各地級以上市經貿局（經貿委）及當地財政部門作為項目主持單位，負責項目的審核並蓋章，省直單位的項目由所屬，省資產經營公司，部份省屬企業（集團）作為項目主持單位，負責項目審核並蓋章。

採納哦

⑵ 《項目管理》簡答題 分別舉出2個屬於項目和不屬於項目的例子

屬於項目的：建造人民英雄紀念碑，組織春節晚會。

不屬於項目的：汽車製造廠的汽車生產，倉庫的原材料管理。

根據項目的定義就能夠舉出例子來。

項目的特點是是一次性、獨特性、目標的明確性、組織的臨時性。如：建設一個軟體系統、組織一次上海旅遊。

從項目特點的反面來舉例2個重復進行的活動，比如：伊利集團某車間生產牛奶製品、網路公司進行的人力資源管理。

(2)成本需求為什麼不屬於項目需求擴展閱讀：

「項目是在限定的資源及限定的時間內需完成的一次性任務。具體可以是一項工程、服務、研究課題及活動等。」

「項目管理是運用管理的知識、工具和技術於項目活動上，來達成解決項目的問題或達成項目的需求。所謂管理包含領導（leading）、組織（organizing）、用人（staffing）、計劃（planning）、控制（controlling）等五項主要工作。」

項目管理（Project Management）：運用各種相關技能、方法與工具，為滿足或超越項目有關各方對項目的要求與期望，所開展的各種計劃、組織、領導、控制等方面的活動。

項目管理本身屬於項目管理工程的大類，項目管理工程包括：開發管理(DM)、項目管理(PM)、設施管理(FM)以及建築信息模型(BIM)。

而項目管理則又分為三大類：信息項目管理、工程項目管理、投資項目管理。

信息項目管理

是指在IT行業的項目管理。

工程項目管理

主要是指項目管理在工程類項目中的應用，投資項目以及施工項目管理。其中，施工版塊主要是做到成本和進度的把控。這一板塊主要使用工程項目管理軟體來把控。

投資項目管理

主要是用於金融投資版塊的把控，偏向於風險把控。

1、 項目范圍管理

是為了實現項目的目標，對項目的工作內容進行控制的管理過程。它包括范圍的界定，范圍的規劃，范圍的調整等。

2、 項目時間管理

是為了確保項目最終的按時完成的一系列管理過程。它包括具體活動界定，活動排序，時間估計，進度安排及時間控制等各項工作。很多人把GTD(Getting Things Done)時間管理引入其中，大幅提高工作效率。

3、 項目成本管理

是為了保證完成項目的實際成本、費用不超過預算成本、費用的管理過程。它包括資源的配置，成本、費用的預算以及費用的控制等項工作。

4、項目質量管理

是為了確保項目達到客戶所規定的質量要求所實施的一系列管理過程。它包括質量規劃，質量控制和質量保證等。

5、項目人力資源管理

是為了保證所有項目關系人的能力和積極性都得到最有效地發揮和利用所做的一系列管理措施。它包括組織的規劃、團隊的建設、人員的選聘和項目的班子建設等一系列工作。

⑶ 項目需求的確立

大部分IT項目缺乏支持文檔，縱然擁有商業案例（ Business Case ）或其他相關文檔，也不能很明確地把項目所需的工作涵蓋起來，只能建立項目的周邊，對項目的實際工作量缺乏描述，這很容易導致項目過程中所產生的變動。
為解決這個和問題，國際上已於上世紀 80 年代末期開始採用「」（ Statements of Work 或簡稱 SOW ）來固定范圍，同時放棄范圍定義（ Scope Definition ）的應用。因為 IT 項目有別於其他基建項目的地方在於基建項目有其他附屬文檔來支持范圍定義，比如在基建項目的項目范圍中，一般都有諸如項目的有關設計圖則、用料標准等等明文規定，讓范圍能夠非常明確地涵蓋基本的工作需求。而 IT 項目的項目范圍中往往沒有這樣的定義。
以商業效益來確認功能需求，再利用功能需求來建立。而在范圍確認後，緊跟著必需建立詳細的工作需求和，否則項目的工作便像橄欖球內的充氣量一般，可以按照客戶的要求隨意變動。
工作需求和項目計劃基本上是利用（ Work Breakdown Structure ）建立。明確的工作陳述（ SOW ）讓渠道商或服務商了解本身的服務承諾，有效地建立項目的成本，降低項目過程中所產生的變動。這些應該在銷售過程中建立，成為服務合約的內容一部分。萬一合約中只有項目范圍定義，那麼交付小組必須在交付初期建立有關的項目工作陳述，避免交付期間所產生的爭議。

⑷ 成本和需求的關系

成本減少，產品價值減少，價格圍繞價值上下波動。價格減少，那麼生產原同樣價值的產品就會比原來多。需求關系呈現供過於求的現象，需求就會上去如果不上去將會商品積壓

⑸ 產品視圖中的需求跟項目中的需求有何不同

1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟體系統最為困難的部分就是准確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟體系統的介面.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間介面是系統開發人員最頭痛的問題.
對於商業最終用戶應用程序,企業信息系統和軟體作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便並非出於商業目的的軟體需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟體.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟體開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟體.不幸的是,當他們開發完這個工具後,發現這個工具不能列印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思准確,如果我們沒有編寫文檔,軟體達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟體需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示:
圖4-1 需求工程域的層次分解示意圖
需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟體類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面:
確定產品所期望的用戶類別.
獲取每個用戶類的需求.
了解實際用戶任務和目標以及這些任務所支持的業務需求.
分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息.
將系統級的需求分為幾個子系統,並將需求中的一部份分配給軟體組件.
了解相關質量屬性的重要性.
商討實施優先順序的劃分.
將所收集的用戶需求編寫成文檔和模型.
評審需求規格說明,確保對用戶需求達到共同的理解與認識,並在整個開發小組接受說明之前將問題都弄清楚.
需求管理需要"建立並維護在軟體工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,並真正把需求應用到產品中.通常的需求管理活動包括:
定義需求基線(迅速制定需求文檔的主體).
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它.
以一種可控制的方式將需求變更融入到項目中.
使當前的項目計劃與需求一致.
估計變更需求所產生影響並在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上.
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤.
在整個項目過程中跟蹤需求狀態及其變更情況.
以上幾點說明是我總結了成功實施項目後系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結.
4.需求的類型
下面這些定義是需求工程領域中常見術語的定義.
軟體需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求).
1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明.
2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明.
3.功能需求(functional requirement)定義了開發人員必須實現的軟體功能,使得用戶能完成他們的任務,從而滿足了業務需求.
在軟體需求規格說明書 (SRS)中說明的功能需求充分描述了軟體系統所應具有的外部行為.軟體需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟體功能需求也許只是系統需求的一個子集,因為另外一些可能屬於子系統(或軟體部件).
作為功能需求的補充,軟體需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標准、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟體產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要.
下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤並通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到並高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換.
從以上定義可以發現,需求並未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什麼.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們並非本書所要討論的.
5.需求分析的原則
不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險.
不適當的需求過程所引起的一些風險:
1. 無足夠用戶參與
客戶經常不明白為什麼收集需求和確保需求質量需花費那麼多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,並一同經歷整個開發過程.
系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險.
2. 用戶需求的不斷增加
在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃並不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在於用戶需求的改變和開發者對新需求所作的修改.
要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標准給予明確說明,並將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助於所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中.
產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,並能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利於減少因變更導致質量的下降.
3. 模稜兩可的需求
模稜兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明.
模稜兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,並且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例並重做許多測試.
處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目後期才被發現,那時再發現的話會使得更正代價很大.
4. 不必要的特性
"畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中並未涉及的新功能.經常發生的情況是用戶並不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張.
同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什麼要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能.
5. 過於精簡的規格說明
有時,客戶並不明白需求分析有如此重要,於是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然後讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明.這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品).
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難.
7. 不準確的計劃
據統計,導致需求過程中軟體成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析.
對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基於不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經准備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標並堅持完成它.
6.需求分析人員和用戶的合作關系
優秀的軟體產品是建立在優秀的需求基礎之上的.而高質量的需求來源於客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處.
只有當雙方參與者都明白要成功自己需要什麼,同時也應知道要成功合作方需要什麼時,才能建立起一種合作關系.由於項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟體產品.
軟體客戶需求權利書列出了十條關於客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟體開發人員、分析人員的義務.而軟體客戶需求義務書也列出了十條關於客戶在需求過程中應承擔的義務.如果願意,可以將其作為開發人員的權利書.
客戶有如下權利:

⑹ 生產成本為什麼不影響總需求

因為經濟學理論中沒有生產成本影響需求的命題。

所謂的生產成本影響需求應該是生產成本帶動的供應量的增加或減少，從而影響需求，是供求關系，不是生產成本。

⑺ 項目需求管理的流程有哪些

1。 實施過程中產生的新需求該由誰來承擔主要管理責任?項目管理者聯盟 項目經理在這種需求的調研的深入程度上如何進行控制?這也關繫到項目團隊的 成本管理。因為項目經理投入精力進行需求管理必然會產生額外的工作量投入。 那能否直接將需求轉移給產品經理? 2. 實施過程中出現的新需求，往往也會帶來新的合同機會，所以是否由專業的技術人員管理(如產品經理)，並反饋給銷售經理?那麼整個需求的傳遞流程 如何才能形成閉環?或者說各崗位的分工界面如何劃分。 3. 就算是項目經理可以把新需求轉移出去管理，那麼如何能保證從需求產生 到產品實現再到合同落實這個過程中每個環節都能有量化的工作價值統計?即轉自項目管理者聯盟 通過哪種權益分配方案最能夠調動整個環節中所有人的積極性，從而保證項目 可以良性地持續地進行滾動發展。項目管理培訓 現實工作中的項目往往牽涉范圍較廣，參與的崗位角色眾多，項目經理一方面需要 在保證一定客戶滿意度情況下完成項目，另一方面也面對著項目落地過程中出現的 各種新問題新機會的局面。這種情況下如何定義項目經理同其他崗位的責任分工界面 最能將PM價值最大化是一個復雜的問題。
我們公司通常應用日事清系統來配合需求管理，日事清是專業的工作計劃、工作日誌軟體,方便團隊加強團隊協作,優化項目管理流程,提升工作效率,獨創的工作日誌一鍵生成輕松完成一天工作!

⑻ 求解習題：項目范圍管理與項目成本管理是什麼關系，為什麼

上面的舉人抄書有什麼用？我來根據我的理解通俗的說：

項目范圍管理：是確定一個項目需要做哪些工作。
項目成本管理：是確定一個項目需要花多少錢。

因此，這兩者的關系應該是前者是後者的必要條件。就是說，你必須知道這個項目要做哪些工作，你才可能知道這個項目要花多少錢。

項目工期管理：也叫項目進度管理、項目時間管理，其實就是通過估算、籌劃、控制，使項目在預定時間內完成。
項目質量管理：其實就是通過一定的體系、方法、措施，保證項目管理過程偏差較小，保證項目成果與預定目標偏差較小。
從它們的定義和內容可以看出，工期管理和質量管理的必要條件也是范圍管理。
同時，在項目范圍確定的框架下，費用、工期、質量三者互相影響和牽制。好的項目管理，就是使費用、工期、質量三者達到最佳的平衡狀態。

⑼ 項目成本管理

項目成本管理(project cost management)：承包人為使項目成本控制在計劃目標之內所作的預測、計劃、控制、調整、核算、分析和考核等管理工作。 項目成本管理就是要確保在批準的預算內完成項目，具體項目要依靠制定成本管理計劃、成本估算、成本預算、成本控制四個過程來完成。 項目成本管理是在整個項目的實施過程中，為確保項目在以批準的成本預算內盡可能好的完成而對所需的各個過程進行管理。
即利用WBS方法，先把項目任務進行合理的細分，分到可以確認的程度，如某種材料，某種設備，某一活動單元等。然後估算每個WBS要素的費用。採用這一方法的前提條件或先決步驟是:
①對項目需求作出一個完整的限定。
②制定完成任務所必需的邏輯步驟。
③編制WBS表。
項目需求的完整限定應包括工作報告書、規格書以及總進度表。工作報告書是指實施項目所需的各項工作的敘述性說明，它應確認必須達到的目標。如果有資金等限制，該信息也應包括在內。規格書是對工時、設備以及材料標價的根據。它應該能使項目人員和用戶了解工時、設備以及材料估價的依據。總進度表應明確項目實施的主要階段和分界點，其中應包括長期定貨、原型試驗、設計評審會議以及其他任何關鍵的決策點。如果可能，用來指導成本估算的總進度表應含有項目開始和結束的日歷時間。
一旦項目需求被勾劃出來，就應制定完成任務所必需的邏輯步驟。在現代大型復雜項目中，通常是用箭頭圖來表明項目任務的邏輯程序，並以此作為下一步繪制CPM或PERT圖以及WBS表的根據。
編制WBS表的最簡單方法是依據箭頭圖。把箭頭圖上的每一項活動當作一項工作任務，在此基礎上再描繪分工作任務。
進度表和WBS表完成之後，就可以進行成本估算了。在大型項目中，成本估算的結果最後應以下述的報告形式表述出來:
①對每個WBS要素的詳細費用估算。還應有一個各項分工作、分任務的費用匯總表，以及項目和整個計劃的累積報表。
②每個部門的計劃工時曲線。如果部門工時曲線含有"峰"和"谷"，應考慮對進度表作若干改變，以得到工時的均衡性。
③逐月的工時費用總結。以便項目費用必須削減時，項目負責人能夠利用此表和工時曲線作權衡性研究。
④逐年費用分配表。此表以WBS要素來劃分，表明每年(或每季度)所需費用。此表實質上是每項活動的項目現金流量的總結。
⑤原料及支出預測，它表明供貨商的供貨時間、支付方式、承擔義務以及支付原料的現金流量等。
採用這種方法估算成本需要進行大量的計算，工作量較大，所以只計算本身也需要花費一定的時間和費用。但這種方法的准確度較高，用這種方法作出的這些報表不僅僅是成本估算的表述，還可以用來作為項目控制的依據。最高管理層則可以用這些報表來選擇和批准項目，評定項目的優先性。 以上介紹了三種成本估算的方法。除此之外，在實踐中還可將幾種方法結合起來使用。例如，對項目的主要部分進行詳細估算，其他部分則按過去的經驗或用因素估演算法進行估算。
基於預算的目標成本控制方法
在國內企業中間，採取嚴格的預算管理的企業並不多見。盡管一些企業管理者從各種渠道了解到實行預算管理的種種好處，因而每到年底，他們總會要求財務部門，或者是銷售部門，或者是"總經辦"這樣的部門去為來年做一份預算。然而，由於大家都對怎樣做預算一知半解，企業平時又沒有積累起做預算所需要的各種數據，以及做預算所需要相應的組織環境，加上時間十分緊迫(通常他們會要求有關人員在1-7天內完成)和其它一些原因，他們做出的預算，其實只是做預算者在揣摸領導意圖後拿出的一個來年的花錢的計劃。而且做這個計劃的人通常明明知道這個花錢計劃只是做一做，滿足老闆當前的要求而已。在大多數企業中，很少有人認為預算會是有用的，不是指預算從理論上講無用，而是在他們的企業沒有用。
人們普遍確信的是，"計劃沒有變化快"。"計劃沒有變化快"，這是句話可以作多樣理解的話。一種理解是，老闆自己不會按照他要求做出的預算執行，預算做得再好也沒有用。一種理解是，我們的企業根本就做不出切實可行、行之有效的預算。還有一種理解是，人際關系太復雜、當家的人太多，即便老闆要堅持按預算辦事，也不定那一天就有一人物把他破壞了。可能還有一種解釋是，環境因素變化太快，企業發展的變數太多，根本就無法預測兩三個月以後的事，所以預算做不出來，做了也一定會不實用。
但是，國外成功企業的經驗顯示，預算管理是有效的成本控制方法。所謂預算，通俗的講就是，事前確定好明天花多少錢?哪裡花錢?誰來花錢?怎麼花錢?誰來控制花錢?要回答這些問題，不僅需要對全盤有把握，而且知道資金從哪裡帶來(並保證能得到這筆資金)，以及知道各種需要購進的東西的未來價格走勢。因為是按計劃來花錢，自然就不會亂花錢、花冤枉錢。為什麼說按事前的計劃花錢就不會花冤枉錢呢?因為計劃通常是事前經過在各部門的共同參與下，反復討論協商出來的。
當然，正如世界上沒有絕對好的東西一樣。基於預算的目標成本控制方法。也並非百分之百好用，因為總有一些事情是無法預計的。但這不能否定預算管理的無效，預算一旦執行以後，也不是鐵板一塊，必要的時候是可以作適當調整的。最重要的是，有預算管理一定會比沒有預算管理好。
基於標桿的目標成本控制方法
所謂標桿，就是樣板，就是別人在某些方面做得比自己好，所以要以別人為楷模來做，甚至比別人做得還要好，或說別人做到了那樣的效果，所以我也要求自己達到甚至超過那樣的效果。
這里的"別人"有三層意思:
其一，它可以是別的企業。當一個企業在某些方面做到某種較好程度時，通常就會有一批企業起而效仿它，比如A汽車製造廠由於採用某種新的工藝，促其每台車的生產成本降低了1%，因此眾多的汽車生產企業也紛紛採取這種工藝。又比如，某企業的人均貢獻率達到了某種水平，於是一家企業開始研究它是如何達到那個水平的，當這家企業確信自己找到答案時，它便以那家企業為目標，採取措施(不一定跟那個企業的做法一模一樣)試圖取得同樣的人均貢獻率，甚至更高的人均貢獻率。以其他企業為標桿，其學習途徑主要有三個:一是，通過一定的媒介(電視、報紙、期刊、書籍、網路、管理顧問)知道某個企業在某一方面或幾個方面做得比自己好，因而決意學習它。二是，到那家企業參觀學習或由那家企業的人員當面介紹，因而決意學習它。三是，在那家企業工作過的人員帶來了那家企業的經驗，在本企業推廣它。
其二，以自身企業過去的某些績效為標准來作為未來的目標予以控制。比如，在本企業的歷史上，最高的人均利潤貢獻額為50000元，或者銷售費用率僅為8%，於是決意在下一年度以此為目標來予以控制。這一點與基於歷史數據的目標成本控制方法是基本一致的。
其三，是以本企業的某個部門或某個人創造的某項紀錄為目標，要來其他部門或其他人以此為標桿，並力爭超越他。比如，某部門連續三個月創造了人均辦公用品費用不超過10元的紀錄，經分析認為，全公司的其它部門如果努力控制辦公用品使用，也能達到這個效果，於是便在全公司倡導或強制性地執行以那個部門的這一結果為標准，來實施降低辦用品費用的計劃。又比如，某位計件工當月創造了一項較高的生產記錄，公司便號召其他人向他學習，也是一種標桿式的管理方法。
基於市場需求的目標成本控制方法
基於市場需求的目標控制方法(我有時也把它稱為"基於決策層意志的成本控製法"，因為這種方法在使用過程中，決策者的意志將起主導作用)。下面是一個典型的基於市場需求的目標成本控制方法的操作案例。
某公司計劃開發生產一種新產品――A型塗料，公司技術人員經過攻關，終於研製出了這種塗料的配方。生產這種塗料需要用清鉛粉、黑鉛粉、粘土和糖漿四種原料，它們所佔的比重分別為:35%、45%、14%和6%。該公司通過市場調查發現，該類型塗料具有競爭性的市場價格0.50美元/公斤，公司確定的產品種產投放市場後的目標毛利為0.25美元/公斤。這樣一來，A型塗料的目標成本即為0.25美元/公斤(0.50美元/公斤-0.25美元/公斤)。然而該公司通過市場調查得知:上述四種原料的成本分別為0.45美元/公斤、0.18美元公斤、0.15美元/公斤和1.00美元/公斤。據此，A型塗料的成本為:0.45×35%+0.18×45%+0.05×14%+1×6%=0.31美元/公斤。也就是說，這個設計方案雖然在技術上是可行的，但其成本卻達不到目標成本的要求。為了實現既定的目標成本，該公司科技人員決定對A型塗料現有的配方進行重新研究調整，以便達到成本目標。通過運用價值工程的原理，他們發現A型塗料耐高溫性能有些過剩，而懸浮穩定性卻略顯不足。為此，科技人員決定在保證A型塗料必要的功能的前提下改進配方。新配方只用清鉛粉、黑鉛粉和膨潤土三種原料，它們所佔的比重分別為15%、80%和5%，而膨潤土的成本僅為0.09美元/公斤。這樣新的A型塗料配方的成本為:0.45×15%+0.18×80%+0.09×5%=0.27美元/公斤。新配方的成本達到目標成本的要求，可以正式投產。
這一方法已經被眾多的企業所採用，即實踐證明它是一種十分有效的控製成本的手段。最初，這種方法可能是某企業迫於競爭的無奈而創造出來的。但是，實際上在競爭並不激烈的產業中，推行此方法依然可以獲得奇特的管理效果。人的潛力是無限的，有時候看似不能達到的目標，如果有一個強權者一定要讓人們達到它，它有時還真得能夠如願以償。許多企業往往並不知道自己企業是否存在降低成本的空間，採取這種方法，有時可以把海綿中所有的水都擰干。
基於價值分析的成本控制方法
一些優秀的製造業中的大企業都使用了這種方法。這類企業往往設有一個專門的部門來負責"降低成本"，他們分析現有的工作、事項、材料、工藝、標准，通過分析他們的價值並尋找相應的替代方案，可以相應地降低成本。比如，某企業的成本管理人員經過認真分析，發現將企業內的保潔工作外包給公司以外的專業保潔公司完成，比企業自己養清潔工成本更低，於是提出議案，公司領導看後認為可以，於是就把公司的保潔工作委託給了一家專業保潔公司。
這種方法在先進的公司使用是經常的和制度化的，即企業設有專門的人員(通常是工程師)以此為工作職責。但是，幾乎所有的公司看似或多或少地使用了這種方法，而其實做得並不專業。具體分析會發現兩種情況:一是，一些企業所進行的價值分析實際上是學另外的企業的經驗。比如，聽到或看到某企業將保潔工作實現外包，降低了保潔和管理成本，於是也來採取外包保潔的管理辦法。這實際上是在運用標桿，而不是獨立的價值分析的過程和結果。其二，一些企業經常也會特地對某些工作、事項、業務、流程等進行價值分析，並且有時也可能找出一個良好的替代方案，以及實行的效果的確比較理想。然而，這種價值分析的過程更多的是因為某些重要人物心血來潮時的行為。
基於經驗的成本管理方法
這是一種最為基礎的和較低級別的，但是應用最為普遍，在一定的條件下效果也是十分好的一種成本控製法。大多數企業的成本管理都是由此開始的，而其他每一種成本控制方法的最底層部分其實都是由此構成的。
它是管理者藉助過去的經驗來現實對管理對象進行控制，從而追求較高的質量、效率和避免或減少浪費的過程。比如說，經驗告訴我們，在采購的過程中，"貨比三家、反復招標、盡量殺價"，可以降低采購成本，於是管理者就要求他們的下屬在采購時"貨比三家、反復招標、盡量殺價"。又比如，經驗告誡我們，對外采購的過程中，如果缺少必要的監督機制，有的采購人員就可能產生自私行為，從而導致企業損失，於是大量的企業常常不惜犧牲效率和成本設置"關卡"來防止采購人員的自私行為。還比如，人們注意到只要對員工盯緊一點，員工的工作效率就會得到相應的提高，於是企業普遍十分強調對員工行為的監督。
毫無疑問，基於經驗的成本管理方法有時是最有效用的提高效率、保證質量和控製成本的措施。一個從最基層銷售員干起，一直干到營銷副總經理職務的管理者，他所管理的銷售人員，一般較少有機會犯直接蓄意損害企業利益的錯誤。然而，經驗有時是也是不可靠的。一位企業總經理過去管理文化層次較低的工作人員的經驗告訴他，加強對犯錯員工的處罰可能減少員工犯錯，從而減少或避免企業的損失，然而如果他管理的工作人員文化層次較高，且都是獨生子女一代，那麼他的這一經驗可能不但不管用，甚至走向反面。
基於經驗的成本管理法有時並不管用，一般出於兩點原因:一是，經驗帶有嚴重的個人色彩，當變化的環境問題超過經驗的范圍時，經驗可能失去效用。二是，經驗往往是"就事論事"的，不是系統思維的結果，因此經驗在實用過程中可能出現系統性消極後果，即對具體的對象而言它們有助於控制甚至降低成本，但就總體而言它們則可能無助於控製成本，甚至造成系統性成本上升，此外，實施經驗化的成本管理，可能在未來留下歷史的陰影。
希望能幫助到你，千萬別忘記點擊採納答案和頂一下哦。