With or Without You

There's far more to managing consultants than just signing a check

By Moshe Japha

2. Build knowledge transfer into the project from day one. I have worked on projects that cost the client millions of dollars. None of that money was invested in knowledge transfer or technical oversight. When the projects ended, the client was left with a working system it did not understand and could not maintain without spending yet more consulting fees. This is not your desired result. You need to learn from your consultants.

There is no training course to which you can send your people that will train them as well as hands-on experience. When you bring in consultants, you are not only paying for a system: You are paying for expertise. Don't let it walk out the door at the end of the project.

Identify resources in your organization capable of learning the new technology as the project proceeds and taking over when the consultants are gone.

Don't succumb to the temptation to retain these people in their full-time assignments and "learn the new system" on the side; it never works. The team members you assign to participate should be full time, or at least 75 percent time on the project. As painful as it is to do without them in their current jobs, (especially because it will probably be some of your best internal talent), the costs of not having them on the project are greater:

• There will be no source to provide insight to the project team of organization-specific issues and problems.
• Your organization retains no understanding of the technical details of the system.
• You will tend to mistrust the consultants as a reaction to your lack of knowledge of what's going on. (More on this point later.)
• The people you most want to keep happy will be resentful that they are not able to learn the new, glamorous technology, while the consultants "do the neat stuff."
• The new system will be less likely to conform to your shop's standards, making it that much harder for your people to learn the technology down the road.

3. Own the project and the work product. Don't fall into the trap of abdicating your role as the owner of the finished product. You will have to support it after the consultants move on anyway.

If you assume the consultants know what they're doing, and do not take active ownership of the work product, you will never get the result you want. This is not due to the consultants' malfeasance or dishonesty, but rather the opposite. The consultants' job is to complete the assigned tasks as well as possible, on time and on budget, per your stated requirements. Language and documents have their limits. Reality has a nasty way of being different from the concept. Your task is to ensure that your original goals are being met and to manage changes to the project as those goals confront the emerging reality.

It is therefore vital for your people to be actively involved in the timely review and signoff of deliverables, the resolution of problems, and "running interference" to make sure that internal organizational conflicts do not sidetrack your project. If your people are too distant from the process, they will not be able to effectively understand or respond to the issues that arise.

4. Don't be intimidated by lack of knowledge. Due to the fact that the consultant has expertise your organization lacks, you may find yourself in the position of having to make budget, design, and functionality decisions in areas in which you and your organization have no expertise. This is possibly the most sensitive area in your partnership with the consultant.

The knee-jerk reaction is to react with mistrust. You assume that the consultants are there to milk you of as much money as possible, so they attack your ignorance. This approach leads to major instability in your project's development. By second-guessing the consultants' motives and decisions, you violate the trust necessary for the partnership to work. You will inevitably make unplanned changes to scope, functionality, and accountability requirements that will become a self-fulfilling prophecy, ensuring the project's failure.

So how do you deal with your knowledge gap? You do have to verify the consultants' work. They need verification as much as you do.

• Keep the knowledge transfer channel open as I've just described. Your own technical people will give you significant insight.
• Look to your SMEs for a reading on their confidence in the consultant's expertise and credibility.
• In the Statement of Work, define the project's milestones and checkpoints to reflect content and functionality you do understand. These checkpoints may be data definitions, visible models, functioning prototypes, and the like. It is important that you define these milestones at the beginning of the project, so they do not represent mistrust, but rather verification. (Ronald Reagan was on to something when he said, "Trust but verify.")
• Spend the time to grow with the newly acquired expertise. Don't hide behind your old knowledge base.

5. Don't reinvent the wheel - use an architecture and standards. Insist on an architecture for the project, whether it be a data warehouse, e-commerce site or enterprise architecture integration project. An architectural plan, consistent with your existing infrastructure, will reduce the number of ambiguities in the Statement of Work.

If you have a set of corporate standards, insist that the consultants' deliverables conform to them; these standards should be in the rules of the game. If you do not have standards, or they are inadequate, make their creation or upgrade a key task at the beginning of the project. Your consultants can be pivotal in this task. If your consultancy downplays the need for standards, it's time to rethink your hiring decisions.

Today's e-environment requires applications and data to be integrated internally and externally. Current, enforced standards are a non-negotiable condition of survival.

6. Set up a ubiquitous communications platform. Constant communication is an easy way to facilitate the partnership with your consultancy. Projects tend to generate a plethora of documents, which contain decisions, explanations, and issues. Create a central repository, with access set up for all team members, to facilitate easy access and dissemination of these documents. All electronically created documents produced by the project should be filed in the repository. You should file any manual documents in a central location, with electronic notification sent to all team members of their availability.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

Develop standards for your communications process:

• Use mechanisms that highlight changes to make it easier for team members to see document enhancements. Microsoft Word's document tracking facility is very useful for this.
• Communication should be your goal. Encourage clarity and structure. Often project libraries are buried with poorly organized and written documents that merely serve as a cover in case of disagreements. What a wasted resource!
• Set up templates for meeting minutes, definitions, specifications, and requirements documents. These templates will make it easier to create, maintain, and read project documents. If documents are hard to read, no one will read them.
• Insist that documents be succinct and on topic.
• Develop a filing system that is intuitive and easy to negotiate.

In this column, I have explored six of the disciplines you can use to manage your relationship with your consultancy. In the next column, I'll discuss the rules of the game.