a note from the boss on the current company reorganization

A man in a hot air balloon, realizing he was lost, reduced altitude and spotted a woman below. He descended further and shouted to the lady

Excuse me, can you help me? I promised a friend I would meet him an hour ago, but I don't know where I am.

The woman below replied,

You're in a hot air balloon, hovering approximately 30 feet above the ground. You're between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude.

You must be in IT,

said the balloonist. Replied the woman,

Actually I am, How did you know?

Answered the balloonist,

Well, everything you have told me is technically correct but I've no idea what to make of your information and the fact is I'm still lost. Frankly, you've not been much help at all. If anything, you've delayed my trip.

The woman below responded,

You must be in Management.

Replied the balloonist,

I am, but how did you know?

Said the woman,

Well, you don't know where you are or where you’re going. You have risen to where you are due to a large quantity of hot air. You made a promise, which you've no idea how to keep, and you expect people beneath you to solve your problems. The fact is you are in exactly the same position you were in before we met, but now, somehow, it’s my f****** fault.

Run, IT, run ... but not as a business

1/28/2008

Nitpicking is fun, but pragmatism pays the bills.

Last week's column, which deconstructed the notion that CIOs should run IT as a business, was fun, but it might have been more self-indulgent than useful.

The column, if you missed it, listed eleven definitions of "business" and demonstrated that none of them makes sense as a basis for running an IT department. But running IT like a business doesn't require you to define it as one, Louis Sullivan's dictum that "form follows function" notwithstanding.

After you've finished singing, dancing and playing the tuba, running IT like a business means negotiating "service level agreements" (SLAs) for what you do and instituting a system of charge-backs to the rest of the business to pay for it.

Negotiated SLAs are contracts between IT and the departments IT serves, and are just plain silly.

Contracts are how businesses manage relationships with their customers, so if you are to run IT as a business, this is what you must do.

Which brings up the question, what happens if you fail to live up to one of your negotiated SLAs? In business, this would result in financial penalties, withheld payments, binding arbitration, or lawsuits.

Just how stupid would a business look if Manufacturing took IT to court for failing to live up to an SLA? This isn't an easy question to answer because "stupid" isn't easily quantified, nor is there a unit of measure for it. If stupid was electricity and we measured it in volts, I'm pretty sure this would reach Taser levels.

Charge-backs, in contrast to SLAs, do have one thing going for them -- they vastly simplify IT governance. If, for example, Marketing wants to re-plumb the company website with a content management system (CMS), you have no worries. Marketing signs up for the cost and charge-backs give you the budget you need. You hire staff, engage contractors or bring in a systems integrator and everybody is happy.

Not really. What really happens is that your staff based its CMS recommendation on what would integrate best with the rest of your technical architecture, scale without major reconfiguration, and allow granular administration to avoid opening interesting holes in your information security.

The Marketing Director, being a prudent steward of her departmental budget, obtains three competitive bids. All are lower than your estimate.

Of course they are. Because your staff failed to run IT like a business. They are running IT like a department, responsible for managing the company's information assets. And so you lose the Marketing Department's business to a competitor.

It isn't the Marketing Director's fault. IT isn't alone in this nonsense. If IT is to be run as a business, so is every other shared service department in the enterprise, Marketing included. Marketing doesn't want to lose the Dental Accessories business unit's account to an outside agency, so it has to keep its costs as low as possible.

And the race to the bottom continues.

CEOs who organize the enterprise so its shared services departments act as independent businesses have forgotten a basic engineering principle ... that optimizing the parts sub-optimizes the whole and vice versa ("Optimizing the organization Keep the Joint Running 10/27/2003).

Specifically, the company's shared services organizations, when run as businesses, lose their authority to preserve the integrity of essential resources. In the case of IT it's the information architecture. In the case of Marketing it's the corporate image and the meaning of the brand. In the case of Human Resources it's the policies that protect employees from bad managers while allowing managers to deal with non-performing employees without the risk of ending up in court.

And so on.

No question, the idea is seductive. CEOs, for understandable reasons, are likely to have a strong faith in the power of markets to regulate themselves efficiently without the need for outside controls or guidance. That being the case, turning the enterprise into a marketplace sure seems easier than the hard work of instituting the governance processes, difficult choices and consensus building that are otherwise required. As is so often the case, trying to avoid hard work doesn't lead to brilliant results.

Marketplaces don't require all of this because they don't have a purpose. They are simply spaces where entities that do have purpose interact in complex ways.

Companies have a purpose. Marketplaces don't. Turning a company into a marketplace misses this essential difference.

In the end, running IT as a business ... and the enterprise as a marketplace ... is an attempt to avoid the need for governance processes, difficult choices and consensus building.

Another name for these activities is leadership. Done right it's hard work.

-----------------

Copyright and other stuff -- The great KJR link point

Running IT like a whatchamacallit

1/21/2008

CIOs are, according to many in the business punditocracy, supposed to run IT as a business. Yet in spite of all of the ink smeared on crushed trees advocating this thought process (not to mention the miniscule magnetic domains that have given up their freedom to store it) I've yet to see anyone define what they mean by "business."

It might seem too obvious to bother with. We all know what a business is, don't we?

That's the problem with this sort of thing: We all do know what a business is, only we don't all know what one is in the same way. Depending on the situation and who is doing the talking, businesses can be:

1. Non-human, amoral organisms that have an existence independent of the people who make them up, and which, like any other organisms, consider self-perpetuation their first and most important goal.
   
2. Mission-driven entities that exist to provide goods and services that have value to someone.
   
3. Product generators that exist to deliver items for which customers will pay more money than was needed to provide them.
   
4. Profit generators that exist to deliver a stream of money to their actively-involved owners.
   
5. Ecologies -- environments in which individuals compete, and sometimes collaborate to obtain resources.
   
6. Assemblages of processes that connect to transform inputs into outputs.
   
7. Places of employment that exchange work assignments for money and non-cash compensation.
   
8. Social fabrics that provide a space for people to interact and form connections.
   
9. Personal "force multipliers" that increase an individual's ability to achieve goals.
   
10. Opportunities for investment, to deliver a lump of cash to a passively involved shareholder.
    
11. Commodities to be bought, sold, aggregated or dispersed for profit.

And more. This isn't a complete list by any means. Nor are the items on the list alternatives on a multiple-choice test. Many can be simultaneously true.

When a CIO is supposed to run IT as a business, which definitions are supposed to be part of the formula?

Certainly not Definition #1. If you work in IT you might like it, as it makes Definition #7 a more enduring possibility. But even ignoring the pundits who also recommend disbanding internal IT in favor of outsourcing, self-perpetuation isn't something you can sell to a board of directors.

Which also means you can scratch Definition #7 off the list.

Definition #2 is a certainty. In its simplest form, IT's mission is to provide working information technology to the business. This, or something like it, is IT's mission whether you run it as a business, a department, or a hobby, so scratch Definition #2 off the list as well. The same logic applies to Definitions #6, #8 and #9.

Definition #3 is a distinct possibility. Never mind a mission. A Definition #3 IT business would deliver products and services to internal customers in exchange for money, through the magic of transfer pricing (the practice formerly known as charge-backs).

Except that it doesn't work that way. When companies engage in transfer pricing they put controls in place to make sure internal departments break even exactly. If they didn't, the business as a whole would be an ecology (Definition #5, as are most companies that engage in transfer pricing anyway). Scratch this one off, too, and Definition #4 for the same reason.

Definition #5 is a good representation of a marketplace as well as a jungle, and in fact, marketplaces are near-perfect parallels to ecologies. It's bad enough when a CEO turns a whole enterprise into an ecology. Another description of this sort of environment is "political quagmire." One presumes "run IT as a political quagmire" isn't what the pundits have in mind.

Definitions #10 and #11 make no sense either. It might be fun to sell shares in IT to various business executives and might even lead to beneficial results, in much the way the Green Bay Packers benefit from having 125,000 fans as the shareholders who collectively own the team.

Somehow I just don't see it working very well in practice.

So there you have it. Eleven different definitions of "business" and not one of them makes any sense for IT. Which leads to a question: If IT isn't a business by any reasonable definition of the term, what might it mean to run it like one?

I'm left without an answer, and with only one possible conclusion -- that I don't know what the pundits are talking about.

I suspect that's something they and I have in common.

-----------------

Copyright and other stuff -- The great KJR link point

yet another very fine whine

The Greatest African American

why Johnny's daddy don't have a job

the allegation

the truth

a dram of justice

unfortunately they didn't nail his father-in-law, Charlie

The connection between leadership and process in IT

1/14/2008

Business is the land of the panacea, and IT is its capital. Sensible people ... people who would never ask, "What do you think -- should I take tetracycline, Vitamin D, or have surgery?" before undergoing the minor inconvenience of a medical diagnosis to determine (a) if they are ill; and (b) if so, with what ... ask whether they should undertake CMM, ITIL or COBiT without first having any idea of what is and isn't working well.

Let's dispose of something right now: Ignore CMM (the Software Engineering Institute's Capability Maturity Model).

That, more or less, is the advice given by Capers Jones, one of CMM's strongest advocates.

CMM is waterfall application development methodology taken off a cliff. (Come to think of it, waterfalls always go off a cliff, by definition. Oh, never mind.) Had everyone followed CMM, the World Wide Web would never have happened. By the time the first few thousand websites had been deployed ... with maybe one tenth the content and functionality of the ones that actually happened ... everyone would have lost interest.

According to Capers Jones, CMM is essential for just about any run-of-the-mill IT shop that employs more than 1,000 developers and undertakes 10,000+ function point projects. He has solid evidence that this is the case.

So if you lead more than a thousand developers, it's just barely possible that you really do need CMM. Probably not, though, because even if you do, you rarely have a reason to charter a 10,000+ function point development project, for two reasons.

The first: You're almost always better off chunking your projects down into a succession of small projects instead. Risk goes down, success is more reliable, and business value happens faster. And, (he said, never passing up an opportunity to plug his books and seminars) you can employ the Bare Bones methodology instead of something bulkier.

The second: Most business IT groups spend the majority of their applications effort integrating, configuring, maintaining and upgrading commercial software packages rather than developing from scratch. The square peg of development methodologies has limited relevance when it comes to the round hole of integration and configuration, despite decades of attempts to pound one into the other.

But I digress.

Four major factors determine the success of any IT organization: Business alignment, process maturity, technical architecture, and human performance.

Which of the four is most important? Human performance, without a doubt. As mentioned here in recent columns, the proof is easy, and geometrical in its rigor: Great employees routinely overcome bad or non-existent process, ineffective leadership and governance, and messy technical architecture. Bad employees just as routinely cause even the best process designs to fail while turning elegant architecture into a tangle of spaghetti, and efficient governance into meaningless committee meetings as projects become eternal.

Bad employees don't routinely fail in the face of excellent leadership for the simple reason that excellent leaders hire bad employees less often, and when they do either coach them to success, reassign them to more suitable roles, or terminate them. Strong leaders don't tolerate weak employees.

That doesn't stop us (us being IT Catalysts, my consulting company) from advising clients on how to make their processes more effective. Far from it. One of the questions we often ask struggling managers is how (but really whether) they know if the processes they're responsible for are healthy.

Am I speaking out of both sides of my mouth?

Not at all. Here's the distinction: Effective leaders place their emphasis on people. Effective managers insist on delivery, and recognize the importance of process in achieving that end.

If you are responsible for a business function you have to be effective at both leadership and management, and they aren't independent topics.

Effective management depends on effective leadership for all the reasons enumerated here over the past few weeks and summarized above: Effective leadership puts motivated employees with the right skills, attitude and focus in the right roles, allowing processes to be effective.

Effective leadership is equally dependent on effective management, although the reason is more subtle: Because effective managers know how to monitor and manage processes, they can know what's going on without having to micromanage.

One other reason for the dependency: If you are in charge of a business function, you have to know how to manage first, because results ... process outputs ... are what you're paid for.

Fail to deliver them and your own manager might insist you spend less time leading and more time closely supervising the work.

-----------------

Copyright and other stuff -- The great KJR link point

and these people have a problem with creationism?

it's hard not to think of this as high-browed humor

the son finds fine whine

the fulton is fulton county ga (ATL); ditto cobb

a good place to whine

I have

A contrarian view of process

1/7/2008

Process has dominated the consulting world, at least since Michael Hammer and James Champy published Reengineering the Corporation in 1994.

Keep the Joint Running and its InfoWorld predecessor, Survival Guide, have been contrarian about process for nearly as long.

The process perspective isn't wrong. It is, however, subordinate to other, more important perspectives. As evidence:

• Jim Collins' Good to Great (2001) isolated five factors common to the high-performance companies he and his team analyzed. Process improvement or reengineering initiatives weren't among them. High-quality leadership, a culture of discipline, and strategic focus were.
  
• William Joyce, Nitin Nohria, and Bruce Roberson published the results of their "Evergreen Project" in What Really Works (2004). Their formulation is a bit more complicated than Collins', but similar in most respects. Their evidence was, if anything, more compelling.
  
  Over the ten years examined in the study, companies that followed the "formula" increased sales by 415 percent and operating income by 326 percent. Companies that didn't increased sales by just 83 percent and operating income by 22 percent.
  
• Regular correspondent Noah Wollner pointed me to an older study by John Kotter and James Heskitt. Titled Corporate Culture and Performance (1992), it contrasted companies that fostered a "performance enhancing culture" with others that didn't. Defined as promoting risk taking and innovation, being receptive to change, valuing entrepreneurship, and encouraging mutual support in identifying and solving problems, the impact was, to say the least, significant:
  
  Over an eleven year span, organizations with performance-enhancing cultures experienced 682 percent revenue growth and 746 percent net income growth. Those that didn't grew revenue by only 166 percent and net income by just 1 percent over the same period of time.
  
• And, as mentioned [in] my last column, every time anyone looks at what drives customer satisfaction, employee attitude is the most important underlying factor.
  
  So far as I can tell, there is no reliable published evidence, other than the anecdotal, that process change is a primary driver of business success.
  
  Does this mean process has no value in a modern corporation? That would be a false inference. The question isn't whether process matters. The question is how it matters.
  
  Those who view companies as collections of processes end up looking at companies as mechanisms -- collections of gears, cogs, buttons, and wheels. From this perspective, employees occupy some but not all roles in a process. Done right, everyone is replaceable, and when replaced, nothing changes.
  
  Those who view companies as collections of people end up in a different place. For us, businesses are, first and foremost, societies. While not the lead story, process still has important roles to play.
  
  First, process encourages consistency where consistency matters -- usually when the company has to produce a large number of very similar items; sometimes when failing to undertake work in a very specific way can lead to dangerous situations or legal liability.
  
  Second, having well-defined processes lets employees focus on getting work done instead of on figuring out how to do it. Just as important, well-defined processes (and procedures) make collaboration easier because everyone involved shares a common understanding of how we do things around here.
  
  And finally, well-defined processes create a framework for constant, steady improvement ("continuous improvement" is the now-cliched, preferred buzz-phrase). Without a well-defined process to provide a baseline, the enterprise has to constantly start over -- the getting-work-done equivalent of software that never progresses beyond the alpha-testing release.
  
  In human-centered enterprises, process also has clear boundaries. The most important is this: Everyone understands that the business exists to take care of customers; that taking care of customers is something employees do; and that employees rely on trustworthy processes to help them do it, when the processes fit the situation.
  
  When a company's processes don't fit the situation, the company has to make a choice. It can, with complete validity, decide that what the customer wants isn't something the company does. If you run a travel agency and a customer wants you to replace a broken axle in the family minivan, "Sorry but we don't do that," is a reasonable response.
  
  "We haven't done that before, but we'll figure out a way to do it for you," is often an even more reasonable response: The company can decide that when its standard processes don't fit a customer's request, the customer has just revealed an opportunity, or something that should be fixed.
  
  Companies that only do what they do eventually do too much of what customers don't need any more. Those that figure out how to handle unexpected requests, on the other hand, sometimes find whole new profitable lines of business in the process.
  
  As it were.
  

-----------------

Copyright and other stuff -- The great KJR link point