Posts in category: Uncategorized

CIO Magazine has an archive of issues stretching back to 1994.  If you want to know what’s been on the minds of IT leaders over the last decade, CIO Magazine is a definitive source.  Notable among their works are the CIO Surveys.  After a decade of unparalleled innovation in computing, one might expect that the role of the IT leader has changed quite a bit, so I found this interesting:

In 1995, CIO’s reported that their number one priority was aligning IT and business goals. 
In 2005, CIO’s reported that their number one priority was aligning IT and business goals.

Allow me to illustrate the term “Alignment” for all the non-CIO’s out there.  Let’s say you’re in IT professional and you’ve been told to change a hard drive.  Instead, you choose to play Solitaire.  Your goals are not in “alignment” with the business goals.  Go ahead and extrapolate.

78% of the time, I have no sympathy for the 78% of the organizations that get absolutely zero value from their IT.

The truth is not quite so ludicrous, but certainly related.  What CIO’s are really trying to say is that they often don’t know what the goals of the business are, nor are they able to influence the organization in ways that would maintain continuity for IT, so they “think” they are doing the job, only to find out that they are not.  CIO’s feeling this way are either a victim of poor management, or are the poor management… and I am inclined to agree with both statements.

I return to the mantra, “IT is a reflection of the organization’s values“.  If IT is not a valued component of the business, those who hire the IT leaders will favor certain aspects of an applicant over aspects that would more readily serve the organization.  Once that happens, all bets are off.

In well-defined roles, it’s easier to find the best candidates.  COO’s, CFO’s… etc… there are time-honored benchmarks by which one can find people who create the best value for the organization.  There are no such benchmarks for hiring IT leaders, and even fewer for measuring performance.  So, organizations gravitate toward “general executive qualities”, which may or may not have anything to do with the job of managing the organization’s IT group.  That’s where the problem starts.

In CIO Mag’s 2006 Survey, despite the fact that 3/4 of CIO’s report an IT background, CIO’s overwhelmingly report that the skills most pivotal for their success are “Ability to communicate effectively” (70%) and “Strategic planning” (59%).  On the opposite side of that is “Thorough knowledge of technology options” (22%), “Negotiation Skills” (12%) and “Technical Proficiency” (12%).

Now, keep in mind that this survey question was “choose all that apply“.  Which means that 78%  of the #1 technology professionals in their organizations DO NOT believe that knowledge of technology is important enough to their jobs to even check the box.  Whaaaa….???

Imagine your CFO saying “Finance?  Not important.”… Or a contractor saying “I don’t need to know about building houses, I’ve got people for that.”…

And yet, these CIO’s are correct… knowing about technology actually isn’t pivotal to their “success”, insofar as it relates to going up the ladder 78% of the time.  This is why, 78% of the time, I have no sympathy for the 78% of the organizations that get absolutely zero value from their IT.

The CIO’s job can be summed up very briefly:  “To make technology available to the organization.” This is not to say that the CIO has to be the technical god of the group.  But the CIO is the person who has to make recommendations to the Executives, so if the CIO isn’t a champ at evaluating technology options, at knowing the critical questions to ask and at maintaining a relevant base of knowledge… even the best communicator, leader, planner in the world will still be a completely incompetent CIO.

I think there is at least some support for this argument based on the Survey’s 10 “Biggest Barriers to Job Effectiveness”.  Among these, CIOs report above all “Overwhelming backlog of requests and projects.”… “Shortage of time for strategic planning“… “Unrealistic/Unknown expectations from the business“… “Lack of alignment of IT and business goals” and “difficulty proving the value of IT“.

So, a CIO’s #1 priority is to align IT and Business goals, but it’s the biggest problem that prevents them from being successful.  That’s like someone who hangs drywall for a living saying “my biggest problem is falling drywall”… very disconcerting.  70% of CIO’s prize their ability to communicate effectively, but they find it difficult to prove the value of IT.  Many value their strategic planning skills, but have no time to do it.  But more importantly, with such low concern for technological competency and negotiation skills, is it any surprise that the requests and projects are out of control, and the expectations are so hard to manage?

Of course not… that’s why those things are a perpetual plague in the IT industry.

Now don’t go running to your CIO saying “this guy thinks you suck”.  This isn’t the fault of the CIO.  Every CIO I have met has been smart, engaging, and brimming with positive leadership qualities.  Damn fine people.  Many just lack very critical qualities that create big problems for an IT organization.  But CIO’s are hired based on the values of the organization, and as organizations begin to value IT more, more IT-critical qualities will be used to judge those they hire.

You don’t have to be an IT professional long before you see the big disconnect between what organizations want, and what they value.

How do you know organizations don’t value IT?

Deloitte conducts a CFO Survey. Interestingly, Controlling costs and providing better information to support the business are the two highest rated priorities, while Enhancing Information Systems barely registers on the chart. I’m not sure what accounts for those numbers… maybe they want to hire Scribes.  Additionally, CFOs report that “Implementing new technology” is the least of the main challenges facing the business.

You don’t have to be an IT professional long before you see the big disconnect between what organizations want, and what they value.  Over time, those two things will come more into line… until then, IT is going to have an unstable, ambiguous role in the organization… and all that implies.

Yes, that’s a bit of a downer, but I want to end this on an up note.  All this instability and lack of direction can actually be a really big positive for those willing to push the organization, champion and validate new technologies, and take charge on emerging issues that will undoubtedly go unnoticed at the upper levels.  You may not be thanked or paid any better now, but you’ll look a lot better as those qualities, that truly define an IT leader, become more critical in landing the big job.

Before we look at IT as a whole, let’s take a look at a more obvious example.  It’s pretty easy to define the job of a programmer.  They take a set of requirements and write code that meets the requirements.  It’s also easy to make that case that programmers can be used to generate value… and they run for days on twinkies alone.  Yet, no matter the skills of the programmers, the value of programming is in what it automates for those using the software.  It’s not enough to simply give a user a number of tools, the tools must be logically presented for the task at hand, and they have to have the *appropriate* level of automation.

The “appropriate level of automation” is key.  Allow me to oversimplify.  It requires a certain number of actions to make text bold in a typical word processor.  We could reduce the amount of work programmatically by making an assumption – such as automatically bolding a whole paragraph with a click.  That’s quicker, but I no longer have the capability to bold individual words, which is too limiting.  On the other hand, if we had to bold each letter individually, it would be a cumbersome process… one that used to be a reality, not too many years ago.

Intentionally or not, this specific scenario is played for every feature that goes into an application… and for every feature that seems obvious, there are 10 that require a deep understanding of how the end user works, what they are trying to accomplish, what they expect to see, how they’ll screw it up… and you can go on and on.  As far as the programmers are concerned, doing it right or wrong usually takes the same amount of work… but the value of the application literally hinges on knowing what the application is supposed to do, up front.  All users who open an application have a certain task they want to perform, and they will gravitate towards applications that do the “right” job in the “right” way.

“The corporate mindset is that if a computer can boot, run Office and access the internet… well… that’s all they do, right?”

Programming is treated as a commodity in organizations that view the task of automation as a means to an end, as opposed to an integral portion of the business model.  “We are now required to keep records of transactions for X years, we think it would be better to do this with an online database… hey programmers, build on online database to do that.”  These projects are usually successful in their scope, but organizations eventually wind up with a hundred different systems that were all built with the same narrow focus, none of which talk to each other and ultimately create unnecessary inefficiencies or duplication.  These same organizations realize at some point that their business is out of control, so naturally, they come to the conclusion that they need to literally rebuild their whole way of doing business from scratch and take a massive technological leap with an aggressive “ERP” project.  Millions of dollar and several years later, they scratch their heads when they wind up with a solution that is far more reminiscent of the old process, than the process the technology should have allowed.  Large scale ($Millions plus) ERP projects have a massive failure rate.  Failure doesn’t mean the ERP was scrapped, failure may be indicated by being overbudget, overtime, underutilized, ROIs much smaller than anticipated, etc… anything that diverges significantly negatively from the original project goals.

Small programming projects tend to be successful because it’s easy to define the processes the programmers are going to automate, the goal usually being to evolve a process with a more efficient mechanism rather than replace a process with something unknown.  Large ERP projects fail for dozens of reasons…  it’s almost impossible for any large organization to fully document all of their existing processes, much less envision how all of those processes can be improved with automation on the whole, and how those changes will impact everything else.  These are seen as capital projects, requiring every employee, every executive, every business office representative to come together as a collective whole to rebuild the business rules from the ground up with technology no one has any experience with.  These projects fail because they expect the organization to function in an unnatural state, rather than using the organizations strengths to drive the development.  In fact, there’s no better way to show how little an organization knows about its own business than to mention the letters “ERP”.

Having to undergo a *large* ($Millions plus) ERP project means, quite literally, that the company has seriously missed the boat on technology – probably for decades.  However, ERP implementations are both inexpensive and successful when it is simply next logical step of an existing, successful, cohesive business development platform.  Surprise surprise, companies that have a successful history of using IT to automate their business processes are more successful in large scale process automation projects.  Duh! 

The ERP debacle, and the fact that so many organizations expect a different result from the same plan, is a symptom of a much larger dysfunction.  If we fail to get value from a cash cow like programming resources, how in the world do we get value out of less-easy to define IT roles in the enterprise, like the help desk, or the systems group, or the software group… etc?  Simple answer is, we don’t.  The corporate mindset is that if a computer can boot, run Office and access the internet… well… that’s all they do, right?  How do you know your large organization has failed to leverage the most basic benefits an IT department can offer?  They use the word “outsource”… a lot.  

We’ll talk about that next time….

 —  By the way, if you’re enjoying these articles… please let others know about them!  Digg this article, mail it, quote it, del.icio.us it, whatever… just spread the word!  Feel free to drop me a line as well!

It’s the boss’ fault.  There… I said it.  But that’s not important right now.  First, a lesson in macro-economics, innovation and human nature.

Is computing a commodity?

A commodity is a bulk product that has no differentiation among vendors.  Commodities are bought and sold almost exclusively based on price as opposed to quality or other unique values and features.

As I mentioned, it is frequently predicted that “computing” and “IT” in general will progress from an individualized endeavor taken on by many, to a commoditized good available on demand from a service provider… like electricity.  Makes sense, who wouldn’t use Enron if they could?

Electricity was not always the poster child of commoditization it is today.  Many companies produced it themselves; they had Vice President level members of the organization to manage it’s production and delivery, and all of it went the way of the lesser known VP of Healthcare (heh… think about it).  Electricity is clearly a commodity today.  The cost and effort associated with producing it makes it infeasible for most… though it’s not entirely unheard of.  The organization I work for produces energy at a significant savings over buying it from a utility, for example.  But electric is all the same for most, so it doesn’t matter who makes it or how it’s made, as long as it’s cheap and always on.  You know what you’re buying and you know what you’re paying.

“the goal of active technological innovation is to simplify, add or improve capability, and create independence”

But is that what people want?  Do you *want* to be tied to a utility for electric?  Let’s look at the phone company over the last decade.  What we’ve found is that people don’t want to be at the end of a leash, hence the cell phone, and people don’t want to be tied to a phone company, hence telephone number portability, the attack on carrier contract practices, and at the ultimate, non-carrier-specific VOIP – all the function of phone service, without the phone company… sorta.  Telephone service has all but lost commodity status, all because of innovative new ways to do the old thing.  It’s happening fast, too, despite every effort of the industry to push against the tide.  Would the baby bells really have survived this long without the rampant corporate protectionism in congressional and regulatory bodies?

The next few years should be interesting.  The cable company will provide data, phone, TV… and so will the phone company.  The electric company is getting in on that action too, finally defiling our virgin electrical outlets with your choice of smut, Ok Go videos and cold calls from your local newspaper.  But the forthcoming wireless technologies put into question whether “tethered” information services will be able to survive at all.  You may get your information from a local ISP over WiMax.  And here’s the very real possibility – a completely non-corporate, community-based wireless mesh.  You buy a box, that box talks to as many other boxes it can find, wirelessly, and we all become one seamless, unowned service provider.  Unlimited data for all, anytime, all the time, with limitless redundancy.

I hold out little hope for that last option.  I think it will be regulated out of existence or lost in the standards committees or fail miserably in proprietary-ville.  The technology to do it exists today, and several companys could make a mint off of supplying the gear, but too many existing companies will feel they need to be protected from such a democratization of service, and there’s no shortage of lawmakers willing to comply, quid pro quo.

So, back to electricity.  If electricity was able to be produced in large quantities easily, safely, cheaply, and reliably, even redundantly… using a device that fits in with your air conditioner and water heater… would you use an electric company?  Of course not, people don’t *desire* utility service, they simply endure it as a matter of cost (including time, risk, reliability, etc). 

I say all this to illustrate a simple truth.  In practice, the goal of active technological innovation is to simplify, add or improve capability, and create independence – “Hey, look what *you* can do now.” 

It takes no great leap of wisdom to say that something, sometime down the road, might become a commodity.  Everything has that potential.  All it requires is that a something is either so unwieldy that it can’t be done/produced independently, or so stagnant and common that there is no way to get an advantage through independence – “Hey, we’ll do that for you faster/cheaper/better than you can do it yourself.”.

It’s that second part that forms the basis of the outsourcing debate.  There is a corporate belief that IT is stagnant.  There is a belief that there is no differentiation between IT services…. and that for a specific amount of money, you get a specific amount of service.  Is that true?  Or has IT has simply been so misaligned with business, its strengths so under-utilized, its impact so poorly measured, that no one has a $*%(#_@ clue if the power is on?

So is computing, and therefore IT, a commodity?  Does treating it as such have merit?  We’ll find out in the next article… and I’ll blame the boss – again.