一个成功的项目经理的标志有拥有一支气氛融洽的积极的团队，上层领导的信任和用户的尊重。一致的行动是另一个标志，它是衡量领导能力的基础。优秀的项目经理应该了解每个雇员的长处和短处。他们认为失败并不是缺点，而是一次学习机会。

项目经理必须建立一套专业标准。但按照一套完美的例子来进行管理却是一个失败的项目经理。这虽然说明他们的多才多艺，但更体现了他们在授权和沟通方面的能力不足。使原来想积极工作的员工变得消极的做法可以毁了项目经理。你在技术方面的能力应该用于指导和培训员工。如果你参与编程或设计，你不是在开发你的团队，也不是在做项目经理。

项目计划技术
以下是在面试中通常会提到的有关项目计划编制的术语和图表。大多项目计划编制工具都会使用到一些或全部术语和功能。你应该复习一下有用的一个或多个项目管理工具，这有助于你进一步熟悉常用的技术和功能。

图表类型：

甘特图：用图形，特别是条形图，描述项目进度的图表。每一个条形符号代表不同的意义。例如：关键任务的条形符号及/或颜色可能与非关键任务的不同。概要任务（活动或阶段）的符号可能于其他任务不同。

Pert图：用流程图来表示所有任务的现行依赖关系。PERT的意思是计划评价与审查技术，是一种网络图。

任务列表：文本/纵向地列出项目计划。通常至少应包括以下栏目：任务编号，任务名称，开始日期，结束日期，持续时间和工作效率。

工作分解结构：项目任务和/或活动的结构图。

关键路径：是贯穿整个项目的一条路径，表明在限定的时间成功完成项目涉及的各任务间的依赖关系。调整关键路径上任务的时间进度将会影响整个项目的交付时间。关键路径方法（CRM）图是一种网络图，用于项目的进度控制和协调项目的活动和事件。

可交付成果：证明一个或多个任务完成的有形事物。例如：逻辑数据模型。

依赖关系：任务间的联系会影响一个或多个任务的开始时间。例如：在没有弄清需求前，不能开始编程。

JAD/简化方法：联合应用程序设计(简化方法是90年代的术语)。一套面向结果的,大脑风暴式的,有一个共同的商业目的信息集合/分享会议。该方法是IBM公司在1970年开发的，由固定的，结构化的过程组成，并在一个有经验的实施者的领导下进行。简化方法去掉了一些结构,然而,仍要求所有各方都必须参加所有的会议和一个有建模技术的记录员作记录。参加者们包括项目团队,管理(与用户)和行政官员。为会议的成功，每个人必须理解和同意目的并且尽快解决他们的任务。

延迟：是任务的结束时间和与其相关的任务的开始时间之间的延迟时间。这允许任务结束时间和开始时间的重叠和拉长。

方法论：一种明确的、有组织的、可重复的、结构化的方法/技术，以完成一个通用的目的。这些技术或指南定义步骤，任务，角色，目的和可交付成果，这些是任何系统的成功的实现所必须的。

衡量标准：一个一致并且可重复的测量一个项目的大小和复杂性的方法。标准准备在整个项目生命期中使用许多方法中的一个。今天公司使用的流行方法是：

a) 功能点（Allan Abrecht）

b) 重要事件 (Tom DeMarco)

c) 加权平均

d) 代码行

里程碑：在项目生命期的一个重要的事件的结束。通常一个里程碑是在关键的路径上的一项活动。它不必是一个有形的可交付产品例如一个逻辑数据模型，但可以是用户对工作成果的肯定。

阶段/活动/摘要标题：概要级的概念。不是所有的项目管理工具都强调特定的阶段和摘要一级的格式，然而许多标准的开发方法用这些术语进行工作分解。

RAD：快速的应用开发(如果不正确地使用会有破坏作用)。通过应用程序生成器，建模和快速原型工具的使用加快开发工作的一条途径。最大的改进是在整个开发生命周期中加入快速原型。这在编码前了解清楚用户需求提供优秀的工具。

资源限制：一个基于可得到的资源的数量，每个资源的技巧的水平，资源工作时间表而开发的计划和时间表。

范围变更：对原先设计要求的功能增加而没有对人员，时间或费用的影响进行评估。范围变更可能是一个商业用户或一个热心的程序员提出的。两者影响系统的交付并且不能被估计，分析，或记录。

面试中的表达的要点(就算问题没被问)
如果你没有管理经验
对于那些从未正式管理过一个项目的，可能是非正式地管理过的人。在那些情况中，当强调他们的技术背景优势的同时需要明确说明他们没认识到他们已掌握的那些技巧。你可以提及你是怎么不得不在没有授权的情况下领导一个大型的开发团队进行工作的。需要强调的是没有一个稳固的技术的基础,你的工程任务和估计的决定可能被过分简单化。当你是项目的领导人，你需要提供技术的连贯避免团队超负荷工作。

如果你的技术技巧在未来的技术的环境中是落伍或不同的
你不需要理解技术环境的内部是如何工作的，但是你应该理解一般的概念和特征决定环境的能力和弱点。许多项目管理技巧是超出技术范围的。因此,如果你的技术技巧是落伍的，你仍然能强调你在技术上能负独立责任。提及你管理的应用类型和及其商业作用。提及团队是如何有效地完成目标的。强调你的管理哲学。提到上级，与你地位同等的人，你的用户和部下是如何评价你的管理能力的，记住提起任何你掌握的商务领域知识。在面试时应该将你对你的技能落后的恐惧抛在一旁。一旦你拥有这个工作，你将能向公司内的专家询问。在所有组织中都有各方面专家的非正式的机构。你可以到处打听一下，把他们找出来。

问面试官的问题：
即使你通过面试，得到了这个职位，你还需要信息进行估价，这时是你的好机会。如果这将是项目经理的第一个工作任务，这尤其是关键。你需要明白你的工作环境。因此，你可以问下列问题：

1. 公司优先权是什么？

2. 本项目的执行资助者是谁？

3. 公司使用的开发原理体系是什么？

4. 本项目最后期限是什么？

5. 有量度项目成功的方法吗？

6. 你的新经理将怎样保持项目信息灵通？

7. 你的新经理管理哲学和风格是什么？

8. 项目上的人们的技能水平是什么？

9. 你将管理的项目的范围被充分地定义吗？

10. 技术环境已经选好了吗？

以下是典型的项目管理面试中通常会问到的问题（期望的回答）：
很多的问题的答案是主观的，面试官想知道你的观点是否和他们的及公司一致。问题的构成如下：

1. 项目管理软件工具知识，

2. 编制项目计划的技术，

3. 人员管理技能

4. 沟通技能

5. 原理体系知识（标准开发生命周期和项目管理）。

项目管理软件工具知识
问题1：工期和工作量之间的差异是什么？

答案1：工期是商业/日历上的天数，与人数和工作量无关。工作量是与日历天数无关的人的工作。例如：

一天的工作量对于一个一只花50%在时间在上面的人来说，他的工期就是两天。如果两个人全职工作，工期是1天，而工作量是两个工作日。

问题2：怎样和为什么要在编制项目计划时考虑依赖关系？

答案2：根据使用的软件包，依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另一个任务能开始之前有一个任务必须完成。例如，逻辑模型必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如果没有完成的程序对线性测试没有影响。

项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。

问题3：你怎样将人的工作步调与计划结合？

答案3：根据组织使用的具体的工具，可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。

问题4：你怎样将培训，假日和个人教育时间表结合起来？

答案4：每个产品都有标明不工作的天数的公司/全球的日历。每个产品都也有个人的资源日历标明个人不工作的时间。如果项目需要教育和培训，应该把它们象任务那样写在项目计划上。

问题5：你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务？

答案5：它的工期将和整个项目时间一样长，占工作量的百分比很小。被分配给任务的每个人花在该任务的时间占他时间的百分比极低。

问题6：实况报告对计划的作用以及实况与最初预计的比较有何价值？

答案6：根据组织使用的特定的工具，每个工具都为实况报告中输入相互独立的要素/域信息。也可以将报表进行分类，来向团队成员和其他相关团体说明关键路径的变化或时间表的调整。这些报告对已实现工作评价和作为在计划下一个工程或阶段的输入有价值。另一个把估计和实况报告比较的有价值的用途是把范围变更对项目的影响记录下来。

做项目计划的技能
问题7：你为什么制定项目计划？

答案7：项目计划是实现成功的系统的路线图。它提供了一种手段来通知每个人希望他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项目状态和调整特殊的资源。逐项列记的“一览表”协助对任何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供了有用的信息。

问题8：你将怎样着手做项目的计划？

答案8：进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制约做成文件。差的估计源于对业务知识和项目范围缺乏了解。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识别和文档化里程碑和可交付产品。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对项目经理，开发团队，支持团队，以及管理层，商业用户都有益处。

问题9：你将怎样着手制定项目计划？

答案9：在适当的活动和阶段或其他的概括的标准说明下，输入确定的任务。将适当的可交付产品及里程碑和特定的任务联系起来。连接全部需要依赖关联的任务。把资源角色或资源名字加到每个任务上。应用度量结果确定事先的任务工作量，把更多的时间用于需求收集，设计和测试。考虑所有已知的节假日，培训，休假或其他的资源停工时间。计划草案将同支持团体，管理层和商务用户一起复查，做为补充性的输入和最终的批准。