本文主要介绍PMBOK所述的项目管理体系中，启动过程组中项目整体管理知识领域中的制定项目章程子过程。
本文主要从该过程可以获取的资源、可以使用的工具、在该过程中需要做的事情(个人经验总结)、做完该过程可以获取的结果四个方面来论述。
一、项目启动阶段
1.1 制定项目章程
1.1.1 可以获取的资源
1.1.1.1 合同
作为项目经理，在接手这个项目时，如果已经签属了合同，尽量能拿到合同进行阅读。因为合同是第一手的反应客户需求和意向的资料，及反应工作成果有效性的依据。
当然也有可能任命你为项目经理时，还没有签属合同，但是这时，一般是有一些意向和备忘录，项目如果大一些时，会有很多会议记录及相关的资料。这些都是最为原始的意向资料，需要及时获取并分析。
当然，作为紧急招聘的项目经理，高层出于合同部分事项的保险考虑，有可能不将合同拿给项目经理看。此时，项目经理需要及时和上级领导沟通，尽可能多的获取项目意向、范围、环境等资料。
1.1.1.2 项目工作说明书
俗话说，工欲善其事，必先利其器。为了能高完成客户目标的成功率，那么就必须比客户更了解他们。那么对客户提供的产品、服务、行业背景、工作流程等信息要了解。甚至能站在行业标准、方法论的层次来指导客户，和客户共同制定新的规则、标准和流程。
工作说明书包括经营需要、产品范围说明书、战略计划等，项目工作说明书理应属于顾客招标文件的一部分。
当然，作为在项目确立前、或者项目刚成立就介入的项目经理，很有可能是未拿到项目工作说明书的。只是能从上级领导或客户那获取一定的获取项目工作说明书的机会。
那么这个项目工作说明书是需要项目经理和他所带领的团队来制作的。
在这方面，如果资源允许，最好能请到行业专家或者对客户熟悉、甚至是来自客户的专家、或者是客户所处行业的权威作为专家来进行项目工作说明书的编写。当然，当项目团队可调配资源不充分的时候，这个活一般是项目经理来主导完成。当然，他也可以把纲领性的部分完成，让团队成员来分担一些体力活部分。
1.1.1.3 事业环境因素
一个项目、一个企业和行业不可能独立的存在，那么与关联的事物就是我们需要了解的。只有对大的周边环境有所了解，才能更有利于我们理解行业、企业、项目。
事业环境因素包括：
★ 组织或公司的文化与组成结构（在管理系统中，该部分可能被转化为用户、部门、权限等模块或子系统。）
★ 公司或行业标准（如管理部门的规章制度、产品标准、质量标准与工艺标准，在一些财务、基建等与数据标准相关的系统中，可以用作预警线等比较和提示功能，当然像一些制度性的，可以作为知识库的形式存在）
★ 基础设施 （如现有的设施和生产设备）
★ 现有的人力资源（如技能、专业与知识，例如设计、开发、法律、合同发包与采购）
★ 人事管理（如雇用与解雇指导方针、员工业绩评价与培训记录，像ERP系统中的人事管理系统、绩效管理系统都来源于此资料的收集）
★ 公司工作核准制度 （诸如一些涉及到工作流的系统中，对核准标准、审批、报送流程都需要非常细致的前期积累）
★ 市场情况 (可以建立竞争对手资料库、竞争产品库及分析系统)
★ 利害关系者风险承受力 （了解各方收益与能承受损失的价值区间）
★ 商业数据库 （如标准的费用估算数据、行业风险研究信息与风险数据库，个人觉得该部分信息的采集是非常的有意义的。在企业或政府的不断动作与发展中，基础数据的大量积累，会导致企业的思想者希望从中挖掘出有意义的信息，并产生价值。那么建立数据集市和数据仓库，并通过人工智能、数据挖掘来发现已存在但并不为人所知的模型。 或者采用统计学中的各种短、中、长期分析模型与找到和总结出一些规律性的东西，个人认为都是非常有价值的）
★ 项目管理信息系统(如自动化工具套件，例如进度管理软件工具、配置管理系统、信息收集与分布系统，或者与其他在线自动化系统的联网接口。该信息在做Portal、数据交互、资源整合类项目和产品时，是必须收集的信息项，因为你只有对现有的情况了如指掌的时候，做总体设计时，才能游刃有余。)
1.1.1.4 组织过程资产
组织的正式和非正式的方针、程序、计划和原则。组织从以前项目中吸取的教训和学习到的知识，如完成的进度表、风险数据和挣值数据。组织过程资产的组织方式因行业、组织和应用领域的类型而异。可以归纳为二类：
■ 组织进行工作的过程和程序
● 组织标准过程，如标准、方针标准产品与项目生命期，以及质量方针与程序;
● 标准指导原则、工作指令、建议评价标准与实施效果评价准则。
● 模板（如风险模板、工作分解模板与项目进度网络图模板）
● 根据项目的具体需要修改组织标准过程的指导原则与准则。
● 组织沟通要求（如可利用的特定沟通技术，允许使用的沟通媒介、记录的保留，以及安全要求）
● 项目收尾指导原则或要求 (如最后项目审计、项目评价、产品确认，以及验收标准)
● 财务控制程序（如时间报告、必要的开支与支付审查、会议编码，以及标准合同条文）
● 确定问题与缺陷控制、问题与缺陷识别和解决，以及行动追踪的问题与缺陷管理程序;
● 变更控制程序，包括修改公司正式标准、方针、计划与程序，或者任何项目文件，以及批准与确认任何变更时应遵循的步骤。
● 风险控制程序，包括风险类型、概率的确定与后果，以及概率与后果矩阵;
● 批准与签发工作授权的程序。
■ 组织整体信息存储检索知识库
● 过程测量数据库，用于搜集与提供过程与产品实测数据；
● 项目档案(如范围、费用、进度，以及质量基准、实施效果测量基准、项目日历、项目进度网络图、风险登记册、计划的应对行动，以及确定的风险后果)；
● 历史信息与所得经验知识库(如项目记录与文件，所有的项目收尾资料与文件记录，以前项目选择决策结果与绩效的信息，以及风险管理努力的信息)
●量问题与缺陷管理数据库，包括问题与缺陷状态，控制信息，问题与缺陷解决和行动结果。
● 配置管理知识库，包括公司所有正式标准、方针、程序和任何项目文件的各种版本与基准。
● 财务数据库，包括如工时、发生的费用、预算以及任何项目费用超支信息。
1.1.2 可以使用的工具和技术
1.1.2.1 项目选择方法
为了在有效的时间内产生更大的收益，需要采用一些选择项目的方法。一般分为两大类：
■ 效益测定方法，比比较法、评分模型、对效益的贡献或经济学模型；
■ 数学模型，如利用线性、非线性、动态、整数或多目标编程算法。
当然不是说选择必须就仅仅使用以上的方法，或者说使用某一种方法。而是先在大方向上，符合公司的整体战略布局，其次在微观上，能赚到相对多的利益，及将风险控制在适当的范围。比较、平分更多的时候，是在相同定位上类似的项目进行比较。
另外，对于很多初创型企业，更多的注重风险。因为初创型企业在操作上一般有较多的不规范。致使短时候内，有可能取得较大的收益，但是，有时候不可控的风险也容易致使项目失败，严重者会导致公司的倒毙。
对于成长型的企业，拥有的资金一般比较稳定，而且储备比较足。更多的会从产品的影响力、给公司带来的潜在影响考虑。特别是考虑上市、融资等资本动作型的企业。更是如此。
1.1.2.2 项目管理方法论
其实PMI推出的PMBOK中说的五个过程组、44个子过程就是一个比较成熟的项目管理方法论。在项目整体规划时，可以对此体系进行裁剪。
1.1.2.3 项目管理信息系统
项目管理信息系统（PMIS）是在组织内部使用的一套系统集成的标准自动化工具。项目管理团队利用项目管理信息系统制定项目章程，在细化项目章程时促进反馈，控制项目章程的变更和发布批准的项目章程。
1.1.2.4 专家判断
专家判断经常用来评价制定项目章程所需要的依据。这种判断及专长在本过程中可用于任何技术与管理细节。任何具有专门知识或经过训练的集体或个人可提供此类专家知识，知识来源包括：
■ 执行组织内部的其他单位
■ 咨询公司
■ 包括客户或赞助人在内的利害关系者
■ 专业和技术协会
■ 行业集团
一般在公司内部都会有方案、策划人员，他们一般具有一到多个行业的专家角色，对行业知识比较了解，但是，有时候当方案、策划人员站的角度不够，或者出方案的级别不够时，就有可能需要咨询公司来帮助解决了。
1.1.3 需要做的事情
1.1.3.1 明晰项目目标
当领导或者投资人与你接恰时，需要对项目的基本情况、流程套路、需要完成的目标、项目涉及的利益所得者、个人和组织需要付出的投入及收益有较清晰的了解。可以在脑海中快速模拟整体个项目的运作。及收搜相关的专业知识。当然在模拟的过程中，需要你对行业知识、专业技术、项目管理流程、质量标准等有一定的知识积累。
当整理后，可以就此项目的目标、所处战略中的位置、短期及长期收益、大致的成本和直属领导和投资人进行讨论。并确认自己是否适合承接此项目。可能是个人理解问题吧，本人只承接自己评估成功率比较大的项目。因为并不是所有的项目都适合你。比如，我原来做.net框架下的软件有五年的开发和架构经验。而如果此系统需要我带领一个java团队，我会考虑难度系数的增加，我是否可以接受。另外，还存在一个机会成本问题。
当然，当项目比较大的时候，应该先给自己一个缓冲的时间段，去做调研。出可行性报告。然后给投资人和领导以最终的回复。
1.1.3.2 明确项目经理的权利、职责和义务
一个没有授权的项目经理做起事情来无疑是束手束脚的。没有相关的权利，很多容易的事情就会变得复杂起来。而一个不会用合适方式要求合适权利的项目经理，我认为不是一个好的项目经理。
上级领导给你权利是希望你帮他做事的，帮他完成项目目标，分担他的压力。所以必定会给你压担子，给你定职责。有些是你可以接受的，另外有一些可能是你不能接受的。
在领导给你的职责中，我觉得有一部分应该算是行业默认必须做的。这部分我称之为义务。另外，有一部分，凭主观能动性来完成的。
1.1.3.3 得到一个正式的任命
一个正式的任命相当于上级领导给相关人员的一个正式周知。告诉他们，这件事情上他们看好你。并让你尝试做这个事情。并会给你相关的权利和义务。希望大家配合你。当然，如果能举行一个项目启动会，并有公司的高层及投资人在场，这样无疑会能你项目的顺利进行开个好头。但是，在弱矩阵类型的项目中，或者因为某些原因，你会非常低调的被任命，当然这也是有利有弊的。所以，需要根据具体的情况来操作。但是，我个人认为，总体来看，有正式的任命还是利大于弊的。这样会让自己定位比较准。
1.1.4 工作的成果
1.1.4.1 项目章程
项目章程是正式批准项目的文件。该文件授权项目经理在项目活动中动用组织的资源。项目应尽早选定和委派项目经理。项目经理任何时候都应在规划开始之前被委派，最好是在制定项目章程之时。
由项目组织之外的、适合为项目提供资金的项目启动者或发起人来发布项目章程。项目通常是由项目执行组织的企业、政府机构、公司、项目集组织或项目组合组织，出于以下一个或多个原因而颁发章程并给予批准：
市场需求、营运需要、客户要求、技术进步、法律要求、社会需要。
有时候，在组织中，因结构简单、或者人员较少、或者是组织初建等原因，不会有很正式的文件和仪式。
另外，项目章程是个一个正式的说明，最重要的我觉得是投资人、你的直属领导对你的信任。相信你有带领团队完成这个目标的能力。信任才是最持久的，因为不信任你，随便可以用正式的文件换掉你。
本文以PMBOK的知识体系为基础架构，并在此基础上进行了一些总结和加了一些自己的理解。如果不当之处，敬请留言。
我会持续的就44个过程，按照这个模式进行总结。这个过程也是我将软件行业与项目管理进行融合的一个过程。希望大家有好的建议也给我消息啦。
