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.

Project managers can’t understand and incorporate these things if they don’t ask, and to make the answers useful they must ask early.

Moreover, whenever it takes place, telling the impacted groups what is going to happen can be just as damaging to project success. Instead, impacted groups should be included during the concept and strategy stage, made aware of the forces driving change and allowed to help shape, and in appropriate cases, limit the process before specifics are crystallized.

Second: nothing is free; if providers aren’t funded or staffed to participate and you aren’t offering to fund them, they aren’t likely to sign on.

In a perfect world, all projects would come with funding for everyone and everything in the organization. Sadly, this is virtually never the case: indeed, most projects are thin on funding for even the technology that will be needed, let alone money to deal with the impacts across the organization.

Experienced system managers, after a beer or two, have been heard to admit that one reason they don’t talk to providers and other impacted groups early is that if all the costs were public up front, the project could be in jeopardy of cancellation before it even starts.

But cost control is one area where provider groups can be a valuable resource. If each group about to be asked for upgraded content and processes is given the opportunity to participate in how their role is structured, they may and often do come up with ways to control cost and complexity.

For example, a provider group using standard word processing tools to capture its content may balk at massive changes to those existing processes, but may be willing to negotiate a level of upgrade that gets to the threshold if not the zenith of acceptability; employing style templates to increase its consistency or proposing simple authoring applications to help authors with especially complex content structures. But these enhancements will not take place if the impacted provider groups are treated as outsiders in the system design processes.

In other cases, provider staff may need upgraded training to understand and use new software and procedures. It is up to the project to establish, provide, and fund this training as well as ongoing help-desk support as the new procedures go live. Impacted groups need to know what level of support they can expect going in lest they run for the hills, fearing the worst, even if it is not imminent.

Third; technology works tirelessly once it’s plugged in, but providers must grow into new ways of working

Perhaps most important factor in working with provider groups is their inclusion in the development of implementation schedules for those activities in which they will be directly involved. Put new technology in operation any time you wish, but don’t assume that human organizations can change overnight along with it.

Phased implementation is arguably the most valuable technique here: go live in stages, activating new procedures as the impacted groups can handle them... and always providing at least a temporary fallback plan. This doesn’t mean accepting a “when we get around to it” answer from providers, but neither does it lend itself to a “this must work by December, or else!” edict.

In areas where content creation staff must accept changes in their authoring procedures, a potentially valuable technique is the “authoring lab,” a workstation loaded with candidate software to be evaluated by chosen authors with a project analyst at their elbow to record criticisms and suggestions during short -- never more than one hour -- test sessions.

This technique can work to lower authors’ anxiety level and to elicit valuable suggestions on how the new tools should be configured and supported. In some cases, a suggested change to the software can be drafted up quickly and re-evaluated by the involved author, further demonstrating the project’s willingness to work with providers to lower system impact.

Content… the golden egg

In a content-centered world, automation, whatever its intent, must deal effectively with the sources of the content it wishes to leverage and deliver. Only by understanding where and from whom that content comes are projects likely to realize the promise that motivated them in the first place. For technologists and project managers steeped in the organized world of IT, this can be a daunting task.

Chief Information Officers, who should be the bridge between providers and technologists, are too often technologists themselves, incapable of functioning at that level. But we must get there if our brave new world of information is to have information to deliver.

There are enough successes around to provide models for what project management should be… if we will just search for them. We can’t start too soon.

Editor's Note: This isn't the first time Barry has taken on the behind the scenes battles of the information world. Read his The Battle for Data Supremacy: The Cost of Ignoring XML