CIOs Are Fired For Failing to Provide Business Value
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. 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.
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.