On the list of things that keep -- or should keep -- content-related project leaders and their IT counterparts awake at night, dealing with the providers of the content to be managed and delivered has to rank near the top.

While new technology, and a host of other whiz-bang delivery resources make conceiving better information products easier, quicker, even fun, project leaders must confront the reality that the raw material to fuel these new systems and products often comes from a chaotic collection of individuals, organizations, departments and aging archives. That can take the edge off even the most ambitious and well conceived systems and products.

Worse yet, in many cases providers, although treated as a coherent conceptual resource in most system methodologies, are nothing close to homogeneous; indeed, dealing with them often ranges from easy to near-impossible.

Finally, despite project staffs’ tendency to deal with providers in terms of their input forms -- documents, regulations, technical manuals, etc. -- they are in fact groups of people presenting all the complexities associated with human and workplace relations.

But deal with providers we must, so how best to approach them so as to get what we need in content structure, accuracy and elegance without turning providers into adversaries?

Recognize what we’re asking of providers

Project managers often view the impact of their efforts on providers akin to installing new software: swap out the old, install the new, test and go live. That view alone can turn a provider group and its staff into modern-day Luddites. Moreover, while project managers often rank provider groups according to their ability to understand and work with the new systems, reality is usually quite different.

Those dunderheads (when it comes to using new computer systems) may be world class -- and yes, sometimes arrogant -- professionals in other disciplines, dealing with all the challenges and complexities that come with those disciplines and caring little for new IT magic. Working with these folks as if they were untrained input clerks is guaranteed to anger them, seriously reducing their willingness to embrace even justifiable changes in their procedures.

And keep in mind that content providers, often with a more direct line to and more influence with the executive suite, often win confrontations.

But it need not be this way.

Central Role of the Project Manager

Creating a project atmosphere based on respect and cooperation is largely the task of the project manager, often requiring serious discipline of the technological team -- to keep their disdain for providers from showing -- and a high level of communication among project and provider groups. Left to chance, neither is likely to happen.

The ideal project manager must work, and think, across the lines between content and technology, translating in both directions and ensuring that both sides fully understand and appreciate the other. But while the ideal candidate is comfortable with technology, the track record of technologists as project managers is not reassuring.

Getting on the same page

Projects are most successful when they achieve an early and open exchange of ideas between providers and project team. When providers understand what is at stake for the organization as a whole and how central their roles are, they often come up with useful suggestions, improving the project and allowing them to take some ownership of their participation.

Attend just one project meeting at which the technologists and providers talk past rather than to each other and exude tension you can cut with a knife, and you realize how important that sense of joint ownership is to project success. Provider groups, especially those to be significantly impacted, often view IT projects as designed by IT, for IT and at their expense: a guaranteed recipe for resistance.

Timing is everything

Once the project has accepted the important role providers play in success and realized that only involved, willing providers will enhance the chances of that success, how to proceed? Here are some thoughts:

First: don’t launch the ship before everyone is on board.

Nothing angers managers more than learning about a project that will impact them after the planning is largely done. Yet this is often how projects go: do the design; select the software; lay out the basic schedule … then call the providers in to outline their role and requirements.

Even if a provider group will be only marginally impacted, its management has, and will, claim a right to know what is coming and to contribute to the process. Issues of content scheduling, funding and budgeting, training and more will affect how provider groups are able, and willing, to meet project schedules and requirements.