Sunday, 31 January 2010 00:00

CIOs Are Fired For Failing to Provide Business Value

Rate this item
(0 votes)

CIO Thinking, by Geek and Poke

CIOs have two major responsibilities—keeping IT's lights on (backups, networks, email, etc.) and providing support for business initiatives. Being mediocre at either will make for a short career. Although the respective budgets are normally a 70:30 split, a CIO will be fired in a minute for failing to properly support the 30%. That portion of their budget actually generates the company money. Keeping the lights on is a thankless job. People simply expect networks run, data served, and viruses inoculated. It is expected much as we expect water when turning on the tap. Supporting business initiatives is just as thankless since 60% of projects seem to always be in trouble.

I am not pulling out the pompoms cheerleading to keep CIOs gainfully employed. I like seeing a job done well. Like all good CIOs, I know they need me just as badly as I need them. I bring the contrarian view that projects cannot be commoditized or successfully completed using some formula. Managers find comfort in the idea that ensuring projects stay within their initially defined scope, schedule, and budget means a successful delivery. Unfortunately, it is not quite that simple. Even making project targets does not guaranteed success. Many projects meet their targets and fail to provide adequate value. Poorly understood requirements, even if well defined, deliver solutions with no value. The path out of this is to accommodate change. For too many IT shops, change translates to time and time into money. Without the right mind set, IT will require significant delays and increases in funding.

It is quite reasonable to pay for design changes in anything. The desire is to minimize cost by encountering the changes as early as possible. For most IT projects, the only time the customer sees the value, or lack thereof, of what is being built is near the end of the project when they can work with the product. IT shops need to think like the business. To change this, business solution providers must focus on four basic traits—agility, communication, responsiveness, and cooperation.


Nothing is static. Business environments change faster than a teenager's clothes before a hot date on Saturday night. Initiatives must change at the same speed. People and the projects must be involved with, accommodate and encourage this change. They need the ability to adapt and change to new business situations.

Look for alternatives for the solution. Do not assume the goal is to make the most robust long lasting system, look for tactical options, objectively propose them, and let management make the decision. Create smaller, more agile projects with highly structured products that are easier to subdivide and build. Reducing complexity improves success rates, expedites delivery, and accommodates change.


Communication is a Two-Way Street

Communication is a two-way street. Direction comes from above and questions flow the other direction. The longer the communications chain the greater chance for the wrong message being delivered or questions getting garbled answers. Lean, low overhead organizations ensure what is being asked matches what is understood. Too many organizations with layers of management send orders to the troops and never provide the opportunity for questions to be answered. Managers assume that the direction is understood and workers think they are doing what is required to meet the concept.

This is true with the customer, too. Changes cannot be accepted unquestioned. Customers and suppliers must work together to determine the best solution to problems as they arise. Communication and cooperation are critical.


Being responsive means providing. To respond without provide something is failing to respond. What better to provide than value. Every action should have its focus on providing value. Functional specifications and test scripts are not value; they are tools on the road to providing value. Product provides value. Responsive teams need to supply the customer with examples, prototypes, mockups, or early versions so everyone understands a common view of the goal.

Deliver solid product with only a few features as early as possible followed by rapid deliveries of new versions with more features. This keeps the focus on the value and away from frills.

Want to read more?

Strategy, alignment, communication of goals is not easy. Our Vision To Value white paper talks about focusing your team on the key strategic corporate goals and ensuring everyone in your organization knows the direction.


Nothing is worse than a house divided. Every day project teams struggle to understand requirements, translate those into a product, and deploy that product on the IT infrastructure. They are the translators between the technical and the tangible. The only tool to make this work is cooperation. All problems are rooted in ill-defined requirements, poorly translated needs, and inadequate infrastructure.

Project teams forget they have the luxury of focusing a relatively confined system. The customer and infrastructure teams are less fortunate. They have vastly complex systems. Small alterations in these systems can have ripple effects throughout. Networks must accommodate dozens of varying applications, while customers have the whims of human nature and billions of imaginative minds looking for new ways to conduct business.

Open and honest brainstorming with a concise discovery plan that arrives at quick answers is the solution. People must be praised for resolving issues rather than berated for having to fix their problem.

As the adage goes, people need to do what they say and say what they do. It is no accident that next week's blog, discussing project heroes, will have cooperation as the primary trait of every hero.

Supporting the CIO

CIOs may be fired for non-delivery, but they are really getting a just reward for failing to build an organization that exhibits these traits. They need to band with their peers to build a culture that is agile, communicative, responsive, and cooperative. One where it is everyone's job to ensure every project delivers value.

Read 5995 times

Related items

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).

  • Project Inception - Designing Organizations For Success

    Buy it now!

    A failing project’s fate is destined long before assigning a project manager. Its doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. In actuality inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could...” From that point forward the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradig.

Leave a comment

More Info on Project Recovery


Please send me more information on fixing a failing project.

Made with BreezingForms for Joomla!® by Crosstec

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References