In 1980, a 3278 green-screen terminal cost (as I recall) about $6,000, not including the mainframe it attached to.

Along came the PC. It cost half that, and was self-sufficient.

IT tried to keep them out. They put too much power in the hands of ignorant users and you couldn’t do serious computing on them anyway. Yes, the IT authorities made both arguments, simultaneously, and didn’t even blush.

PCs leaked in despite IT’s opinion. Distributed computing leaked in too. The economics made them unavoidable. Various pundits claim otherwise, but they are comparing the costs of PCs and distributed computing with the competition-deflated costs of mainframe computing, not the pre-PC high-margin early-1980s price tag.

Fast-forward to now. You can buy a 150 gigabyte drive for less than $100. For another hundred bucks you can buy a USB external disk to back it up.

For 150 backed-up gigabytes, IT would charge $1,500 per year.

From my backup drive I can restore any file in five minutes. IT would take more than a day. Self-service? Forget it.

In 1980, IT completely locked down the 3278 terminal, by definition. IT now locks down the PC, not by definition but by choice. Meanwhile, at home, people install whatever they please, and in spite of what the doomsayers tell you, few run into insurmountable problems. Those who do sheepishly ask their teen-aged children to help them. Their teenagers give them the same eyeball rolls they get from the Help Desk staff at work, but much better service.

Nothing in this comparison is fair. Fair has nothing to do with it. My PC at home beckons, saying “Yes, you can do that too.” My PC at work says, “No you can’t.” Your end-users experience that contrast every working day.

Preaching to them that “it’s a business computer, to be used only for business purposes,” isn’t persuasive, because they know something we in IT often ignore: It isn’t really a computer.

Oh, technically that’s what it is, but technically doesn’t matter. The PC is a portal to a universe of possibilities. While the word “cyberspace” has fallen out of use, the idea of cyberspace is alive, well, and built into the perception of everyone who looks at a screen while manipulating a keyboard and mouse.

It might be time … past time … for IT to look at its job in a new way.

Try this on for size: Imagine you ran IT as if it embraced this PC-as-portal perspective. As if IT’s job was to manage one corner of that universe of possibilities.

What would you do differently?

Let’s take it a step further. Let’s look, not just at the PC but about work as a whole from the employee’s point of view. That shouldn’t be too hard. We in IT are employees too, when we aren’t busy being IT professionals.

From the employee’s point of view the job is, in addition to being a way to earn a living, a place for: social interaction; developing the self-esteem that comes from creating value and achieving important things; structuring time and staying occupied; exercising their brains and keeping them from becoming stale.

Few employees draw a hard boundary around their work life, keeping it psychologically distinct and independent of the rest of their life. They are the same people in the office as out of the office.

We in IT are stuck in a 1950s industrial view of the workplace. Much of the workforce is post-industrial in perspective. They don’t “achieve work/life balance.” They just live their lives, wherever they happen to be at the moment — sometimes in the office, sometimes out of it.

In the office they research reports, create presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, answer personal phone calls.

Out of the office they think about the reports, edit the presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, and answer personal phone calls.

Employees live a significant part of their lives in the universe of possibilities they reach through their PCs, their Blackberries, the Treos, their iPhones.

The economic gap between self-sufficient computing and central IT that drove the PC revolution is back. The existential gulf separating IT’s perception of work from the employee perception of work is new, and wider. We in IT had better figure it out, or business users will figure it out without us.

Because for us, a PC is an expensive, hard-to-support business resource. But for them it’s a portal to an entire universe they can buy at Costco for a few hundred bucks.

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 …