项目经理是负责项目整体管理的，理论上需要对项目的交付承担整体责任。在每个行业都有项目在执行，因此都有项目经理。不同行业的项目和项目经理有很大的差异。
IT行业的项目经理也有他们自己特有的难题和困惑。
（一）需求不确定
项目需求的渐进明细是IT项目的一个基本特征，也就是说需求往往得随着项目执行的深入，逐渐实现部分功能的基础上，才能更清晰的看到下一步的具体任务。这也是IT项目区别于其他项目，比如土建项目的最大的特征。土建类项目，一张图纸出来，必须严格依照图纸来实施，否则就是违约；IT项目是一定不会照着最初的需求来实施的。
因为在一套系统还没有建立起来的时候，所有的需求，都是大家自己设想的，包括功能点、处理逻辑、数据逻辑甚至UI布局和风格。
这些不确定的事情，都需要在实际项目实施的过程中逐渐确定下来的，通过需求基线和需求管理来实现。但是这个过程就必然涉及到成本工作量的变化，这个变化影响到项目实施者的利润，涉及到跟甲方的博弈。
这毫无疑问是让IT项目经理的脑袋变得巨大的一个困惑点。因为它无解。
（二）产品不完善
国内的IT企业，相当比例的是都是服务型的，提供的基本都是产品加服务的方式，获得订单，完成交付。但是大家，又似乎都走在产品化的道路上，因为产品化程度越高，意味着实施成本越低，公司如果能有一套包打天下的产品，每个合同只要派几个人过去做个现场部署，甚至现在都可以云部署或者远程部署了，那成本必然大幅下降。
但是在To B的领域里，我们逃不开的是定制化。而对于强势的大B企业，定制化占比往往更高。
这个时候的项目经理就苦逼了，公司的标准化产品无法满足每个客户的定制化需求，于是，项目经理只能夹缝里求生存了。
这是让IT项目经理的脑袋变得更大的另一个困惑点。因为它也无解。
（三）更广的知识面
IT项目是要帮助客户解决他们遇到的业务痛点，但是怎样解决其实一直项目建设完成，都是一个逐渐清晰的过程，需要不断的探讨、不断的分析，甚至不断的博弈。
这个过程中作为PM，要管理范围、管理进度、管理质量、管理成本......，好多事啊。
不懂得多一点，随时被人带坑里。
但是人非圣贤，孰能全才？
多广的知识面算广呢！应该也无解。
（四）验证标准不统一
一个假设，因为需求的不确定，甚至到了开发完，交付的时候，还想变，怎么办？通常的操作方式就是客户会按照他的理解来说要求：“这个功能，我这段文字的意思，是要实现成这样的，你理解错了。修改一下吧。”
是不是想抓狂？！
最坑爹的是这不是假设，是通常会发生的。
一点建议
项目要做成什么样不确定，公司支持的能力不确定，自己技能可能不足够，做成啥样就算完成也没谱……
如此多的难题，很难完全解决，项目经理的江湖其实是个社会化的江湖，不是纯技术的，不能全部用技术来解决。社会化的技能，就是八仙过海了。
从纯技术的视角来看，个人觉得最重要的，是抓住两点，一个是目标，一个是分解。
目标管理是项目管理中很重要的点，我认为说成核心也不为过。项目经理得清楚客户为什么想作这个项目，他的业务痛点（也许不是业务上的痛点）是什么，要通过这个项目建立起来的系统，来解决什么问题。回答清楚了这些问题，再去了解现状是什么，先搞清楚你是站在什么“地基”上搞建设，然后再去考虑系统建设中具体要做的目标是什么。
这种方式下来至少大方向不会变，随着实施过程中项目团队对业务的逐渐熟悉，项目经理可以逐渐找到一些主动权，在需求、方案、进度、风险的各种讨论中逐渐可以提供对客户有价值的输入信息，这个时候获得客户的信任才可能成为可能。才可能使自己不那么困惑。
任务分解是项目管理的主要手段，我认为是核心战术技能。清楚了要达成的目标，对它进行分解，才可能清晰的知道项目执行过程中，需要谁在什么时间去做什么事，谁的哪项任务是项目的关键任务，谁的任务完成进度和质量会影响到其他谁的任务。分解的原则是没有遗漏、没有多余、责任到人。通过分解，理清楚项目任务、资源情况、任务依赖、资源依赖、进度要求等情况，才有可能去操盘项目。
当项目经理可以操盘自己负责的项目，对整体目标、进展、资源都了如指掌的时候，公司内外、客户面前，才能赢得尊重。才可能使自己不那么困惑。
IT圈的项目经理是这样的，其实作人做事很多情形下都是这样的。
醉里挑灯看剑，梦回吹角连营——虽然难，也豪迈。