和商誉的影响，这些是强制性的，都是要做的。如果变更，就准备好承担相应责任。
在不同的项目情景里，我们可能会用到不同的项目关键里程碑划分的方式，最常见的两种方式有：
强调过程的按阶段拆分
强调结果的按迭代拆分
在软件项目管理中，前者在瀑布模型中比较常见，比如拆成需求分析、设计、编码、测试、上线等阶段。后者敏捷模型中比较常见，比如拆成用户支付、用户下单等功能点。这个都需要基于你的项目特点和环境慎重的判断和选择。
其次，在软件开发中错误发现得越晚，对于开发造成的损失越大。里程碑式开发模式可根据每个阶段产出结果分期确认成果，避免血本无归。通过早期里程碑评审一般可以提前发现需求和设计中的问题，降低后期修改和返工的可能性。例如，在需求分析阶段发生的错误，那么最多就是把需求分析写一遍，损失的是一个人的劳动；而到了测试阶段发现了需求错误，再回去重新做需求分析，那么损失可能是致命的。
而且一般人在工作时都有前松后紧的习惯，里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理粒度。对复杂的软件开发项目而言，每一阶段的进度都需要逐步逼近目标，里程碑产出的中间“交付物”就是每一步逼近的结果，也是控制的对象。如果没有里程碑，中途想知道“现在进度做得怎么样了”则是很困难的事。
项目人员组织架构
确定项目人员组织架构按 PMP 的说法也叫识别项目干系人，这个是项目管理中一个非常关键的事情。
项目干系人我们可以从这两个维度来识别：
参与项目的人：项目直接关系人包含：项目团队、项目经理、职能经理等；项目发起人；业务伙伴、合作厂商、第三方资源等等。
受项目影响和影响项目的人：客户/用户；政府或社会团体机构；普通公众。
识别干系人我们不是把干系人找出来就可以了，还需要识别每个干系人对项目的需求和期望、对项目的贡献、影响及其制约作用等这些都是要整理记录下来，准备后续的管理。
对于不同的项目关系人，我们在项目管理的时候应该采用不同的管理策略：
权力大且项目相关利益大的要重点管理：他们有很高的权力，也很关注项目的结果，项目经理应该“重点管理”，跟他们明确项目目标，使其积极的参与到项目中来；频繁地与这区域的干系人沟通，并听取他们的反馈建议，让他们满意。项目的客户、主管领导就是这块区域的人。
权力大但项目相关利益不大的要令其满意：他们有很高的权力，但对项目的相关性不是很大，这一区域的人项目经理应该定期向他们汇报项目的进展结果，这一部分人更关注结果，不需要了解细节。我们要保证这一部分人满意，尽量不要让他们影响项目的正常进展。
权力小但项目相关利益大的要随时告知：项目结果会直接影响到这一部分人，所以项目的进展、变更等等一系列的事情，都应该随时告知这部分人。
权力小且项目相关利益也小的要最小关注：利益低权力也低，花很少的精力关注下即可。
识别出项目关系人是第一步，下一步我们要梳理出项目的关系人组织架构，理清关系人之间的业务关系。最常见的我们有两种干系人组织架构图：
一种是基于项目组织相关方的梳理方式，如把项目核心工作团队和周边相关组织分离出来，明确项目核心工作团队和上层管理决策团队、兄弟依赖团队、行业运营团队等部门之间的关系。目标是明确在项目中各个组织的定位和职责；
第二种是基于项目任务的拆分，明确各个子系统、模块的负责人，这样的好处是确定每个干系人的职责范围和项目工作汇报关系；
但要强调的一点是识别干系人是需要持续识别并贯穿项目的始终的事情：
干系人识别不可能一步到位一下子就全部识别出来，虽然在启动阶段识别全部的干系人一般会作为目标，但是这是一个几乎不可能完成的任务。因为不同的项目阶段，项目的干系人会不同。
项目在运行过程当中，干系人也是会发生变化的，当干系人发生变动时，要重新对干系人进行识别和评估，并主动投入精力进行沟通和交流，力争新的项目干系人是为项目服务的。
干系人对项目的态度也会发生变化，开始时支持项目的干系人，如果在执行过程中干系人发现项目已经不再符合他的利益，甚至损害他的利益，则可能会从支持者的角色转变到反对
