公司各种职位里，大概没有比CIO更有难度的了。CIO们不仅在技术项目中会遇到各种各样的问题，如何让业务部门接纳并认可项目的机制也成了挑战。可以说，研究应该如何确保事情进展顺利是每个人的本能。但在这之前，需要CIO们再想想有哪些“坑”总是让你“踩了又踩”。
受到技术的“蛊惑”
大多数CIO都拥有技术类背景，因此他们很自然的会想要参与细节层面的技术问题研究。但是，CIO这项工作要求的是宏观层面和战略性层面上的技术理解，而非对技术细节的解决能力，具体的技术细节应该有专门的技术人员负责处理。
如果一位CIO不能做到这点，那么他不仅不能提升团队效率，还有可能出现帮倒忙的情况，给公司业务带来风险。企业需要的是一名懂得指挥技术人员解决商业问题的CIO，他们并不关心你是否会使用C++。
使用微观管理法
在边缘化工作岗位了几年之后，许多CIO们开始渴望回归重新参与到IT工作中。有些CIO甚至离开办公室，对其下属的部门经理重新开始了微观管理，而不是给与指示放权管理，让这些部门经理们能够真正管理起自己的项目。
如果你发现自己也有类似想法，请务必要及时制止。你应该扮演的角色是给与这些部门经理应有的支持，做足够的“巡视”和审查工作，确保项目正常运转，而不是过分介入亲自处理每一件事。
低估最终用户体验的重要性
由于CIO们常常与技术打交道，因此他们往往把重点放在项目的主要技术上，为了能够让业务正常运行，应用程序的研发也经常要依赖于这些技术。包括数据库结构、操作系统和网络性能等等。然而，即使这些元素都在最佳的状态下运行，应用程序的推出依然也会面临失败的情况，这是因为应用程序的用户界面和最终用户体验(EUE)的设计有误。
CIO们往往都低估了这两个因素的重要程度。为了避免出现EUE层面的失败，CIO们可以招聘一些熟悉用户体验和应用程序设计“人为因素”元素的IT人员参与程序的研发工作。
“宅”在办公室
上面提到有的CIO渴望重新操刀项目细节管理，当然也就有CIO极度享受办公室的“宅生活”方式。
永远不要假设项目管理报告汇报的项目状态是百分之百正确的。要确保IT项目工作顺利进行的最好办法就是走出你的办公室，和基层工作人员及管理人员建立起融洽的关系。通过观察他们的肢体语言以及谈话内容，你可以获得更为准确的项目进展程度信息。通常，你都可以在问题被写进项目状态报告之前，通过这样的交流沟通及时发现问题。
成为一名控制狂
IT人员天生就要受到上级的约束。这点CIO们十分了解。但是如果你打算管控能够促成项目成功的经理人员，或是培养最终用户和他们的客户经理之间的信任关系时，你可能会发现你不得不放弃这种想法。
许多CIO都希望能够在技术项目中抓住控制权，特别是当他们拥有类似项目经验(经常负责这类项目)的时候。但较好的办法是，向你的下属展现出一点点的耐心和宽容。允许他人参与并表达自己的想法。
不再重视QA
应用程序和系统的成功推出，很大一部分是取决于应用程序和系统完善的测试工作。这种测试工作应该基于单元测试和集成测试、最终用户体验、以及回归测试和压力测试。
由于许多CIO都来自应用程序开发部门，因此他们对诸如质量保证(QA)等系统和应用程序的测试流程带有一种天生的不耐烦心态。这样，项目的时间表往往强调了应用程序的开发时间，而缩短了保证QA工作的时间进程。在项目架构中千万不要有这种倾向。你同样也需要为QA人员留有充足的时间和应有的支持。相信这样你一定能够从完善的应用程序和系统产品中得到丰厚的回报。
从不改进IT部门奖励机制
虽然IT成功的许多基本准则和方法都基本保持不变，但其中一些准则和方法却悄然发生了变化。现在，人们对良好的用户体验、IT服务文化的提供、一切以客户为中心的理念具有越来越高的期望值。
此前，IT领域的机制缺乏可靠性和CIO的支持，包括培训、质量保证、人为因素工程方面的应用程序设计以及帮助台的服务响应。如今，这些因素都跑到了专注于服务和质量的IT SLAs(服务等级协议)的前端。
但仅仅通过衡量工作人员的表现情况来完成这些SLA的标准是完全不够的。对于IT人员来说，金钱和晋升机会才是最重要的。如果一名优秀的QA人员，或是一名培训讲师，或一名人为因素分析师在其IT机制中没有得到任何的职业发展空间或加薪机会，那么他们或将选择离开，或将选择进入传统的“高回报”领域，如应用程序开发或数据库领域。
