Tips For Doing The IT-Business Tango

As a technology editor who's been involved in Web publishing since the early days, I've seen my fair share of IT projects. I've helped plan and test numerous content management tools, designed and launched new Web sites from scratch, redesigned and relaunched existing Web sites more times than I'd care to remember, rolled out new site features like advanced search and blogs, and just generally had my hand in a thousand different IT-related projects over the years.

I've seen firsthand how horribly things can go awry when business and IT folks don't communicate with one another. On one site relaunch project, the developers didn't let the editors know until the last minute that they wouldn't be able to update their live site during the entire testing/switchover period. With no contingency plan in place, the site was static for several days—anathema to a news outfit.

On another project, the business/editorial side failed to request that the content management tool under development include a scheduling component, with the result that the editors and producers often had to get up at 3:00 a.m. to post time-sensitive material.

I could go on, but it would be more instructive to find out from the pros how to avoid these sorts of communication breakdowns. Nancy Sallie and Brad Shimmin are both Business Analysts at CMP Media, but their titles don't tell the full story: They act as project managers for IT-business projects and as liaisons between the two groups. I asked Sallie and Shimmin for their advice to folks on both sides of the IT-business fence.

Tips For Business:

1. Put together an executive team that will take responsibility for each project. "Right now a lot of business users are left on their own," says Shimmin. "Your boss puts you on a project and disappears until it's time to make it live. You have no backup, no guidance, no authority, no support."

Project leaders should have the support of a specific executive who can make decisions around the project if, for example, it's delayed or goes over budget. "The decisions are being fed up the food chain; they're not going to come back and bite you," says Shimmin.

Having executive support also gives the IT side confidence in the stability of the project, adds Shimmin. "They know they're getting projects that are well baked and high priority."

2. Get input from developers early on. "Often the business side has a good idea of what they want to do, but they might not understand the limitations, and they might not understand the possibilities," says Shimmin. "Have development and business get together at a very early stage so that you're not investing time and energy going down a wrong path."

"Developers have a lot of value that the business side may overlook," he continues. "Because they understand the system so well, they understand the impact a project could have on the business. They might have a better solution than the one the business people started out with."

3. Get the plan down on paper. "Documentation is key," says Sallie. "When everybody can actually see what you're talking about, then there's less chance of misunderstanding."

She also warns the business side to read the project plan carefully and sign off on it. "Sometimes business doesn't read the business document. They need to check it over carefully to be sure that's really what they want," she says.

4. Understand that your project doesn't live in a vacuum. "Sometimes the business folks say, 'I need this, I need this, I need this.'—but only x number of projects can get done at a time," says Sallie. "Other times we hear, 'Forget about that project right now; do this one instead.' But it's difficult to change projects in midstream. Realize what it means to stop a project and then have a developer go back several months later and pick it up again. Is it worth it, or is it better to finish the project now?"

5. When reporting problems during the testing phase of a project, be specific. Sending an e-mail that says, "The XYZ feature doesn't work" isn't very helpful. Write down exactly what steps you performed before the problem occurred. Copy and paste any error messages you received into your report, or take a screenshot of the problematic feature or component.

Tips For IT:

1. Don't make assumptions. "One of the biggest places where things go wrong is in the handover meeting," says Sallie. "Sometimes the developer makes assumptions about what the business wants and that's not always right. If you're going down the wrong path it can derail a project. Ask questions; don't assume."

2. Communicate, communicate, communicate. Sometimes developers get going on a project and forget to communicate their progress, says Sallie. This can cause problems when glitches or delays happen and the business side doesn't know about them until late in the game.

It can also cause problems even when everything's going well. "Developers have been known to implement something without having the business test it first," says Sallie. That might sound funny, but there's almost nothing you could do to draw down the ire of the business folks faster.

Tips For Everyone:

1. Always work through your liaison, if you have one. Sallie explains the role of the liaison: "We translate business requests for the developers. We try to extract as many details as we can to get the business side what they want."

It might be tempting, says Sallie, but you should never try to circumvent your liaison. "The business people sometimes want to go around the liaison. They go directly to IT with their request, and the developer says yes, but nobody's thought through all the ramifications. That's what we're here for."

Likewise, developers should bring their questions and suggestions to the liaison, who will confirm with the business side. If the liaison isn't kept in the loop, the whole project is likely to fall apart, because only that person knows all the pieces of the puzzle.

2. If you don't have a liaison, try to think like one. If your company is too small to have someone playing the liaison role, it's up to both business and IT workers to think through all the elements of the business and infrastructure that might be affected by a project. Once you have the full picture, you can work together on the best solution.

3. Use a common language that everyone understands. Shimmin recommends using the Prince 2 project management standard. "Have a corporate mandate that requires standardized language and elements—a risk log, a management log, a project plan—and enforce it. Having a common foundation really eases projects," he says.

4 Be patient. Be flexible. Be respectful. It's important that everyone involved in a project ask a lot of questions to truly understand the goals and limitations. "Some people get upset when you ask questions, saying 'I already told you that!'" says Sallie. "If someone doesn't understand something, be patient—they're just trying to clarify and make sure they get it right in the beginning." Likewise, be flexible. "Unforeseen things do happen," says Sallie. Everyone involved in a project needs to be willing to adapt to changes in schedule, scope, and so on (within reason, of course).

"Look at it as a partnership," advises Shimmin. "You've got to work together to develop a respectful relationship and understand the constraints and pressures on both sides."

Valerie Potter is Features Editor for the TechWeb Pipelines. The TechWeb Spin TechWeb's editors are busy assigning and editing and linking and otherwise creating the content you see on TechWeb.com and the Pipeline sites, but we wanted the chance to tell you what we see and what we think about it directly. So, each week, The TechWeb Spin will bring you the informed insight and unique perspective of a different TechWeb editor: Fredric Paul, Scot Finnie, Tim Moran, Stuart Glascock, Alexander Wolfe, Val Potter, and Cora Nucci. We hope you like it, and even if you don't we hope you take the time to tell us what you think about it.