在项目管理中，一个制定好的计划，是整个项目绩效测量的核心，不能随意变化，更不能随心所欲的变更。
任务更新必须经过发布一环，同时还要运用通知和反馈机制进行有效的沟通和记录，这是保证项目变更处于控制状态必须。也是沟通管理在PROJECT软件中的体现。

同时，为了适应变化，Project在具体活动的变更上有非常灵活。通过赋予直接任务人的自主变更权限，项目对环境的变迁具有非常强的适应能力。

我的了解，PROJECT在处理企业资源调配与平衡方面是非常麻烦的。例如：我在某一项目中分配某一资源，这时我就无法知道该资源在其他项目的分配情况，也不知该资源是否已超出最大限量，更不用说对资源的平衡了。而实际上，我们在管理企业多项目中，非常重要的一点就是资源的管理，包括角色需求、资源需求分析、资源配备、资源负荷分析及资源的调整与平衡等。所有大家在选择产品时一定要注意产品是否是真正意义上的多用户、多项目的产品。

xhp碰到的问题是一个典型的多项目管理问题。
在PROJECT中解决起来极其容易。xhp出错的原因在于没有考虑到资源共享问题。往往是一个项目，编一个“资源工作表”，在这种情况，软件当然不知道在不容项目里的资源是同一个人。
针对这个问题，我们只需要在“工具”调用“资源共享命令”就可以有效解决。

基于我的体会，project最强大的功能恰恰就在于对资源的管理。
xhp所强调的“资源配备、资源负荷分析及资源的调整与平衡”在project中都有专用的工具。特别是“资源调配”工具能非常有力的帮助项目管理自动资源负荷过载问题

我们往往无视自身管理水平的不足，而苛求软件解决一切项目管理问题。

这也许是我们对项目管理软件最容易产生的错误认识。

管理问题，永远都是人的问题。而不是技术问题！

1）PROJECT2002 RPO.两个用户能够同时以读和写权限打开同一个工程？

PROJECT2002 专业版也好，标准版也好，都是可以非常容易实现这个需求。
假设A项目和B项目是两个正在处于编辑状态的项目。
将使用插入命令，将A插入B，这是后无论是在A项目中进行编辑，操作，还是在B项目里对A进行处理，都可以进行。
这非常适合多人同时协作编制大项目计划。

更高级的协作是通过PROJECT2002 SERVER来实现的

Howard＝＝＝>TOSEA没有正面回答我的问题，我的问题是两人同时在同一个项目中进行各自项目分块计划编制，以反映出项目计划编制的适时变化。TOSEA的方法将给计划编制者带来很多的麻烦，麻烦之一：当A插入B后，在B中进行分组、排序时，A始终会是一个整体作业包，不会虽随B项目中选择的分组、排序条件而将插入B的A项目的作业与B项目作业"融为一体"。麻烦之二：当A插入B后，在A与B作业之间的逻辑关系由谁来定义？看来是需要由B来帮A的编制者来完成，这将带来更多的沟通和协作问题。如果是在一个项目中，本来很简单的问题，在这种情况下就变得很麻烦了。

2）假设A项目有两个WBS分支, WBS1和WBS2, 那么如何实现WBS1由甲来管理（计划编制等一系列的操作），并且甲不能对WBS2下的作业内容进行增加、修改和删除等操作；而WBS2由乙来管理（计划编制等一系列的操作），并且乙不能对WBS1下的作业内容进行增加、修改和删除等操作；同时甲乙双方要求能够同时对项目A所授权访问的范围进行操作。这就是一个简单的分级授权操作要求，微软PROJECT2002 PRO.如何实现? 这是通常一个项目多人协作一个简单的需求。

对这个需求的解决办法，我目前的的解决方案是将WBS1和WBS2作为两个独立项目看待，对于项目间出现的任务交叉现象，可以采用“在项目间建立联结”的办法处理。

Howard＝＝＝>TOSEA说可以“在项目间建立联结”的办法处理，TOSEA注意了，项目间的作业关系是通过‘作业的限制条件’来保证进度计算时各自作业时间参数的准确性的，那么A、B项目需要进行进度计算或更新时，A、B项目的数据日期（Data Date）如何处理？ 另外，多项目的报表制作很麻烦噢！

Howard===>TOSEA的变通方法都是制表不治本，根本的症结就在于，PROJECT不支持同一各项目在数据库记录级进行多用户并发读写操作，所以没有办法真正实现在同一项目内部多各协同者的分块、分级管理，如果我的项目很大，有10个WBS大的分支，按照TOSEA的方法，岂不要建立10个小项目，如果每个大的WBS分支下还有一些分支，岂不项目数多得数不清？ 大家不妨仔细查看一下，PROJECT对于一个具体项目是否有根进一步的分级授权管理？

在项目管理中，一个制定好的计划，是整个项目绩效测量的核心，不能随意变化，更不能随心所欲的变更。
任务更新必须经过发布一环，同时还要运用通知和反馈机制进行有效的沟通和记录，这是保证项目变更处于控制状态必须。也是沟通管理在PROJECT软件中的体现。

同时，为了适应变化，Project在具体活动的变更上有非常灵活。通过赋予直接任务人的自主变更权限，项目对环境的变迁具有非常强的适应能力。

Howard===>大家不妨去问问微软， Project的“PUBLISH”的设计用途是什么？不要被好像有理由的解释所“迷惑”，由于PROJECT WEB ACCESS存取作业所对应的数据库表和PROJECT2002 PRO使用的数据库表根本就不是同一个， 所以没有办法实现数据同步，那只好‘PUBLISH’一下。

基于我的体会，project最强大的功能恰恰就在于对资源的管理。
xhp所强调的“资源配备、资源负荷分析及资源的调整与平衡”在project中都有专用的工具。特别是“资源调配”工具能非常有力的帮助项目管理自动资源负荷过载问题

<B>Howard===>让我们再分析一下资源管理功能</B>：
对于一个企业级项目管理工具，企业的资源管理者通常会关心以下几个问题：
1）要在<B>同一个</B>视图中直观看到，企业所有人力资源目前都被分派了哪些项目的任务，这些任务都需要他在什么时候开始和完成；完成这些任务时分别需要他在哪些天、工作多长时间；
2）直观看到企业所有项目的人力资源负荷情况，超负荷要提示显示
3）由于公司的人力资源通常时分布在不同的部门中的，项目经理/计划人员在编制计划初期时，通常无法确定/甚至没有权力要将谁分派到这个项目当中完成某项作业，这时项目经理/计划人员需要将项目里需要的资源计划上报给公司相关部门，这个资源需求计划往往是一个包含具体人员名单的需求计划，而是一个包含需要某某技能描述的“角色”（如系统分析员、程序员、DBA等）计划，然后公司将根据整个公司的人力资源技能、负荷状况和项目需要，再最终决定分派“张三”到项目A中担任DBA，完成项目A中具体任务，这就是XHP提到的角色管理。
4）对于企业级的资源管理，管理者往往还需要从资源角色的角度来合理组织资源，即首先查看企业所有项目对不同角色需求，例如企业有10个项目需要DBA，那么企业哪些人能做DBA呢？企业能做DBA的人员配备能满足那10个项目的需求吗？时间上是否有冲突？如果经过计划优化后还不行，这是就会考虑借用、招聘、分包等方案。

基于以上分析，可以做如下判断：
1）PROJECT 2002 PRO 目前这个版本还做不到基于角色的人力资源管理、分派，在作业的资源窗口不能根据需要的角色来挑选需要的资源，反正有一大堆资源，您就慢慢挑吧；
2）PROJECT 2002 PRO 还不能在同一个视图（LAYOUT）中直观分析企业所有资源，在企业所有项目中分派、负荷情况。
3）PROJECT 2002 PRO 目前这个版本在资源定义窗口，还没有一个完整人力资源树状结构图，它的资源的定义是没有树状结构关系的；操作者在作业的资源窗口分派资源时，就不得不从上千个资源中艰难地找到一个需要地资源，在挑选的当时，也不知道选择这个资源会不会有冲突，结果就是先艰难地挑一个（秘笈！不要眼花！），挑完后在来资源直方图看看，有没有冲突？没有，继续挑，挑完了，可能眼镜度数加了50。

基于以上需求，TOSEA的“project最强大的功能恰恰就在于对资源的管理”的观点能否成立？我想大家可以自己做判断。

从PMBOK的体系来看，项目管理软件在项目管理活动只起着非常有限的作用，他始终都是一种工具和技术手段。
真正有着项目管理意识和能力的人才最关键的因素。

我们往往无视自身管理水平的不足，而苛求软件解决一切项目管理问题。

这也许是我们对项目管理软件最容易产生的错误认识。

管理问题，永远都是人的问题。而不是技术问题！

===> Howard的观点：
希望有更好的项目管理软件方便、快捷地实现项目管理中遇到地问题，项目管理软件是为项目管理者配备的，如果它不能方便地
解决项目管理中问题，哪还有啥用？