成功项目管理的秘密(1)
项目部管理规章制度范文（5篇）
项目部管理规章制度范文为规范项目部职工行为，保证施工生产的顺利进行，现结合实际情况，特制定本规章制度：一、行为规范考核1、维护本项目部利益，热爱本职工作，遵守项目管理制度，牢固树立主人翁意识。
2、遵守下级服从上级的原则，项目部人员必须服从项目负责人的统一领导和分工安排。
3、爱护____财产，损失或遗失照价赔偿。
严禁盗窃____财物，发现以一罚十，情节严重的移交司法部门处理。
4、由于工作失误造成材料报废或消耗超标、以及经济损失等由责任人全额赔偿。
5、生产场地、机械设备及宿舍区必须定期整理，保持整洁、文明、卫生的工作环境。
二、劳动纪律考核1、严格执行工艺纪律，文明生产、文明施工，如因违反操作规程或野蛮作业面而造成的一切责任由当事人负全责。
2、上班时间不得溜班、窜岗，不得在施工场地追逐打闹，不得在上班途中无故滞留宿舍。
3、特殊情况不得在外留宿，发现一次，除在项目部通报外，扣除当月奖金。
4、保质保量完成当天的下达任务，不能完成任务的扣除半天考勤。
5、项目部人员不得酗酒打架，发现一次除在项目部工程例会上通报外，扣除本月基本工资。
6、项目部物资、财务等重要岗位责任人员不得接受供料方和下属施工队的宴请，发现一次除在项目部工程例会上通报外，扣除当月奖金，情节严重的上报上级党委。
三、安全生产(文明施工)考核1、严格按照操作规程施工，遵守“进场须知”等各项规章制度，增强自我防范意识和自我保护意识，杜绝违章作业。
2、项目部人员一律统一佩带安全帽、工作服，挂牌上岗，持证作业。
3、不准在营区内私拉乱接电线，不准在宿舍内接电炉子等易引起火灾的电器等。
正常的接线应由电工统一安排。
4、项目部人员如发现不安全因素就及时反映，及时清除，并有责任劝阻、制止其他人员的违章作业。
5、不准下河洗澡、到老百姓的池塘吊鱼，发现一次罚款____元。
四、考勤、请假考核1、严格执行请假制度，请假应有正当理由，并按手续提前出具书面报告，经批准后方可离岗。
项目管理精华总结
项⽬管理精华总结⽼师展⽰的是这样的⼀张图：这就是项⽬管理的九⼤领域：整合管理、范围管理、时间管理、费⽤管理、质量管理、⼈⼒资源管理、沟通管理、风险管理、采购管理。
项⽬管理好像⼀头⼤象，将其⼤卸九块之后，要装进冰箱就容易多了。
看看书上是怎样解释这九⼤领域的：整合管理：包括识别、确定、结合、统⼀与协调各项⽬管理过程组内不同过程与项⽬管理活动所需进⾏的各种过程和活动。
范围管理：确保项⽬包括成功完成项⽬所需的全部⼯作，但⼜只包括必须完成的⼯作的各个过程。
时间管理：包括使项⽬按时完成必须实施的各项过程。
费⽤管理：包括涉及费⽤规划、估算、预算、控制的过程，以便保证能在已批准的预算内完成项⽬。
质量管理：包括保证项⽬满⾜原先规定的各项要求所需的执⾏组织的活动，即决定质量⽅针、⽬标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量持续改进等⽅针、程序和过程来实施质量体系。
⼈⼒资源管理：包括项⽬团队组建和管理的各个过程。
沟通管理：包括保证及时与恰当地⽣成、搜集、传播、存储、检索和最终处置项⽬信息的所需的过程。
风险管理：包括项⽬风险管理规划、风险识别、分析、应对和监控的过程。
采购管理：包括从项⽬团队外部购买或获得为完成⼯作所需的产品、服务或成果的过程。
3.五招四⼗⼆式要把⼤象装进冰箱，分成九块还是太⼤了，还得切⼩⼀点。
因此在PMBok第四版中，⼜将九⼤知识领域细分为42个过程，这些过程可以分为5个组，启动过程组、规划过程组、执⾏过程组、监控过程组和收尾过程组。
这五⼤过程组42个过程，就是武术中的招式，可以直接⽤来实战中了，因此不妨称之为“五招四⼗⼆式”。
这⼀节牵涉到⽐较多的项⽬管理理论知识，如果你完全没有接触的过的话，读起来可能会⽐较困难，建议先啃⼀遍PMBok，或者跳过本节。
1. 五⼤过程组五⼤过程组与九⼤领域⼀样，同样体现了做事的逻辑，只不过⾓度有所不同：启动：确定是否要做，以及做什么规划：打算怎么做执⾏：按照计划去做控制：做对了没有收尾：做完了收⼯可以看出，这是⼀个完整的做事流程。
项目部保密管理制度范文(3篇)
项目部保密管理制度范文一、目的为了保护公司及项目部的商业秘密和敏感信息，维护公司和项目部的经营和利益安全，特制定本保密管理制度。
二、适用范围本保密管理制度适用于项目部全体员工，包括项目经理、工程师、技术人员等。
三、保密责任1. 项目部领导对项目的保密工作负有领导责任，确保保密制度的执行。
2. 项目部员工应当严格遵守保密制度，不得泄露公司和项目部的商业秘密和敏感信息，以及与项目相关的机密文件和资料。
四、保密内容1. 商业秘密：公司关于技术、市场、经营等方面的信息、数据和资料，未经公司允许，不得外泄。
2. 敏感信息：与公司和项目相关的各类数据、文件和资料，包括但不限于合同、报价、设计图纸、施工计划等，未经允许，不得向外界泄露。
五、保密措施1. 项目部设立保密管理机构，负责监督和执行保密工作。
2. 所有员工在加入项目部之前，应签订保密协议，承诺不泄露公司和项目部的商业秘密和敏感信息。
3. 项目部内部设立保密物理区域，限制外部人员进入，并安装安全监控系统。
4. 项目部对每位员工的工作场所和办公设备进行监控，禁止随意带出公司和项目部的文件和资料。
六、保密违规处理1. 对于违反保密制度的行为，视违规程度轻重，采取相应的处理措施，包括口头警告、书面警告、停职、开除等。
2. 对于泄露商业秘密和敏感信息的行为，将依法追究法律责任。
七、保密培训1. 项目部应定期组织保密培训，提高员工的保密意识和技能。
2. 新员工入职时，应接受保密培训，了解保密制度和相关规定。
八、保密责任追究对于违反保密制度的员工，项目部有权追究其保密责任，要求其赔偿由此造成的损失，并保留向法律机关报案的权利。
九、保密制度的审查和修改本保密制度由项目部领导负责审查和修改，经批准后执行。
十、附则本保密管理制度自颁布之日起生效，并适用于项目部的全体员工。
如有违反本制度的行为，将追究相应的法律责任。
以上为项目部保密管理制度的范文，具体内容可根据不同公司和项目部的实际情况进行调整和完善。
建设工程项目保密制度及措施范本
一、总则为加强建设工程项目保密工作，确保国家秘密、商业秘密和个人隐私的安全，根据《中华人民共和国保守国家秘密法》和有关法律法规，结合我单位实际情况，特制定本制度。
二、保密范围1. 国家秘密：涉及国家安全和利益，依照法定程序确定为国家秘密的事项。
2. 商业秘密：不为公众所知悉、能为权利人带来经济利益、具有实用性并经权利人采取保密措施的技术信息和经营信息。
3. 个人隐私：涉及个人身份、健康状况、家庭情况等不宜公开的信息。
三、保密措施1. 组织管理（1）成立保密工作领导小组，负责保密工作的组织、协调和监督。
（2）各部门负责人对本部门保密工作负总责，明确保密责任人。
2. 人员管理（1）加强对涉密人员的保密教育培训，提高保密意识。
（2）签订保密承诺书，明确涉密人员保密责任。
3. 物质管理（1）对涉密文件、资料、设备等实行分类管理，明确保管责任人。
（2）设置保密室（柜），配备必要的保密设施。
4. 通信管理（1）涉密通信应使用专用设备，不得在非涉密通信中传输涉密信息。
（2）禁止在互联网、社交媒体等公共信息网络发布涉密信息。
5. 网络管理（1）建立网络安全管理制度，加强网络安全防护。
（2）对涉密信息系统实行分级保护，确保信息系统安全稳定运行。
6. 项目管理（1）在项目立项、实施、验收等阶段，严格执行保密审查制度。
（2）对项目涉及的秘密事项，采取必要的技术、管理等措施，防止泄露。
四、泄密处理1. 对泄密事件，立即启动应急预案，采取有效措施，防止事态扩大。
2. 对泄密责任人，依法依规追究责任，严肃处理。
3. 对因泄密造成严重后果的，依法追究刑事责任。
五、附则1. 本制度自发布之日起施行。
2. 本制度由保密工作领导小组负责解释。
3. 本制度如有未尽事宜，由保密工作领导小组根据实际情况予以补充和完善。
项目部保密管理制度范本（四篇）
项目部保密管理制度范本第一章总则一、为维护公司的合法利益，保障公司长期稳定发展，促进项目的顺利进展，特制定本规定。
二、公司秘密是关系到公司的权利和利益，依照特定程序确定，在一定时间内只限一定范围人员知悉的事项。
三、项目部所有人员都有保守公司秘密之义务。
四、公司保密工作，实行既确保秘密又便利工作的方针。
五、对保守、保护公司秘密及改进保密技术、措施等方面成绩显著的部室或者职员实施奖励。
六、本制度由项目部办公室负责实施。
第二章保密范围一、项目进展中重大决策的事项；二、项目发展战略的秘密事项。
三、项目所有生产工艺线的图纸设计、技术参数等秘密事项。
四、项目部掌握的招标资料、合同、协议、意向书及可行性报告、主要会议记录等；五、项目过程中尚未进入市场或尚未公开的各类信息。
六、项目财务预决算及各类财务报表、统计报表。
七、项目人员的人事档案、薪资待遇、劳务性收入及相关信息。
八、一般性决定、决议、通告、通知、行政管理资料等内部文件不属于保密范畴。
九、其他秘密事项。
第三章保密密级分为“绝密”“机密”“秘密”三级。
绝密是特别重要的公司秘山东寿光巨能生物蛋白项目部密，泄露会使公司权益和项目发展遭受到特别严重的损失；机密是重要的公司秘密，泄露会使公司权益和项目发展遭受到严重的损失；秘密是一般公司的秘密，泄露会使公司的权力和权益受到损害。
一、项目发展中，直接影响公司权益的重要决策文件资料为绝密级；二、项目的规划、生产工艺线的图纸设计、技术参数、财务报表、统计资料、重要会议纪要等视为机密级；三、项目档案资料、合同、协议、员工福利待遇尚未进入市场或尚未公开的各类信息为秘密级。
第四章保密措施一、项目人员须增强保密意识，不该问的不问，不该说的不说，不该看的不看。
二、项目部主任主抓保密工作，各小组负责人为本小组的保密工作负责人。
三、严禁私自携带外来人员随便出入项目建设区域。
四、秘密文件、资料和其他物品的制作、收发、传递、使用、复制、摘抄保存和销毁，由办公室主任或项目经理委托专人执行；采用电脑技术储存、处理、传递的公司秘密由有关操作人员进行保密处理。
项目管理理论知识
36
按计划流程管理项目
范围目标计划 人力成本,项目预 算 团队工作分解
项目发展
工作排序
37
战略与行动规划
拿破仑曾说:没有哪场胜仗是按计划取得,然而, 他会为每一场战役制定详尽的作战计划。 详细的计划应该是以终为始清晰的目标
2. 不是游动的
3. 列出她们
实施质量保证
开展规划确定的系统的质量活动， 确保项目实施满足要求所需的所有过程
实施质量控制
监控项目的具体结果，判断它们是否 符合相关质量标准， 并找出消除不合绩效的方法
13
2.6 项目人力资源管理
跟踪团队成员的绩效， 提供反馈，解决问题， 协调变更事宜以提高项 目绩效。 确定、记录并分派项 目角色、职责，请示 汇报关系，制定人员 配备管理计划
人力资源规划
项目团队组建
项目团队建设
项目团队管理
培养团队成员的能力， 以及提高成员之间的 交互作用，从而提高 项目绩效。
招募项目工作所需的 人力资源
14
2.7 项目沟通管理
沟通规划
确定利害关系者对信息与沟通的需求
信息发布
将所需信息及时提供给项目利害关系者
绩效报告
搜集与传播项目的绩效信息，包括状况 报告、绩效量度及预测
Don’t —不要担心以后的计划步骤（比如人员的配置）会左
右你的决定。
54
项目时间术语
CUS
SUP ET
CT
CT ET
CUS
`
40
团队与交流
J J J J J J J J J J J J
J J
团队越强大， 信息交流就 越广泛: N*(N-1)/2
41
插曲：团队合作考验游戏
建设项目保密管理规定(3篇)
第1篇第一章总则第一条为了加强建设项目保密管理，确保国家秘密和建设项目涉及的商业秘密、技术秘密、个人隐私等信息的保密安全，根据《中华人民共和国保守国家秘密法》、《中华人民共和国合同法》等法律法规，结合本建设项目实际情况，制定本规定。
第二条本规定适用于本建设项目涉及的所有单位、个人以及参与建设项目的第三方，包括但不限于设计、施工、监理、咨询、采购、运营等环节。
第三条建设项目保密管理应当遵循以下原则：（一）依法管理原则：严格按照国家法律法规和政策规定进行保密管理。
（二）分级管理原则：根据信息的密级和重要性，采取相应的保密措施。
（三）责任到人原则：明确保密责任，确保保密措施落实到位。
（四）宣传教育原则：加强保密宣传教育，提高全员保密意识。
第二章保密范围和密级第四条建设项目保密范围包括但不限于以下内容：（一）国家秘密：涉及国家安全和利益，按照国家秘密的密级划分标准确定。
（二）商业秘密：具有经济价值，具有保密性，涉及企业竞争优势的信息。
（三）技术秘密：具有实用价值，具有保密性，涉及技术创新的信息。
（四）个人隐私：涉及个人身份、财产、健康状况等个人隐私信息。
（五）其他需要保密的信息。
第五条建设项目信息的密级划分按照以下标准：（一）绝密级：泄露后可能对国家安全和利益造成特别严重损害的信息。
（二）机密级：泄露后可能对国家安全和利益造成严重损害的信息。
（三）秘密级：泄露后可能对国家安全和利益造成损害的信息。
（四）内部级：不宜对外公开的信息。
第三章保密措施第六条建设项目保密措施包括以下内容：（一）制定保密方案：根据保密范围和密级，制定相应的保密方案。
（二）签订保密协议：与参与建设项目的单位、个人签订保密协议，明确保密义务。
（三）技术措施：采用物理隔离、技术加密、访问控制等技术手段，确保信息保密。
（四）人员管理：对参与建设项目的相关人员开展保密教育培训，提高保密意识。
（五）保密检查：定期开展保密检查，及时发现和整改保密隐患。
项目实施保密管理措施
一、保密事项保密原则开展工作，在工作中将严格按照《中华人民共和国保密条例》执行，以确保项目中涉及到用户单位秘密以及我公司自身项目技术秘密的不对外泄漏。
（一）保密内容保密内容包括：项目技术方案、各类项目图件、档案资料、项目进度及开展方式、项目实施细节及用户单位要求保密的其它资料等，同时也包括工作区域内的保密。
（二）保密实施细则1.项目技术方案由技术起草者负责保管，对其它部门及外单位人员不得透露任何技术内容及细节；2.对使用单位的需求情况由项目负责人落实并保证不得向外界透露，并以书面形式传递项目人员和技术负责人；3.对项目参与的所有人员进行保密宣传教育，并签订保密协议；4.合同签订后的相关文档资料立即存档，并建立保密所必备的借阅制度；5.对民政局提供的街路地名标志名称等信息保密，未经允许不得公开或提供给他人。
（三）保密守则1.不该说的秘密，绝对不说；2.不该问的秘密，绝对不问；3.不该看的秘密，绝对不看；4.不该记录的秘密，绝对不记；5.不在非保密本上记录秘密；6.不在私人通信中涉及秘密；（四）保密承诺我方将接触贵单位的相关保密信息，为了保护贵单位的商业利益，我方特作如下承诺：我方承诺在以下几方面涉密的信息不得泄露。
我方在合作洽谈及业务过程中所获知的相关保密信息。
项目尽职调查过程中获得的信息。
我方在尽职调查过程中所获得的与项目交易基础资产相关的信息，包括但不限于资产信息、债务人及担保人的财务信息、财产状况信息等。
该项目的交易信息。
与项目进展、签署、执行过程中形成的交易结构、交易模式、交易文件相关的法律、商务信息。
（五）保密义务1.采取必要保密措施的义务我方承诺将采取一切合理的保密措施，妥善保管贵单位的保密信息，禁止任何与该保密信息无关的人员接触或取得该保密信息。
2.对外披露的书面许可义务未经贵单位的书面许可，我方承诺不以任何方式将保密信息公布、披露给任何第三方，或许可任何第三方使用上述保密信息。
3.确保有权人士遵守保密信息的义务我方有确保有权人士遵守保密信息的义务，就有权人士对保密信息的保密义务承担连带责任。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
成功项目管理的秘密(1)1. 定义项目成功的标准在项目的开始，要保证风险承担者关于他们如何判定项目是否成功有统一的认识。
经常，满足一个预定义的进度安排是唯独明显的成功因素，然而确信还有其它的因素存在，比如：增加市场占有率，获得指定的销售量或销售额，取得特定用户中意程度，剔除一个高爱护需求的遗留系统，取得一个特定的事务处理量并保证正确性。
2. 识别项目的驱动、约束和自由程度每个项目都需要平稳它的功能性，人员，预算，进度和质量目标。
我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在那个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你能够在一个规定的范畴内调整。
相关的详细信息，请参照我的《创建一种软件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。
3. 定义产品公布标准在项目早期，要决定用什么标准来确定产品是否预备好公布了。
你能够把公布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其它方面说明项目差不多达到了它的目的。
不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，同时与你的客户指的“质量”一致。
4. 沟通承诺尽管有承诺不可能事件的压力，从不作一个你明白你不能保证的承诺。
和客户和治理人员沟通哪些能够实际取得时，要有好的信誉。
你的任何往常项目的数据会关心你作说服的论据，尽管这关于不讲道理的人来说没有任何真正的防备作用。
5. 写一个打算有些人认为，花时刻写打算还不如花时刻写代码，然而我不这么认为。
困难的部分不是写打算。
困难的部分是作那个打算--摸索，沟通，权衡，交流，提问同时倾听。
你用来分析解决问题需要花费的时刻，会减少项目以后会带给你的意外。
6. 把任务分解成英寸大小的小圆石英寸大小的小圆石是缩小了的里程碑。
把大任务分解成多个小任务，关心你更加精确的估量它们，暴露出在其它情形下你可能没有想到的工作活动，同时保证更加精确、细密的状态跟踪。
7. 为通用的大任务开发打算工作表假如你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务开发一个活动检查列表和打算工作表。
每个检查列表应该包括那个大任务可能需要的所有步骤。
这些检查列表和工作表将关心小组成员确定和评估与他/她必须处理的大任务的每个实例相关的工作量。
8. 打算中，在质量操纵活动后应该有修改工作几乎所有的质量操纵活动，如测试和技术评审，都会发觉缺陷或其它提高的可能。
你的项目进度或工作细分结构，应该把每次质量操纵活动后的修改，作为一个单独的任务包括到里面去。
假如你事实上不用作任何的修改，专门好，你差不多走在了本任务的打算前面。
然而不要去希望它。
9. 为过程改进安排时刻你的小组成员差不多埋住在他们当前的项目中，然而假如你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时刻在过程改进上。
从你的项目进度中留出一些时刻，因为软件项目活动应该包括做能够关心你下一个项目更加成功的过程改进。
不要把你项目成员能够利用的时刻100％的投入到项目任务中，然后惊奇于什么缘故他们在主动提高方面没有任何进展。
10. 治理项目的风险假如你不去识别和操纵风险，那么它们会操纵你。
在项目打算时花一些时刻集体讨论可能的风险因素，评估它们的潜在危害，同时决定你如何减轻或预防它们。
要一个软件风险治理的简要的指南，参见我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。
11. 依照工作打算而不是日历来作估量人们通常以日历时刻作估量，然而我倾向于估量与任务相关联的工作打算（以人时为单位）的数量，然后把工作打算转换为日历时刻的估量。
那个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整要求，会议，和所有其它会让时刻消逝的地点。
12. 不要为人员安排超过他们80％的时刻跟踪你的组员每周实际花费在项目指定工作的平均小时数，实在会让人吃惊。
与我们被要求做的许多活动相关的任务切换的开销，显着地降低了我们的工作效率。
不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她能够赶忙做4个这种任务，假如他或她能够处理完3个任务，你就专门幸运了。
13. 将培训时刻放到打算中确定你的组员每年在培训上花费多少时刻，并把它从组职员作在指定项目任务上的可用时刻中减去。
你可能在平均值中早差不多减去了休假时刻、生病时刻和其它的时刻，关于培训时刻也要同样的处理。
14. 记录你的估算和你是如何达到估算的当你预备估算你的工作时，把它们记录下来，同时记录你是如何完成每个任务的。
明白得创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将关心你改善你的估算过程。
15. 记录估算同时使用估算工具有专门多商业工具能够关心你估算整个项目。
依照它们真实项目体会的庞大数据库，这些工具能够给你一个可能的进度和人员分配安排选择。
它们同样能够关心你幸免进入“不可能区域”，即产品大小，小组大小和进度安排组合起来没有已知项目成功的情形。
Software Productivity Centre( spc.ca)公司的Estimate Pro是能够一试的好工具。
16. 遵守学习曲线假如你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。
不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可幸免的学习曲线。
17. 考虑意外缓冲情况可不能象你项目打算的一样准确的进行，因此你的预算和进度安排应该在要紧时期后面包括一些意外的缓冲，以适应无法预料的事件。
不幸的是，你的治理者或客户可能把这些缓冲作为填料，而不是明智的承认事实确实如此。
指明一些往常项目不愉快的意外，来说明你的深谋远虑。
18. 记录实际情形与估算情形假如你不记录花费在每项任务上的实际工作时刻，并和你的估算作比较，你将永久不能提高你的估算能力。
你的估算将永久是推测。
19. 只有当任务100%完成时，才认为该任务完成使用英寸大小的小圆石的一个好处是，你能够区分每个小任务要么完成了，要么没有完成，这比估量一个大任务在某个时候完成了多少百分比要实在的多。
不要让人们只入不舍他们任务的完成状态；使用明确的标准来判定一个步骤是否真正的完成了。
20. 公布、公平地跟踪项目状态创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。
努力让项目在准确的、基于数据的事实基础上运行，而不是从因为可怕报告坏消息而产生的令人误解的乐观主义。
使用项目状态信息在必要的时候进行纠正操作，同时在条件承诺时进行夸奖。
这些提示不能保证你的成功，然而它们将关心你在你的项目上获得一个坚实的把手，同时保证你做了所有你能够做的事来让项目在那个疯狂的世界上成功。
Managing software projects is difficult under the best circumstances. Unfortunately, many new project managers receive virtually no job training. Sometimes you must rely on coaching and survival tips from people who have already done their tour of duty in the project management trenches. Here are 20 such tips for success, which I’ve learned from both well-managed and challenged projects. Keep these suggestions in mind during your next project, recognizing that none of them is a silver bullet for your project management problems.Laying the GroundworkTip #1: Define project success criteria. At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Some examples are increasing market share, reaching a specified sales volume or revenue, achieving specific customer satisfaction measures, retiring a high-maintenance legacy system, and achieving a particular transaction processing volume and correctness.Tip #2: Identify project drivers, constraints, and degrees of freedom. Every project needs to balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver aligned with project success, or a degree of freedom that you can adjust within some stated bounds to succeed. For more details about this, see Chapter 2 of my Creating a Software Engineering Culture (Dorset House, 1996).Tip #3: Define product release criteria. Early in the project, decide what criteria will determine whether or not the product is ready for release. You might base release criteria on the number of high-prioritydefects still open, performance measurements, specific functionality being fully operational, or other indicators that the project has met its goals. Whatever criteria you choose should be realistic, measurable, documented, and aligned with what "quality" means to your customers.Tip #4: Negotiate commitments. Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers and managers about what is realistically achievable. Any data you have from previous projects will help you make persuasive arguments, although there is no real defense against unreasonable people.Planning the WorkTip #5: Write a plan. Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is actually doing t he planning—thinking, negotiating, balancing, talking, asking, and listening. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project.Tip #6: Decompose tasks to inch-pebble granularity. Inch-pebbles are miniature milestones. Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate,fine-grained status tracking.Tip #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks, such as implementing a new object class, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he or she must tackle.Tip #8: Plan to do rework after a quality control activity. Almost all quality control activities, such as testing and technical reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. If you don’t actually have to do any rework, great; you’re ahead of schedule on that task. But don’t count on it.Tip #9: Plan time for process improvement. Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you’ll have to invest some time in process improvement. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don’t allocate 100% of your team members’ available time to project tasks and then wonder why they don’t make any progress on the improvement initiatives.Tip #10: Manage project ris ks. If you don’t identify and control risks , they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can mitigate or prevent them. For a concise tutorial on software risk management, see my article "Know Your Enemy: Software Risk Management" (Oct. 1998).Estimating the ProjectTip #11: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time, but I prefer to estimate the amount of effort (in labor-hours) associated with a task, then translatethe effort into a calendar-time estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.Tip #12: Don’t schedule people for more than 80%of their time. Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Don’t assume that just because someone spends 10 hours per week on a particular activity, he o r she can do four of them at once; you’ll be lucky if he or she can handle three.Tip #13: Build training time into the schedule. Determine how much time your team members typically spend on training activities annually, and subtract that from the time available for them to be assigned to project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.Tip #14: Record estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary, and it will help you improve your estimation process.Tip #15: Use estimation tools. Many commercial tools are available to help you estimate entire projects. With their large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff al location options. They’ll also help you stay out of the "impossible region," combinations of product size, team size, and schedule where no known project has been successful. A good tool to try is Estimate Pro from the Software Productivity Centre( spc.ca).Tip #16: Respect the learning curve. If you’re trying new processes, tools, or technologies for the first time on this project, recognize that you will pay a price in terms of a short-term productivity loss. Don’t expect to get the fabulous benefits of new software engineering approaches on the first try, so build extra time into the schedule to account for the inevitable learning curve.Tip #17: Plan contingency buffers. Things never go precisely as you plan on a project, so your budget and schedule should include some contingency buffers at the end of major phases to accommodate the unforeseen. Unfortunately, your manager or customer may view these buffers as padding, rather than the sensible acknowledgement of reality that they are. Point to unpleasant surprises on previous projects as a rationale for your foresight.Tracking Your ProgressTip #18: Record actuals and estimates. If you don’t record the actual effort or time spent on each task and compare them to your estimates, you’ll never improve yo ur estimating approach. Your estimates will forever remain guesses.Tip #19: Count tasks as complete only when they’re 100% complete. One benefit of using inch-pebbles for task planning is that you can classify each small task as either done or not done, which is more realistic than trying to estimate what percent of a large task is complete at any time. Don’t let people "round up" their task completion status; use explicit criteria to tell whether a step truly is completed.Tip #20: Track project status openly and honestly. Create a climate in which team members feel safe reporting project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that sometimes arises from fear of reporting bad news. Use project status information to take corrective actions when necessary and to celebrate when you can. These tips won’t guarantee success, but they will help you get a solid handle on your project and ensure that you’re doing all you c an to make it succeed in a crazy world.。