It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

I’m promoting a new business model: Whole Business Outsourcing (WBO). It’s the next logical step after Full Functional Outsourcing (FFO) and its successor, business process outsourcing (BPO). Here’s our value proposition:

A popular means to personal wealth is to start a company, create the illusion of success, then get rid of it for a large chunk of change, leaving the hard work of running it at a profit to someone else.

If you accept the popular-but-unsupported-by-a-shred-of-evidence proposition that businesses should “keep the core and outsource the rest,” it follows that for companies like this, everything except shareholder relations, the IPO process, venture funding, and selling the company outright (pick no more than two) must be non-core.

Humans choose sides and hate the other. It’s built in. Ethnic groups deprived of outside disdain fragment into ethnic subgroups that insult each other. Religions deprived of religious persecution fragment into religious factions that persecute each other. Minnesotans tell Iowa jokes.

A business deprived of strong competition isn’t immune to this human tendency either – it fragments into departments whose members make snide comments about each other while their managers vie for budgets and other resources. If you want to see an example of this, chances are the only tool you’ll need is a mirror.

I received a bunch of mail following a recent column recommending that IS establish multiple PC standards based on different kinds of work habits. Most of my mail makes it clear that lots of IS professionals still view the rest of the business with disdain and classify end-users into three groups: Idiots, troublemakers, and what was your name again?

Before you accuse me of IS-bashing and throw aside your issue of InfoWorld in disgust, ask yourself this: Do you or your analysts tell dumb-user stories? If they snicker at white-out on the screen, photocopied diskettes, and mistaking an answering machine for a modem, you have a problem.

Do your end-users snicker at the “Helpless Desk,” call outside consultants instead of IS analysts, and sneer at your pocket-protector-wearing chip-heads? If so, you have a problem, and if you don’t know whether they do or not you have a bigger problem.

As an industry we tend to focus on technologies to solve our problems, and when technologies alone aren’t enough we apply new methodologies or write new policies and procedures. Throwing technologies, methodologies, and policies into an atmosphere of mutual distrust has a predictable result: Zilch.

The psychological cause of the mutual distrust between IS and the rest of the business is the same xenophobia that afflicts us socially and internationally. Fortunately, within a corporation it’s curable.

How? Glad you asked. Here are some concrete actions you can take to create a cooperative atmosphere between IS and the rest of the company:

Trust-builder No. 1: Don’t be part of the problem. It’s easy to instill loyalty and esprit de corps by fostering an us vs. them attitude. Often, the process is unconscious. Watch your own behavior. Never disparage other parts of the company.

Trust-builder No. 2: Stamp out the word they. Insist on we: “They haven’t told us what they need,” becomes “Let’s figure out what we need.” If you can’t use “we” you don’t have the right people in the room. Get them there, or at least put a name on whatever part of “they” doesn’t turn into “we.” “They won’t let us do what we need to do,” becomes “How do we persuade Jim Smith of what we need to do?”

Trust-builder No. 3: Foster mutual problem-solving. “You” becomes “we,” too. “You need to do this,” becomes “We need to do this.” Include both end-users and IS professionals in your teams so it’s always “we.” Working together builds trust.

Trust-builder No. 4: Don’t allow blame. Don’t allow its synonyms, either. “Who caused this mess?” is usually a waste of everyone’s time and energy. “How do we fix it?” takes care of problems and builds trust in the bargain.

Trust-builder No. 5: Replace requirements with design. When you determine requirements, you ask, “What do you need?” When you design you ask, “How can we make this work?” It’s a joint effort now. You’re a partner, not just taking dictation.

Trust-builder No. 6: Foster xenophobia. People distrust members of other groups. You can’t eliminate this very human tendency, so exploit it instead. “How can we make this work?” becomes “How can we turn this into something that helps us beat those schlemiels over at the XYZ Company?”

Distrust between IS and the rest of the business is bad and getting worse. Whose fault is it? See trust-builder #4 for the answer. What’s important is that you … sorry, we … need to fix it. It’s our job.

I wrote harsh words about the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) (“The connection between leadership and process in IT,Keep the Joint Running, 1/14/2008).

Nobody wrote to disagree. Not exactly. Hillel Glazer, an SEI insider, politely informed me that I was hopelessly out of date: SEI abandoned CMM in 2001 in favor of Capability Maturity Model Integration (CMMI). He agreed to an interview to explain the situation. Mike Konrad, one of CMMI’s authors, reviewed Hillel’s answers and wrote me independently to endorse them.

Bob: SEI describes CMMI as a general-purpose process framework that can be used to create just about any sort of business process — not just software methodologies. Do we need yet another process methodology, given that we already have: Lean, Six Sigma, Lean Six Sigma, Theory of Constraints, and Reengineering?

Hillel: To be more precise, “CMMI-DEV” is not for creating business processes or for creating (developing) products, but for improving the business processes of product and service development. CMMI assumes a given organization already has business processes and desires to improve them. What happens all too often is organizations are compelled to use CMMI but start out not having/knowing their processes and so CMMI becomes both how they define their processes as well as how they improve them. It’s a fundamental — and widely held — misunderstanding of CMMI.

Bob: In his 2005 interview, Capers Jones was openly dismissive of Agile and similar adaptive, iterative methodologies. With CMMI, has SEI softened its stance?

Hillel: Capers Jones is not a reviewer or contributor to CMMI, and I wouldn’t say SEI folks and Capers Jones see eye to eye on many things.

When CMMI was being written, reviewers were criticizing SEI for making it so “waterfall” centric. The authors were genuinely dumbfounded as to what it is in the model that gave that “anti-iteration” connotation. CMMI is 100% agnostic as to the product development life cycle an organization chooses to use, and always has been. Also, the SEI has created a team-oriented development method called “Team Software Process” (TSP) which has been demonstrated as being very agile-oriented.

Bob: Does any of this really matter to bread-and-butter IT shops? Most companies don’t develop — they integrate and configure purchased applications. The packaged methodologies, waterfall or iterative, weren’t designed for this world. Does CMMI offer something useful for it, or is it also intended for new development?

Hillel: Right now, ITIL probably provides more value than CMMI to pure-play IT shops. However, stay tuned, there’s another CMMI in the works for “services” organizations that goes beyond a static library of management and service workflows and offers a continuous improvement mechanism to companies providing services — IT or otherwise.

Bob: I’ve recommended culture change as the first step in implementing a more process-driven approach in any organization — to create a “culture of process” — and to make sure process owners are fully educated in process management. Do you agree? If not, how do you recommend starting down the CMMI path?

Hillel: I completely agree. When working with companies that do need a culture shift, the first thing I get them to internalize are the CMMI’s “generic practices” which provide the process acculturation so many organizations lack.

In many cases, no matter how much power they’ve been given, you can’t start with the CIO, you must start with the CEO. The CEO needs to see the business value of being process-oriented. Otherwise, the CIO will be placed in an untenable position at the business level.

Bob: Anything else?

Hillel: What’s most often misunderstood about this is that “CMMI is a model, not a standard.” CMMI contains no processes or procedures of its own, and is not a thing that can be complied with. It’s a fundamental shift in expectation and experience of most CMMI users — who are used to complying with standards. Wrapping one’s head around and being able to apply a model takes a whole different set of aptitudes than complying with a standard.

We hear “just tell me what to do” all the time. Combine that with the impatience (read: short attention span) and lack of process culture among too many executives — a topic you regularly rail against — and you have a recipe for process disaster.

Bob: Last question: Do you agree Keep the Joint Running is the most insightful commentary in the IT industry? Or would you rather have me twist your responses in creative ways that make you appear to be the biggest schlemiel in the trade?

Hillel: LOL!

Bob: Don’t say I didn’t warn you …