IT项目管理的20条锦囊妙计

说实话从项目意向到项目启动，如果完成的好，真的就完成了项目的一半了。

在项目启动前需要完成的任务包括：

项目的意向获取；

项目的核心干系人接触，了解项目的最基本需求、风险、制约和期望，并考虑基本假设；

进行项目方案的准备并与核心干系人达成一致意见，这个可能要反复几轮；

双方达成商务意向，内部也要与必要的供应商或分包方达成商务意向；

完成内部的可行性研究报告，这一点最麻烦，对外部而言可能是先完成招投标，也可能就是口头约定，但在内部的立项，确定成本中心、收入中心、项目预算等都是极其重要的事情；

然后，组织项目实施团队（这里的实施是指将项目概念和目标付诸实现的团队，而不仅是狭义的系统实施工作），项目实施团队中的核心人员应当尽可能多地参与第3步的活动，这样才不会出现，“跟客户拍脑袋，团队拍屁股”的情况；

接下来，对方案的各部分拆解，确认自制/采购的决策，其实如果是熟悉的领域，一般就是采购也会有既定伙伴，如果是不熟悉的领域，供应商方案和能力考察就要在第2、3步之间完成；

最后，走完双方或多方的立项过程，召开项目启动会，明确目标、各方责任、里程碑、成功标准、退出标准等，以及项目管理流程和要求，如开发流程、需求管理流程、质量管理流程/标准、变更控制流程、问题升级流程等，如果软件企业规范，这些应该是那一套模板，甚至就在一个文档中说明的组织级要求。

到这里，基本上启动前的工作才做得差不多，这里只能写个梗概，供您参考吧。还有很多细节和组织战略紧密相关，但是在此无法尽述。

在上述过程中，1~4步，属于商务洽谈得范畴，不太有章可循，但也与技术、方案挂钩；5~8步，属于企业管理或项目管理的范畴，是有一定之规或有章可循的。另外，这些过程并非瀑布式的死套路，而要灵活，知道项目前期准备与项目、项目交付之间的关系，发现问题要及时到更早的步骤去找原因，并尽快解决。

以下内容根据网上内容进行收集整理

2015年参与了公司十三五的IT战略规划编制，当时并没有了解太多战略规划方法论，主要还是咨询公司主导。近期又参与到IT战略规划的修编，希望能做得更好一些，有所提升，所以仔细研究了下四大咨询公司IT战略规划项目的方法论（资料大多来自百度文库），毕竟这些咨询公司很善于把无序的项目型工作整理出结构化的方法论来。从各家规划的方法论来看，套路基本相似，根据这些规划方法论层层展开、分析，一家公司的IT战略规划也就逐渐明晰起来。

IT战略：制定信息化的愿景、目标和需要的能力，并给出信息化建设指导原则；

IT架构：勾画实现IT战略目标所需要的应用系统架构、集成技术架构和基础设施架构目标蓝图；

IT管控：搭建IT总体管控模式、定义IT组织结构、职能和关键岗位职责、定义IT管理流程框架和IT评价及审计机制。

总的来讲，在项目启动之后，整个规划项目将划分成四个关键的步骤：分析业务与IT现状、确定IT战略方向、设计未来IT蓝图以及制定IT战略实施计划。各个阶段将分别完成一系列任务，并提交相应的工作成果。

在整个项目过程中，最关键、最核心的是未来IT蓝图设计阶段。项目组将在理解了客户的业务战略、业务现状、IT现状以及已有的IT项目计划的基础上，充分运用埃森哲对业务发展趋势以及技术发展趋势的深刻理解，参考国内行业机构在实施信息化过程中的各种先进经验，为客户设计出未来的IT蓝图。

本阶段埃森哲最重要的任务是通过与客户项目负责人的深入沟通，进一步明确并确定项目的工作范围，在此基础上制定出合理的项目计划。同时，埃森哲与客户双方均需尽快为项目配备相应的资源。

项目启动阶段最重要的成果是明确可行的项目计划。

在现状分析与诊断阶段，埃森哲项目组将基于埃森哲已有的对税务业务的理解，进一步了解客户业务流程的特点，从而了解客户各级部门面临的与信息技术有关的主要问题和需求。

另一方面，更重要的是要了解分析客户当前的IT架构（包括数据架构、应用系统架构、IT基础设施架构）和IT管控模式（包括IT部门的业务流程、IT部门组织和管控模式等），从而对客户已经具有的信息技术能力有一个全面的了解。

通过对客户业务与信息技术现状的调研，项目组将会对客户的业务和信息技术条件有基本的理解，并对客户的长处和弱点有所了解。

在现状分析与诊断阶段，项目组将会阅读客户所提供的大量的文件、资料等，并会对客户各主要业务部门以及信息技术部门进行一系列的访谈。

现状分析与诊断阶段最重要的成果是现状分析报告。这份报告一方面要描述业务现状与信息技术现状的基本情况，另一方面，更重要的是要识别出业务对信息技术提出的最主要的需求，以及信息技术领域面临的一些最主要的问题。

我们将通过对 客户主要领导进行访谈，获得对客户业务战略的理解。在分析了客户业务与信息技术的现状，并理解了客户的业务发展战略的基础上，项目组将结合埃森哲全球税务咨询的经验和对信息技术的深刻理解，并参考国内外的先进实践经验，制定出客户的IT战略方向。

我们假设客户已经清楚地定义了业务发展战略，并且形成了相应的文件。因此我们的访谈只是对有限的问题与客户主要领导进行进一步确认。当我们完成对业务战略和IT战略方向的确认和定义后，也将与客户主要领导对该结果进行确认。

如前所述，决定客户的IT战略实际上就是要分析业务战略对信息技术提出的要求，从而定义出客户的IT愿景、关键的IT目标、需要的IT能力，以及IT在客户应该扮演的角色。

在确定了IT战略方向以后，我们还会根据客户的现状、战略目标以及先进的实践经验，形成制定IT蓝图的一些重要的指导原则和一些基本思路。

项目组所确定的战略方向、指导原则以及初步的设计思路将会客户进行充分地沟通，得到客户的确认之后，这些原则和初步思路将用于指导下一阶段的IT蓝图设计。

这个阶段的主要任务是设计客户未来的IT架构和与之配套的IT管控模型。IT架构包括数据架构、应用系统架构以及IT基础设施架构（硬件设备、系统软件和网络等），而IT管控模型则包括IT组织、IT流程以及IT绩效管理等。

业务对信息技术提出要求，同时，信息技术也会为业务的发展提供新的可能。因此，在设计未来的IT蓝图时，有可能会发现，有必要对部分的业务流程进行调整和优化。流程改进的建议也将在这个阶段完成。

根据分析结果并经过深圳国税的确认后，项目组将定义客户的信息技术能力蓝图和IT架构。定义的IT架构覆盖以下方面：

数据——确定主要的数据来源和数据流（数据分布和数据接口），这一方面是为了将应用系统与业务流程对应起来，另一方面也是为了支持业务流程以及应用系统之间的信息流

应用系统——既包括各个应用系统的功能描述，也包括应用系统的集成与整合架构

IT基础设施——对支持应用系统的关键硬件、系统软件、设施加以说明，并勾画出概要的网络结构与网络资源需求

为了管理、执行和支持所定义的 IT 架构，需要对信息技术进行有效的管控。 IT 管控模型主要包括以下要素：

IT业务流程——定义IT系统的规划、建设、维护等业务流程以及相关的决策和财务方面的责任

IT部门的组织模型——定义IT部门的组织结构、角色、职责以及IT部门与其他业务部门的关系

IT部门的绩效目标和考核指标——定义业务绩效指标，指导IT组织的管理

IT业务规范和标准——确定用于指导IT系统实施和绩效监控的原则（如定义服务水平，系统开发标准等）

分析 客户未来IT蓝图与现状之间的差距，确定这些差距的难度与优先级，提出客户的IT系统整合候选方案，并对候选方案进行综合对比分析，提出建议方案。根据整合方案确定在今后三年中客户需要实施的IT项目、在实施阶段中各个项目的时间顺序、相互依赖关系、项目时间表和需要的资源。

我们还将在项目中与 客户密切配合，基于客户的业务战略和业务需要确定适当的实施战略、实施指导原则、实施所需的方法论支持、客户需要提供的保障条件等。

项目进行过程中，每个阶段结束以后，项目组都会提交相应的报告，作为该阶段的工作成果，而所有这些报告以及相应的过程文件便组成了整个项目的交付成果。

为了帮助 客户更好地理解我们在本项目结束后将提交的工作成果，下面对本规划项目将交付的成果进行初步的解释，并给出了其中部分成果的示例。

项目启动阶段的主要成果是项目计划，项目计划的主要内容包括：

项目进度计划

项目资源计划与职责定义

项目质量计划

项目文档模板

项目进度计划示例可参见本项目建议书“项目进度计划”部分。

现状分析阶段的任务一方面是了解客户的业务特点和业务对信息技术提出的需求，另一方面是了解客户现有的IT架构和IT管控模式。现状分析阶段的工作成果是现状分析报告。

在了解了客户业务与信息技术现状的基础上，结合埃森哲对税务行业和信息技术的深刻理解，项目组将提出客户未来的信息技术发展战略方向。相应的结论将包含在现状分析报告中一并提交。

现状分析报告主要包括以下内容：

客户业务现状概述

业务对信息技术提出的关键需求

客户现有的IT架构；包括数据架构、应用系统架构、基础设施架构

客户IT管控的现状；包括IT业务流程、IT部门的组织模型、IT部门的绩效目标和考核指标以及IT业务规范和标准等

客户信息技术发展战略方向、指导原则和初步思路

现状报告的重点是发现问题。除了详细的现状描述以外，现状报告将会对项目组在业务流程、业务需求、IT架构、IT管控方面的一些关键发现进行归纳，并有重点、有针对性地提出客户IT发展的战略方向、指导原则以及一些初步的思路，为下一步的蓝图设计奠定基础。

蓝图设计阶段的主要任务是基于现状分析的成果，在IT发展战略方向与指导原则的指引下，提出必要的业务流程改进或者流程重整的建议，设计客户未来的IT架构与IT管控机制。

蓝图设计阶段的主要工作成果是蓝图设计报告。这份报告将包含以下一些基本内容：

业务流程改进建议

未来的数据架构

未来的应用系统架构；包括应用系统的功能分布、主要应用系统描述、主要应用系统的迁移路径建议、应用系统集成与整合架构等

未来的基础设施架构；包括网络、硬件、系统软件以及运行维护、开发、安全等的基本原则

未来的IT管控机制；包括主要IT业务流程的定义、IT部门的组织结构、IT部门绩效考核与考核指标、IT业务规范

对于客户而言，应用系统的集成与整合将是未来的蓝图设计要解决的特别突出的一个问题，这方面的工作将体现在“未来的应用系统架构”部分。

制定出客户的IT蓝图之后，项目组将分析客户未来IT蓝图与现状之间的差距，确定这些差距的难度与优先级。提出客户的IT系统整合候选方案，并对候选方案进行综合对比分析，提出建议方案。根据整合方案确定在今后三年中客户需要实施的IT项目、在实施阶段中各个项目的时间顺序、相互依赖关系、项目时间表和需要的资源。

现状与蓝图之间的主要差距

总体实施计划：项目划分；总体阶段划分；各个阶段的时间安排、资源需求、预期效果；实施过程中的关键因素

项目定义：对主要项目的范围、目标、资源需求、成本收益等进行定义与分析

项目实施过程中的工程管理方法

总体实施计划示例：

即使在最完美的条件下，管理一个软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。不过，只依靠某一两条“妙计”，是无法顺利完成项目的。

1定义项目成功的标准

在项目的开始，要保证各方对于判断项目是否成功有统一的认识。通常，跟紧预定的进度是明显的成功要素，但是肯定还有其他的因素存在，比如，增加市场占有率、获得指定的销售量或销售额、取得特定用户满意程度、淘汰一个高维护需求的遗留系统等。

2把握各种要求之间的平衡

每个项目都需要平衡它的功能、人员、预算、进度和质量目标。我们把以上五个项目方面中的每一个方面，综合成一个约束条件，你必须在这个约束中进行 *** 作;你也可以定义成与项目成功对应的驱动力，或者定义成通向成功的自由程度。可以在一个规定的范围内调整。

3定义产品发布标准

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以将发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可 *** 作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与客户所指的“质量”一致。

4沟通

尽管可能无意中了不可能的事件，但不要做一个明知不能保证的。坦诚地和客户和管理人员沟通那些实际成果。任何以前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有真正的作用。

5写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划，困难的部分是做这个计划——思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。

6把任务分解成“英寸大小的小圆石”

“英寸大小的小圆石”是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确地估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。

7为大任务制定计划工作表

如果你的组经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他必须处理的大任务相关的工作量。

8计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用做任何的修改，很好，你已经走在了计划的前面。

9为“过程改进”安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投一些时间在“过程改进”上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

10管理项目的风险

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。

11根据工作计划而不是日历来估计

人们通常以日历时间做估计，但是我倾向于估计与任务相关联的工作计划(以“人时”为单位)的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求、会议，和所有其他会让耗费时间的地方。

12不要为人员安排超过工作时间80%的任务量

跟踪你的组员每周实际花费在项目指定工作上的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。一个员工一周理论上工作40小时，但不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。

13将培训时间放到计划中

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。

14记录你的估算和你是如何达到估算的

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

15记录估算并且使用估算工具

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即将任务量、小组劳动力和进度安排组合起来一看，根本不可能成功。

16遵守学习曲线

如果你在项目中第一次尝试新的过程、工具或技术，你必须承受短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。

17考虑意外缓冲

事情不会像你项目计划的一样准确地进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。向他们指明一些以前项目不愉快的意外，来说明你的深谋远虑。

18记录实际情况与估算情况

如果你不记录花费在每项任务上的实际工作时间，并和你的估算做比较，你将永远不能提高你的估算能力，你的估算将永远是猜测。

19只有当任务100%完成时，才认为该任务完成

使用英寸大小的小圆石的一个好处是：你可以区分每个小任务要么完成了，要么没有完成。这比估计一个大任务在某个时候完成了多少百分比要实在得多。使用明确的标准来判断一个步骤是否真正的完成了。

20公开、公正地跟踪项目状态

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正 *** 作，并且在条件允许时进行表扬。

以我多年参与、主导IT实施/开发项目的经验，我觉得项目实施过程中没有任何问题几乎是不可能的事儿，因此出现问题本身没什么值得大惊小怪的，而如何对待问题、如何处理问题却是一个最值得关注的问题。这就是我所信奉的“问题本身不是问题，对待问题的态度是个大问题”。1、合同签署前要充分了解未来客户方项目负责人的实施方法论有些客户自己不懂该如何实施项目，也谈不上方法论，那么项目过程中可能要以实施人员引导、制订实施方案及项目计划并且征得客户方关键干系人的认可。如果客户自己在实施方面就有自己成熟的一套想法，而且客户反复在沟通过程中强调自己对于项目的要求，那么前期负责和客户接洽的人员就必须对这些信息敏感并且尝试着挖掘一下，客户可能对实施有哪些要求，我们自己是否熟悉这套东西，应该提早准备哪些应对措施。前期与客户接洽的人员切不可不加思索地就来一句“肯定没有问题。。。”之类的承诺。2、要多琢磨客户在项目过程中反复强调的东西一个成熟的客户会在项目启动早期把一些他特别在意的东西反复强调，这些东西很有可能就是客户所预见的项目风险或者项目的方向。实施方项目组成员一定要仔细琢磨客户的意图，琢磨不清楚就多找客户沟通、多提问题以帮助自己理解他的意图。倾听和提问是一个实施顾问特别应该具备的一个素质。3、出了问题要及时回应是人都害怕不确定的东西，客户也一样。如果出了问题，实施方项目组成员或高层没有及时回应对于客户来说是一个非常大为光火的事情。这就跟我们到商场买东西发现所购买商品存在某些问题或者某些疑问时向导购人员提出来，导购人员置之不理是同类的问题。及时做出反应不是要求马上拿出解决方案，而是让客户知道我们已经在采取措施，并且明确给出客户提出解决方案的时间。尤其是获悉相关信息的公司高层更应该及时响应，一个理性的客户肯定不会把芝麻小事也让实施方高层知道，既然知会了高层想必会有客户的道理，比如问题升级了或者遇到了严重的问题。4、针对问题的解决方案切忌含糊、托辞作为客户，项目出现了问题还心情超好的可能性不大。所以，实施方在针对问题给出解决方案一定要慎重：首先仔细分析问题是否真正存在，是否超出了项目的范围，如果存在也不超出范围那么问题的根源可能是什么，现实情况下能否有解决方案，解决方案所需要耗费的成本是否可以承受（是否存在客户承担部分成本的可能？），是否会给客户方带来任何风险，解决方案估计什么时间可以完成等等都需要经过内部专家团队反复推敲、论证、模拟。然后把有完整分析、明确解决方案、完成时间及接口人的信息发给客户，征求客户意见。如果有些东西超出项目范围或者超出实施方的能力，那么也建议诚恳地和客户沟通，看如何通过其他方式来弥补因为这些问题存在所造成的遗憾。提供解决方案时有五个大忌：1)、忌含糊其辞，没有多少人喜欢这些看不明白的东西，可千万别在客户的坏心情上面火上加油；3)、忌没有解决问题的时间表；4)、忌为自己方辩护；5)、忌信口开河似的承诺5、出现问题后要及时展开沟通，丰富沟通的渠道和层次上面谈到了及时回应，算是及时沟通的一种，但还不全面，那只能在问题出现以后稍稍缓和客户的情绪。在提出解决方案、和客户确认以及方案实施的过程中，建议实施方负责人要在自己公司内部(尤其与高层之间)、以及客户方项目干系人之间及时、定期展开沟通。如果问题的确比较严重，对项目有较大影响，项目负责人还应该考虑丰富沟通渠道、提高双方沟通的层次，以便于可以有效地把处理的进度、遇到的问题传递给双方项目组、管理层，及时调动优质资源配合问题的及时管控、处理。我觉得做到了以上五点，再配合以专业技术层面的努力，大部分客户应该都会满意，而不至于项目合作双方的不愉快从此成为项目的一个噩梦烦扰着彼此。其实我们不需要也无法苛求彻头彻尾的专业，但我们一定要有一个专业的态度和精神，这是我看待项目合作的一个基本态度。

来自8Manage IT团队的消息:

IT 项目管理最常见的挑战分别为：

学习曲线大。由于 IT 领域甚广，例如懂 IT 基础设施的团队多数不懂行业特定的应用软件开发。

不明确的需求及其蔓延性。项目授权使 IT 项目开展，但它不能替代从所有利益相关者那里收集详细的需求和期望，且需要处理未知或不明确的需求以及它们的蔓延性。

合作伙伴缺乏清晰的沟通。IT 项目经理若不能妥善管理沟通，就容易发生冲突，这可能影响按时交付和实现项目目标。

IT 组件的复杂依赖关系。团队遇到的另一个 IT 挑战是 IT 组件与 IT 基础架构 及 IT 组件与 IT 组件之间的复杂依赖关系。

针对这4种挑战一下为我的解决方案：

1不同类型的 IT 项目有不同的侧重点和管理陷阱。项目失败与否很大程度取决于项目资助人或管理层对 IT 项目团队尝试和错误所花费的时间与成本的容忍度。要解决 IT 项目的最大挑战，最重要的先决条件是找对团队，确保项目团队对项目涉及领域有足够的认识、经验和技能。

2在项目开始时使用PM 的需求管理功能来确保您有适当的工作流来收集、确认和签署项目需求，并重新确认时间线和成本预算。同时在 PM 的项目计划与执行中可实时重新协商时间和重新分配资源，并实时看到时间线和成本预算方面的必要变化。

3将合作伙伴及供应商纳入项目的利益相关者，而供应商参与项目的员工纳入项目成员管理，这不但简化和自动化您的 *** 作，还能最大化来自供应商的信任 。

4使用 8Manage PM 把每个 IT 组件可交付成果和其依赖的其他可交付成果关联，这样每个可交付成果负责人都能随时看到以下最新信息。

IT项目管理是项目管理在IT领域的应用，结合IT行业特点运用项目管理技术、理念和方法，包括9大知识领域（项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理）以及启动、计划、实施、控制和收尾等过程组成。

在IT项目管理中通常会使用8Manage项目管理工具，可以从立项-计划-实施-收尾等全过程监控，可以管理到项目的进度、计划、风险、资源、成本、需求、变更、时间等方面， 项目实时管理，第一时间汇总项目动态，项目超支、风险预警提醒，支持多部门、多站点、大型复杂项目，多项目实时管理，第一时间发现项目问题，迅速提醒、响应。

IT项目的特征：

(1)时间紧迫性。

任何项目都有周期限制，但是IT行业的特点决定了其在这方面有更加严格的要求。IT项目的紧迫性决定了项目的历时有限，具有明确的起点或终点，当达到了目标或目标被迫终止时，项目即结束。随着信息技术的飞速发展，IT项目的生命周期越来越短，时间甚至成为项目成功的决定性因素，因为市场时机稍纵即逝，如果项目的实施阶段耗时过长，市场将被竞争对手抢走。因此，作为IT经理在开始一个项目之前，就必须明确项目的时间约束，甚至具体到每一个任务都必须明确时间要求。

(2)项目独特性。

按照项目定义可知，每一个项目都是惟一的，世界上没有完全一样的两个项目。但是这一特性在IT领域表现得更为突出，IT项目不仅向客户提供产品，更重要的是根据客户的要求提供不同的解决方案。即使有现成的解决方案，也需要根据客户的特殊要求进行一定的客户化工作。因此，IT项目经理必须在项目开始前通过合同(或等同文件)明确地描述或定义最终的产品是什么。如果刚开始对项目的目标没能定义清楚，或未达成一致，则最终交付产品或服务时将很容易发生纠纷，造成不必要的商务和名誉损失。在IT项目中，即便是定义清楚了项目的目标，客户仍然会经常调整实现指标，这就使得项目变得很难控制，因此这就需要项目组与客户单位有良好的沟通渠道，否则变更是无止境的。

(3)不确定性。

IT项目的不确定性是指项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。因为项目计划和预算本质上是一种预测，在执行过程中与实际情况定会有差异。另外，在执行过程中还会遇到各种始料未及的“风险”，使得项目不能按原有的计划来运行。因此，在IT项目实施过程中既要制定切实可行的计划，又不能过度计划。过度计划就是将项目中非常微小的事情都考虑清楚才动手实施，制定“详细的计划”的目的是试图精确地预测未来，但这有时也是不切实际的，在执行过程中经常会出现计划难以与实际一致，而不得不频繁地进行计划调整。因此，在IT项目执行过程中仍会碰到各种各样意想不到的问题，且往往没有现成的处理方法，这就需要项目经理掌握必要的工具方法，掌握整体过程和关键要素，灵活面对，妥善解决。

IT工程技术网(>

以上就是关于大企业IT项目如何做好启动管理全部的内容，包括:大企业IT项目如何做好启动管理、IT战略规划项目方法论、IT项目管理的20条锦囊妙计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！