【导语】“guojigg”通过精心收集，向本站投稿了3篇如何规避信息化项目管理中的难题，下面是小编为大家整理后的如何规避信息化项目管理中的难题，仅供大家参考借鉴，希望大家喜欢!
篇1：如何规避信息化项目管理中的难题
企业选择了合适的系统（软件），不一定意味着信息化的成功，咨询公司或软件供应商的实施能力，特别是项目管理能力将起到决定作用。
我们通过大量的调查和对项目的调研，发现在实施管理中经常遇到以下几个难题。
1．用户需求难以确定。很多用户很明确企业信息化的作用，也找到了实施顾问，但对于企业自己的需求很模糊，要么就是各部门提出很多要求交给软件公司或咨询公司，要么就是请咨询公司通过调研整理出需求，然后请用户确认，但随着项目的开展，往往需求也随之发生变化，变化是需要的，但是变化太频繁、变化的幅度大，则直接影响项目的实施进度和效果。
我们认为，在项目的前期对各个层面的管理人员做充分的培训，一来可以强化他们管理变革和技术创新的意识，对企业信息化有较为全面的理解，对项目过程中容易或可能碰到的问题有充分的了解和准备，这样在项目真正启动的时候能够确定需求。培训之后的调研就是与用户交流的过程和在思路上达成一致的过程，同时也是把咨询公司的经验与企业的经验交换的过程，更是对用户进行诊断和原来管理方式进行评估的过程。
2．工作量难以确定。用户需求不确定导致工作量不确定是原因之一，更重要的原因是迄今为止仍然缺少有效的技术与方法来事先估算系统分析与系统设计所需要的时间。尽管时间经验很重要，但因为企业发展很快或系统本身更新也很快，分行业的解决方案越来越细，越来越专业，很多大系统也是首次“开发”或使用，估算的计划与实际往往有偏差。还有另外一个原因就是系统实施过程中出现的不确定因素，比如人员变动、企业的经营受到巨大冲击等等。但供应方与用户充分合理的交流可以避免类似问题的发生，
3．项目实施难以按期完成。项目不能按期完成是用户抱怨的最常见的原因之一，可以说大多数项目都不能如期完成，或者留有“尾巴”，有的甚至宣告项目失败。
通常，在提交给用户的建议书中关于项目周期（实施计划的阶段）常常偏短。主要原因有来自用户的压力以及来自竞争对手的压力，当然也可能是对项目的盲目乐观。
即便计划制定得很合理，还是会因为各种不确定因素延期，尽管对于工作量一定的项目（咨询公司通常用人·天表示），看起来通过增加实施人员，可以缩短工期，但实际效果十分有限。因为参加实施的人员经常需要经过大量的沟通，这种沟通所耗费的资源（时间和经费），随人数的增多呈指数上升，有时增加人员之后甚至产生更多的混乱和返工，最后造成更大的延迟，除非这些增加的人员是有经验和协作性相当好。我们可以想象，让业余球员加入到明星球队中踢足球，竞争力会大大降低。
4．高层领导难以及时了解问题。在企业信息化项目过程中，往往坏消息向上传递的速度较慢，报喜不报忧几乎是所有组织存在的通病，实施过程中出现的问题往往被中层过滤掉，不能及时反映到管理和决策的高层中去，有时候用户也碍于情面私下解决，导致出现的问题不断积累，出现的错误不能及时纠正，继续发展扩大直至积累到难以纠正才报告给高层领导，这样的案例国内外很普遍。
实际上项目的启动之前制定了很多的规范文档，对双方都是约束，但随着项目的推进，人际关系也相处得很好，往往会忽略规范。到最后出了问题就矛盾激化。其实，双方代表的是不同利益和责任，隐瞒通融实在没有必要。
5．用户的感受和态度容易被忽视。应当尽早对用户进行培训，进行多层面的沟通，让用户深入理解在项目过程中的难点以及可能产生的组织结构与职务、岗位、职责的变化，经常鼓励他们积极参与项目的整个过程，有效排除各种干扰和抵触情绪以确保项目的成功。
篇2：信息化项目实施中 14种常见管理问题
数据显示，只有约29%的IT项目能圆满完成，根据项目管理顾问和软件提供商的经验，有许多IT部门都在不断重复着一些错误。他们中有的没有遵循标准的项目管理流程，有的没有配备适当的人员来进行项目开发与管理，有的缺乏对项目风险的评估。总得来说，IT部门在项目管理上的失误大多是由计划不当或沟通不畅所引起的。这些错误严重降低了项目的成功几率。
在下文中将罗列出14种常见的项目管理失误，帮助你加以比照、测量与改善。
用人不当
1. 缺乏适当的人员与技能
影响：用人不当与资源分配失调是项目管理失误中最常见的一种现象。一个项目能否圆满完成，人员与技能的配备占了主导因素。用人不当的结果往往会导致项目无法继续执行，这样就算计划再好，也是纸上谈兵。
解决方案：IT与项目经理应全面了解及掌控技能与资源情况，包括对项目顾问、合约承包商和外包商的详细评估。使用项目管理软件可以帮助项目经理充分掌握所有团队成员的技能与工作量分配。在了解分工与职责后，IT与项目经理就可以决定如何在日常工作和项目中合理分配资源。指派专门的资源经理来负责解决人员与资源的分配问题也是一个不错的主意。
如果你在项目人员分配上依然有困难，或许可以考虑先查看整个公司的项目组合，然后暂缓那些与商业战略关系不大，或非任务关键的项目，从而释放部分可用资源。
2. 缺乏富有经验的项目经理
影响：如果没有一名经验丰富的项目经理掌舵，项目很可能会随着发展而失去控制。
解决方案：聘用一名符合项目要求，并拥有出色人际关系处理技巧的项目经理。他应当有号召力，能够管理风险，并在团队成员和外部参与者之间起到协调作用。此外，一名优秀的项目经理也应该具备相关技术的知识与技能。
流程问题
3. 没有遵循标准的项目管理流程
影响：这是项目管理中的第二大常见失误。缺乏合理的流程会抬高项目风险，加大项目失败的可能性，最终导致无法在限定的时间与预算内完成项目。
解决方案：制定良好的项目管理流程能助你提高项目效率，并及时捕捉到项目执行过程中的各种问题，控制风险。
IT与项目经理应事先建立可重复的流程来进行项目规划、资源分配与成员沟通。这样才能保障项目所能产生的回报与成效。
4. 流程太多太杂
影响：过多的流程会让项目失去灵活性，继而影响参与者的积极性。
曾经有一家软件开发商告诉客户公司的项目经理，他们能够在不增加成本与工作量的基础上添加额外的功能，但项目经理却回绝了这一建议，因为他觉得公司用户并没有要求这一功能。其实，只要不影响项目预算与计划进度，又征得用户的同意，多添加一些功能是利大于弊的。
解决方案：提高灵活性，与项目支持者及参与者积极沟通。
5. 对项目变更缺乏追踪
影响：要么预算超支，要么进度拖慢(或两者兼有)。
解决方案：建立正式的变更申请流程，任何项目范围内的变更(比如添加新功能)都应在变更文件上详细注明，并由项目最高主管签字批准，
此外，项目经理也需判别出该申请对预算和时间进度会产生什么影响。
6. 对项目动态缺乏了解
影响：管理学大师彼得德鲁克曾说过，无法管理就无法测量。反应到项目上，即无法及时协调资源，或对变更做出应变。
解决方案：使用软件。
7. 对小问题掉以轻心
影响：问题不会自己解决。如果对小问题掉以轻心，那么它们就会演化成大问题，最终成倍增加项目成本。
解决方案：加强项目团队成员的态度与意识，及早纠错。等到亡羊补牢，为时已晚。
计划问题
8. 没有定义项目范围
影响：如果商业与IT部门没有事先定义项目范围，那项目终将无法满足预期的成效，IT也会缺乏方向来如期完成项目。
解决方案：通过商业用例和范围划定来纠正错误定义的项目。
9. 忽略项目之间的关联
影响：忽略项目之间的关联会造成资源分配失调(比如配给某项目的人员也是另一项目所需要的)，从而影响项目进度，作为连锁反应，其它项目也会受到拖累。
解决方案：在制定项目计划时将关联因素考虑在内。与项目参与者多交流，并绘制项目关联表，可协助你明确了解各项目之间的关系。
10. 风险评估过于随意
影响：项目脱离原有轨道，IT需清理预料外的麻烦。
解决方案：风险评估应是项目计划的一部分。可以在团队中进行头脑风暴，收集可能的风险因素，然后设法规避这些风险。这一活动不会花费太久的时间，而且他也能帮助你在正式开始前充分了解项目的软肋所在。
11. 对用户抵触心理认识不足
影响：用户对新技术的抵触会让项目所投入的资金与精力白费。
解决方案：在项目计划阶段先考虑到推行过程中的阻碍，并设法化解这些阻力。与那些工作将受新项目影响的用户交流沟通，向他们阐述项目会给他们的工作流程带来的有利变化与价值。
12. 时间进度表欠完善
影响：团队成员对何时完成何种任务没有概念，对整体项目的按时达成形成阻滞。
解决方案：最简单的方法是判别出项目中所有的活动，并在这些活动后面标注预计完成日期。使用项目管理软件亦可创建进度计划表。
沟通问题
13. 对不合理的项目期限不作反驳
影响：使自己陷入无法如期完成项目的窘境，并有损IT部门的信誉。
或许公司所设定的项目期限过于苛刻，而IT部门强行完成只会起到反作用。
解决方案：IT经理应向公司管理层解释无法预期完成的实际困难，以及强行完成所需付出的代价(比如成本大幅上升，资源预算超支等)，让管理人员在成本和速度之间做出选择。
14. 与项目支持者、参与者缺少沟通
影响：IT无法达成预期的要求。
解决方案：在传递关键书面文件与表格的同时加以当面说明，并用对方能够理解的方式简明地阐述要点(有些商业人员不会理解长篇大论的技术术语)。
在这种沟通互动中，其实公司的商业分析师在用户与IT之间扮演了一个非常重要的协调角色。
建议对参与项目，或受项目影响的所有商业成员提供一份项目综述(从计划到部署)，并标示出那些活动要求商业人员参加互动，以及互动的目的。总之，IT应多花一些时间来指导商业部门了解项目执行的步骤。
篇3：创业项目管理中的难题和解决方法
说起创业公司，在创业初期面临的一个比较大的痛点，莫过于如何实现高效低成本的项目管理模式 – 小步快跑、快速迭代?
如何将研发团队有效组织起来，在可控、可视化的范围类进行产品版本迭代更新?
现如今，大多数互联网创业公司都追崇者敏捷开发的思路，甚至很多成熟型大公司都沿用这种开发管理模式。
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。“ Fix time, Flex Scope”是敏捷迭代的核心理念。
在创业公司，很多创业者初期在项目管理上都使用任务看板、每日站会、计划纸牌等手段进行项目管理，这也是比较常见的项目管理手段。
因为这种方式会更加便捷，没有“套路”，能让人一目了然、快速看到现在在发生什么，未来将要发生什么。
但是这里会存在以下几个难题：
人工线下操作、记录粘贴耗费时间和精力;
修改删除麻烦，不方便随时更新;
历史记录看不到，无法回顾历史数据;
子任务拆分不方便，拆分后无法修改;
对人员管理不便，随着团队扩张，操作越来越困难。
我们在创业道路上是如何做的呢?
最近两年在创业的道路上，经历了从0到1的团队搭建，直到研发团队超过40人，包括产品、设计、研发、测试。整个研发团队按照一个项目的节奏跑自己的产品，曾经也拆分过小项目组跑其他项目。
不论是大项目组跑也好，小项目组跑也好，都是以产品为核心导向进行功能迭代开发。
40多人都在一个办公区域(基本不存在异地沟通问题)，整个项目采用敏捷开发、版本迭代的过程在跑，产品版本迭代将近30次，基本保持每1-2周一次迭代的过程。
虽然跑的很快，但开始我们也存在一些问题创业公司共同的项目管理问题。
整个产品分为android/ios/网页端/PC端等 多系统多平台。但后台人员是公用的，基本是1对多的关系。
这种多终端协作开发的方式需要一套成熟的项目流程进行管理，整个团队也尝试过用任务看板等线下的方式进行项目研发管理。然而依然会碰到下面几个问题：
耗费时间和精力：最初大家还是愿意接受线下手工的方式写字操作各自任务记录，后面每人每日都要花费大量时间手写任务列表，进行卡片粘贴。到最后整个团队都觉得这样写起来很麻烦，逐渐放弃了手动写的过程，转而进入线上工具的管理。
更新删除麻烦：团队每个人每天都需要对今天完成的任务进行更新，多数时候当大家拿起笔去更新时重写内容时就开始愁苦。写了一天代码要下班了还得重新写字更新今日任务，尤其碰到需要删除重新的需求任务更是崩溃。
历史记录找不到：每天只能看到当天完成了什么，昨天完成了什么。当整张墙贴的密密麻麻时，想找一个人任务时，眼睛都要瞅半天。此时大家真想有个“搜索”功能。尤其在每期迭代结束后，统计每个人任务进度时，简直要崩溃。此时多希望有个工具能帮我做这件事。
子任务拆分不方便：产品需求永远都会拆分子任务，研发在开发时也需要拆分更细的子任务。此时自己用人工的方法来做就显得特别麻烦，尤其拆好的子任务要做拆分修改时，更是麻烦。
人员管理麻烦：我们当初整个看板名字是固定的，随着后续有新同事进来，旧同事离开，整个看板都需要更新。这时就需要把看板上的所有任务全部清除后再重新布局。
后面尝试转移到线上工具管理后，整个研发团队的迭代节奏明显加快许多，原先将近两周才完成的迭代、现在相同任务量缩短到一周。每日晨会、站会时间也由半小时缩短到15分钟。研发团队每日下班的时由原先花费将近10分钟更新今日任务的时间，缩短至1-2分钟搞定下班回家。
从这个现象可以看出：一个有效的工具能帮助研发团队提高效率。
在产品迭代流程方面，我们采用周期的研发节奏，整个产品研发的迭代顺序大致是 需求收集 – 需求分析 – 功能策划 – 原型设计 – 需求评审排期 – 开发阶段 – 测试阶段 – 上线阶段，这里实现一个完整的迭代。
对项目时间管理，本来采取的是线下excel表格管理，后面也逐渐转移线上工具化管理。
下面就详细讲解下 在产品迭代项目的每个阶段我们都做了什么。
需求收集阶段
产品部门有自己的需求收集和分析方法，我们会在建立一个“需求池 ”，产品会将收集来的各方面需求收录到池子里。
需求池的需求主要来源于市场、用户、竞品、老板、产品经理。我们会用线上工具将需求进行分类管理，比如APP端需求、运营需求、网页端需求等等。并定期对需求池中的需求进行合并删减。
在需求收集阶段，产品部会和运营、市场、商务等同事进行详细沟通，确保了解每一个需求的目的和意义。
需求分析阶段
对建立的“需求池”，产品对定期进行评估，评估也是基于产品内部的讨论，在讨论前一定要确保了解每一个需求背景和意义，不要一个人拍脑袋把需求拍出来。
我们崇尚以产品为公司核心导向，所以产品经历的决定权很重要，直接影响公司战略走向。所以对于需求池的需求进行详细分析时，一定多基于用户、市场和公司角度出发。
对需求池的需求分析主要做两件事：
整理需求池内容，从优先级和重要性两个纬度进行产品功能筛选。
确定需求池优先级和重要性后，进行需求标记，创建新迭代并关联需求。
确定要做的需求后，就需要开始细化需求。这时候就考验产品经理的功底了。
功能策划阶段
在确定要做的需求后，为了保证需求在研发阶段的完整性和可分工，需要在功能策划阶段就要对产品需求进行模块拆分和任务拆分;确保需求的颗粒度与研发时间评审的模块一致，如果不知道怎么拆分，需要提前与研发同学沟通。
在任务拆分后，为了保证及时同步给研发同事，需要将子任务先在线上工具关联到迭代，目的主要有两个：
可以让研发同时知道下一期功能范围和模块，提前进行技术框架搭建或技术预研。
方便产品同事(多人负责一个模块)的协作设计。
在线上工具上，可以对需求进行关联，比如父子关系，方便连续查找，树形结构更容易一目了然。
原型设计阶段
原型设计阶段最难管理的是版本问题，这里包括两类文件的版本管理。
产品经理的原型稿件
设计师的高保真设计稿
首先，原型稿修改的次数远远会大于设计稿，主要因为一些需求会在评审后或者开发中才会发现问题，修改或者补充的。再者，我们的创业公司原型稿上大都有交互说明一起的，一般修改/补充文字说明比较多。而且原型稿的使用对象更多是研发和测试同学，所以每一次版本记录和修改后同步都是巨大的工作量。
做好的方法是建立统一的svn或线上管理工具，如果有修改可以实时同步。
设计稿也是类似，一般设计稿改动的频率较小，但我们当时为了保持同步也会统一以版本命名，上传到在线管理工具上，统一管理。确保信息同步及时，研发过程中不至于使用版本不同而导致提测是几个端的功能效果不同。
需求评审排期
需求评审我们一般会有3次评审，之前有过两次，但发现在开发时存在很多重复沟通，很多需求研发同事都没有搞明白。
分析原因主要是需求评审会上时间短，很难短时间就搞懂所有逻辑。所以后面换成了3次，添加了一次“预评审会”。
在第一次“预评审会”上，不讨论需求细节，只讨论框架和流程。让大家知道下个迭代要做什么，先在脑海中有概念。
一般预评审会的时间会在上个迭代的测试阶段，这样在距离这个迭代结束的下次评审会前，大家有时间提前带着框架和流程去熟悉下需求细节，这样就可以带着问题进行第二次需求评审会评审了。
同时也可以在这个评审会上遇到一些技术改动比较大的问题，或者技术难点提前周知产品，评估看是否要对需求进行调整。
第二次评审会上，属于正式评审，会把产品需求从每个细节进行一次评审。每个人都带着问题来听，没问题的地方快速过，有问题的地方着重讨论确定的方案，这样就节省大量时间。
因为都是线上需求管理，遇到问题直接当场标记，会议后针对标记的地方进行修改。有记录，而且还不会遗漏。
第三次评审会，主要对第二次需要修改的地方过一遍，顺便加深研发同学对需求的理解程度。一般第三次评审会会在第二次评审会的第二天。我们一般选择第二次在前一天下午，第三次在第二天上午。利用晚上的时间修改需求，这样就可以节省项目时间。
紧接着就是第二天下午的项目排期了，会直接在线上工具已经拆分好的子任务上进行人员分配，包括开发人员、测试人员，之后进行开发周期的安排。
在线上管理的目的是：分配好人员后，大家就能自己登录后看到负责的任务，同时系统也会自动计算出开发周期。
开发阶段
开发人员按照每个子任务的排期时间，在每个需求的时间节点前完成开发即可。
在开发周期内会安排几种会议：
每日晨会：每天早上全员参加，围绕 昨天进度，今日安排，遇到问题 三个话题展开。每人大约几十秒时间，不讨论详细解决方案。遇到问题的同事或者需要跟xx对其的人在晨会后 以小组的形式单独详细讨论。晨会的目的是做到明确每个人的安排，同步及知道要解决的问题。
每周例会：每周的例会一般安排在周五下午。1个小时左右，主要同步项目整体进度，集中解决规则及制度性的问题。
临时会议：一般遇到开发过程中的重大问题，需要即可解决的，才会组织临时会议。一般是问题的干系人及老大们参加。
分享会议：每周会安排一次项目成员的分享会，由一个人准备，分享自己的所闻所感。建立团队间乐于分享的友好氛围。
开发阶段，会项目的管理主要是线上工具，同步及沟通的工具一般都是线上管理平台及在线聊天工具。因为我们都在一起办公，遇到问题吼一声，人就过去了。
测试阶段
测试同事会提前根据需求编写测试用例，测试用例也会在开发前进行评审。测试用例会更新到线上工具，让每个人都能看到。测试时也会根据评审的用例进行，防止带入主观判断。碰到的测试问题也会自动提交到bug池，关联给对应的开发人员，确保不遗漏bug修改。
因为创业公司测试人力少，我们一般都是全员找bug，可以设置一些有奖活动。比如谁找的bug多，谁就可以获得奖励。
上线阶段
当所有任务测试 完成后，即可上线。上线前产品、运营都需要列出对应的负责内容。建立checklist，逐一检查是否有遗漏问题。
一般版本是否上线会由测试邮件发布测试质量报告，并提出是否可以上线的建议，产品会根据邮件反馈进行判断是否可以上线。这样既有了双保险，由能一封邮件就完成上线同步工作，提高上线效率。
除了研发团队外，公司还将运营和商务也划归到项目中统一管理。为了让各部门信息互相同步，让技术同学了解业务帮助他们更好基于业务层面进行开发，让业务同学更了解技术难处，能提出更加合理的需求，用开发的语言跟开发同事沟通。
以上是从创业经历的实战项目总结出来的创业公司项目管理流程，并不一定适用于每一家创业公司，但其中一些方法不论是大公司还是小公司都可以尝试使用。
★ 难题范文
★ 项目管理论文
★ 企业项目管理范文
★ 项目管理年终总结
★ 项目管理工作汇报
如何规避信息化项目管理中的难题（合集3篇）
