Supporting business practices: The easiest job in IT

Last week’s Advice Line hinted at a false dichotomy, namely, that in the future IT will need to support business practices instead of business processes. If only the future were so easy — it won’t. Like every previous expansion of IT’s sphere of responsibilities, we’re going to support business practices in addition to everything else we’ve been doing, business processes in particular.

The difference is that our history supporting business processes points the way toward our future supporting business practices. All we have to do is recognize the shift. The rest is just a matter of the right package and the good sense to get out of our own way.

[ Find out the 10 business skills every IT pro must master. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld’s 29-page “Mobile and BYOD Deep Dive” PDF special report. | For more of Bob Lewis’ continuing IT management wisdom, check out his Advice Line blog and newsletter. ]

IT’s ever-expanding sphere of responsibilities

The history of IT is one of scope creep writ large.

First, we began processing accounting transactions. Then we added support for manufacturing, distribution, supply chain, human resources, and other parts of the business, using pretty much the same approach to systems design because they all fit the same paradigm: Present data-entry screens, feed a database by posting transactions, and use the database to generate reports.

Then the personal computer dragged us, kicking and screaming, into the world of unstructured data and human-to-human interaction, where we found ourselves supporting word processing software, electronic spreadsheets, presentations, email, Web conferencing, and (shudder) the telephone system. Worse, the World Wide Web shoved us into face-to-face collaborations with marketing, where requirements change at least every season and not wanting Macintoshes is a character flaw.

Somewhere in there we also squeezed in support for analytics and the data warehouses needed to enable this reuse of the data we’d already helped collect. Compared to how well we support transaction processing, while we’ve mostly made our peace with marketing and the Web, we’ve never quite mastered analytics and unstructured data.

It all has to do with the difference between business processes and practices, the latter pointing the way forward.

Business processes and practices

As I’ve mentioned before, work is organized along a continuum, with business processes at one pole and business practices at the other. Processes are about following a standard sequence of steps, specified in detail, to create repeatable, predictable results. That’s what you need for mass production, and it delivers the fringe benefit of making employees interchangeable.

Practices don’t make employees interchangeable. Far from it — while they involve a standard sequence of steps, they’re specified only at a high level, not in detail. The details themselves depend on the situation and on the knowledge, judgment, experience, and expertise of the practitioner.

Practices are what you need to deliver customized, tailored, feature-rich, high-value results. You need them even more when your goal is to outmaneuver a competitor — when predictability is a guaranteed way to lose.

Here’s how this connects: Transaction processing systems are exactly what business processes need in the way of IT support. Look at where industry has focused its thinking and it’s all there: Business process design has Lean, Six Sigma, Theory of Constraints, and various hybrid methodologies to support it; transaction processing systems have data-flow diagrams, object-oriented analysis and design, services-oriented analysis and design, and normalization standards for data design to support them. Plus, under the hood, we have transaction processing monitors, relational database management systems, and languages designed with transaction processing in mind.

There is no comparable general body of business practice design theory, nor any design methodologies for the kinds of systems needed to support business practices. All we have are special-purpose methodologies and systems tailored for specific practices.

Business practice support case study: Project management

Project management is one of the most extensively developed business practices, both from a methodology perspective, and with respect to supporting software. Let’s see what we can learn from it.

First things first: Many of the well-intentioned folks responsible for developing, maintaining, and teaching project management methodologies don’t recognize the difference between processes and practices, and they’re doing what they can to pretend project management can be a process. Good project managers learn the valuable parts of these methodologies, but never lose sight of what the discipline actually requires: 50 percent technique, 25 percent armchair psychology, and 25 percent political street smarts (in round numbers).

The first lesson has nothing to do with IT: Don’t try to hammer the square peg of a practice into a process-oriented round hole.

Data design comes next. Projects consist of a hierarchy of tasks. No problem there. We know how to represent a hierarchy in a database. We use recursive data structures, where each record includes a field that points to a different record in the same table that owns it.

“What else do you need?” we ask our project management subject matter experts.

“We’d like to be able to drag a task from one owner task to a different one sometimes,” they explain.

We tell them patiently that this isn’t how user interfaces work, giving them a screen in which they can enter the new owner-record serial number instead. “Anything else?”

“We need to be able to enter estimated and actual start and finish dates for every task.”

“No problem. Next?”

“In any task we need to be able to enter ‘dependencies’ — one or more tasks that have to finish before it can start …”

“No trouble,” we interrupt. “We’ll create a child table that hangs off the task master table.”

“… and for these tasks we need the software to calculate the projected start and finish dates. We’ll need to see the projected start and finish data for every task in the user interface, too,” they explain.

“No, no, no,” we exclaim impatiently. “The user interface is for data entry. What you’re describing takes a query and a formatted report. We can program that.” And so on, until we’ve “documented the requirements” and go on to write the least-usable project management support package in history.

We wouldn’t do this, of course, but only because IT professionals generally understand project management better than anyone else in the business, and we have personal experience with project management software. But if that wasn’t the case, it’s how a lot of IT departments would “negotiate the system requirements” with the users who need it to support the business practice they engage in.

The good and bad news of IT support for business practices

The situation with project management provides the good news with respect to business practice support: For the most part, you can find COTS (commercial, off-the-shelf software) and/or SaaS (software as a service) offerings that support those business practices in your company that correspond to well-recognized disciplines.

In addition to project management, you can find campaign management systems for marketing, sales support software for the sales force, and case management systems for attorneys, to name just a few. That’s not to mention all the ways practitioners of various disciplines have tortured Excel (or, if they’re highly evolved, SharePoint) into doing their bidding.

The bad news about the good news? For the most part, these practice management support systems take us back to the bad old days of unintegrated “islands of automation.” I’ve read estimates for Salesforce.com, for example, that as many as 90 percent of all implementations are stand-alone, with no integration into the rest of the company’s systems, though there’s probably a strong correlation between larger implementations and better integration.

Very few companies integrate project management software or SaaS into the rest of their systems either — it’s all manual rekeying.

I guess this leads to the good news about the bad news about the good news: When it comes to providing software support for business practices, expectations are low. Help practitioners select a suitable package and provide technical support without complaining about their unreasonable expectations — you’ll be among the industry leaders. Provide a modicum of integration besides and you’ll be a front-runner.

Where else can you get so much credit for such little effort?

This story, “Supporting business practices: The easiest job in IT,” was originally published at InfoWorld.com. Read more of Bob Lewis’ Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.