和商譽的影響，這些是強制性的，都是要做的。如果變更，就準備好承擔相應責任。
在不同的項目情景里，我們可能會用到不同的項目關鍵里程碑劃分的方式，最常見的兩種方式有：
強調過程的按階段拆分
強調結果的按迭代拆分
在軟件項目管理中，前者在瀑布模型中比較常見，比如拆成需求分析、設計、編碼、測試、上線等階段。后者敏捷模型中比較常見，比如拆成用戶支付、用戶下單等功能點。這個都需要基于你的項目特點和環(huán)境慎重的判斷和選擇。
其次，在軟件開發(fā)中錯誤發(fā)現得越晚，對于開發(fā)造成的損失越大。里程碑式開發(fā)模式可根據每個階段產出結果分期確認成果，避免血本無歸。通過早期里程碑評審一般可以提前發(fā)現需求和設計中的問題，降低后期修改和返工的可能性。例如，在需求分析階段發(fā)生的錯誤，那么最多就是把需求分析寫一遍，損失的是一個人的勞動；而到了測試階段發(fā)現了需求錯誤，再回去重新做需求分析，那么損失可能是致命的。
而且一般人在工作時都有前松后緊的習慣，里程碑強制規(guī)定在某段時間做什么，從而合理分配工作，細化管理粒度。對復雜的軟件開發(fā)項目而言，每一階段的進度都需要逐步逼近目標，里程碑產出的中間“交付物”就是每一步逼近的結果，也是控制的對象。如果沒有里程碑，中途想知道“現在進度做得怎么樣了”則是很困難的事。
項目人員組織架構
確定項目人員組織架構按 PMP 的說法也叫識別項目干系人，這個是項目管理中一個非常關鍵的事情。
項目干系人我們可以從這兩個維度來識別：
參與項目的人：項目直接關系人包含：項目團隊、項目經理、職能經理等；項目發(fā)起人；業(yè)務伙伴、合作廠商、第三方資源等等。
受項目影響和影響項目的人：客戶/用戶；政府或社會團體機構；普通公眾。
識別干系人我們不是把干系人找出來就可以了，還需要識別每個干系人對項目的需求和期望、對項目的貢獻、影響及其制約作用等這些都是要整理記錄下來，準備后續(xù)的管理。
對于不同的項目關系人，我們在項目管理的時候應該采用不同的管理策略：
權力大且項目相關利益大的要重點管理：他們有很高的權力，也很關注項目的結果，項目經理應該“重點管理”，跟他們明確項目目標，使其積極的參與到項目中來；頻繁地與這區(qū)域的干系人溝通，并聽取他們的反饋建議，讓他們滿意。項目的客戶、主管領導就是這塊區(qū)域的人。
權力大但項目相關利益不大的要令其滿意：他們有很高的權力，但對項目的相關性不是很大，這一區(qū)域的人項目經理應該定期向他們匯報項目的進展結果，這一部分人更關注結果，不需要了解細節(jié)。我們要保證這一部分人滿意，盡量不要讓他們影響項目的正常進展。
權力小但項目相關利益大的要隨時告知：項目結果會直接影響到這一部分人，所以項目的進展、變更等等一系列的事情，都應該隨時告知這部分人。
權力小且項目相關利益也小的要最小關注：利益低權力也低，花很少的精力關注下即可。
識別出項目關系人是第一步，下一步我們要梳理出項目的關系人組織架構，理清關系人之間的業(yè)務關系。最常見的我們有兩種干系人組織架構圖：
一種是基于項目組織相關方的梳理方式，如把項目核心工作團隊和周邊相關組織分離出來，明確項目核心工作團隊和上層管理決策團隊、兄弟依賴團隊、行業(yè)運營團隊等部門之間的關系。目標是明確在項目中各個組織的定位和職責；
第二種是基于項目任務的拆分，明確各個子系統(tǒng)、模塊的負責人，這樣的好處是確定每個干系人的職責范圍和項目工作匯報關系；
但要強調的一點是識別干系人是需要持續(xù)識別并貫穿項目的始終的事情：
干系人識別不可能一步到位一下子就全部識別出來，雖然在啟動階段識別全部的干系人一般會作為目標，但是這是一個幾乎不可能完成的任務。因為不同的項目階段，項目的干系人會不同。
項目在運行過程當中，干系人也是會發(fā)生變化的，當干系人發(fā)生變動時，要重新對干系人進行識別和評估，并主動投入精力進行溝通和交流，力爭新的項目干系人是為項目服務的。
干系人對項目的態(tài)度也會發(fā)生變化，開始時支持項目的干系人，如果在執(zhí)行過程中干系人發(fā)現項目已經不再符合他的利益，甚至損害他的利益，則可能會從支持者的角色轉變到反對
