With or Without You, Part 2

Laying ground rules is the most important factor in working effectively with consultants

By Moshe Japha

Bringing in a consulting firm can be an effective way to ensure a timely, cost-effective response to strategic business intelligence requirements. But if you think choosing the right consulting firm is all you need to do in order to reap these benefits, you're in for a rude awakening. In part one of this column ("With or Without You," Oct. 20, 2000), I discussed six disciplines for successfully managing your partnership with consultants. These are:

• Involving the business throughout the project. Your systems model business processes. An incorrect understanding of the business processes will doom any strategic IT effort to failure. Although IT pundits have been preaching this principle for decades, it still is the most difficult for organizations to apply.
• Building knowledge transfer into the project from day 1. Use the consultants' knowledge and skills as an onthejob training course. The pain in letting your key people delve into the project will be dwarfed by the benefits. You are paying for knowhow; don't let it walk out the door.
• Owning the project and the work product. The client, not the consultant, must be the project driver. Key decisions and direction must come from either the sponsor or a knowledgeable designee. This person must be involved on a daytoday basis with the project's progress and issues.
• Not being intimidated by lack of knowledge. Staying on top of the project will sometimes take the client into uncharted waters. Ignorance begets fear and panicinspired decisions. The client must stretch to keep abreast of new paradigms and technologies the project employs. Daily involvement will make this task much easier.
• Not reinventing the wheel instead, using an architecture and standards. Employ your shop's existing standards and architecture. If you don't have any standards, then an early project task should be to develop them. Integration and constant business change require a well thoughtout plan for how your hardware, applications, and data fit together and will grow in the future.
• Setting up a ubiquitous communications platform. People issues are always stickier than technical ones. The first step in tackling them is timely, easy communication of project progress, decisions, deliverables, and issues. Setting up a central repository for documents, easytouse templates, and standards goes a long way to facilitating the communications you'll need.

In this article, I address the final and most critical discipline: the "rules of the game" that govern your relationship with consultants.

The Rules of the Game

The keys to a successful relationship with consultants are a clear understanding of where you're headed and a plan for getting there. Whether you contract with your IT department, your users, or a consultancy, what you do not specify in the "rules" can kill you. In fact, vague, ambiguous governance is a symptom of vague, ambiguous plans. Doubt and misdirection cost dearly in the resources you can least afford to waste: time and money.

Now, of course, you often don't know the details. Your initial project may be specifically to develop them. That's fine. You still need to specify your deliverables, the criteria of success, timelines in which you will deliver, the assumptions you are working under, the roles and responsibilities of the players involved, how change will be managed, and how disputes will be handled.

If I have to do all that, why bother? Because, it doesn't matter who is executing the project; someone must figure out these details. You can either plan for them or let them be driven by panic and confusion when they take you by surprise. Internal organizations fool themselves into thinking they can avoid these details. The costs are just easier to hide when an invoice for hard cash doesn't have to be paid.

So what does it take to make it work? Let's explore the components of the rules of the game:

Deliverables: What is going to be created by the effort? How does each deliverable contribute to the project's objectives?

It may seem obvious that you need to know what you're producing. However, once you start specifying the details, you gain tremendous insight into the issues and intricacies you face.

1. You must define what is to be produced, whether it is a plan, a model, prototypes, or a fully functional system. People often organize these deliverables into a Statement of Work. Specify how each deliverable contributes to the overall project objectives and fits in the logical progression of the project. This exercise helps develop a workable project plan.

2. Plan for your deliverables to be due throughout the project. These deliverables represent key milestones to ensuring the project is on track. Often, as deliverables are developed, change requirements surface. The earlier they are identified, the easier it is to negotiate changes to plans, contracts, and schedules. Very long tasks tend to be poorly defined and estimated, and are often work-time black holes.

3. Each deliverable must have a client team member, knowledgeable in the deliverable's purpose and goals, sign off on the deliverable. Timely review and sign-off is as much on the critical path as development of the deliverable. Delays cost here. However, this should be a nonevent, as the reviewer should be involved with the developing product all along.

Criteria of Success: How do you know you are done? How can you measure if the deliverable is good enough to meet the objectives? There is often a point after which incremental investment of time or money does not pay.

To ensure an objective measure of acceptability, the rules should specify what constitutes a complete, successful deliverable. It is sometimes useful to define what is not included. (See Table 1.)