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.