我想知道有多少人(项目经理和技术主管)使用WBS(工作分解结构)进行项目规划?我听说这是一件好事,但是有很多"好事"要做,但最终还是没有用.
这对项目规划真的有帮助吗?如果是这样,那么正确的做法是什么.可能一些链接/文章可以帮助.
请记住我不是项目经理,但有时我必须完成他的任务.
在传统的项目管理中,如果使用正确,WBS是一个非常宝贵的工具.
我总是以自上而下的方式完成它,从大部分工作开始:
用户界面
后端
数据转换
并简单地深入到更具体的水平
提款交易的数据输入屏幕
查询以获取用户历史记录
将STATS12表从1.1版转换为1.2版
直到工作分解结构中的每个元素都小于报告期.
我的意思是,如果我必须每两周向链上报告一次进展,则不允许任何单个元素超过估计的大约八天.如果是,则需要进一步细分.
这具有以下主要有益效果:
如果大多数估算是正确的,我可以在每次会议上报告进展情况 - 这对于PM来说总是很好看:-).
较小的工作总是比较大的工作更容易准确估计.
落后于时间表变得非常快.
保存估算的历史数据及其对现实的最终准确性,为下一周期提供更多详细信息,以便您可以智能地调整估算.
最后一点在未来的估算中很重要.例如,如果Sam持续低估用户界面作业10%,那么您知道将来会提高这些估算值.
这应该发生在IMNSHO,否则你的PM工作比工程更具猜测性/黑魔法.
对不起,我真的无法为你提供任何链接,因为这主要是多年从事这个角色所获得的经验.我可以访问很多链接以使其更容易,但它们是公司内部的(我们足够大,可以使用我们自己的方法).
WBS当然可以帮助您规划项目.它们对于确保您的赞助商和团队成员正在查看同一个项目特别有用,尽管可能只是在不同的级别.
工作结构是您将在项目中进行的工作的地图.应该使用WBS来一致地解释您将要实现的目标,如何实现目标,需要多长时间以及需要花费多少.
WBS不会自行完成所有这些工作,但它是规划项目的早期构建块之一.在定义/验证项目范围后,通常会创建WBS.您需要详细说明范围,因为您的WBS将从您的可交付成果中删除.
创建WBS是一个自上而下的过程,您可以在其中获取可交付成果列表,然后将其分解为工作包.如果您正在创建一个新的财务系统,您可能会有几个可交付成果;
1. General Ledger 2. Journal Interface 3. Account Payable module 4. Accounts Recievable module 5. Bank Interface 6. Reporting
上述可交付成果将构成您WBS的顶部.
1.0.0 General Ledger 1.0 Transaction Ledger 2.0 Accounts Maintenance 2.0.0 Journal Interface 1.0 Journal creation 2.0 Journal review 3.0 Journal update 4.0 Journal deletion 3.0.0 Account Payable module 1.0 AP Invoice creation 2.0 AP Invoice review 3.0 AP Invoice update 4.0 AP Invoice deletion 4.0.0 Accounts Recievable module 1.0 AR Invoice creation 2.0 AR Invoice review 3.0 AR Invoice update 4.0 AR Invoice deletion 5.0.0 Bank Interface 1.0 Generic Payment interface 2.0 ANZ Bank interface 3.0 Westpac Bank Interface 4.0 Commonwealth Bank interface 6.0.0 Reporting 1.0 Trial Balance 2.0 Balance Sheet 3.0 Operating Statement 4.0 Invoices Pending
(注意:编号系统很方便.例如:您将知道6.3.2是创建操作语句报告的第二项任务.)
然后,您将继续将它们分解为工作包,每个工作包需要4小时到5天才能完成.完成WBS后,您可以让您的团队成员或专家估算每个工作包(任务)从下到上需要多长时间.这些估算将帮助您计划与WBS和商定的原始范围一致的初始计划和预算.
为什么这样?有几个原因,第一个是易于沟通.您的估算人员需要低水平的工作包(即:4小时到5天)才能准确估算.但是您的赞助商需要高水平的具体可交付成果来评估您的日程安排和预算.通过早期决定WBS,您可以实现这两个目标.
通过使用一致的WBS,赞助商可以查看您的日程安排和预算,并将其与原始计划联系起来.他们可能会认为4.0.0不值得付出努力.这是从您的可交付成果中转移出来的WBS的责任,您的赞助商只需要查看第一级就能了解正在发生的事情.
如果您在早期定义WBS,您的赞助商,您的早期团队成员和其他利益相关者可以看到他们参与的内容,也可能发现项目中缺少的内容.上面的一个例子中很多人都很容易让专家在你开始之前发现并修补这些漏洞.
这里的关键点是;
1. Create your WBS from your deliverables 2. Break the WBS down into work packages between 4 hours to 5 days long 3. Estimate on the work packages 4. Report your schedule against the top level(s) of your WBS 5. Report your budget against the top level(s) of your WBS
复杂(即:成本高或风险高)的项目通常需要另一个步骤.大型项目或具有高风险概率的项目通常是分阶段的.这仅仅意味着将您的可交付成果分组为最高级别.每个阶段都应该产生可衡量的东西,让你的赞助商决定是否继续.这样你就可以避免大爆炸的方法.在进入下一阶段之前,应该判断每个阶段是否完整,经验教训等.大型软件开发,构建和构建都是以这种方式完成的,实验项目也需要仔细监控,因为成功可能无法保证.
上面的同一个项目分为几个阶段;
1.0.0.0 Phase 1 1.0.0 General Ledger 1.0 Transaction Ledger 2.0 Accounts Maintenance 2.0.0 Journal Interface 1.0 Journal creation 2.0 Journal review 3.0.0 Reporting 1.0 Trial Balance 2.0.0.0 Phase 2 1.0.0 Journal Interface 1.0 Journal update 2.0 Journal deletion 2.0.0 Account Payable module 1.0 AP Invoice creation 2.0 AP Invoice review 3.0 AP Invoice update 4.0 AP Invoice deletion 3.0.0 Reporting 1.0 Balance Sheet 2.0 Operating Statement 2.0.0.0 Phase 3 etc etc etc
您的WBS应该与您的可交付成果有明确的链接,您可以使用分阶段进行复杂的项目.无论哪种方式逻辑是相同的,继续分解您的WBS,直到您拥有最低级别的工作包,这些工作包是可以在4小时到5天内完成的具体任务.您和您的团队成员需要专注于完成工作包,但是您和您的赞助商将专注于监控和控制WBS的前一个或两个级别.
编辑: WBS不应该一直到任务.我已经在任务和WBS上发布了一个更清晰的例子.