关于项目质量
最近做了一个项目,质量说实话堪忧。
项目开始的时候还是规划的很好的。预算不说充足至少是够用,所以人员配备也不错,项目计划按正常出。一切看起来都很美好。
计划阶段开始出现问题。首先是客户承诺交付的需求和设计无法交付,只能给一个非常粗略的框架图。然后是项目时间计划,由于项目的采购阶段延误,但是验收时间不愿意延迟,导致项目要分阶段上线。在最开始的阶段需要上线MVP,剩下的功能,由于其中一部分需求不成熟,要再分两期上线。整个项目上线时间变成三次。
最近做了一个项目,质量说实话堪忧。
项目开始的时候还是规划的很好的。预算不说充足至少是够用,所以人员配备也不错,项目计划按正常出。一切看起来都很美好。
计划阶段开始出现问题。首先是客户承诺交付的需求和设计无法交付,只能给一个非常粗略的框架图。然后是项目时间计划,由于项目的采购阶段延误,但是验收时间不愿意延迟,导致项目要分阶段上线。在最开始的阶段需要上线MVP,剩下的功能,由于其中一部分需求不成熟,要再分两期上线。整个项目上线时间变成三次。
上篇提到了两个教训跟理所当然的假设有关。我们可以很笼统的把他们归结为沟通不到位。但哪怕很主动沟通的项目经理也经常会问,我需要沟通什么?假设的验证就是一个很重要的内容。
项目中的假设是什么?按定义,假设是那些你认为是真实的事情:那些你认为以后会发生但还没有发生的事情,你觉得是真实的业务事实尽管你并没有证据。然而记住,我们不把这个叫拍脑袋,我们管这个叫Educted Guesses。
今天聊一聊项目管理中的容易踩的大坑,那些看得见的、看不见的、认为是理所当然的假设。
这个话题分两篇,第一篇先给大家分享两个让我印象深刻的经验教训。
第一个是之前有一个项目,系统需要与一个其他系统进行对接,需要对方系统给我们开几个API接口。
在项目初期,对于这个数据交换需求与那个系统的技术同事做过初步对接和可行性评估,评估的结果是大概开几个接口,技术也可实现。于是项目就愉快的推进了。
在网上看到一个数据,只有15%的项目经理一次只需要负责一个项目,其他的项目经理都需要同时负责多个项目,甚至有15%的项目经理一次需要负责10个以上的项目。
我在工作中,也只有很少很少的时间里,是一次性只负责一个项目。
同时负责很多个项目会产生一些需要克服的困难,比如最明显的如何在不同的项目中分配自己的时间和精力,如何同时满足不同客户的不同需求,如何在不同项目之间分配资源,等等。
项目:某客户离岸油田平台的设备制造项目,项目包含设计、制造、测试阶段。
时间:距离第一阶段设计评审还有8周
事件:由于公司在接下来的一个月现金流紧张,公司总裁突然要求项目经理将项目的设计评审提前2周,并提前2周拿到第一阶段报酬。项目经理承诺3天内给公司总裁答复。
分析当前情境 总裁离开后,项目经历仔细分析了这件事情的严重性和当前情况。
项目经理第二天与团队成员开会,讨论当前情况并得到了很多有用的建议:
I’ll also post case study on this topic from my work practice. Stay tuned.
Definition:
Issue
A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements
Issue Management
Issue management, therefore, is a planned process for dealing with an unexpected issue. – Project Issue Management
Difference between issue and risk
An issue is something happening currently, a risk is something that might happen in the future.
Impact of an Issue:
Deliverables
Baseline
Project Failure
Goal of Issue Management:
The goal of issue management is to provide a formal structure for identifying, recording, managing, and tracking issues through to resolution to minimize any negative impacts to the program
Who will perform the Issue Management:
For some articles said it’s the responsibility of PMO. I’d say sure it is! But I’d also emphasize that Project Manager is the primary responsibility for a project, therefore he/she is the primary responsibility for the issue management of the project.
Tools and Techniques:
Issue Log
Process:
Identify issues -> Log and assessment -> Assign respond -> Investigate -> Design solution -> Implement solution -> Resolve issue -> Close Issue
In the meantime:
Regular review
Determine if need to escalate to higher management team
Stakeholder communication
Role and Responsibility:
PMO and PM, responsible for issue management
Assignee, sole person accountable for the issue
Priority Define:
High: If the issue is business critical and is a “show stopper” (Due date must be identified and logged)
Medium: If the issue is business critical, but has a clear and timely resolution path
Low: If the issue is not business critical but needs resolution at some point
– Infosys training
Escalation level:
Level I: Issues are resolved and documented by the project team and/or work team. Decision deadline: up to one (1) week.
Level II: Issues that cannot be resolved at the project team management level are submitted to the project director for review with the project team management. Decision deadline: up to one (1) week.
Level III: Issues which cannot be resolved at the project team management level, or which are so sensitive as to require executive approval, will be submitted to the steering committee, for resolution. Decision deadline: up to 14 days.
Level IV: Issues which cannot be resolved at the steering committee level are submitted to the Project Sponsor for review with senior management. In addition, an issue can be escalated directly to Level IV based on issue criticality.
– PMO handbook (www.pmi.org)
Issue Log (Template Download):
Ref#: the sequence number of an issue
Priority: the defined priority of an issue
Submit Date