项目章程
1. 文档简介

此文档目的旨在说明本次厦门机场货运系统升级项目的项目目标、项目范围、初步项目计划、项目双方相关责任人及承担责任，并通过双方项目负责人对此文档的签署确认以上内容，做为项目实施过程中的基本依据。

2. 项目综述
2.1 背景

20##年，天信达信息技术有限公司为厦门机场货站提供了货运信息系统CFPS。随着厦门机场货站业务的不断发展，机场集团对该货运系统提出了更高要求，其中包括更好的可维护性、更友好操作界面、更强大的统计功能，更稳定高效的数据库及应用服务。经过天信达信息技术有限公司与厦门机场货站协商，决定对系统进行升级，并签定了《天信达厦门机场货运业务管理系统集成升级技术合同》。

2.2 项目目标

通过本次项目升级，达到以下目标

1.  改善目前货运系统的使用流程，提高系统使用性和数据准确性。

2.  优化财务及货运量统计功能，通过系统对运营数据的统计分析功能，提高厦门机场货站管理层对市场的控制及决策能力。

3.  增加出港分单业务功能，实现厦门机场出港分单业务全面数据化，提高厦门机场货站生产效率。

4.  使用.NET开发平台，提供更加便捷、人性化的操控界面。

5.  增加海关新舱单系统功能，满足海关新的业务标准。

2.3 项目范围

本次项目升级实现功能详见合同附件一《技术备忘录》，各功能具体的业务实现方式将以合同附件四《需求说明书》为标准。我们将以合同附件一《技术备忘录》、合同附件四《需求说明书》作为项目范围控制的根本依据，在产品开发完成后的项目实施阶段，厦门机场提出的客户化修改意见，天信达将计算人工成本，按照合同附件二《厦门货站货运系统升级报价(系统软件)》的规定，天信达将提供100人天的客户化修改服务，当实际修改工作量超出合同规定的100人天时，天信达将通过项目变更管理流程执行（详见项目变更管理流程）。

2.4 项目主要干系人

厦门机场货站：

项目负责人   刘宇光； 业务技术负责人  陈涛

主要责任：

1.  调动厦门机场方面各类资源，配合天信达的项目执行工作

2.  完成项目执行过程中各阶段可交付物成果及相关文档的确认工作。

3.  在项目执行期间，对各部门提出的项目范围内的需求修改意见进行总结、筛选及确认。

天信达信息技术有限公司：

项目经理     刘浩瀚

主要责任：

1.  确定项目范围，严格按照项目范围执行项目，保障项目每一阶段可交付物的质量，并得到用户方认可。

2.  制定项目计划，并尽最大努力保障项目按照计划执行。

3.  与用户方负责人保持良好的沟通，及时发现并解决项目执行过程中的各项问题。

项目组成员：

产品顾问：刘伟      

货运核心业务开发组负责人：顾翠霞      

货运核心业务开发组成员：赵小伟  李国进  孟庆国   刘爱华   杨志晓

接口功能开发组负责人：陈绍健

接口功能开发组成员：王强富  张庆华

技术支持工程师：郭红霞

2.5 假设和约束

如果由于以下情况的发生，导致项目范围及进度变化，将严格执行项目变更流程，天信达对由此给项目带来的负面影响不承担责任：

A 客户方部门组织结构变化，导致各部门业务流程发生改变。

B在项目实施阶段，客户方提出严重超出附件一《技术备忘录》及《需求说明书》内容的需求修改意见，导致系统需要结构性调整。

C 由于甲方或第三方不能积极配合或不能按时完成承诺任务，例如保障硬件设备按时到货和正常运行；保障网络的稳定性；在项目执行中提供规定的文档，例如《系统测试修改意见报告》（详见《项目实施计划》第3.6节）。

D 本项目硬件设备设计方案由天信达提供，天信达应承担因硬件设备设计方案的不合理性或遗漏导致不符合生产要求的责任。

2.6 项目的批准及授权
此项目由天信达信息技术有限公司总经理郭东丹及厦门国际航空港空运货站有限公司机场货站总经理蔡祖明正式授权，于20##年6月18日对此项目正式批准，并授权刘宇光为甲方项目经理，刘浩瀚为乙方项目经理。

3. 初步项目实施计划

3.1 项目启动

计划内容：

制定并确认《项目章程》，包括项目范围、项目初步计划以及双方相关责任人的确认

地点：厦门机场国内货站

计划时间：20##年4月

双方责任

项目经理刘浩瀚提供《项目章程》初稿，并进行详细说明。通过双方项目负责人详细讨论并最终确认签署《项目章程》。

可交付物成果：《项目章程》

3.2 需求调研

计划内容：

由天信达工程师对项目范围中的各内容进行咨询，并通过走访各相关部门负责人，了解实际业务流程，汇总需求，并最终制定《需求说明书》，此阶段任务已经完成，其中《需求说明书》已经做为合同附件经甲乙双方认可并签署。

地点：厦门机场

计划时间：20##年2月16日－20##年3月3日

双方责任：

由天信达工程师走访各部门，详细了解客户方业务流程，汇总各部门需求意见。并提供《需求说明书》，厦门机场货站负责人积极配合天信达工程师，全程陪同走访咨询过程，并要求各部门负责人积极配合天信达工作，全面完整的提出需求修改意见。经过双方多次详细沟通讨论，最终制定并签署《需求说明书》，以此做为项目范围控制的重要标准。

可交付物成果：《需求说明书》

3.3 系统设计开发及内部测试

计划内容：根据附件一《技术备忘录》、附件四《需求说明书》，天信达项目组开发团队进行系统的设计开发及内部测试工作，最终提供《厦门机场货运系统CFPS3.0升级测试版》。

地点：北京天信达公司

计划时间

设计开发：20##年5月7日－20##年7月31日。

内部测试：20##年8月3日－20##年8月19日

双方责任:天信达开发团队及厦门机场测试人员严格按照《需求说明书》和《技术备忘录》内容中要求进行开发工作，并通过严格内部测试，保障产品质量。厦门机场测试人员将在内部测试后期，利用一周的时间到达天信达本部，配合天信达执行内部测试工作。

可交付物成果：厦门机场货运系统

3.4 硬件设备现场安装调试

计划内容：天信达工程师到达厦门机场，对硬件厂商（厦门机电）的硬件设备安装工作进行指导和监督，确保硬件设备服务器架构达到合同《附件五厦门空港货站生产系统升级集成商技术要求》之规定标准。

地点：厦门机场货站

计划时间：20##年8月10日－20##年8月14日

双方责任：天信达负责第一批硬件的监督验收工作，天信达提供数据库结构报告、维护手册，服务器端应用系统安装手册，维护手册，并提供维护培训。

可交付成果：《数据库结构报告》、《数据库维护手册》《应用服务器系统安装手册》《应用服务器系统维护手册》

3.5 系统安装调试

计划内容：天信达工程师现场安装调试系统，保障系统数据库和应用服务稳定运行。

地点：厦门机场货站

计划时间：20##年8月20日－20##年8月24日

双方责任：厦门机场应首先保证硬件设备和本地网络的稳定可用性。天信达工程师负责系统的安装调试工作，并保证数据库服务和应用服务的稳定运行。

可交付成果：厦门机场本地环境下稳定运行的CFPS3.0货运操作系统。

3.6 CFPS3.0系统操作培训

计划内容：天信达技术支持人员对厦门机场业务骨干进行系统操作培训。

地点：厦门机场货站

计划时间：20##年8月25日－20##年8月31日

双方责任：厦门机场应提供培训场地及相关设备（如投影仪等），制定业务人员培训计划，并保障业务人员准时参加，建议参训人员脱产培训。天信达对厦门机场业务骨干进行培训工作，并提供《系统使用手册》。

可交付成果：《系统使用手册》、《培训验收报告》

3.7 厦门机场货运系统CFPS3.0客户端测试

计划内容：由厦门机场项目负责人组织各部门业务骨干对厦门机场货运系统CFPS3.0进行全面测试使用，总结并归纳系统修改意见及bug，最终提供《测试系统修改意见报告》文档。其中对于厦门机场提出的新的需求修改意见（以《需求说明书》和《技术备忘录》为基准），超出以上范围的需求，我们将计算人工成本，并将该人工计入附件二《厦门货站货运系统升级报价(系统软件)》规定的100人天工时。违背需求说明书内容的计入

地点：厦门机场货站

计划时间：20##年9月1日－20##年9月20日。

双方责任：厦门机场应积极组织测试团队，按照《需求说明书》和《技术备忘录》内容，对系统进行完整流程测试，由客户方项目负责人总结归纳修改意见及bug。天信达技术支持人员将配合厦门机场负责人，对测试中遇到的各种问题进行及时的沟通、确认工作，并区分定义出阻碍生产流程，在系统切换前必须修改完成的内容。最终经双方签字确认《测试系统修改意见报告》。

可交付物成果：《测试系统修改意见报告》

3.8 系统完善阶段

计划内容：由天信达开发组根据《测试系统修改意见报告》，进一步完善优化系统，在本阶段主要解决阻碍生产流程的需求修改意见和bug，并为系统投产做稳定性测试。在此期间客户方提出的超出《测试系统修改意见报告》内容的需求修改将被记录，为保障项目实施计划，这部分修改意见将在项目验收后维护阶段讨论执行。

地点：北京天信达公司

计划时间：20##年9月1日－20##年9月30日

双方责任：天信达开发团队严格按照《测试系统修改意见报告》内容对系统进行完善修改工作，由于时间限制，天信达将优先解决《测试系统修改意见报告》中定义的阻碍生产流程的修改内容，该部分修改意见完成后，系统即达到上线切换标准，天信达组织会议，与厦门机场讨论并确认《系统切换方案》。报告中的其他内容天信达将在系统稳定切换后逐步完成。厦门机场配合天信达，对已经修改内容进行测试工作，并与《测试系统修改意见报告》内容进行核对，经双方确认后，签定《系统切换达标书》。

可交付物成果：稳定运行的货运系统CFPS3.0，《系统切换达标书》，《系统切换方案》。

3.9 新老系统并行阶段

计划内容：按照《系统切换方案》厦门机场组织人员投入新系统的使用，天信达技术支持人员到达现场协助厦门机场，保障新系统的稳定运行。

地点：厦门机场货站

计划时间：20##年9月21日－20##年9月30日

双方责任：厦门机场负责人积极组织各部门业务人员投入新系统的使用，确定各部门业务骨干，熟练掌握新系统的使用流程，为下一步全面切换做好准备，在天信达的协助下对每天的系统使用情况进行记录，分析总结系统使用中出现问题的人为原因和系统原因，并形成《系统每日使用报告》。天信达技术支持工程师到达现场，协助客户使用新系统，保障系统投产稳定运行，并配合厦门机场负责人对每日系统使用情况进行总结，形成《系统每日使用报告》。在此期间客户方提出的超出《测试系统修改意见报告》内容的需求修改将被记录，为保障项目实施阶段系统的稳定性，这部分修改意见将在项目验收后，售后维护阶段协商解决。

可交付物成果：《系统每日使用报告》。

3.9系统正式使用阶段

计划内容：按照《系统切换方案》，厦门机场停止老系统使用，全部业务转入新系统。

地点：厦门机场货站

计划时间：20##年10月1日－20##年10月30日

厦门机场负责人积极组织各部门业务人员全面使用新系统，各部门业务骨干应起到模范带头作用，指导协助全体业务人员积极使用新系统。厦门机场项目负责人在天信达的协助下对每天的系统使用情况进行记录，分析总结系统使用中出现问题的人为原因和系统原因，并形成《系统每日使用报告》。天信达技术支持工程师现场协助各部门业务骨干使用新系统，保障系统投产稳定运行，并配合厦门机场负责人对每日系统使用情况进行总结，形成《系统每日使用报告》。在此期间客户方提出的超出《测试系统修改意见报告》内容的需求修改将被记录，为保障项目实施阶段系统的稳定性，这部分修改意见将在项目验收后，售后维护阶段协商解决。

可交付物成果：《系统每日使用报告》。

4 项目变更管理

在完成《厦门机场货运系统升级项目需求说明书》后，项目执行阶段，厦门机场提出的客户化修改意见，天信达将计算人工成本，按照合同附件二《厦门货站货运系统升级报价(系统软件)》的规定，天信达将提供100人天的客户化修改服务，当实际修改工作量超出合同规定的100人天时，则需要进行项目变更流程，主要过程如下：

1.  由客户方提出需求修改申请（文字描述）。

2.  天信达对需求修改的可行性及影响进行评估，如果认为确实不可行，则给出详细理由，并进行书面答复。经双方讨论协商，尽量选择替代方案。

3.  经评估后可以完成的需求，则进行工作量评估，上报公司领导，提出商务意见。

4.  经双方协商确认后，签署《项目需求变更申请表》如下：

                                       编号：

甲方：厦门国际航空港空运有限公司      乙方：天信达信息技术有限公司

甲方代表                                  乙方代表                     

签署日期                                  签署日期                       

第二篇：项目计划模板-1

（项目名称）

项目综合计划

（项目经理姓名和/或关键小组成员）

修改号：

修改日期：

编写人：

日期：

审批人：

日期：

项目计划大纲

1.0 引言

作为项目起源的问题/机会陈述。

2.0 项目概述和章程

此处包括项目的总体描述。即关键目标、长度，以及主要的风险和收益。还包括一个项目章程。项目章程规定了项目的目的、影响说明书和与外部组织的接口。

3.0 目标和目的

项目目标和目的应该包括项目成功应该满足的可衡量标准（成本、进度和质量）。

初步的项目成本/收益分析（ROI、NPV、回收期等等）的结果，当存在时，应该被包含在此章中。本章所描述的目标和目的将用来：

● 指导项目执行，记录项目计划编制的假定，以及有关项目方案的选择决策。

● 促进干系人之间的沟通，协助关键的管理审查。

● 提供项目进展衡量和项目控制的基线。

4.0 工作分解结构

工作分解结构（WBS）是以可交付成果为导向的项目元素的分组，它组织和定义了项目的总体范围。它用来建立或确认对范围的共同的理解，层次越低，对项目元素的描述越详细。

WBS的每一细目都被分配了独特的编码，并且在WBS字典可以描述每个控制帐户；即分配给单个组织/个人的，用来管理范围、进度和成本的可管理的工作块。它的编码方式还可以包括成本帐户结构。

5.0 工作说明和范围要求

● 范围说明，（有时被称为工作说明（SOW））,是对已知的整体工作范围的叙述性描述，它因该反映成功完成项目所必需的所有工作。

● 范围说明应该使用与工作分解结构相同的结构，由段落和子段落组成。范围说明通常是写在WBS的高层和/或中层；如控制帐户及其以上的层次。

● 特征和功能要求应该加以明确规定，因为他们定义了项目应该包括和不应该包括的内容。

● 范围说明或工作说明的编写使干系人对于项目范围有了共同的理解。它应该包括：

A. 项目产品－产品描述摘要

B. 项目可交付成果－将项目范围的主要部分分为更小的更好管理的部分。可能时应该规定排除在可交付成果之外的情况。

6.0 进度

这一章描述了保证项目及时完成的进度过程。以下时对项目进度计划编制主要过程的概述。

● 活动/任务/子任务定义－识别出得到项目各种可交付成果所需的具体活动。还识别出与项目进展和结果相关的主要里程碑。

● 活动/任务/子任务排序－识别活动间的依赖关系、关键可交付成果和约束条件。

● 活动/任务/子任务历时－估算完成每个活动所需的历时。

● 进度计划编制－分析所收集的数据，将数据输入进度计划，分析活动顺序、历时和资源要求。

7.0 项目人员安排

利用范围说明或工作说明（SOW）以及项目工作分解结构识别必需的技能，应该选择和通过谈判获得人员组成一个项目小组，从而能够完成项目范围中的具体任务和子任务。项目小组的结构应该与项目WBS的结构匹配，采取职责矩阵的形式。项目职责矩阵应该记录小组的职责和任务。

8.0 预算/资源要求

预算/资源要求包括了四个主要过程，以保证项目在批准的预算内完成。这些过程共同建立和维持了一个综合的项目范围、进度和成本基线（也成为成本基线）。这一基线应该包括在本章节当中。

成本预算-考虑了各种成本核算选择方案之后做出的对完成工作所需的资源成本的估算。

成本预算-以工作范围为基础，将成本总估算分配给个别的工作细目，从而建立项目成本基线。而此项目成本基线将用来衡量和监测成本绩效。

资源计划编制-确定完成工作所需的资源，包括编制规定团体成员的职责的职责分配矩阵，目的是，并且建立项目的必要沟通网络。

成本控制=这包括控制改变项目成本基线（综合的范围、进度、成本基线）的因素的行为。此部分应该包括对项目所运用的挣值管理技术的描述。

9.0 假定

在所有领域，特别是不存在明确定义的领域，必须设定和使用假定。一个假定的成败对其在项目中目前的未来的运用是至关重要的，假定应该在整个初期计划阶段被规定，并记录在本部分当中，用于所有的范围/质量、成本和进度计划。

对假定的详细记录包括识别与项目计划所有组成相对应的假定。项目控制账户的关键假定可以记录在wbs字典中。其他假定应该随着所有其他范围、质量、进度和成本计划的编制加以记录。

10.0风险

风险管理包括在项目全过程中管理风险所使用的程序。本部分将对下列主要过程进行概述。

● 风险管理计划编制-重点是编制风险管理计划。

● 风险识别-可能影响项目的风险。

● 风险评估-评价风险和风险的相互作用，从而评估可能的后果。必要时同时使用定性和定量的分析方法。

● 风险应对计划编制-定义把握计划的步骤和应对威胁的方法，包括具体的应对选择方案和行动界限。

● 风险监测/控制-跟踪风险和风险的影响，跟踪缓解计划的编制和执行产生的影响，寻找新的风险。参见以下的11.0

● 风险分析工作表的作用是纪录风险识别、定性分析、应对措施和控制/报告。

11.0项目报告和控制

报告-再项目整个生命周期中，应该定期对项目成本、进度和技术绩效进行报告。这应该包括有报告内容的规定，如分发列表、管理审查和纠正措施。经常性的项目审查会议也应加以计划，并包括在本章当中。

控制-对项目状况的管理审查、缓解项目绩效问题的纠正措施计划编制和实施。控制的重点应该是如下四个领域：

● 工作范围和技术应用-评价正在完成的工作是否符合经批准的项目范围，并且评价相关技术是否满足项目目标。本部分应该记录挣值管理技术的方法和应用。

● 成本控制-按照项目基线监测项目进度绩效，以保证以最低成本完成经批准的项目范围。

● 进度控制-按照项目基线监测项目进度绩效，以保证及时完成。

● 风险应对控制-评价个别的绩效问题如何影响项目的所有目标：范围、进度和成本。必要时进行综合的风险缓解跟踪。参见以上的10.0。

12.0变更控制

全面的变更控制包括（a）影响导致变更的因素：(b)确定变更是否发生；（c）变更发生时管理变更。这要求：

● 维持健全的绩效测量基线。

● 保证产品范围的变更被包含并且反映在项目范围定义中。变更指令日志是纪录所有变更申请处理情况的文档。

● 协调跨知识领域的变更。（进度变更常常影响成本、风险、质量和人员安排）

● 保证对项目基线变更进行明确的变更识别，管理审批，和正式实施。

13.0约束条件

约束条件对项目可能产生正面或者负面的影响。在尽可能的情况下，每个项目都要识别约束条件（内部或者外部），约束条件的类型可能包括（还有其他泪向）：

● 项目里程碑

● 资源可得性

● 交付日期

● 监管机构或法律问题

14.0 沟通计划编制

项目沟通计划编制包括保证项目信息及时并且适当地生成、收集、散布、储存和最终处理所必需的过程。它是项目成功所必需的人员、想法和信息之间的关键连接。此处应该适当的记录并且由项目经理及其小组遵循的主要过程如下。

● 沟通计划编制－－确定干系人的信息和沟通需求：睡需要什么信息；他们何时需要；如何将信息传达给他们。应该包括所有重复进行的项目会议计划编制。

● 信息分发－－使项目干系人及时获得所需信息。

● 绩效报告－－收集和散布绩效信息。这包括状态报告、进展衡量和预测。适当参考本项目计划的11.0、17.0和其他有关章节。

● 管理收尾－－生成、收集和散布信息，从而正是结束项目阶段或项目。

15.0 质量计划编制

项目质量计划编制包括保证项目满足其预定需求所必需的过程。这包括确定质量政策、目标和责任的所有活动。

此处应该适当记录并且由项目经理及其小组所遵循的主要过程如下。

● 质量计划编制－－识别与项目相关的质量标准并且确定如何满足这些标准。

● 质量保证－－定期评价项目总体绩效，从而保证项目将满足相关的质量标准。

● 质量控制－－检测具体项目结果，从而确定它们是否符合相关质量标准，并且设法消除造成不满意绩效的原因。

16.0 合同和采购计划编制

项目合同和采购计划编制包括从执行组织外部获取货物和服务所必需的过程。这些货物和服务，或“产品”，是通过六个过程获取的。此处应该适当记录并且由项目经理及其小组所遵循的主要过程如下。

● 合同采购/计划编制－确定采购什么，何时采购，包括需提前很长时间定购的货品。

● 询价计划编制－记录产品要求和识别潜在供方。

● 询价－获取适当的报价、出价、发盘或建议书。

● 供方选择－从潜在卖方中选择。

● 合同/采购管理－管理与卖方的关系。

● 合同/采购收尾－合同/采购的完成和解决，包括任何未决事项的解决。

可能的话，主要的分包商、咨询顾问和供应商应该在此或在本计划的第7.0章确定。

17.0项目完成

在项目生命周期的早期阶段做好项目完成计划将保证所有必要的项目完成可交付成果被捕捉。这些可交付成果可以作为未来项目的参考和/或用于审计目的。项目完成可交付成果可以包括，但不局限于，如下内容：

● 可交付成果

● 项目计划

● 工作范围

● 估算

● 成本文件

● 变更指令申请

● 进度

● 月度状态报告

● 工程设计图纸

● 规格

● 可交付成果摘要

● 项目文档索引和关键项目函件，以及外部文档

● 经验教训

● 其它项目细节

● 变更指令日志

又见有关项目沟通计划编制的第14.0章的管理收尾，作为相互参照。

18.0附属的与项目相关的计划

● 范围计划

● 进度计划

● 成本计划

● 质量计划

● 人员获取计划

● 沟通计划

● 风险管理计划

● 风险应对计划

● 采购计划

其它计划可能也属于项目计划编制，这取决与项目的需求以及客户和项目母公司的政策。