2004年10月14日

 

有效的项目管理

这是微软资深项目经理人Stephen Maguire的项目管理经验。软件开发和网站开发有极其相似的地方,我们可以从中学习领会许多知识。

可以从中学习领会许多知识。
首先明确一些文中的概念:

项目经理:是项目的负责人,负责拟定进度,监督工作确实按进度实行,确保所有工作都方向正确,不出纰漏,培训团队恩怨,并向高级主管报告项目状况。

设计师:我们这里说的设计师包括程序设计师和网页设计师,网站开发的主力人员。

技术经理:由团队中资深设计师担任,负责项目的内部整合,确定开发规范,确保技术文件更新。

产品经理:非团队人员,负责与行销人员或客户协调,监督网站的开发符合客户和公司的期望。

第一章.有效团队的基础。(共4节)
1.
专心改善产品

公司付工资给设计师,要他们在合理的时间开发出品质精良的网站,但是设计师们的时间却经常被其它事情占用了。

典型的情况是设计师要花大量的时间准备会议,参加会议,读写开会记录和进度报告,还有回复email等等,这些事情都不能改善网站的工作,虽然其中一些是设计师自己主动做的,但更大一部分是项目经理下的命令。

虽然项目经理的本意是好的,但是却违背了项目经理的基本守则:

项目经理的任务是努力消除设计师工作上的一切障碍,让设计师权利专注在真正重要的工作上网站开发。

这不是震惊世界的发现,只是简单的道理,但是有多少项目经理确实做到呢?

请不要从字面上理解我的话,并不是说设计师只许制作网页,开发程序,事实上,思考如何设计,测试和培训等等,虽然不是直接投入在改善网站上,但对网站的质量却有重大深远的影响。


2.排除干扰

如果你希望团队在期限之内完成网站,就必须尽可能排除一切不必要的工作。在你分派工作给组员前,请问问自己,这件工作真的有必要让大家做吗?身为项目经理,必须时刻问自己一个问题:
我努力的目的究竟是什么?

这样工作就不容易偏离方向。记住,要以整个项目的眼光来看事情,你就不会陷入个别细节中了。

比如开项目进度会议。目的是为了了解项目进行的情况,以避免项目进度失控,但是如果每一个项目都如期完成,也没有人要加班,那还有必要报告进度吗?

还有常见的就是让组员写报告,交代自己做了什么,解释为什么延迟了,这往往会令很多设计师头疼和反感。一天8小时工作时间,很可能4个小时花在了写报告上。而正常的开发工作却不得不加班做。

请不要误解我的意思,我并不是说不需要进度报告,只是提醒项目经理们,不要过分注重“项目流程”,而忽略了真正的产品—-你的网站。我的一点心得是:用一个新的办法了解进度,容易写,而且不花时间。

1.
每当有设计师完成一个功能(子项目),就发一个内部email给大家;

2.
每当项目进度可能落后,就和我私下交流,讨论解决的办法。


3.
明确目标
就象你准备考一个学位或者买房子,都要筹划一番,然后行动,再达到目的,做一个网站项目同样需要制定明确的目标。注意“要完成一个网站”只是一个模糊的目标,它还不够具体和明确。

实际操作中,可能很多网站在目标不明确的情况下也完成了,但问题是,在这之前,有多少时间被浪费了?虽然你运气好,完成了项目,可是比起有明确的目标,有目的有控制的规划,实施来说,哪一个更稳当,风险更小呢?

什么样的目标是明确的目标呢?其实并不一定是博大精深的,只要足够详细,能够保证项目向正确的方向进行就可以。通常只要项目组长花几小时,或者几天时间就可以制定一个详细的项目目标。例如本站:

目标1: 建立一个以网站项目管理为主题的网站。

评价:目标已经明确主题,但还是不够详细。

目标2:为网站项目管理爱好者提供一个交流的平台。

评价:目标定位了服务对象和主要功能。但是并没有体现我们建立网站的深层目的。

目标3:为网站项目管理爱好者提供一个学习交流,并能够共同制定详细规范的平台。

评价:明确的目标,指出了服务对象,最主要的功能和网站本身的目的。

在目标确定后,我们就坚持这个大方向,凡是有利于目标实现的最先完成,比如:论坛,规范文章。与目标无关或关系不大的,可以不做或者推迟做,比如人才交流,漂亮的界面等。

设定目标就是把“你要完成的事”用清晰的语言描述出来,让团队每一个成员都有明确的概念。只要把目标稍微理得清楚些,整个项目的方向就会有惊人的改变。记住这一点吧:理清详细的项目目标,可以避免在不必要的工作上浪费时间。
也许设定目标会花你一两天时间,但相对报酬是非常值得的!


4.
设计的优先考虑
好比买菜,有人买罐头的因为最便宜,有人买冷冻的因为最方便,有人买新鲜的因为最健康,因为在他们的心目中,强调的优先考虑不同,网站开发也是一样的道理:同一个程序,不同的设计师写的代码必定不同,有认为代码越简练越好,有认为容易使用最重要,还有的则喜欢追求执行速度。

项目的目标和网站开发的优先考虑并不相同,但两者有重叠和影响的部分,因此我们要建立以下基本观念:项目目标引导项目的方向,而设计的考虑顺序影响设计的过程。

每个项目的具体情况不同,考虑的优先顺序也回不同,一般来说,程序设计考虑的优先级表为:

1.
尺寸大小
(size)
2.
速度

3.
安全性

4.
可测试性

5.
容易维护

6.
简洁

7.
再用性

8.
可移植性

除了优先考虑顺序外,你还应该建立各项考虑点的质量规范,例如你认为尺寸是优先考虑,那么多大才算合格呢?如果事先能够决定最合适的优先考虑顺序,并建立质量规范,团队就不会浪费时间,网站的整体风格就会比较一致。

第一章小结
回顾本章讨论的内容,我们可以得出网站开发的良好基础是:

确定您要达成什么样的目标以及如何去做,让每一位组员都明白目标,并专注地朝这个目标努力,设定设计的优先考虑顺序,以及相对的质量规范。


第二章 有效的作业方式
1.
什么时候修改错误

如果我问你,网站开发过程中,正确的除错时机是什么?你会怎么回答?

A.
等到所有功能开发完毕后再一起测试修改;

B.
一发现错误就立刻除掉它;

C.
无所谓,反正花的时间是一样的。

正确的选择是B:一发现错误立刻除掉!

对项目来说,最糟糕的情况莫过于被bug整得团团专,来不及完成项目目标。如果只管开发,把bug留到最后,会高估项目的完成率,看起来马上要完成的项目,却惊异的发现还需要3个月的时间除错。微软的经验是:

(1).bug
越晚清除,时间花得越多;

(2).
在开发过程中立刻除虫,可以让您早些学到经验,然后不会犯同样的错误;

(3).
如果能够保证没有任何错误,您就能比较准确的估出项目的完成时间。

所以,设计师应该把找错误当成一件重要的事情,不要为任何理由而耽误。

2.email的时间陷阱

email是个很棒的工具,但是水能载舟,亦能覆舟,如果email被不当使用,也会影响生产力。
我常发现很多设计师喜欢让email打断他们的工作,不是指他们发了太多的email,而是只要有新的email进来,他们就停下手边的工作,看看有什么新闻,有什么新鲜事,并开始回复email。有些设计师5分钟就收一次信,这样一天下来,可能什么事也做不成,因为设计工作是需要一整段时间去思考和沉在其中才能完成的。

为了解决这个问题,我告戒新设计师门,恢复email要分批做,早上一上班,中午休息时间,或者是下班前看一下都可以,但不要有事没事都不停的看email

3.好方法让大家分享

工作的策略是非常重要的,因为它是许多经验和思维浓缩而成的,将这些策略或者方法集合起来,能够让个人的生产力和工作质量提升到更高的境界。
身为主管,你应该鼓励组员提出改进工作效率的建议。引导组员思考的方法也很重要。比如,下面两个问题:

a.
为什么进度总是一再落后?

b.
有什么办法可以避免将来再发生进度落后?

第一个问题可能的答案是:互相依赖的工作太多,工具太难用,老板是个白痴等等;第二个答案可能是:减少互赖性的工作,购买更好的工具,与老板加强沟通。

两个问题的方向不同,第一个是探究原因,导引出抱怨;第二个是未来改进的方法,导引出解决办法。

问题越精确,问题越有力,对项目目标的实现就越有益,让我们再看三个问法:

a.
如何保持每次都如期完成项目?

b.
如何在不加班的前提下,如期完成项目?

c.
如何在不加班,也不增加人手的前提下,如期完成任务?

第三个问法,就迫使大家来点真正有创意的思考和认真检讨工作本身值得改进的地方了。一次比一次更精确的问题,可以刺激思考过程,激发更有创意的答案。

4.无意义的惩罚
惩罚是一种心理上的负强化作用,惩罚是对员工的责骂,训斥与威胁,就象鞭打马匹使它服从主人的命令。发现有一位组员进度落后了,不得了!叫过来骂一顿,这就等于是给了他一贴重剂量的药物,逼使他以后不敢再对进度掉以轻心。

这种管理手段是该受谴责的,我绝对不鼓励任何人这么做。想一想我们前面提到的立刻除错策略,如果设计师发现错误,他花费好几天时间解决这个问题,当然不是他喜欢的结果,但主管却因此让他受到威胁,设计师以后还会仔细查错吗?我们希望任何事都是很自然,没有必要加重组员的苦恼,绝不是强调谁是老板谁是奴才,谁必须服从谁。

如果主管们的用意是希望组员因此而工作更努力的话,就大错特错了。这种责骂只会激起组员心中的愤怒,羞恼和沮丧。实际上,往往这些项目的问题都出在管理方面,目标不明确或者野心太大,设计师只是倒霉的遇上了差劲的主管,其实他们的能力不比其他项目的设计师差。因此放弃责骂吧,责骂只会让项目更糟,绝对没有任何改善的效果。

第二章小节
这一章的内容,我们主要明确以下观点:我们要采取策略性的作业方式,并不断的找出一些简单而有效的方式改善目前的工作,小小的改变可能产生惊人的效果。

第三章:保持进度

我们都希望项目按照事先规划好的进程来进行,但事实总是无法尽如人意,有时候会有点超前,大部分情况是落后,。即使最顺利的项目,也无法完全按照计划执行,但是,如果你放任计划随意进行,有一天你猛然发现项目脱轨太远,无法把方向扭过来,剩下的时间也不够,那么项目就完蛋了。项目就象一枚瞄准月球的火箭,只要有一点点不够精确,到时候就无法命中目标,差之毫厘,失之千里,实在不可不慎重。聪明的主管懂得这个道理,他们会经常注意项目的精度,随时修正方向,保持项目不偏离计划进行。本章将介绍一些很有效的策略,帮助项目保持进度。

1.向前看
我一直相信,项目之所以脱轨,主要原因在于人们没有认真思考如何使项目保持进度,顺利进行。如果没有未雨绸缪,只是坐等问题发生,到那时候就太迟了。一个月前没有花30分钟思考这个问题,现在就可能要浪费几小时或几天的时间去修正。这就是所谓的“被动工作”。

解决这种被动工作的方法,就是化被动为主动,事先发掘潜在的问题,并设法避免。有很多方法和技巧可以训练自己“向前看”,但总结起来不过是一句简单的要决:

定期暂停手边的工作,然后往前思考,随时做必要的修正,以避免未来的大障碍。

我已经有十年以上的习惯,每天花1015分钟思考下列问题,并且列出答案:

有什么事情是我今天能做,而且可以帮助项目在未来几个月内顺利进行的?

这是一个十分简单的问题,但是如果主管定期用它检讨,思考,必定能想到许多保护项目不受以外打击的妙方。

2.明确定义需求的范围
有一个故事:我出差住旅馆,有时候会去餐厅吃早餐,偶尔会有客人跑进来,看到大家都在吃早餐,就问服务生:“你们的早餐时间几点结束呀?”我看到这位饿慌的客人急着向后转,喃喃自语:“我真想吃午餐。”然后在服务生没来得及向他解释现在已经可以点午餐之前,匆匆离去。这位客人明明想吃午餐,却问早餐结束的时间,他该问的是“现在供应午餐吗?”

通过这个故事,我想说的是:人们在开口要求的东西未必是他真正想要的,处理他的要求之前,请务必确定他究竟想要做什么。

在网站项目开发中,经常会遇到客户或者领导层提出一些希奇古怪的需求。一次,首席设计师惊慌失措的跑来找我,告诉我麻烦来了,客户对新设计的界面不满意,要求按照某个著名网站一摸一样的设计。如果真的那样做,需要重新花一个星期才能做出来,可是目前离期限的时间已经很短了。听了他的陈述后,我必须承认如果真得那样做,我们的进度就完蛋了,同时我也很好奇,为什么客户会有这样的要求,所以在我答复他们做还是不做之前,请客户经理去了解一下这个需求的原因。不一会儿,客户经理笑嘻嘻地回来了。

他们只是看中了那个网站的动态下拉菜单,觉得那样比较吸引人”

呵呵,我知道他在笑什么了,这样的动态菜单我们其实早就有现成的模板了,只要将它替换现有的设计就可以了。而我们的设计师不清楚客户的喜好而已。

大部分客户在提出需求时都不解释原因,这种情况太普遍了,甚至你的管理层也会发生这种情况。如果你从他们的请求中无法看出他们的目的,你可以反问他们,在还没有弄清楚究竟想要做什么之前,不要贸然答应,宁可拒绝他们的要求也不要浪费这种时间。

3.就是说不
当遇到客户或上级的无理需求,项目经理往往会忍气吞声的同意他们的要求。迫于某些压力,主管们宁可宁事息人,也不愿意为了整个产品或自己的团队坚持最佳的选择。

有时候,对方的请求也可能是非常合理的,你也想同意,但是因为你的日程排满了,实在爱莫能助,您也只好对他们说“不”。然而,在我的经验中,很多主管为了避免冲突,仍然会同意这样的请求,只是不知道该如何如期完成这些过多的工作,只是想到时候再说吧,船到桥头自然直,事实上事情很少这么容易船上若是载了太多的货,就是船身直了也过不了桥啊。

这些主管不了解,勉强接下自己不可能完成的任务,实在是一长痛代替短痛的做法,到时候无法如期完成,倒霉的是整个团队因此必须加班工作。所以,最好的办法还是老老实实拿您的日程表,与客户或上级说明自己心有余而力不足的情况,设法安排一个折中的日程或工作内容。想想这要比现在无条件答应请求而最后食言的结果要好的多。

我并不是鼓励您对任何计划外需求都一口回绝,我只是强调:绝对不要答应别人自己做不到的事情,这样对双方都有害无益。

说“不”也许令人不快,但这才是勇敢的面对问题的态度。说完“不”之后,就是设法解决问题的开始;明知道不可行而答应,就是问题发生的开始。

4.你无法让每个人都满意
身为主管,您一定回面临各种各样的要求,为了工作的效能,您得学会在适当的时机,适当的说“不”。无论您说得多么委婉,对方都不会喜欢被拒绝,他们可能会认为你错了,然而,您必须了解自己无法让每个人都满意的事实,您要做的是协调,而不是完成每一件事,那是做不完的。

当您碰到互相冲突的需求时该怎么办?有没有比较有效的办法?这就是我们在前面强调项目目标的用意了。例如您的目标是完成网站的主要功能,附加的装饰性的功能需求就应该婉拒。当然您一定会受到抱怨,您不妨耐心向客户解释,问题总得交代清楚。

每个人都不愿意被别人讨厌,这是人类的本性。但是身为项目主管,你必须明白这个道理:如果您希望每个人都满意,最后您会焦头烂额,什么事都做不成。

记住:不要为了讨好别人而伤害工作进程,您永远要根据自己的目标,做适当的决策。

同样,对待上级的建议您也应该考虑后再决策,不要盲从。应该以项目目标为最优先的考虑。我不是主张反抗权威,而是强调:上级也是人,一样可能犯错,他们的建议不一定是最好的,如果你想做一名出色的主管,您必须非常认真的衡量所有的建议,不论是谁提出的,您都得确定其符合项目目标才能采纳。

如果上级要求您做一件事,而您认为不妥,那您应该在着手进行之前向上级说明您的想法,也许上级回同意你的想法而放弃他的建议,也许,上级会赞许你的想法,但仍请你考虑他的意见,不论结果如何,起码经过沟通对彼此都有帮助。

记住:是你在为项目负责,不要让任何人的建议阻碍项目的进行,包括上级的建议。

5.很酷,但并不重要

网站项目的开发,不能只是为了有趣,有挑战性,或者够个性,够令人眩目。
有些时候,设计师会建议增加一些花哨的或者不应该开发的功能,他们的出发点是好的,渴望做出最好的产品,满足客户的需求。只是他们并不那么清楚怎么做才是对产品最有利的,这种不应该加入产品的功能特色有两类:一是不符合产品的未来发咱方向,仅仅因为这项功能别人都有;二是客户的特殊要求。有时候,功能齐全并不一定是最好的,(每个网站都开发聊天室,论坛,投票,邮件列表,留言本,计数器,但是并不一定都有用。)有自己独特的风格更重要,在产品中加进了太多的枝枝节节的东西,可能使产品过度膨胀,也花费了设计师们太多时间和精力,未必是值得的。

遇到这种情况的话,您该怎么办呢?您应该探究这个需求背后的动机。好好想一想,对产品而言,加入这些功能有没有策略上的价值,能不能真正改善产品?如果仅仅是很酷,没有其他更具说服力的理由的话,那么请不要在这上面浪费时间。

第三章小结:
到目前为止,相必您已经很清楚什么样的工作才是应该全力投入的:与目标一致的策略性工作。但是这还不足以让您保持进度,你还得尽量撇开不合理需求,克制大家追求“酷”的欲望,尽量减少对产品没有改善效果的工作。如果你无法学会说“不”,或者无法了解别人真正的需要是什么,你就会发现自己深陷泥沼,净做不该做的事情。

想确保项目按计划进行,其关键就在于项目经理完全明白该做什么,并且不让该做的事受到不当的干扰。

 

MANAGEMENT OF TIME AND COST  时间与成本管理

Introduction and Theory 简介与理论

Planning and Scheduling 制定计划和进度

Resource Management and Financial Management 资源和财务管理

Cost Control and Value Analysis 成本控制与价值分析

Variability and Risk Management 变化因素与风险管理

Introduction and Theory 内容简介与理论

objectives 目标

Management theory; evolution. 管理理论及其发展

Project Management; definitions. 项目管理的定义

Stakeholders;client and project team. 资金保管者;代理人和项目小组

Financial management in projects. 项目中的财务管理

Network Analysis 网络分析

Resource Management 资源管理

Resourcing project 项目的资源

Supply chain and projects Logistics. 供应链和后勤工作

Resource allocation and smoothing 资源的调配

Investment appraisal 投资评估

Budgeting control 成本控制

Cash flow forecasting 现金流量预测

Earned Value analysis 增值分析

Management accounts 管理记录

Risk Management 风险管理

Risk analysis 风险分析

time and cost 时间和成本

Contingency management 意外事件管理

Perception and attitudes 观察和态度

Experience 工作经历

Methodology 方法论

organisation 组织学

Sessions 研讨

The fundamental principles of project management 项目管理基础理论

Project Management definitions 项目管理定义

Forecasting 预测

Estimating 评估

Programming 规划

Planning 制定计划

Control 控制

Contractor 合同

 

MANAGEMENT OF TIME AND COST

时间与成本管理

Introduction and Theory

内容简介与理论

Planning and Scheduling

制定计划和进度

Resource Management and Financial Management

资源和财务管理

Cost Control and Value Analysis

成本控制与价值分析

Variability and Risk Management

变化因素与风险管理

Introduction and Theory.

内容简介与理论 

Introduction to the course; objectives.

课程简介及目标

Management theory; evolution.

管理理论及其发展

Project Management; definitions.

项目管理的定义

Stakeholders;client and project team.

资金保管者;代理人和项目小组

Financial management in projects.

项目中的财务管理

 

Planning and Scheduling

制定计划和进度

Industrial scheduling

工业进度

Network Analysis

网络分析

Resource Management and Financial Management

资源管理与财务管理

Resourcing project

项目的资源

Supply chain and projects Logistics.

供应链和后勤工作

Resource allocation and smoothing

资源的调配

Cost C trol and V ue Analysis OHT 5

成本控制与价值分析

Investment appraisal

投资评估

Budgeting control

成本控制

Cash flow forecasting

现金流预测

Earned Value analysis

已增价值分析

Management accounts

管理记录

 

Variability and Risk Management

变量和风险分析

Variability in resources

资源中的变量

Risk analysis, time and cost

风险分析,时间和成本

Contingency management

意外事故管理

Perception and attitudes

观察和态度

Introduction to the course OHT 2.1.

课程介绍

lntroduction of the tutor

讲师介绍

Experience

工作经历

Background

背景

Objectives

目标

Methodology,organisation

方法论,组织学

Sessions;outline

研讨;大纲

“If there are any doubts or questions, please ask”

Management theory

管理理论

Evolution of management thinking in the UK

英国项目管理发展

The basic principles for managing a process based organization; Fayol.

管理组织中进程基本原理;Fayol.

Introduction of project based management

项目管理简介

The fundamental principles of project management

项目管理基础理论

Project Management definitions, OHT 2.3

项目管理定义

The definition of:

定义

Forecasting

预测

Estimating

评估

Planning

制定计划

Programming

规划

Control

控制

Stakeholders in project management

项目管理中的资金持有者

Sponsor

赞助人

Champion

竞争者

Client

代理人

Customer

客户

Contractor

合同

Sub - contractors

子合同

Suppliers

供货商

Financial management; trading and balance sheet

财务管理;贸易平衡表

项目管理知识术语

 

公共的首字母缩略词

 

ACWP   Actual Cost of Work Performed            已执行工作实际成本

AD      Activity Description                      工作描述

ADM    Arrow Diagramming Method              箭线图示解法

AF      Actual Finish Date                       实际完成日期

AOA    Activity-On-Arrow                       双代号网络图

AON    Activity-On-Node                        单代号网络图

AS      Actual Start Date                         实际开始日期

BAC    Budget At Completion                     在完成时的预算

BCWP   Budgeted Cost of work Performed           已执行工作预算成本

BCWS   Budgeted Cost of work Scheduled           计划完成工作预算成本

CAC   cumulative actual cost    累计实际成本

CBC   cumulative budgeted cost  累计预算成本

CCB    Change Control Board                     变更控制委员会

CEV   cumulative earned value    累计盈余量  

CPFF   Cost Plus Fixed Fee                       成本加固定费用(合同)

CPIF    Cost Plus Incentive Fee                    成本加奖励费用(合同)

CPI     Cost Performance Index                   成本执行指数

CPM    Critical Path Method                      关键线路法

CV      Cost Variance                           成本偏差

DD      Data Date                              数据日期

DU      Duration                               持续时间,工期

EAC     Estimate At Completion                   在完成时的估算

EF      Early Finish date                         最早完成日期

ES      Early Start date                          最早开始日期

ETC    Estimate (or Estimated) To Complete         到完成时的估算

EV      Earned Value                            挣值法

FF      Free Float or Finish-to-Finish               自由时差,或完成到完成关系

FFP     Firm Fixed Price                         完全固定总价合同

FPIF    Fixed Price Incentive Fee                  固定价加奖励费用

FS      Finish-to-Start                           完成到开始关系

GERT   Graphical Evaluation and Review Technique   图示评审技术

IFB     Invitation For Bid                        邀标

LF      Late Finish Date                         最晚完成日期

LOE    Level of Effort                           投入水平

LS      Late Start date                           最晚开始日期

MPM   Modern Project Management               现代项目管理

OBS    Organization(al) Breakdown Structure        组织分解结构

PC     Percent Complete                         完成百分比

PDM    Precedence Diagramming Method           优先图示法

PERT   Program Evaluation and Review Technique    计划评审技术

PF      Planned Finish date                       计划完成日期

PM      Project Management or Project Manager      项目管理或项目经理

PMBOK  Project Management Body of Knowledge     项目管理知识体系

PMP     Project Management Professional           项目管理专业人员

PS       Planned Start date                        计划开始日期

QA      Quality Assurance                        质量保障

QC      Quality Control                          质量控制

RAM    Responsibility Assignment Matrix            责任分配矩阵

RDU     Remaining DUration                      剩余工期

RFP     Request For Proposal                      请求建议书

RFQ     Request For Quotation                    请求报价单

SF      Scheduled Finish date or Start-to-Finish       计划完成日期或开始到完成关系

SOW    Statement of Work                        工作说明

SPI     Schedule Performance Index                 进度执行指数

SS      Scheduled Start date or Start-to-Start          计划开始日期或开始到开始关系

SV      Schedule Variance                        进度偏差

TBC  total budgeted cost       总预算成本  

TC      Target Completion date                    目标完成日期

TF      Total Float or Target Finish date             总时差,或目标完成日期

TS      Target Start date                          目标开始日期

TQM    Total Quality Management                 全面质量管理

WBS    Work Breakdown Structure                 工作分解结构

 

术语

1.         Accountability Matrix  会计责任矩阵

参考责任分配矩阵。

2.         Activity 工作

在一个项目期间执行的一项工作元素。一项工作通常有一个预计的时间,预计的成本,和预计的资源需求。工作经常被划分成单个任务。

3.         Activity Definition  工作定义

确定完成项目的各种可交付成果必须执行的具体工作。

4.         Activity Description(AD)  工作说明

在项目网络图中使用的一个简单短语或标示。工作说明通常描述工作的范围。

5.         Activity Duration Estimating  工作持续时间估算

估算完成单项工作所需要的工作期间的数量。

6.         Activity-On-Arrow(AOA) 箭线式网络图(双代号网络图)

参阅箭线式图示法。

7.         Activity-on-Node(AON) 节点式网络图(单代号网络图)

参阅优先图示法。

8.         Actual Cost of Work Performed(ACWP) 已执行工作实际成本

在规定的时间内完成工作所发生的实际总成本(直接的和间接的)。参阅挣值法。

9.         Actual Finish Date(AF) 实际完成日期

工作实际完成的时间点。(注意:在某些应用领域中,当工作“实质性地完成”的时候,就定义为工作“完成了”。)

10.     Actual Start Date(AS) 实际开始日期

工作实际开始的时间点。

11.     Administrative Closure 行政收尾

生成,收集和分发信息,正式形成项目完成手续。

12.     Application Area 应用领域

项目的一种类别,它具有未在所有项目中表现出来的共性元素。应用领域通常根据项目的产品(例如,类似的技术或工业部门),或客户的类型(如:内部的与外部的,政府的与商业的)来定义的。应用领域经常是重叠的。

13.     Arrow 箭线

工作的一种图示表达方式。参阅箭线式图示法。

14.     Arrow Diagramming Method(ADM) 箭线式图示法

一种由箭线来表示工作的网络图示技术。箭线尾表示工作的开始,箭线头表示工作的完成(箭线的长度并不一定表示预期的持续时间)。工作在称之为节点的地方相接(通常绘制成小圆圈),图示出工作执行的预期的序列。参阅优先图示法。

15.     As-of Date 截止日期

参阅数据日期。

16.     Backward Pass 逆推计算法

为项目网络中全部未完成的工作进行最晚完成日期和最晚开始日期的计算。它是从项目的完成日期沿网络逻辑按反向工作序列进行计算的。完成日期可以在正推计算中得出,或者由客户或负责人设置。参阅网络分析。

17.     Bar Chart 横道图

一种与进度信息有关的图示方法。一个典型的横道图中,工作或其它项目元素列在图的左边,时间刻度横跨顶部显示,工作的持续时间以跨越它的时间的水平条表示。也称为甘特图。

18.     Baseline基准计划

按批准的变更修订的原始的计划(项目,工作包,或工作的)。通常与一个修饰语一起使用(例如,成本基准计划,进度基准计划,执行度量基准计划)。

19.     Baseline Finish Date 基准计划完成日期

参阅预定的完成日期。

20.     Baseline Start Date 基准计划开始日期

参阅预定的开始日期。

21.     Budget At Completion(BAC) 在完成时的预算

估算的在项目完成时的总成本。

22.     Budget Estimate 概算

参阅估算

23.     Budgeted Cost of Work Performed(BCWP) 已执行工作预算成本(已完成投资额)

在一个给定的时间内为已完成工作(或部分工作)核定的成本估算总和(包括分摊的各种间接费用)。参阅挣值法。

24.     Budgeted Cost of Work Scheduled(BCWS) 计划执行预算成本(计划完成投资额)

在一个给定的时间期间内(通常到项目的某个日期)计划完成的工作(或部分工作)核定的成本估算总和(包括分摊的各种间接费用)。参阅挣值法。

25.     Calendar Unit 日历单位

在编制进度计划中使用的最小时间单位。日历单位一般为小时、天、周,但是也可以以班次,甚至分钟。最初是在项目管理软件相关的计算中使用的。

26.     Change Control Board(CCB) 变更控制委员会

由项目干系者正式组织起来的小组,它的责任在于批准或拒绝对于项目基准计划的变更。

27.     Change in Scope 范围变更

参阅范围变更。

28.     Chart of Accounts 会计科目表

任何借助分类(例如,劳动力,供应商,材料)来监督项目成本的数值化的系统。项目会计科目表通常基于最初执行组织的会计科目表。参阅会计代码。

29.     Charter 许可证

参阅项目许可证。

30.     Code of Accounts 会计科目代码

任何用来唯一地识别工作分解结构的每个元素的数值化的系统。参阅会计科目表。

31.     Communications Planning 沟通计划编制

确定项目干系者对信息和沟通的需要。

32.     Concurrent Engineering  协同设计

人员配置的一种方法,最一般的形式是安排项目的实施者参与设计阶段的工作。有时和快速跟进相混淆。

33.     Contingencies 应急费用(不可预见费)

参阅储备金和编制应急计划。

34.     Contingency Allowance 应急费用

参阅备用金。

35.     Contingency Planning  编制应急计划

一种管理计划的开发,确定在一个特定的风险事件发生的时候,为确保项目成功应采用的替代策略。

36.     Contingency Reserve 应急储备

一种分开编制的计划量,用来应付计划只是部分地编制了的情况(有时称之为“知道的未知”)。例如,返工是确定的,但是返工的数量是不知道的。应急储备可能包括成本,进度,或二者皆而有之。应急储备意在减轻遗漏成本或进度项时所造成的影响。应急储备通常包括在项目成本和进度的基准计划内。

37.     Contract 合同

合同是一种相互具有约束力的协议,它强制卖方提供特定的产品,强制买方为其付款。合同通常划分为三个大类别:

l          固定总价或总价合同——这类合同对于一个明确规定的产品规定一个固定的总价。固定总价合同也可以包括满足或超过选定的项目目标(如进度目标)时的奖励费用。

l          成本补偿合同——这类合同包括对于承包商实际成本的补偿。成本通常划分为直接成本(项目直接发生的成本,如:项目组成员的工资)和间接成本(作为运转企业的执行组织分配到项目的成本,如公司总经理的工资)。间接成本通常取直接成本的一个百分数计算出来。成本偿还合同经常包括满足或超过选定的项目目标(如进度目标或成本目标)的奖励费用。

l          单价合同——承包商按照当前每个单位服务的价格得到支付(例如,专业服务每小时100元,或油漆墙面每平方米2元),总合同款随完成的总工作量而变。

38.     Contract Administration 合同管理

管理与卖方的关系。

39.     Contract Close-out 合同收尾

合同的完成和结算,包括所有的遗留问题的解决方案。

40.     Control 控制

控制是这样的一些过程,即把实际执行与计划执行工作进行比较,分析偏差,评审可能的替代方案,并在必要时采取适当的纠正措施。

41.     Control Chart 控制图

控制图是一个过程的结果随时间变化的图形表示。与建立起来的控制线对应,确定一个过程是处在“控制之下”,还是“需要调整”。

42.     Corrective Action 纠正措施

为使预期的项目执行情况与既定计划相吻合所做的变更。

43.     Cost Budgeting 成本预算

把成本概算分配到项目的每个组成部分。

44.     Cost Control 成本控制

控制项目预算的变更。

45.     Cost Estimating 成本估算

估算完成项目工作需要的资源成本。

46.     Cost of Quality 质量成本

为了保障质量所发生的成本。质量成本包括编制质量计划,质量控制,质量保障和返工的成本。

47.     Cost Performance Index(CPI) 成本执行指数

已执行工作预算成本对已执行实际成本的比率(BCWP/ACWP)。CPI经常使用如下的公式预测可能的成本超支的额度:原始的成本估算/CPI = 在完成时的预测成本。

48.     Cost Plus Fixed Fee(CPFF) Contract 成本加固定费用合同

买方应支付卖方容许的成本(按合同规定),加一个固定利润(费)进行补偿的一种合同。

49.     Cost Plus Incentive fee(CPIF) Contract 成本加奖励费用合同

买方支付卖方的容许成本(按合同规定),并且卖方通过满足确定的执行标准而挣得利润的合同。

50.     Cost Variance(CV) 成本偏差

1)任何一项工作的估算成本和那个工作的实际成本的差。(2)在挣值法中,BCWP减去ACWP

51.     Crashing 赶工

在分析了各种以最低的成本获得最大限度的持续时间压缩的替代方案之后,采取措施缩短整个项目的总持续时间。

52.     Critical Activity 关键工作

在关键线路上的任何工作。最常用的方法是使用关键线路法测定。某些工作并不在关键线路上,但在词典上意义的解释是关键的,很少在项目的范围内使用。

53.     Critical Path 关键线路

在一个项目网络图中,决定项目的最早完成日期的工作系列。当某些工作超前或着拖后完成时关键线路随时在变化。尽管正常情况下关键线路是为整个项目计算的,但是也可以为里程碑和局部项目计算。关键线路通常定义为时差等于或小于一个指定值的工作所组成的线路,通常这个值是0。参阅关键线路法。

54.     Critical Path Method(CPM) 关键线路法

用来预测项目持续时间的一种网络分析技术。这种技术是通过分析哪个工作序列(线路)具有最小的进度安排的机动性(最小时差量)实现的。最晚日期是从一个特定的完成日期开始(一般用正推计算法得到的项目最早完成日期),用逆推计算法计算完成的。

55.     Current Finish Date 当前完成日期

当前估算的工作将在什么时候完成的时间点。

56.     Current Start date 当前开始日期

当前估算的工作将在什么时候开始的时间点。

57.     Data Date(DD) 数据日期

区分实际的(历史的)数据与将来的(计划编制的)数据的时间点。也称为状态日期或截止日期。

58.     Definitive Estimate 确定性估算

参阅估算。

59.     Deliverable 可交付成果

为了完成一个项目,或项目的一部分,必须产生的可以度量的,有形的,可验证的任何成果,结果或事项。在涉及到外部的可交付成果时,更狭窄地使用这个术语,它是由项目业主或客户批准和控制的交付成果。

60.     Dependency 依赖关系

参阅逻辑关系。

61.     Dummy Activity虚工作

在箭线式图示法中具有0持续时间的工作的表示。虚工作是在用常规的工作箭线不能完整地或正确地描述逻辑关系时使用的。虚工作用虚箭线图形表示。

62.     Duration(DU) 持续时间,工期

为了完成一项工作或其他项目元素所要求的工作期间数(不包括假日或其它非工作时间)。通常以工作日,工作周表示。有时不正确地用连续的时间(包括非工作时间)表示。参阅人工量。

63.     Duration Compression 持续时间压缩

在不减少项目范围的前提下缩短项目的时间。持续时间压缩不总是都是可行的,并且经常要求增加项目成本。

64.     Early Finish Date(EF) 最早完成日期

在关键线路法中,基于工作逻辑关系和任何其他进度方面的限制条件,一项工作(或项目)的未完成的部分可能完成的最早时间点。最早完成日期随项目的进展和项目计划的变更而变化。

65.     Early Start Date(ES) 最早开始日期

在关键线路法中,基于工作逻辑关系和任何其他进度方面的限制条件,一项工作(或项目)的未完成的部分可能开始的最早时间点。最早开始日期随项目的进展和项目计划的变更而变化。

66.     Earned Value(EV) 挣值法

1)度量项目执行效果的一种方法。它把原计划的工作量和实际完成的工作量进行比较,测定成本和进度是否控制在计划之内。参阅已执行工作实际成本,计划工作预算成本,已执行工作预算成本,成本偏差,成本执行指数,进度偏差和进度执行指数。(2)一项工作或一组工作工作执行的预算成本。

67.     Earned Value Analysis 挣值分析

参阅挣值法定义(1)。

68.     Effort 人工量

为了完成一项工作或其他项目元素所要求的劳动力的单位数量。通常以工作人小时,工作人日,或工作人周表示。不要和持续时间相混淆。

69.     Estimate 估算,概算

最可能的量化结果的一个评定。通常应用于项目成本和持续时间,并且总是应当包括某些准确性的标记(例如:土x%)。通常和一个修饰语一起使用(例如,初始的,概念的,可行性的)。某些应用领域具有特殊的修饰语,这些修饰语意味着具体的准确性范围(例如:在工程和建设项目中的定单额度估算,预算估算和确切估算)。

70.     **Estimate At Completion(EAC) 在完成时的费用估算

在确定的工作范围完成后,一项工作,一组工作,或项目预期的总成本。预测EAC的主要的技术包括基于项目执行到某个日期为止对原始估算的某些调整。也以“在完成时估算”表示。经常表示为EAC = 到某个日期为止的实际成本+ETC。参阅挣值法和到完成时的估算。

71.     Estimate To Complete(ETC) 到完成时的概算

为了完成一项工作,一组工作,或项目,还需要的成本。预测ETC的主要的技术包括基于项目执行到某个日期为止对原始估算的某些调整。也以“到完成时估算”表示。参阅挣值法和在完成时的估算。

72.     Event-on-Node单节点事件图

一种网络图示技术。在这种技术中事件是由框(或节点)表示的,节点通过箭线连接,表示出要发生的事件的次序。在原始的计划评审技术中使用。

73.     Exception Report 例外报告

仅包括计划的主要的偏差(而不是全部偏差)的文档。

74.     Expected Monetary Value 预期货币值

一个事件的发生概率和将导致的收益或损失的结果。例如,如果下雨的概率为50%,并且下雨将造成100元的损失,则下雨事件预期的货币值是50元(0.5*100元)。

75.     Fast Tracking 快速跟进

通过重叠正常情况下需要按顺序进行的工作来压缩项目进度计划,如设计和建设两项工作局部重叠进行。有时和协同设计混淆。

76.     Finish Date 完成日期

与一项工作的完成相关的一个时间点。通常由如下词修饰:实际的,计划的,估算的,编制的,最早的,最晚的,基准计划的,目标的和当前的。

77.     Finish-to-Finish(FF) 完成到完成关系

参阅逻辑关系。

78.     Finish-to-Start(FS) 完成到开始关系

参阅逻辑关系。

79.     Firm Fixed Price(FFP) Contract 完全固定总价合同

一种合同类型。在这种合同中,买方支付卖方定量的一笔款,而不管卖方的成本。

80.     Fixed Price Contract 固定总价合同

参阅完全固定总合同。

81.     Fixed Price Incentive Fee(FPIF) Contract 固定总价加奖励合同

一种合同类型。在这种合同中,买方支付卖方固定的一笔款,并且,如果卖方满足了确定的执行标准,还可以挣得附加的奖励费用。

82.     Float 时差,机动时间,浮动时间

在不推迟项目完成日期的前提下一项工作从它的最早开始日期可以滞后的时间量。时差是按一种数学方法计算出来的。它随项目的进展和项目计划的变更而变化。也称之为总时差,线路时差。参阅自由时差。

83.     Forecast Final Cost 预测最终成本

参阅在完成时的估算。

84.     Forward Pass 正推计算法

为项目网络中所有工作未完成的部分计算最早开始和最早完成日期。参阅网络分析和逆推计算法。

85.     Fragnet 局部网络

参阅子网络。

86.     Free Float(FF) 自由时差

在不推迟紧后工作完成日期的前提下,一项工作从它的最早开始日期可以滞后的时间量。参阅时差。

87.     Functional Manager 职能经理

负责在一个特定部门的工作或职能的经理(例如:工程经理,制造经理,市场经理)。

88.     Functional Organization 职能组织

一种工作人员依照他们的专业按层次分组的组织结构(例如:在顶层有产品、市场、工程和财务;就工程而言,又划分为化学、电和其他等)。

89.     Gantt Chart 甘特图

参阅横道图。

90.     Grade 等级

用来区分具有相同的使用功能(例如:锤子),但质量要求不同的物件的类别或等级(例如,不同的锤子可能需要经得起不同大小的力)。

91.     Graphical Evaluation and Review Technique(GERT) 图示评审技术

一种网络分析技术,这种技术允许逻辑关系规定条件和按概率处理(即:某些工作可能不执行)。

92.     Hammock 集合工作

一种汇集的或概括工作(一组相关的工作作为一个整体表示,并且在一个摘要级别上报告)。一个集合工作可能有,也可能没有内部的序列。参阅子项目和子网络。

93.     Hanger 悬摆

在一个网络线路中非预期的断裂。悬摆通常是由于遗漏工作或遗漏逻辑关系引起的。

94.     Information Distribution 信息分发

定期地将需要的信息提供给项目干系者。

95.     Initiation 立项

使机构承诺开始一个项目阶段。

96.     Integrated Cost/Schedule Reporting 成本/进度综合报告

参阅挣值法。

97.     Invitation for Bid(IFB) 邀标

一般说来,这个短语等同于请求建议书。但是,在某些应用领域它可能具有一个更狭窄的或特定的意义。

98.     Key Event Schedule 关键事件进度计划

参阅主进度计划。

99.     Lag 滞后量

一种逻辑关系的修正,它直接地给后续工作一个滞后量。例如,在一个具有10天滞后量的完成到开始关系中,后续的工作在先行工作完成以后10天之内不能开始。参阅提前量。

100.  Late Finish Date(EF) 最晚完成日期

在关键线路法中,在不推迟一个特定的里程碑时间的前提下(通常是项目的完成日期),一项工作(或项目)可能完成的最晚时间点。

101.  Late Start Date(ES) 最晚开始日期

在关键线路法中,在不推迟一个特定的里程碑时间的前提下(通常是项目的完成日期),一项工作(或项目)可能开始的最晚时间点。

102.  Lead 提前量

一种逻辑关系的修正,它允许后续工作一个提前量。例如,在一个具有10天提前量的完成到开始的关系中,后续的工作可以在先行工作完成之前10天开始。参阅推迟量。

103.  Level of Effort(LOE) 投入水平

测量不容易用明显的成就来衡量的辅助性工作(例如,供应商或客户的联络工作)的一种手段。它通常是由在一个特定的时间期间内的工作比率来测定的。

104.  Leveling 平衡

参阅资源平衡。

105.  Life-cycle Costing 全生命期成本估算

当评估不同的替代方案时,将包括购置,运作和处置再内的成本估算的概念。

106.  Line Manager 产品经理

1)实际工作在制造产品或提供服务的任何小组的经理。(2)一种职能经理。

107.  Link 连接

参阅逻辑关系。

108.  Logic 逻辑

参阅网络逻辑。

109.  Logic Diagram 逻辑图

参阅项目网络图。

110.  Logical Relationship 逻辑关系

项目的两项工作之间的关系,或者一个项目工作和一个里程碑之间的关系。参阅优先关系。有四种可能的逻辑关系:

完成到开始关系——“从”工作必须在“到”工作可以开始之前完成。

完成到完成关系——“从”工作必须在“到”工作可以完成之前完成。

开始到开始关系——“从”工作必须在“到”工作可以开始之前开始。

开始到完成关系——“从”工作必须在“到”工作可以完成之前开始。

111.  Loop 回路

通过同一个节点两次的网络线路。使用传统的网络分析技术(如CPMPERT)不能把回路分析出来。在GERT中允许回路。

112.  **Management Reserve 管理储备量

一个分开编制的计划量,它用来应对不可预测的情况(有时称为“不知的不知”)。管理储备量可能包括项目的成本或进度。管理储备量意于减小遗漏的成本或进度目标所带来的风险。管理储备量的使用要求变更项目成本的基准计划。

113.  Master Schedule 主进度计划

一个概括级的进度计划,它识别主要的工作和里程碑。参阅里程碑进度计划。

114.  Mathematical Analysis 数学分析

参阅网络分析。

115.  Matrix Organization 矩阵型组织

由项目经理和职能经理共同负责按优先级别把项目工作分配到每个人的组织结构方式。

116.  Milestone 里程碑

在项目中的重要的事件。通常为一个主要的可交付成果的完成。

117.  Milestone Schedule 里程碑进度计划

一个概括级的进度计划。它识别主要的里程碑。参阅主进度计划。

118.  Mitigation 减轻风险

通过降低一个风险发生的概率,或风险发生时减少它的影响,进而采取步骤,缓解风险。

119.  Modern Project management(MPM) 现代项目管理

区别当前范围广泛的项目管理(范围,成本,时间,质量,风险等)和狭义的、集中在成本和时间的,传统的项目管理的一个术语。

120.  Monitoring 监控

捕捉、分析和报告项目的执行情况,通常与计划进行比较。

121.  Monte Carlo Analysis 蒙托卡罗分析

一种进行风险评价的技术,为了计算项目可能的结果分布,它要对项目执行许多次模拟计算。

122.  Near-Critical Activity 次关键工作

具有比较小的时差的工作。

123.  Network 网络

参阅项目网络图。

124.  Network Analysis 网络分析

确定项目工作未完成部分的最早和最晚的开始和完成日期的过程。参阅关键线路法,计划评审技术,和图示评审技术。

125.  Network Logic 网络逻辑

建立起来项目网络图的工作关系的集合。

126.  Network Path 网络线路

在一个项目网络图中的任何连续的连接起来的工作系列。

127.  Node 节点

一个网络中的一个限定点。把某些或所有的其他关系集结起来的集合点。参阅箭线式图示法和优先图示法。

128.  Order of Magnitude Estimate 定单额度估算

参阅估算。

129.  Organizational Breakdown Structure(OBS) 组织分解结构

为了将工作内容和各组织单位联系起来而对于项目组织的一种描绘。

130.  Organizational Planning组织计划编制

确定、行文并任命项目职务和规定责任和报告关系。

131.  Overall Change Control 整体变更控制

协调整个项目期间的变更。

132.  Overlap 重叠

参阅提前量。

133.  Parametric Estimating 参数估算法

使用历史数据和其他变量之间的一个统计关系(例如:在建设领域中的平方米,在软件开发中的代码行数)来计算一个估算值的技术。

134.  Pareto Diagram 帕累托图

按事件发生的频率进行排序的一种直方图,它表示出每个原因产生多少结果。

135.  Path 线路

在一个项目网络图中顺序相接的工作集合。

136.  Path Convergence 线路收敛

在数学分析中,持续时间近似相等的平行线路推迟量它们所满足的里程碑的完成时间的趋势。

137.  Path Float 线路时差

参阅时差。

138.  Percent Complete(PC) 完成百分比

在一项工作上,或者一组工作上用百分数表示的工作量的估算。

139.  Performance Reporting 执行报告

为了保障项目进展,收集和分发项目执行的信息。

140.  Performing Organization 执行机构

成员大部分直接参与完成项目工作的企业。

141.  PERT Chart 计划评审技术图

一种特殊的项目网络图。参阅计划评审技术。

142.  Phase 阶段

参阅项目阶段。

143.  Planned Finish Date(PF) 当前计划的完成日期

参阅计划完成日期。

144.  Planned Start Date(PS)  当前计划的开始日期

参阅计划开始日期。

145.  Precedence Diagramming Method(PDM) 优先图示法

由框(节点)代表工作的一种网络图示技术。工作通过优先关系连接起来表示出执行工作的顺序。

146.  Precedence Relationship 优先关系

在优先图示法中,为表述逻辑关系使用的一个术语。在当前的用法中,优先关系、逻辑关系和依赖关系广泛地交互使用,而不管使用的图示法。

147.  Predecessor Activity 先行工作

1)在箭线式图示法中,进入一个节点的工作。(2)在优先图示法中,“从”工作。

148.  Procurement Planning采购计划编制

确定采购什么和什么时候采购。

149.  Program 计划

以一种协调的方式管理的一组相关的项目。计划通常包括连续工作的一个成分。

150.  Program Evaluation and Review Technique(PERT) 计划评审技术

一种面向事件的网络分析技术,用它来估算当估算单个的工作持续时间存在着较高程度的不确定性时的项目持续时间。PERT把关键线路法应用到一个加权的平均持续时间的估算中。

151.  Project 项目

为完成一个唯一的产品或服务的一种一次性努力。

152.  Project Charter 项目许可证

由高级管理部门提供的一个文档,它给项目经理特权把组织的资源应用到项目工作中。

153.  Project Communication Management 项目沟通管理

项目管理的一个子集。它包括确保项目信息恰当地收集、分发所要求的过程。它由编制沟通计划、信息分发、执行报告和行政管理收尾组成。

154.  Project Cost Management 项目成本管理

项目管理的一个子集。它包括确保项目在批准的预算内完成项目所要求的过程。它由编制资源计划、成本估算、成本预算和成本控制组成。

155.  Project Human Resource Management 项目人力资源管理

项目管理的一个子集。它包括使参加到项目的人员得到最有效地使用所要求的过程。它由编制组织计划、招募工作人员和队伍建设组成。

156.  Project Integration Management 项目综合管理

项目管理的一个子集。它包括使各个项目元素能够恰如其分地协调所要求的过程。它由项目计划开发、项目计划执行和整体变更控制组成。

157.  Project Life Cycle 项目生命期

按顺序的项目阶段的总体,这些阶段的名称和数量是由参加项目机构的控制需要来决定的。

158.  Project Management(PM) 项目管理

在项目工作中应用知识、技能、工具和技术完成项目,以便满足或超过项目干系者需要和期望。

159.  Project management Body of Knowledge(PMBOK) 项目管理知识体系

一个描述在项目管理的专业之内的知识的总和全称术语,像其他的专业(例如:法律、医药和会计)一样,这个知识体系由使用和发展它的实践家和学术工作者支撑的。PMBOK包含通过实践检验,并得到广泛应用的传统作法和已经得到部分应用的创造性做法。

160.  Project Management Software 项目管理软件

专门用来辅助进行计划和控制项目成本和进度等的计算机应用系统。

161.  Project Management Team 项目管理班子

直接参与到项目管理工作中成员。在某些小的项目中,项目管理班子可能实际上包括全部项目组成员。

162.  Project Manager(PM) 项目经理

负责管理一个项目的人。

163.  Project Network Diagram 项目网络图

任何表示项目工作逻辑关系的图示表示。为了反映项目的年度序列关系,网络图总是从左向右绘制。经常错误地叫做PERT图。

164.  Project Phase 项目阶段

逻辑上相关的项目工作的总和。通常结束在一个主要的可交付成果完成时。

165.  Project Plan 项目计划

用来指导项目执行和控制正式批准的文档。项目计划主要用途是提供书面的计划编制的假设和决定,以便使项目干系者之间的沟通,提供的书面计划包括范围、成本和进度的批准的基准计划。一个项目计划可以是概括性的,或详细的。

166.  Project Plan Development 项目计划开发

利用其他编制计划过程的结果,合成一个连贯的、表达清楚的文档。

167.  Project Plan Execution 项目计划实施

通过执行项目内的工作来完成项目计划。

168.  Project Planning项目计划编制

开发和维护项目计划。

169.  Project Procurement Management 项目采购管理

项目管理的一个子集。它包括从执行组织的外部获得货物或服务所要求的过程。它由编制采购计划、编制询价计划、询价、供应商选择、合同管理和合同收尾组成。

170.  Project Quality Management 项目质量管理

项目管理的一个子集。它包括确保项目将满足所执行的标准需要所要求的过程。它由编制质量计划、质量保障和质量控制组成。

171.  Project Risk Management 项目风险管理

项目管理的一个子集。它包括对于项目风险的识别、分析和应对所要求的过程。它由风险识别、风险量化、风险应对措施开发和风险应对控制组成。

172.  Project Schedule 项目进度计划

执行项目工作和达到里程碑编制的计划日期。

173.  Project Scope Management 项目范围管理

项目管理的一个子集。它包括确保成功地完成项目,项目要包括并且仅包括所要求完成工作的过程。它由立项、范围计划编制、范围核实和范围变更控制组成。

174.  Project Team member 项目队伍成员

直接或间接向项目经理报告工作的人员。

175.  Project Time Management 项目时间管理

项目管理的一个子集。它包括确保项目按规定时间完成所要求的过程。它由工作定义、工作排序、工作持续时间估算、进度计划开发和进度控制组成。

176.  Projectized Organization项目型组织

项目经理具有全部权力指定优先级别,并指挥分配到项目的每个人的工作任何组织结构。

177.  Quality Assurance(QA) 质量保障

1)按一个常规标准评估整个项目的执行情况,提供项目将能够满足相关质量标准的置信度。(2)指定负责质量保障的组织单位。

178.  Quality Control(QC) 质量控制

1)监视特定的项目结果,测定它们是否遵照相关的质量标准,识别并排除未满足执行要求的原因的过程。(2)指定负责质量控制的组织单位。

179.  Quality Planning质量计划编制

确定质量标准,并且确定如何达到这些标准。

180.  Remaining Duration(RDU) 剩余持续时间

完成一项工作还需要的时间。

181.  Request for Proposal(RFP) 请求建议书

RFP是一种招标文档,用来从预期的产品或服务的卖方征集建议书。在某些应用领域,它可能具有更狭义的,或更特定的含义。

182.  Request for Quotation(RFQ) 请求报价单

一般说来,这个术语等同于请求建议书。但是,在某些应用领域,它可能具有更狭义的,或更特定的含义。

183.  Reserve 储备量

为了减轻成本和(或)进度风险,编制在项目计划中的一种准备量。通常和一个修饰语一起使用(例如:管理储备量,应急储备量)提供进一步的缓解什么类型的风险细节说明。修正术语的特定含义因应用领域而不同。

184.  Resource Leveling 资源平衡

任何由于资源管理的考虑而决定进度计划(开始和完成日期)的网络分析形式(例如:有限的资源限量,或在资源级难于管理其变更)。

185.  Resource-Limited Schedule 资源约束进度计划

项目开始和完成日期反映出预期的资源限量的项目进度计划。最终的项目计划总应当是资源约束前提下计划。

186.  Resource Planning资源计划编制

确定为了完成项目工作,需要什么资源(人、设备和材料),数量为多少。

187.  Responsibility Assignment Matrix(RAM) 责任分配矩阵

一种把项目组织结构和工作分解结构相关连的结构,它帮助确保项目范围中的每个工作元素都指定有负责人员。

188.  Responsibility Chart 责任图

参阅责任分配矩阵。

189.  Responsibility Matrix 责任矩阵

参阅责任分配矩阵。

190.  Retainage 保留金

合同条款的一个部分,为了确保合同条款全部完成,直到合同完成后才支付这笔款项。

191.  Risk Event 风险事件

可能影响项目变得更好或更坏的随机发生的事件。

192.  Risk Identification 风险识别

确定哪些风险事件可能影响项目。

193.  Risk Response Control 风险应对控制

在整个项目进行期间对于项目风险上的变化做出反应。

194.  Risk Response Development 风险应对开发

确定扩大机会或减轻威胁办法。

195.  S-Curve S曲线

累积的成本、劳动力工时或其它量的图形化显示,按时间点进行绘制。其名称是因为在一个项目上产生的这些曲线类似于S的形状而获得的,它在开始时段内上升比较缓慢,在中间阶段上升加速,最后阶段缓慢收尾。

196.  Schedule 进度计划

参阅项目进度计划。

197.  Schedule Analysis 进度计划分析

参阅网络分析。

198.  Schedule Compression 进度计划压缩

参阅持续时间压缩。

199.  Schedule Control 进度计划控制

控制项目进度计划的变化。

200.  Schedule Performance Index(SPI) 进度执行指数

已经执行工作预算对计划执行预算的比率(BCWP/BCWS)。参阅挣值法。

201.  Schedule Variance(SV) 计划偏差

(1)一项工作的计划完成量和这个工作实际完成量之间的差。(2)在挣值法中BCWP减去BCWS

202.  Scheduled Finish Date(SF)计划的完成日期

在一项工作上原计划的工作完成时间点。计划的完成日期正常情况下在最早完成日期和最晚完成日期之间。

203.  Scheduled Start Date(SS)计划的开始日期

在一项工作上原计划的工作开始时间点。计划的开始日期正常情况下在最早开始日期和最晚开始日期之间。

204.  Scope 范围

一个项目所提供的产品和服务的总和。

205.  Scope Baseline 范围基准计划

参阅基准计划。

206.  Scope Change 范围变更

项目范围的任何变更。范围变更几乎总是要求对项目成本和进度进行调整。

207.  Scope Change Control 范围变更控制

控制对于项目范围的变更。

208.  Scope Definition 范围定义

为了提供更好的控制,把项目主要的可交付成果分解为比较小的、更易于管理的组成部分。

209.  Scope Planning范围计划编制

开发一个包括项目可行性论证、主要的可交付成果和项目目标的书面范围说明文件。

210.  Scope Verification 范围验证

确保所有确认的项目可交付成果已经满意地完成的过程。

211.  Should-Cost Estimates 合理的成本估算(标底)

对一个产品或服务的一种成本估算,用以评估预期的供应商所建议的成本的合理性。

212.  Slack 时差

PERT中使用的与Float等同意义的术语“时差”。

213.  Solicitation 询价

获取相应的报价单、标价、报盘或建议书。

214.  Solicitation planning 询价计划编制

编写产品需求文档并识别潜在的来源。

215.  Source Selection 供方选择

从潜在的供应商中挑选

216.  Staff Acquisition 工作人员招募

获得指定到并且在项目上工作所需要的人力资源。

217.  Stakeholder 项目干系者

参加或可能影响项目工作所有个人或组织。

218.  Start Date 开始日期

与一个项目工作的开始相关的时间点,通常是由如下的一个词修饰的:实际的,计划的,估算的,编制的,最早的,最晚的,基准计划的,目标的和当前的。

219.  Start-to-Finish 开始到完成关系

参阅逻辑关系

220.  Start-to-Start 开始到开始关系

参阅逻辑关系。

221.  Statement of Work(SOW) 工作说明

对合同中的规定产品或服务的文字描述。

222.  Subnet 子网

项目网络图的一个局部,通常代表某些子项目。

223.  Subnetwork 子网络,局部网络

参阅子网。

224.  Successor Activity 后续工作

1)在箭线式图示法中,离开一个节点的工作。(2)在优先图示法中,“到”工作。

225.  Target Completion Date(TC) 目标完成日期

限制,或通过修改网络分析方法实现的一个强制的日期。

226.  Target Schedule 目标进度计划

参阅基准计划。

227.  Task 任务

参阅工作

228.  Team Development 队伍建设

开发个人或小组的技能,改善项目执行效果。

229.  Team members 队伍成员

参阅项目队伍成员。

230.  Time-Scaled Network Diagram时标网络图

任何以工作的位置和长度代表它的持续时间的项目网络图。基本的时标图是包括网络逻辑的一个条形图。

231.  Target Finish Date(TF) 目标完成日期

在一项工作上工作计划(确定为目标的)完成日期。

232.  Target Start Date(TS) 目标开始日期

在一项工作上工作计划(确定为目标的)开始日期。

233.  Total Float(TF) 总时差

参阅时差。

234.  Total Quality Management(TQM) 全面质量管理

在一个组织内实现一个质量改进计划的通用方法。

235.  Workaround 权变措施

对一个不利的风险事件的处理。它同应急计划不同,在不利风险事件未发生前没有在风险事件应对措施中考虑到。

236.  Work Breakdown Structure(WBS) 工作分解结构

针对可交付成果的项目元素的分组,它归纳和定义项目的整个范围。层次每降一级,代表增加一级项目组成部分的细节定义。项目组成部分可能是产品或服务。

237.  Work Item 工作项

参阅工作。

238.  Work Package工作包

工作分解结构中在最低级别上的一个可交付成果。一个工作包可能被划分为若干工作任务。

 

 

2004年09月29日

 

一、             项目管理与Project2000的关系

在项目管理知识体系中,包括九大知识领域(范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、综合管理)。但从项目管理辅助工具软件Project2000来说,它包含了这九大知识领域中的5大核心领域,另外4个领域需要通过其它辅助工具或人工操作来完成。包括的5大领域如下所述:

1、 范围管理

项目管理的第一个知识领域就是“范围管理”,在项目范围中,包括两层内容:一是项

目范围;二是产品范围。项目范围针对的是我们项目的目标,包括软件开发、集成、培训和项目实施等。产品范围侧重在软件的需求范围,可以理解为对项目范围的一个重要补充。两者有一定关联,但也各有侧重,只有这两者相加,才构成了我们完整的项目范围。然而在Project2000工具中,指的项目范围是指第一种,结果输出就是WBS分解。

2、 时间管理

时间管理也称进度管理,在Project2000中,它提供了工期估计、工作搭接关系、进度安

排、进度控制等基本功能。还能够自动计算出关键路径,可以很方便的设置我们的里程碑控制点,并能够实现项目的动态跟踪。还提供了多种时间的管理方法,甘特图、网络图、日历图等。应该说时间管理,是Project 2000中最强大的功能。

3、 费用管理

在费用管理中,Project2000中采用的是“自底向上费用估算”的技术,由于它是依赖每

WBS任务的估算,所以使得费用估算更为准确。并且它还能与EXCEL等进行结合,生成费用曲线图和挣得值趋势图。

4、 人力资源管理

在人力资源管理中,Project2000提供了人力资源的规划、人力资源责任矩阵、资源需求

直方图、资源均衡等,它能帮我们做好资源的分配、进行资源的工作量、成本和工时的统计。

5、 整合管理

   项目管理的整合管理就是对于整个项目的范围、时间、费用、资源等进行综合管理和协调,在Project2000中,它能根据范围、时间、资源的变化自动进行相应计算和调整。

 

二、             Project2000使用前的环境设置

 

在进行计划编制前,需先设置好Project2000的使用环境,这样可以更方便我们计划编

制时的操作。环境设置一要根据自己的习惯,二是要根据项目的实际情况。下面介绍几种常用的环境设置项。

u       首先,要设置项目摘要信息,在摘要信息中需输入该项目的标题、项目经理和单位等信息。主要是便于打印时显示的信息。

操作方法:选中菜单 文件      属性      摘要信息     

u       设置项目的日历,默认从星期日开始,中国人的习惯一般是从周一开始。

操作方法:选中菜单 工具      选项      日历      每周开始于    

u       设置任务类型,默认为“固定工时”,固定工时的含义是当一项任务分配给一个人做是10天,当增加一人时,则工期自动变为5天。我们的操作习惯应该是人员增加时,原工期一般要求仍不变。所以需选择为“固定工期”。

操作方法:选中菜单 工具      选项      日程      默认任务类型     

u       设置WBS编号,默认无WBS编号,为了计划阅读清晰,建议设置大纲编号作为WBS编号。

操作方法:选中菜单 工具      选项       视图      选中显示大纲编号。

u       设置工作时间,默认是按标准日,也即周六、周日休息。行政日指不但考虑周六、周日休息,而且考虑到中国的传统节假日(如国庆、五一等)。我们一般要根据项目的具体情况,如该项目比较工期比较紧,项目组要求每周六加班,周日休息,那么就需将周六设置为“非默认工作时间”。

操作方法:选中菜单 工具      更改工作时间      选中对象      非默认工作时间。

u       设置条形式样式,可根据自己的习惯,设定关健任务、非关健任务、进度条、里程碑为不同的样式和颜色。

操作方法:选中菜单 格式       条形图样式     

    说明:建议环境设置可以设置为一个模板,这样就无需每个项目都进行设置一下,提高计划编制效率。

 

 

一、             如何使用Project 2000来制定计划

 

在项目管理知识体系中,项目的计划包括4个核心计划和4个辅助计划,4个核心计划

为:范围计划、人力资源计划、进度计划和费用计划;4个辅助计划为:质量计划、沟通计划、风险计划和采购计划。利用Project2000工具,能很方便的完成4个核心计划的制定。

为了使我们能够更好的掌握如何运用Project2000工具来做计划的,在这里将上述讲述

4个核心计划,分解成8个步骤来讲述,并在每个步骤当中,给予案例,这样更便于我们的理解和操作。

 

注:案例背景描述:   

某企业决定开发一套项目管理软件。

该软件的主要功能包括:项目及工作信息的录入、项目网络计划图的绘制、项目时间计划的安排、甘特图计划的制定、项目执行信息的录入与分析及各种计划报表的输出等。该企业准备投入25万元进行该系统的开发,时间要求是2025周。该软件项目的计划开始时间是200211日,企业要求软件正式验收前需要试运行4周以上的时间,并根据试运行情况进行适当修改。 

 

1、 目标确定

项目目标就是实施项目所要达到的期望结果,是衡量项目成功与否的标准。项目目标

包括约束性目标和成果性目标。约束性目标主要指进度、费用、质量三重约束,成果性目标主要指要完成的产品。

项目目标的描述必须明确、具体、尽量定量描述,需满足Smart原则:

u       Specific 明确

u        Measurable 可衡量性

u        Achievable 虽然极具挑战性, 但是有计划完成

u        Result Driven 面向成果

u        Time 具时间性

案例示范

目标描述:

a、  总费用:在100万的费用预算内;

b、  时间:从200211日开始,至2002627日完成,总工期24周;

c、   交付物:开发一套功能齐全的项目管理软件、其中主要功能为:项目及工作信息的录入;项目网络计划图的绘制;项目时间计划的安排;甘特图计划的制定;项目执行信息的录入与分析及各种计划报表的输出等。

说明:Project2000中,没有特定的项目目标书面位置,可以专门采用Word文档进行描述,也可直接在Project2000中的备注栏中注明。

2、 范围定义

范围定义就是将项目可交付成果分成几个小的、更易管理的单元。范围定义的结果是

形成工作结构分解图(WBS)。WBS分解就是先把复杂的项目逐步分解成一层一层的要素(工作),直到具体明确为止。

WBS分解的步骤:

u       总项目

u       子项目或主体工作任务

u       主要工作任务

u       次要工作任务

u       具体工作包

WBS的表现形式:

u       树形列表

u       锯齿列表

WBS分解结果要求:

u       可管理、可定量测量、可独立分配任务的;

u       可以进行费用和时间的估计;

u       不体现工期和活动的先后顺序;

u       包括管理活动;

u       分解完后需进行核对。

说明:WBS分解是项目计划的基础,也是最关健的。需要做的前期调研和需求分析工作。如果WBS偏差率较高,则整个计划的基本上很难执行。所以这块基石一定要打好。

另外,在WBS分解过程当中,项目管理工作内容不能漏掉。

案例示范:

Project 2000中,WBS分解采用的是锯齿形式,WBS编码能自动生成,最多可分解

500多层,100万个WBS任务。如:

   

 

 

1、 工作排序

工作排序的确定涉及到各工作之间相互关系的识别和说明。任何工作的执行必须依赖于一定工作的完成,也就是说它的执行必须在某些工作完成之后才行,这就是工作的先后依赖关系。工作的先后依赖关系有两种:一种是工作之间本身存在的、无法改变的逻辑关系。如设计与开发。还有一种是组织关系,一般由管理人员根据实际情况来确定。我们要在逻辑关系的基础上再加以分析,考虑组织关系。

 工作排序需要确定的内容:

u       强制的逻辑关系的确定;

u       组织关系的确定;

u       外部制约关系的确定;

u       实际过程中的限制和假设。

工作排序常用的方法:

u       单代号法(AON法)

u       双代号法(AOA法)

案例示范:

2、 工期估计

工时的估计是项目计划制定的一项重要的基础工作,它直接关系到项目的总工期。如果估计的太短,那么在工作中会造成被动局面;相反,如果估计的太长,那么整个工期延长。所以说在工时估计的时候,要在考虑到各种资源、人力、物力、财力的情况下,把工作置于独立的正常状态下进行估计,要做统盘考虑,不可顾此失彼。

工期估计的方法:

u       专家判断。依赖于专家组成员的历史经验。

u       类比估计法。依赖于同类型项目的历史实际数据。

    说明:在人力资源尚未分配时,进行工时估计,一般以按平均资源能力进行估算。

案例示范:

3、 进度安排

根据项目内容的分解,找出各组成要素工作的先后顺序,估计出各工作的延续时间之后,就要安排好项目的时间进度。因为在进度安排之前,我们的计划都是假设在正常情况下的计划,实际中我们的计划会受到各种因素的影响和限制,所以需要根据这些限制重新对进度进行调整。进度安排主要是要根据实际情况来考虑我们的计划。另外,在进度安排中,要将里程碑计划和关健路径计划加入。

进度安排的方法:

u       关健路径法。关健路径是指机动时间为0的工作,如果延期,会导致总工期延期,需特别关注。

u       里程碑计划法。为更好的对项目进度的进展测量进行测量,需设置合理的里程碑点,用于检查阶段性成果的输出,以及实际进度与计划的偏差。

u       计划评审技术(PERT)。对于工作先后逻辑关系及活动不确的时间,可采用最最短时间a、最可能时间m、最长时间b,然后按照β分布计算该工作的期望时间t

u       并行压缩法。对于限定工期的项目,往往需采用并行处理技术,保证项目在限定的工期内完成。并行处理虽然压缩了时间,但同时会引发人力资源和质量的风险,需综合考虑。

   案例示范:

   在该项目的Project甘特图进度安排中,红色表示关健路径、绿色表示里程碑检查点、蓝色表示非关健路径。

 


 

1、 人力资源安排

资源计划涉及到决定什么样的资源,以及多少资源将用于项目的每一工作的执行过程

之中。这里的资源包括人、设备和材料等。象我们的设备分解单也是属于资源计划中的设备和材料资源,也是项目经理必须考虑的。另外还有更重要的一个就是人力资源计划。也就是我们要计划好每项任务由谁来完成,我们计划的资源能否满足要求。以及我们可以获得哪些人力资源,对各种资源的需求及需求计划加以描述。

人力资源计划:

u       分析出人力资源需求

u       人力资源获取

u       人力资源培训

Project2000中,先需建立资源库,具体操作是:工具-》资源-》分配资源。将项目所需人力资源录入,人力资源包括本部门、协作部门、用户和第三方厂商等。资源库建立完后,就可采用拖放的方式来对每条任务分配资源。

资源分配完毕后,项目计划编制者需调整和优化资源,如资源过度分配或资源剩余等。

说明:1、这里所指的资源,均指人力资源,其它如设备资源没有包括在此中。

      2、在第四步工期估计时,尚未分配资源,所以按平均资源能力估计,但资源分配后,对工期估计要做相应一些调整。

案例示范:

2、 费用估计

费用估计指的是预估完成项目各工作所需资源的费用的近似值。目前我们考虑的资源

主要是人力资源和差旅费用。而设备和材料资源暂未考虑。费用估计应该与工作质量的结果相联系。费用估计过程中亦应该考虑各种形式的费用交换。

费用估计的常用方法:

u       类比估计法。依赖于历史数据的积累。

u       从上而下估计法。

u       从下到上估计法。

Project2000中,采用的方法是“从下到上估计法”,这种技术通常首先估计各个独立工作的费用,然后再汇总从下往上估计出整个项目的总费用。估计相对会比较准确。

Project2000预算中,我们首先要输入人力资源的单位价格,在Project工具中,人力资源基本单位为:工时。在数据录入时要进行换算,需将每天标价除以8,转换为工时单价。人力单价估计完后,还要对差旅、招待、活动、通信费、办公等其它费用进行单价估计,如差旅费平均每趟多少,招待费平均每次多少,活动费平均每次多少等,这些单价要依据项目的规模、复杂度和地域等因素来确定,有的还要参照公司财务制度的标准(如通信费用报销规定、差旅补贴规定等)。在Proejct2000的差旅、招待费等的单价录入中,类型选择为“材料”。

案例示范:

3、  费用预算

费用的预算包括给每一项独立工作分配全部费用,以获取度量项目执行的费用基线。

费用预算可以分为三部分,即人工费用预算、辅助服务费用预算和采购物品费用预算。但我们目前费用预算主要考虑的是人工费用预算和差旅等其它费用。

Project2000中,当费用估计完成后,一般来说人力成本便自动计算出来了。但对于差旅等其它费用还需按里程碑或或主体任务进行分配,对于较小的项目也可就在总项目中分配(本例就是在总项目中分配)。分配方法与第六步的人力资源分配方法一样。

案例示范:

 

 

一、             计划的应用

计划的编制,不是单独由项目经理来做,应该是要求项目成员或项目主要成员一起参与。

项目计划制定完后,还要组织计划的评审。计划评审通过后,就形成了项目的基准计划,这个基准计划是日后项目控制的杠杆,也是项目绩效考核的重要基础数据。

应用一:里程碑计划

里程碑,一般都是项目的关健控制点,里程碑的设置应满足阶段成果和易测量两种属性。对项目高层经理或项目主管来说,他们进度控制的焦点往往就是里程碑计划。

操作方法是,选中菜单的项目-》筛选-》里程碑。并插入列备注(输出成果)。

案例示范:(蓝色字体就是我们的里程碑点,共4个)

应用二:关健任务

关健任务,也即机动时间为0的工作,只在关健任务上的工期延期一天,则总工期必将延期一天。所以关健任务对总工期的控制有关至关重要的作用。对项目经理来说,进度控制的侧重点应在关健路径的任务上。

关健路径显示有两种方法:一是在菜单的格式-》甘特图向导-》关健路径;另一种是在菜单的项目-》筛选-》关健路径。第一种情况在前面计划编制的第6步进度安排时有体现。下面以第二种为例。

案例示范:

 

应用三:任务责任分配

基准计划形成后,项目经理需将各任务分配给个每个项目成员。并要求每个项目成员签署任务责任书或任务承诺书,一般在正式开工前的开工会议上进行。任务分派完后,这样我们的计划就开始正式进入执行阶段了。

Project2000中的任务分配,操作过程是:资源使用状况-》在列中加入开始时间、完成时间、完成百分比、备注(即输出成果)等列,使得任务分配的信息更全面。

案例示范:

 

   应用四:资源负荷分析

   计划完成后,还要检查资源分配是否超负荷,如资源超负荷过多,则该计划很难执行。检查资源超负荷的方法如下:

   首先,检查哪些资源已超负荷分配了。操作方法:击点左边栏中的“资源工作表”,红色并且标志列中有感叹号的,则为该资源超负荷分配了。

   案例示范:

  

   接着,超负荷资源找出来后,我们接着要将该资源超负荷分配的任务要找出来。操作方法:选中菜单的项目-》筛选-》使用资源,然后根据弹出的提示框,选择资源“王五”。则可看出超负荷分配的任务。

   案例示范:

   对于人力资源分配时,必须掌握一个均衡分配的原则,不能某一段时间人力资源需求量骤增,某一段时间骤减。这样对人力资源的调配和获取带来困难。项目经理可以通过“人力资源工时曲线图”帮助进行分析。

   操作方法:选择 视图-》工具栏-》分析,则这是在Project2000工具中会出现:“在EXCEL中分析时间刻度数据”,点击该快捷图标-》选择完整项目-》选择导出的域为“工时”-》选择时间单位为“周”-》导出数据

   案例示范:(人力资源工时曲线图)

  

   应用五:费用预算曲线图

   在费用预算,如按时间坐标来分析,有两种表现方式,一是费用预算曲线图,二是费用预算累计曲线图。

   操作方法:同上面的“人力资源工时曲线图”基本一致,只是需在导出域中选为“成本”便可。

   案例示范:(费用预算曲线图)

   对于费用预算累计曲线图,同上述操作方法基本一致,就是在选择导出的域为“累计成本”便可。

   案例示范:(费用预算累计成本曲线图)

  

另外,在费用预算中,如从资源坐标来分析,费用来源分为两大类,一是人力成本费用,二是差旅、交通、招待、会议、等费用。费用从资源角度显示如下。(当然也可将人力资源成本倒出到EXCEL中进行小计。)

   案例示范:

一、             如何使用Project 2000来控制计划

1、 进度跟踪

在控制项目之前,必须将Project计划保存成基准计划,操作方法:工具-》跟踪-》

保存比较基准(注:在Project2002当中,可以保存为多个比较基准)。

项目在执行过程中,项目经理需定时(如每三天或一周一次),对项目的基准计划进行

REVIEW,检查实际进度与计划进度之间的偏差。操作方法:工具-》跟踪-》更新任务。则会弹出如下窗口。

    案例示范:

   

假如,实际工期花费了11工作日,则在实际工期中输入11便可,完成百分比,则会自动计算,在下面进度控制中,便会体现实际工期比计划工期多用了1天。

注:也可采用直接双击任务栏,填写完成百分比、实际开始时间和实际完成时间。在填写完成百分比时,可建立快捷键,更方便操作。操作方法:视图-》工具栏-》跟踪。如图所示:

2、 未完成任务的查看

在项目跟踪过程中,重点会对未完成任务进行跟踪,那么如何显示出这些未完成任务的

信息呢?操作方法是:工具-》筛选-》未完成的任务。

案例示范:

 

3、 进度和费用偏差

由于保存了基准计划,所以就有了与实际情况的比较的基准。假如,在“用户需求调研”

任务实际多花了一天,需求分析双增加了“李四”来帮忙。这样,计划与实际便产生了偏差。

操作方法:在列中按鼠标右键,插入“比较基准工期”、“工期差异”、“成本”、“比较基准成本”、“成本差异”等列。这样就构成了实际与计划的对比表。

案例示范:

4、 项目跟踪甘特图

项目实际进度与计划进度的偏差,通过跟踪甘特图可以比较直观的看出来。优点就是

视觉上比较直观。缺点是偏差范围没有像第3点那样准确。两者各有所长。

    操作方法:选中“跟踪甘特图”便可。在下图中,下面灰色部分表示原比较基准进度条,上面的蓝色部分表示实际进度条。从该图中可看出实际进度有后延。

案例示范:

5、 项目总体进展情况统计

从项目进度控制层次来看,进度控制可分为三层:总体进度控制、里程碑进度控制、

详细进度控制。对于总体进度控制,一般针对项目分管领导或总经理这一层次。他们通过关注的是项目总体情况。在Project2000中,将能很方便的提供出这些信息供高层管理者查看。

   操作方法:选中菜单 项目-》项目信息-》在对话框中点击“统计信息”。例如从下图中可以看出:该项目在当前状态下,已完成总任务的28%,费用花了112,034.81元,总工期延期了1天,费用超支了3904.00元。

   案例示范:

   

6、 挣得值法分析

挣得值法实际上是一种分析目标实施与目标期望之间差异的方法,又称偏差分析法。它

控制的原理就是利用已完成工作的实际成本(ACWP)、计划完成工作的预算成本(BCWS)、实际完成工作量的预算成本(BCWP)三个基础数据,来计算得出进度偏差(SV)和费用偏差(CV)。

假如,以第一个里程碑点200121日作为检查点,来计算该项目的进度和费用偏差值。

操作方法:选择,项目-》项目信息-》在弹出的“项目信息”框中,将状态日期选择为:“2002121日”。然后分别插入列“BCWS”、“ACWP”、“BCWP”、“SV”、“CV”等,从计算结果可得SV<0CV<0,说明该项目在第一个里程碑点进度延期了,费用也超去了,必须采取控制措施或计划变更。

案例示范:

说明:由于检查点为2002121日,而“需求分析”任务工期为5天,实际完成日期为2002122日,所以的计划工作量的实际成本为8000*4/56400;已完成工作量的预算成本为4000*4/53200。图示如下:

关于软件实施项目管理的探讨 

作者:李明国

项目管理是一门新兴的管理学科,其涵盖范围非常广,本文仅立足于软件实施过程中项目管理的应用,以项目管理周期为主线展开探讨。

一、 项目经理的职责和作用

  项目经理是项目的总负责人,负责从项目启动到项目结束的整个项目实施过程。其在项目管理中的职能主要体现在协调,而非行政指派。
主要职责:
1、 在技术、费用和时间特定的前提下,利用组织中的现有资源完成项目最终目标;
2、 和客户、项目组成员、其他相关人共同商议选择开展项目的最佳计划;
3、 为达到目标做出必要的决策;
4、 当项目计划变更时,及时向主管汇报;
5、 在时间和费用允许的条件下,和各项目部门协调工作程序;
6、 负责协调项目组人员间的关系
7、 按项目计划进行项目验收,
8、 如果目标达不到而合同允许,建议结束项目或改变方法;

二、 软件实施项目管理的过程(注:和PMBOK2000存在差异)

1、 项目开始
  项目开始阶段主要针对软件合同内容,制定项目的总体安排计划,并由公司售前人员和对方企业项目实施人员对前期项目资料进行移交,确定项目责任和授权,尤其要明确项目的验收标准。在项目开始阶段进行的项目管理主要包括以下内容:
  ·项目总体安排 对项目的时间、进度、费用、人员等作出总体安排,制定该项目的总体计划。
  ·资料移交 包括合同、售前调研报告、需求分析、验收标准、对方公司的项目组成员等资料。
  ·项目范围定义 在资料移交的基础上,定义该项目的整体范围。
  ·项目授权 由企业与公司销售部门根据项目合同,明确双方职责,并由企业根据项目的需要对实施组进行项目管理的授权
.对该阶段的资料进行整理、归档。
2、 项目计划
  项目计划阶段是该项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。
(1) 对项目组成员进行职能分工,画出项目管理组织结构图、明确各自职责。如下图所示:

(2) 全体项目组成员参与,对该项目进行工作结构分解(WBS),按工作内容或生命周期进行分解,分解项要求越细越好;绘制工作分解结构图。如一个包括二次开发的软件实施项目的工作分解结构

(3)根据工作分解结构,绘制人力资源分配图和责任矩阵图。如下图所示:

(3) 制定项目实施的进度计划(甘特图、关键路线图、网络图)。该进度计划包含各工作任务的计划(由各负责人分别做出),计划中需要调用对方资源的,需要由对方参加并签字确认。
甘特图图例:

附件:XX项目甘特图可以用PROJECT2000打开

(4) 人力资源计划
安排整个项目运行期的项目参与人员,明确人员到岗日期,严格控制人力资源费用。

(5) 费用及成本计划
作为软件实施项目的费用及成本计划主要发生在人力资源费用上。

<费用分配表>

3、 执行/控制项目

  在项目执行过程中为了保障项目在预期的目标(进度、质量/范围、成本)范围内完成,必须严格执行项目计划,尽量避免项目需求变更和人员变更。如果出现不可预知的因素导致项目变更,必须及时调整项目目标、项目计划,并通知对方,由对方签字确认。
  项目控制的主要任务是项目进度控制,按不同管理层次对进度控制的要求可以分为三类:项目进度总控制、项目主进度控制、项目详细进度控制。总进度由项目经理负责,主进度由各项目部门负责,详细进度由各作业单位负责。在项目出现进度变更时,要及时提交变更报告,包括变更对进度安排的影响和要求。
  作为项目经理应根据项目计划的关键路线图,在项目执行过程中应关注关键路线的执行情况。
针对项目变更通常采用补救、更新计划等处理方式。
4、 项目收尾和后评价
  项目收尾是指峡谷木的成果完成后的结束工作。包括提交项目交付物并为项目发起者所接收、将项目取得的经验文档化并进行推广
  项目结束阶段的工作包括项目验收(范围验收、质量<目标>验收、资料整理和验收、项目交接等)和项目后评价两项。
  针对项目验收而言包括阶段性的项目验收和总验收两部分,其中阶段验收是总验收的基础。在每个阶段工作完成后,由相关责任方共同参加,相关责任人在验收报告上签字。验收内容包括项目进度、项目目标完成情况、评价和项目文档。

三、 项目后评估

  项目后评价为项目收尾阶段的一项工作,主要是在项目验收结束后针对项目的实施情况进行总结,并将项目经验进行推广。项目后评估报告应包括内部交流和对外(媒体)发布两部分内容

2004年09月28日

X

0.00

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.0

0.1

0.2

0.3

0.4

 

0.5

0.6

0.7

0.8

0.9

 

1.0

1.1

1.2

1.3

1.4

 

1.5

1.6

1.7

1.8

1.9

 

2.0

2.1

2.2

2.3

2.4

 

2.5

2.6

2.7

2.8

2.9

0.500 0

0.539 8

0.579 3

0.617 9

0.655 4

 

0.691 5

0.725 7

0.758 0

0.788 1

0.815 9

 

0.841 3

0.864 3

0.884 9

0.903 2

0.919 2

 

0.933 2

0.945 2

0.955 4

0.964 1

0.971 3

 

0.977 2

0.982 1

0.986 1

0.989 3

0.991 8

 

0.993 8

0.995 3

0.996 5

0.997 4

0.998 1

0.504 0

0.543 8

0.583 2

0.621 7

0.659 1

 

0.695 0

0.729 1

0.761 1

0.791 0

0.818 6

 

0.843 8

0.866 5

0.886 9

0.904 9

0.920 7

 

0.934 5

0.946 3

0.956 4

0.964 8

0.971 9

 

0.977 8

0.982 6

0.986 4

0.989 6

0.992 0

 

0.994 0

0.995 5

0.996 6

0.997 5

0.998 2

0.508 0

0.547 8

0.587 1

0.625 5

0.662 8

 

0.698 5

0.732 4

0.764 2

0.793 9

0.821 2

 

0.846 1

0.868 6

0.888 8

0.906 6

0.922 2

 

0.935 7

0.947 4

0.957 3

0.965 6

0.972 6

 

0.978 3

0.983 0

0.986 8

0.989 8

0.992 2

 

0.994 1

0.995 6

0.996 7

0.997 6

0.998 2

0.512 0

0.551 7

0.591 0

0.629 3

0.666 4

 

0.701 9

0.735 7

0.767 3

0.796 7

0.823 8

 

0.848 5

0.870 8

0.890 7

0.908 2

0.923 6

 

0.937 0

0.948 4

0.958 2

0.966 4

0.973 2

 

0.978 8

0.983 4

0.987 1

0.990 1

0.992 5

 

0.994 3

0.995 7

0.996 8

0.997 7

0.998 3

0.516 0

0.555 7

0.594 8

0.633 1

0.670 0

 

0.705 4

0.738 9

0.770 3

0.799 5

0.826 4

 

0.850 8

0.872 9

0.892 5

0.909 9

0.925 1

 

0.938 2

0.949 5

0.959 1

0.967 2

0.973 8

 

0.979 3

0.983 8

0.987 4

0.990 4

0.992 7

 

0.994 5

0.995 9

0.996 9

0.997 7

0.998 4

0.519 9

0.559 6

0.598 7

0.636 8

0.673 6

 

0.708 8

0.742 2

0.773 4

0.802 3

0.828 9

 

0.853 1

0.874 9

0.894 4

0.911 5

0.926 5

 

0.939 4

0.950 5

0.959 9

0.967 8

0.974 4

 

0.979 8

0.984 2

0.987 8

0.990 6

0.992 9

 

0.994 6

0.996 0

0.997 0

0.997 8

0.998 4

0.523 9

0.563 6

0.602 6

0.640 4

0.677 2

 

0.712 3

0.745 4

0.776 4

0.805 1

0.835 5

 

0.855 4

0.877 0

0.896 2

0.913 1

0.927 9

 

0.940 6

0.951 5

0.960 8

0.968 6

0.975 0

 

0.980 3

0.984 6

0.988 1

0.990 9

0.993 1

 

0.994 8

0.996 1

0.997 1

0.997 9

0.998 5

0.527 9

0.567 5

0.606 4

0.644 3

0.680 8

 

0.715 7

0.748 6

0.779 4

0.807 8

0.834 0

 

0.857 7

0.879 0

0.898 0

0.914 7

0.929 2

 

0.941 8

0.952 5

0.961 6

0.969 3

0.975 6

 

0.980 8

0.985 0

0.988 4

0.991 1

0.993 2

 

0.994 9

0.996 2

0.997 2

0.997 9

0.998 5

0.531 9

0.571 4

0.610 3

0.648 0

0.684 4

 

0.719 0

0.751 7

0.782 3

0.810 6

0.836 5

 

0.859 9

0.881 0

0.899 7

0.916 2

0.930 6

 

0.943 0

0.953 5

0.962 5

0.970 0

0.976 2

 

0.981 2

0.985 4

0.988 7

0.991 3

0.993 4

 

0.995 1

0.996 3

0.997 3

0.998 0

0.998 6

0.535 9

0.575 3

0.614 1

0.651 7

0.687 9

 

0.722 4

0.754 9

0.785 2

0.813 3

0.838 9

 

0.862 1

0.883 0

0.901 5

0.917 7

0.931 9

 

0.944 1

0.953 5

0.963 3

0.970 6

0.976 7

 

0.981 7

0.985 7

0.989 0

0.991 6

0.993 6

 

0.995 2

0.996 4

0.997 4

0.998 1

0.998 6

X

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

3

0.998 7

0.999 0

0.999 3

0.999 5

0.999 7

0.999 8

0.999 8

0.999 9

0.999 9

1.000 0

五步求解PERT图
  (2004-8-12 10:37:00) 来源:中国计算机用户 作者:北京赛迪信息工程监理有限公司副总经理 陈兵
   本文主要介绍网络计划技术在ERP项目管理中的应用。

    在以往的项目建设中,编制项目进度计划常常采用甘特图(或称横道图)来表示,甘特图简单明了、形象直观,但不适合用于大型和复杂信息工程项目的建设和监理工作。

  因为甘特图不反映各项工作之间的逻辑关系,因而难以确定某项工作推迟对完成工期的影响;当实际进度与计划有偏差时也难以调整。另外,甘特图虽然直观清晰,但只是计算的结果,而一项工作什么时候开始,什么时候结束,却是需要通过计算来实现,甘特图并没有给出好的算法。

  网络计划技术可以有效解决这些问题。目前应用比较广泛的两种计划方法是关键路径法(Critical Path Method,简称CPM)和计划评审技术(Program Evaluation and Review Technique,简称PERT)。

  CPM和PERT是独立发展起来的计划方法。两者的主要区别在于:CPM是以经验数据为基础来确定各项工作的时间,而PERT则把各项工作的时间作为随机变量来处理。所以,前者往往被称为肯定型网络计划技术,而后者往往被称为非肯定型网络计划技术。前者是以缩短时间、提高投资效益为目的,而后者则能指出缩短时间、节约费用的关键所在。因此,将两者有机结合,可以获得更显著的效果。

  信息工程项目建设过程中不可预见的因素较多,如新技术、需求变化、到货延迟,以及政策指令性影响等。因此,整体工程进度计划与控制大多采用非肯定型网络计划,即PERT网络模型。

  信息工程项目应用网络计划技术的步骤如下:①绘制网络图;②网络计划计算;③求关键路径;④计算完工期及其概率;⑤网络计划优化。

  步骤1:绘制ERP项目网络图

  本文主要以某公司(中小型企业)ERP项目建设为例,讲述网络计划技术在信息工程项目监理工作进度控制中的应用。

  (1) 定义各项工作(作业)

  恰当地确定各项工作范围,以使网络图复杂程度适中。

  (2) 编制工作表

  首先是根据实施厂商的实施方法和业主单位的实际情况,制定ERP项目工作清单(如表1所示),并确定各项工作的先行工作。在工作定义过程中,应考虑有关项目和项目目标的定义、说明以及历史资料。工作定义过程结束时,要提交的成果之一就是工作清单。工作清单必须包括本项目范围内的所有工作,应当对每项工作列出文字说明,保证项目成员准确、完整地理解该项工作。

 

  其次进行项目描述。项目的特性通常会影响到工作排序的确定,在工作排序的确定过程中更应明确项目的特性。

  再次,确定或估计各项工作时间。估算的方法在后面介绍。

  最后,表明各项工作之间的逻辑关系。着重考虑的内容如下:

  a. 强制性逻辑关系的确定。这是工作排序的基础。逻辑关系是工作之间所存在的内在关系,通常是不可调整的,一般主要依赖于技术方面的限制,因此确定起来较为明确,通常由技术人员同管理人员的交流就可完成。

  b. 组织关系的确定。对于无逻辑关系的项目工作,由于其工作排序具有随意性,从而将直接影响到项目计划的总体水平。这种关系的确定,通常取决于项目管理人员的知识和经验,它的确定对于项目的成功实施是至关重要的。

  c. 外部制约关系的确定。项目工作和非项目工作之间通常会存在一定的影响,因此在项目工作计划的安排过程中,也需要考虑到外部工作对项目工作的一些制约及影响,这样才能充分把握项目的发展。

  d. 实施过程中的限制和假设。为了制定良好的项目计划,必须考虑项目实施过程中可能受到的各种限制,同时还应考虑项目计划制定所依赖的假设和条件。

  (3)根据工作清单和工作关系绘制网络图

  根据表1中各工作之间的逻辑关系,可绘制双代号网络图如图1所示

 

  步骤2: 网络计划计算

  (1)工作时间估计

  工作延续时间的估计是项目计划制定的一项重要的基础工作,它直接关系到各事项、各工作网络时间的计算,和完成整个项目任务所需要的总时间。若工作时间估计的太短,则会在工作中造成被动紧张的局面;相反,就会使整个工程的工期延长。

  网络中所有工作的进度安排都是由工作的延续时间来推算的,因此,对延续时间的估计要做到客观正确。这就要求在对工作做出时间估计时,不应受到工作重要性及工程完成期限的影响,要把工作置于独立的正常状态下进行估计,要统盘考虑,不可顾此失彼。

  估计工作时间的方法主要有:

  a. 专家判断:专家判断主要依赖于历史的经验和信息,当然其时间估计的结果也具有一定的不确定性和风险。

  b. 类比估计:类比估计意味着以先前的类似的实际项目的工作时间来推测估计当前项目各工作的实际时间。当项目的一些详细信息获得有限的情况下,这是一种最为常用的方法,类比估计可以说是专家判断的一种形式。

  c. 单一时间估计法:估计一个最可能工作实现时间,对应于CPM网络。

  d. 三个时间估计法:估计工作执行的三个时间,乐观时间a、悲观时间b、正常时间c,对应于PERT网络:期望时间t=(a+4c+b)/6。

  (2)工作最早开始时间

  工作最早开始时间是到指某个节点前的工作全部完成所需要的时间,它是本项工作刚刚能够开始的时间。

  (3)工作最迟开始时间

  工作最迟开始时间是指某项工作为保证其后续工作按时开始,它最迟必须开始的时间。

  (4)时差的计算

  时差是指在不影响整个任务完工期的条件下,某项工作从最早开始时间到最迟开始时间,中间可以推迟的最大延迟时间。

  步骤3:求关键路径

  关键路径有两种定义:

  ①在一条路径中,每个工作的时间之和等于工程工期,这条路径就是关键路径。

  ②若在一条路径中,每个工作的时差都是零,这条路径就是关键路径。

  图1所示的网络图,关键路径所需时间=3+16+10+15+1+30+15=90天(图1中加黑部分)。

  步骤4:计算完工期及其概率

  设路径T的总时间(即路径T上各项目工作的时间和)为T(=∑t作业路径),标准差为σT,则在工期D内完工的概率为:

  以表1和图1为例,关键路径D-F-G-I-J-K-L,T=90

   步骤5:网络计划优化

  在项目计划管理中,仅仅满足于编制出项目进度计划,并以此来进行资源调配和工期控制是远远不够的,还必须依据各种主、客观条件,在满足工期要求的同时,合理安排时间与资源,力求达到资源消耗合理和经济效益最佳这一目的,这就是进度计划的优化。优化的内容包括:时间(工期)优化;缩短工期,时间(工期)-成本优化。

  (1)时间优化

  工期优化包括两方面内容:一是网络计划的计算工期Tc超过要求工期Ts,必须对网络计划进行优化,使其计算工期满足要求工期,且保证因此而增加的费用最少;二是网络计划的计算工期远小于要求工期,也应对网络计划进行优化,使其计算工期接近于要求工期,以达到节约费用的目的。一般前者最为常见。

  (2)时间(工期)-成本优化

  CPM方法是解决时间—成本优化的一种较科学的方法。它包含两个方面的内容,一是根据计划规定的期限,规划最低成本;二是在满足成本最低的要求下,寻求最佳工期。

  缩短工期的单位时间成本可用如下公式计算(参见图2):

 

  工期-成本优化的步骤是:

  a. 求关键路径;

  b. 对关键路径上的工作寻找最优化途径;

  c. 对途径中K值小的工作进行优化;

  d. 在优化时,要考虑坐邻右舍。

  举例说明,参见图3:

 

  a.如果仅考虑正常工期估计

  则路径A-B的工期是16,成本是130000;路径C-D的工期是18,成本是70000。因此关键路径是路径C-D,项目总工期为18,总成本是200000。

  b.如果全部活动均在它们各自的应急时间内完成

  则路径A-B的工期是11,成本是172000;路径C-D的工期是15,成本是87000。因此关键路径是路径C-D,项目总工期为15,总成本是259000。

  c.用工期—成本平衡法压缩那些使总成本增加(斜率)最少的活动的工期,确定项目最短完成时间。

  第一次压缩,由于关键路径的工期决定着项目的总工期,所以取路径C-D进行优化。计算得KA=6000,KB=10000,KC=5000,KD=6000。为了将项目的工期从18周减至17周,针对关键路径C-D。确定关键路径上哪项活动能以最低的“斜率”(成本被加速),可以看出KC=5000最小,因此将活动C的工期压缩1周。得出项目周期17周,总成本为205000。

  第二次压缩,为了再缩短一个时间段,从17周缩短至16周,必须再次找出关键路径,两路径的工期分别是A-B为16周,C-D为17周,因此关键路径仍是C-D,它必须再次被减少。这时,虽然活动C比活动D的“斜率”(每周加速成本)低,但活动C已达到它的应急时间9周了。因此,仅有的选择是加速活动D的进程。将活动D的工期压缩1周,项目工期为16周,总成本为211000。

  第三次压缩,再次将项目工期缩短1周,从16周降至15周。有两条关键路径。为了将项目总工期从16周减至15周,必须将每个路径都加速1周。路径A-B压缩活动A,路径C-D压缩活动D,项目周期15周,总成本223000。

  第四次压缩,从15周降至14周。有两条相同的关键路径。必须将两条路径同时加速1周。路径C-D,均已达到它们的应急时间。加速路径A-B的进程会毫无意义。停止优化过程。

  d.工期-成本优化结果,如表2:

  项目总工期减少l周,项目总成本将增加5000元;

  项目工期减少2周,项目总成本将增加l1000元;

  项目工期减少3周,项目总成本将增加23000元。

 

  在运用网络图做计划时,要体现一个系统分析的思想。信息工程项目实施是由多种工作按一定层次组成的复杂系统。其任务由多个部门承担,因而各项控制活动只有组成一个既明确分工,又相互协调配合、紧密衔接的有机整体,才能达到既定的风险、进度、费用控制目标。

  链接

  双代号网络图的五个组成部分

  网络图是用来表示工作流程的有向、有序的网状图形,由箭线和节点组成。网络图有多种表示方式,最常见的有双代号网络(activity-on-arrow network, AOA)和单代号网络(activity-on-node network, AON)。

  双代号网络是一种用箭线表示工作、节点表示工作相互关系的网络图方法,在我国这种方法应用较多。双代号网络计划一般仅采用结束到开始的关系表示法。如图是双代号网络图的示例。

 

  (1)事项(事件、结点)

  事项是工程(计划)的始点、终点(完成点)或其各项工作的连接点(交接瞬间)。在网络图中,用箭线端部的圆圈或其它形式的封闭图形表示。

  (2)工作(作业、活动)

  工作是指一项有具体内容的、需要人力、物力、财力、占用一定空间和时间才能完成的活动过程。例如需求分析、软件架构设计、代码编写、单元测试等。工作由节点和边组成。

  (3)先行工作和后续工作

  先行工作和后续工作 如果在工作A完成后才可以开始工作B,则工作A叫作工作B的先行工作,工作B叫作工作A的后续工作。

  (4)平行工作

  如果工作A结束后,工作B和C可以同时开始进行,则工作B和C叫作平行工作。

  (5)虚拟工作

  虚活动(工作)是只表示工作之间相互依存、相互制约、相互衔接的关系,但不需人力、物力、空间和时间的虚设的活动,一般用虚线边表示,虚拟工作的时间为零。

应用PERT进行项目工期估计
作/转载者:田俊国     发布时间:2003-5-5    浏览量:1213 
来自:51CMM.COM

PERT(计划评审技术,Program Evaluation an Review Technique) 是50年代末美国海军部开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的,其理论基础是假设项目持续时间以及整个项目完成时间是随机的,且服从某种概率分布。PERT可以估计整个项目在某个时间内完成的概率。PERT和CPM在项目的进度规划中应用非常广,本文通过一个项目实例对此技术加以说明。
一、 活动的时间估计
  PERT对各个项目活动的完成时间按三种不同情况估计:
  1、乐观时间(optimistic time)–任何事情都顺利的情况,完成某项工作的时间。
  2、最可能时间(most likely time)–正常情况下,完成某项工作的时间。
  3、悲观时间(pessimistic time)–最不利的情况,完成某项工作的时间。
  假定三个估计服从β分布,由此可算出每个活动的期望ti:

  其中: ai表示第i项活动的乐观时间,mi--表示第i项活动的最可能时间,bi表示第i项活动的悲观时间。
  根据β分布的方差计算方法,第i项活动的持续时间方差为:

  例如,某政府OA系统的建设可分解为需求分析、设计编码、测试、安装部署等四个活动,各个活动顺次进行,没有时间上的重叠,活动的完成时间估计如下图所示:

二、 项目周期估算
  PERT认为整个项目的完成时间是各个活动完成时间之和,且服从正态分布。整个项目
 
 因为图2是正态曲线,根据正态分布规律,在±σ范围内即在47.304天与54.696天之间完成的概率为68%;在±2σ范围内完即在43 .608天到58.393天完成的概率为95%;在±3σ范围内即39.912天到62.088天完成的概率为99%。如果客户要求在39天内完成,则可完成的概率几乎为0,也就是说,项目有不可压缩的最小周期,这是客观规律。
通过查标准正态分布表,可得到整个项目在某一时间内完成的概率。例如,如果客户要求在60天内完成,那么可能完成的概率为:

三、小结
  实际上,大型项目的工期估算和进度控制非常复杂,往往需要将CPM和PERT结合使用,用CPM求出关键路径,再对关键路径上的各个活动用PERT估算完成期望和方差,最后得出项目在某一时间段内完成的概率。
  PERT还告诉我们,任何项目都有不可压缩的最小周期,这是客观规律,千万不能不顾客观规律而对用户盲目承诺,否则必然会受到客观规律的惩罚。

文章来源:文章-其他
发布时间:2003-5-5 
项目管理者联盟[mypm.net]

2004年08月19日
關於風險管理,<與熊共舞>是一本很不錯的書。
 
前段時間,看到一個關於IT治理的開放標準,COBIT(Control Objectives for Information and related Technology,信息及相关技术的控制目标),
這是一個非常適合IT項目審計的標準,
與PMBOK類似,它將項目分成4各領域,34個過程,
對於對每一個過程,都進行了細分,並進行成熟度認證。
 
我們目前的項目管理,缺乏一些有效劃分與控制,也缺乏對項目的有效評介,
當然,我們的理論也根據很弱。
 
上封Mail中關於”代码同行评审”(我們的CodeReview)與”對项目进展定期檢查”,都是一些比較好的措施,
我們平常也有作,只是在執行力度上需要加強,執行方式上需要摸索與總結。

一、项目风险发生的根源

 极少听见有项目主管说他的项目没有任何风险而一切尽在掌握。对于一个项目来讲,风险的出现非常常见,把所有风险都拒之门外几乎没有可能,你几乎没有可能完美的解决“工期”、“资源”、“质量”三者的天生的冲突,这些导致项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上只是一种预测,在执行过程中与实际情况肯定会有差异,这些预测和实际情况的差异性,就为项目各种各样的风险埋下了伏笔。经过一些项目实践,我总结出项目风险产生的原因主要有以下几条。

1. 项目计划中对风险管理没有引起足够的重视,导致风险发生以后手足无措。

2. 轻视前期需求工作,导致项目实际产品与客户预期的差别较大。

3. 项目过程中过渡轻视文档管理,导致风险发生以后要么无据可依(通常指需求发生变更以后,发现当初需求文档不完善),要么后继无人(通常是一些设计类文档,在人员发生变动的时候,其它人看不懂文档,无法接手工作)。

4. 轻视质量控制,导致主管得到的信息与实际差距较大,不能清晰的及时判断出真正的风险是否已经发生。在项目运作过程中,如果只靠员工的报告来掌握项目进展是不够的。事实上,员工都愿意报喜不报忧,在项目初期就出现的问题苗头,如果不能传递上来,将在后续阶段造成大更大的纰漏。缺乏质量控制机制,也就是缺乏有效的“监督”人员来制约,是造成这种情况的主要原因。

5. 轻视架构和概要设计。一般项目时间紧、资源有限,这样一些项目管理者在缺乏对系统架构和其它技术方面的设计缺乏有效的论证的前提下,就凭借着经验匆匆启动项目,很可能导致以后一旦因为客户需求变化等因素对整个系统的架构产生影响,导致系统大量的修改。以前就我曾经经历过这种事情,简直让人崩溃。

6. 缺乏积极的应对风险的措施。实际上,项目发生风险非常正常,很多风险甚至可以预料是肯定会发生的,一旦比较大的风险发生,会直接对项目组每个成员产生一些负面影响,此时很多项目管理者不能以积极的态度应对,而是自乱了阵脚,很可能导致项目计划频繁变更,项目节奏感被打乱并且逐渐开始失控。

二、解决措施

 任何问题,如果找到了真正原因,其实已经向解决问题迈进了一大步。针对以上风险发生的原因,我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。

在项目计划中重视风险的评估

很多项目主管在项目启动的时候认为既然团队已经建立好了,项目计划已经制定好了,就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的,任何项目都会有风险的。在项目初期认真做好风险的评估,并且能让你的项目干系人(尤其是项目主管的掌控项目资源的负责人)清楚这些风险,那么一旦风险发生,也可以更加从容不迫的应对,并且有理由更好的协调资源,不至于让大家不知所措。

要重视需求工作

一个好的需求是连接业务层面和技术层面两类人,让他们达成一致的目标的关键,对于大型的复杂的项目尤其重要。好的需求可以很好的控制客户需求变更给项目带来的负面影响,(很多项目都是这样,不断的需求变更导致不断的修改,如此反复,最后陷入无法自拔的泥潭),因为客户一旦签字确认以后,这份需求就应该与商业合同一起具备法律效力而对客户进行必要的约束;另外一份清晰的没有二义性的需求可以让开发人员非常清晰自己应该完成什么工作,测试人员很好的编写测试用例,就是这份需求,可以大大降低项目组以后在沟通、修改方面的成本,提高效率和产品质量。

其实大部分人都知道“需求”的重要性,有些人肯定会说:“项目时间和资源有限,怎么可能化那么多精力专门做需求呢?”。这是一种误区,需求并不一定要长篇累犊、事无具悉,但是一定要有需求。具体需求怎么写,应该对整个项目做评估以后制定一个策略。比如因为公司长期从事某方面业务,那么这些就可以写简单点;或者项目时间太紧,那么需求文档的模版可以根据实际情况做一些必要的简化。

不合格的需求,往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是项目的一份纲领性文件,是以后项目路线的指挥棒,好的需求一定能清晰的描述出整个项目:包括都要做什么以及这些事情的优先级。比如知道优先级以后,项目的管理者就可以根据重要性、难以程度而因人制宜的分派工作,尤其遇到时间特别紧张的情况下,可以说服客户先上最重要的系统模块而把一些不重要的放在以后逐渐实施,这样把好钢都用在刀刃上,在资源等方面受到很多限制的前提下,尽量做到大家的满意,这也为降低日后的风险打下了坚实的基础。

重视项目文档管理

 让项目主管最痛苦的事情莫过于:当一个重要成员半途离开项目组时,才发现他根本就没有留下任何可用的文档。尤其在IT项目中,人员流动性强,文档就是成员之间交接的重要工具。但是很多主管很容易陷入“重技术实现,轻文档”的误区,他们总是认为项目实施时间紧迫,为了节省时间,可以在项目收尾阶段突击写文档。要是项目周期稍长一点,到了最后,谁还会清清楚楚记得每个实现细节呢?如果下一个项目与此类似,以前的劳动成果还有谁能继承得下来呢?

 当然,现在越来越多的公司已经注意到了管理好文档的重要性,一般可以借助VSSCVSPVCS等工具来很好的对文档进行版本控制,但是有一点要特别引起注意:单单关注文档本身远远不够,还要重视文档的质量!即使是在现在很多管理很规范(比如已经通过了CMM3ISO9000等认证)的公司,“重过程、轻质量”也是一个突出问题。一般在每一份文档入基线以前,都要通过评审、同行评审等方式来对文档进行专门的“轰击”以保证文档的有效性,这些评审小组中如果能包括一些行业、技术方面的专家将经常能达到更好的效果,这些专家完全可以从公司外面聘请。

 有了完善和有效的文档做基础,能降低很多项目过程中的风险。

重视质量过程控制

 很多人通常认为,在的项目组中最重要的是主管和设计开发人员,而认为项目中的质量过程控制没有什么必要。但是在实际项目过程中,单靠研发人员提供的报告来判断项目进程、确认是否有或者将有风险发生远远不够。因为大部分人喜欢报喜不报忧,而且汇报的内容大部分只是他本人主管的认知,也缺乏通盘的考虑。越复杂的项目,越需要量化的管理,必须有一种机制能让管理者真正掌握项目的实际进展情况,最有效的办法就是建立质控部门与实际的研发部门相互制约,监控测试项目实际情况和实际的问题,而不参与项目的具体实施。

作为一个项目管理者,明确这种研发和质控的关系,除了更好的保证项目质量以外,还能客观的反映项目实际情况,通过这些文档来表明每个基线、每个成员的工作量和完成质量,对识别、预测项目风险意义重大,当然,这些措施也大大降低了项目过程中可能的风险发生的概率。


重视架构和概要设计

 IT项目中,编码实施固然重要,但是对于一个比较复杂项目中的项目组来讲,如何让不同角色的研发人员高效协作,将是更加要紧的问题。
 
设计文档,尤其是架构设计就是能够让这些研发资源更加高效协作,降低返工的有效手段。有了这些设计作为指引,研发人员就可以同步工作,共享公用的资源(比如,经过设计分析以后,发现客户业务方面有ABC三个业务模块,但是其实这三个模块中有几乎50%在技术实现上是公用的)。在实际设计的操作过程中,可能有时候项目组内部成员几乎没有一个有经验,那么最好还是聘请一些外部的专家来帮忙,我在实际的项目中,发现这个效果会比较好。

 有了这些有效的纲领性的技术文件,会在实际开发过程中大大降低各种潜在的风险。

采用积极的应对风险的措施

 让人遗憾的是,即便我们做了很多的事情来防止风险的发生,通常还会有风险发生。一旦突如其来的风险发生了,例如:项目组核心成员突然病倒,客户组织结构发生调整或者虽然当初签订了合同确认了需求,但是客户业务调整了,那么我们总不能一意孤行的还是移交给客户一套其实已经无法运转的系统吧。这些风险一旦发生,躲避不是办法,作为一个项目主管来说,更加行之有效的办法是带领整个团队,用积极的心态、科学合理的方法来以最小的代价克服它。当然,这也需要项目组的经验以及项目主管的综合素质来支撑。

 通常处理风险的过程分为三步走:识别  量化 应对。通过风险识别确定哪些风险可能影响项目,并把风险归档作为以后过程财富的很好的积累,把产品、历史信息、其它相关信息作为输入,利用检查表、流程图、面谈等手段,得出风险的来源、征兆等结论;风险量化是指评价风险和它们之间的相互作用,从而评估项目可能结果的大概范围。如果你想启动风险量化过程,那么你需要首先知道这些风险的来源,量化是一项比较复杂的活动,除了采取货币、时间等来衡量以外,最好借助专家的判断。有了比较量化的结果以后,项目主管就能清晰的意识到风险的严重性,从而做出更加贴切的应对措施;有了以上的结果以后,就可以制定风险应对措施来制定应对措施了。

 总之,知道了项目风险的原因和应对措施,对项目的顺利进行有非常重要的意义,很多情况下,能否很好的处理好项目的风险会成为项目成败的关键,这种处理突发风险的能力也成为衡量一个项目主管人员重要指标。