All IT organizations test. Some test software before it’s put into production. The rest test it by putting it into production.

Testing before deployment is widely regarded as “best practice.” This phrase, as defined here, translates to “the minimum standard of basic professionalism.”

Which brings us to organizational change management (OCM), something else all organizations do, but only some do prior to deployment.

There is, you’ll recall, no such thing as an IT project, a drum I’ll continue to beat up to and beyond the anticipated publication date of There’s No Such Thing as an IT Project sometime in September of this year.

Which brings us to a self-evident difference between testing, aka software quality assurance (SQA), and OCM: SQA is about the software; OCM is about the business change that needs the new software.

As we (Dave Kaiser and I) point out in the upcoming book, organizational changes mostly fall into three major buckets: process, user experience, and decision-making.  Process change illustrates the SQA parallel well.

Probably the most common process change goal is cost reduction, and more specifically reducing the incremental cost of processing one more unit.

As a practical matter, cost reduction usually means layoffs, especially in companies that aren’t rapidly growing. For those that are growing rapidly it means employees involved in the process will have to handle their share of item processing more quickly.

In a word, employees will have to increase their productivity.

Some unenlightened managers still think the famous I Love Lucy chocolate factory episode illustrates the right way to accomplish this increase. But for the most part even the least sophisticated management understands that doing things the exact same way only faster rapidly reaches the point of diminishing returns.

Serious process change generally results in different, and probably fewer distinct tasks in the process flow, performed by fewer employees because there are fewer tasks and those that remain will be more highly automated.

Which brings us back to OCM and when it happens in the deployment sequence.

Managers don’t need a whole lot of OCM know-how to understand the need to re-train employees. But many still blow it, teaching employees how to operate the new software: Click here and this happens; click there and that happens.

Training shouldn’t be about how to operate software at all. It should be about how employees should do their changed jobs using the new software.

But training is just the starting point. What’s often also lost in translation are all the other organizational changes employees have to adjust to at the same time. Three among many:

> Realignments: Employees often find themselves reporting to new managers. This, in turn, usually leads to a severe case of heads-down-ism until employees figure out whether spotlighting problems in the new process flow will be welcomed, or if a new manager’s style is more along the line of messenger-shooting instead.

> Metrics: With new processes often come new process optimization goals, which in turn should mean new process metrics, but too-often doesn’t.

The first rule of business metrics is that you get what you measure — that’s the risk you take. So if a company changes a process without changing its metrics, employees will do their best to continue using the old process, as this is what’s being measured.

> Colleagues: Some work that had been performed by employees who work in a different city, building, floor, or cubicle down the hall, and oh, by the way, these folks used to know each other by name. That work might now be performed by total strangers who live in a different country and time zone, and speak a different native language.

Just adapting to different accents can be challenging enough. Add cultural and time-zone differences to the mix, make everyone involved unknown to each other, and the opportunity for process traffic jams increases, not by increments but by multiples.

No matter what the intended change, for it to be successful all these factors, and others, will have to be addressed.

Change leaders can address them before instituting the change, helping the organization and everyone in it prepare. Or, they can leave it up to everyone to muddle through.

Muddling through does have one advantage: Change leaders can blame anything and everything that goes wrong on change resistance.

Given a choice between effective planning and blaming the victims … well, it’s hardly even a choice, is it?

More and more, services organizations of all kinds are relying on what we used to call telecommuters and now refer to as “remote employees.”

I’ve written about the subject before, concentrating on how to make telecommuting work, both for the organization and for its telecommuters. If you’re interested you’ll find the columns here.)

What I didn’t cover in any of them: How services firms, and especially large services firms that extensively rely on a remote workforce, collect them into project “teams,” put them in front of customers for the project kick-off event, maybe take the new “team” to dinner at a nice restaurant, and expect the “team” to function as a team.

I enclosed team in scare quotes because members are left to interact on a basis of trust and alignment to a shared purpose with no basis for either.

What’s truly scary is how few services firms take any steps at all to turn their assemblage of remote employees who have never before met into a functioning team.

What’s only a smidgeon less scary is how often large corporations mimic this services firm worst practice. It’s less scary only because the poor teamwork that results is more visible in internal teams than with those fielded by a vendor.

As is so often the case, the problem begins with the difference between tangible and intangible costs and benefits.

If you aren’t familiar with the terms and what makes them problematic, we covered this ground a month or so ago, in “KonMari and your business.” How it applies here: Bringing remote team members together results in easily recognized expenses: airfare, hotel bills, and meals. They’re tangible costs.

The benefits, in contrast, are intangible: Getting team members together helps them understand who each other are as human beings; it gives them a chance to reconcile hidden assumptions, work styles, perspectives, and particular strengths.

It lets project managers communicate nuances and subtleties about the project’s goals and priorities far beyond what they can accomplish with teleconferences, email, and even web conferences accompanied by PowerPoint.

As a correspondent once put it, email communicates facts, but it doesn’t build teams. Teleconferencing and web conferencing permit the exchange of ideas, but not the connection of co-workers.

I say the benefits of bringing team members face to face are intangible because failing to do so constitutes a risk — something bad that might happen in an uncertain future. Worse, it’s the kind of risk that, even when it turns into reality, still won’t be acknowledged as the cause of the problems in question.

For example, every good project manager recognizes the critical role rapport with the project’s sponsor and governance committee plays every time something unexpected comes up. Project managers can build rapport in direct proportion to the time they spend face to face with these fine folks, and especially the time they spend face to face early in the project, before issues arise.

Second example: Agilistas … practitioners of real Agile methodologies, not “Scrummerfall” variants that replace Agile’s “individuals and relationships over processes and tools” with the exact, polar opposite … recognize the importance of being able to consult, frequently and informally, with product owners, subject matter experts, and end-user representatives throughout development of whatever is being developed.

Unless team members have met these people face to face at least once, the social hurdles that must be overcome to have even one conversation are considerable. Frequent and informal conversations? Good luck with that.

Which is why offshore agile projects rely heavily on on-site business analysts to have these conversations. And that’s okay. It isn’t great, but it’s okay, so long as the business analysts and project team members have had the opportunity to interact face to face.

In the interest of not beating the subject to death and of providing useful solutions, I trust the useful solution is, by now, obvious: If, as a vendor, you’re planning to deploy teams of remote employees, bring them together at the beginning. Specifically, bring them together for a week of orientation and socialization a week before the official project kick-off meeting.

Follow that with three weeks of working together on-site in a bull-pen environment. During this period, schedule as many briefings as possible — sessions in which various project stakeholders explain the current situation and their hopes, concerns, and expectations for the project’s outcomes.

Couple this with a professional-grade, on-demand web conferencing environment. It will be essential for collaboration once the team has been built.

For building the team? Not so much.