混乱
象大多数的故事一样，这个故事也发生在很早以前。但是当我谈起它的时候，伤疤依然疼痛。我曾经在一个软件开发团队工作过，这个团队拼命的想生产一个产品，或者是只要能使用的任何东西。由于过去项目的失败，这个团队尽管许多基础建设已经到位了，但是却缺乏成功的向导和迹象。你可以说这个团队存在，但是缺乏清楚的组织结构和许多达到成功的必要的商业要素。这个团队的使命和眼界被一个受过良好教育，可是很可能没有经验的新领导人弄得墨成一团。
至于商业需要，它们一直在那儿。幸运的是，操作系统满足了稳定的最小需要。但是同样遗憾的是，这些系统并不能适应快速改变的环境，而且在许多年后，也超过了它们的平均寿命。为了替换这些老化的主机，执行者提出了一系列的 “改进创新”。执行这些创新对开发团队而言，几乎不需要优先级考虑并且甚至只需花费更少的钱。
许多内部的项目不过是在重复着劳动和竞争。“买一套ERP软件，定制它来满足我们的需要”，“为什么我们要重新发明轮子呢”。那些是来自团队内的经常的喊声，也是一个来自企业失败项目的教训。经过了与巧舌如簧的销售人员一道玩若干回高尔夫和共进几次两小时的午餐的结果就是为一套ERP软件投资几百万美元。但是那只不过是买License的花费。
模型、标准和认证
“我喜欢用老软件，为什么我一定要改变？”，用户、软件开发人员、需求分析师、项目经理和股东都面临着对即将到来的变化的相互间的抵制。
明显的，需要正规的项目管理。而执行管理层选择了CMM作为银弹工具。“只要这样一个基础组织就位，所有的项目就可以成功的、一致的完成。我们需要工作组在6个月之内达到CMM2认证。”起先，这些指令都被忽略或者轻视，但是执行管理层通过中层管理者的奖金来施压。
通过和一个成熟的开发团队的比较来提高自己看起来比填写一个空白的过程文档更容易。复制他们的制度和过程看起来也是一条可以达到CMM检查表的捷径。“让我们改变这些文档的页眉、页脚，拿来为我所用。”由于执行者又要实施另一种模型ISO9001,所以这个策略并没有起到作用。从这个前提出发，“文档化你所做的，并根据你的文档去做事”，一条粗线被画在了文本流程和实际操作之间。
在运用了CMM差距分析检查表后，这些结论发展成为了一个CMM项目计划。因此什么是这个团队应该建造的呢，过程或者产品？项目计划和项目跟踪与监控的关键过程域的执行逐步演化成了现存的项目办公室。但是却遗失了执行这些过程的技巧。
咨询的角色
组织了解了越多的成功的开发团队，他们就需要越多的启发，使他们能够看到“隧道的尽头”。他们不得不补充工作团队的技能。“求你告诉我们为什么我们的小孩这么丑陋。但是如果我们放弃了，我们要回到项目的混乱状态去。”于是他们花费很大的价钱请咨询机构来调查。在预算被耗尽的几个星期之后，他们拿出了一个报告，描述了他们需要什么样的过程和技能。但是如果没有一个有悟性的讲解员去把这些咨询报告翻译成简单的操作，那么这份报告就好像讲给聋子听了。
为了增加复杂度的层次，不断变化的公司战略和新的创意压迫着全方位的预算。当这个团队对增加一点又减少一点这样反反复复的投资提供感到气急败坏的时候，他曾寻找过促进项目管理知识交流的更划算的方法。有一个方法就是去补充合同制的雇员。这个策略持续了一段时间，大量的知识在领导、项目管理专业人员和以前公司的雇员间交流。这个方法看起来能满足目标。但是在大多数的团队里，个人冲突是屡见不鲜的，并且很可能这个项目的领导被要求离开。在招聘某个替代职位的过程中注意到一些个人的特点将会得到一个更能与团队协调的候选人，但是雇佣期会比较短暂。当预算同市场的薪酬等级相比，不具有竞争力时，“别处的牧场更绿”。更多的尝试提供了更多的回报，并且知识交流还在继续。
自我与策略
很多执行主动性与指示或与一般理解互相冲突。这种冲突之一可以是当项目过程需要资金和人员支持时，发现追加预算和人员已被冻结。在此例中，“起伏波计划编制”允许“现实主动性”超出现有项目的预算。同样，许多软件解决方案至少在服务器结构上受限于共同的“摒弃微软哲学”。在那时，今天亦如是，软件商销售中间产品，数据库软件升级到视窗系统，而很久以前则是把应用程序接口到不同品位的UNIX。关于微软服务器在共同结构上的使用，“通用技术结构总署”强制推行美国产业工会联合会标准的认可程序。
悦耳的讲座
一个关键项目与项目部的发起人离开了，使推进要素停止运行了一段时间。替补执行者带来了很好的经验财富，如同一个出色的发起人一样。但是，进行了一年以后，法人层又进行了改组，那位经验丰富的人选成了一位赌金保管员，而不再是主管。在一个新的组织结构和运行环境下，开发小组发现他们服务于同样的客户，而且更多了。这导致了执行委员会成员的变化，关键优先权置实体于变化控制程序。期间，此属于“企业资源计划”的公司与同组织一个大的公司结合，并改变了联系和方向。这种结合将涉及一个导致大部分结构重新设设计的工程
今天的基线
组织结构是一个脆弱的矩阵，由职能经理构成，他们保持预算并使前景复杂化。虽然项目节奏一直在变化，但它持续地受到项目管理小组监督并在需要时向任何一位汇报。该小组当前全部由法人和合同专业人员组成，他们为客户提供产品的文件。有着如下领域：变更，风险，范围管理的项目管理机构，小组正在由项目向客户需要的交付项目转变。但缺少了什么呢？
何去何从
今天，项目部严格地关注于项目。日常变化例如“企业资源计划”软件结构影响了许多项目和大量的产品发布。小组正缓慢地朝着部门领导靠拢，但项目内部依存的概念却相去甚远。这种观点将为项目部的管理者提供一个清晰的理解本部门内部所有项目变化带来的的影响
自从关键人物掌握了许多项目所需的能力，人力资源混乱是经常发生的。交叉训练，合同资源以及任务思考的主动性正在进行但却未列入进度表。
如果这个软件开发团队要稳定发展，他们的成功依赖于高效的信息传递和领导能力。这一点的确重要，因为这个团对已经是销售、市场和信息服务行业中的一分子了。新的企业领导来源于市场杠杆的调解。一些人预言研发小组要能按市场需求，适时地生产高品质的产品。然而那是矛盾的吗？
您的位置：
