做项目最要紧的是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的。项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。
作为项目经理，前期工作是最重要的，当接手一个新项目时，首先要尽可能地多从各个方面了解项目的情况，可以从以下几点展开：
1. 这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。
2. 这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益。
3. 了解自己公司对项目的看法和期望，有时候领导口头肯定是说支持你的项目，但你还需要做到了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，
4. 大致计算一下你手上的资源，首先是时间，其次是人员，这不细说。
5. 做好项目说明书，一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。简单的说项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。
6. 一切准备就绪前最好做一份报告，向领导及客户经理沟通好资源问题。若一开始就确定资源无法保障，那请尽快结束项目。
7. 组建项目成员，一定要带有精通客户业务的人，这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。避免我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。
8. 定好沟通机制很重要，不把沟通规则说清楚，你以后就会吃亏。首先约定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。其次就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。
9. 接下来就是做项目计划，首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这一块很多项目管理书都有介绍，具体请阅读相关书籍。
10. 进入项目执行过程，项目经理做到上传下达的工作。比如保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，项目实施过程会很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强，所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论。
11. 项目内部管理还要注意时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，如何向客户交付是项目经理一直要注意的事情。
12. 关于需求变更，是项目管理最头疼的事情。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。面对变更，应该注意以下事项：
1) 确保以前的文档，就是记载着以前的结论的东西，客户是签过字的，避免以后说话没有凭据；
2) 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？
3) （项目初期的工作）明确更改流程，尽量加上免责条款，就像医院给病人做手术以前让家人签的免责条款，就学习那个，让大家都意识到任何的更改都有成本和代价。
最后，作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。 另外对于项目验收工作，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了XP还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。
声明：易商讯尊重创作版权。本文信息搜集、整理自互联网，若有来源标记错误或侵犯您的合法权益，请联系我们。我们将及时纠正并删除相关讯息，非常感谢！
