1. Know what you want.

2. Trust the consultant.

3. Treat the consultant as a partner.

That's all there is to it. Really. Admittedly, I have glossed over the part about finding a good firm with which to work. But debating the criteria for choosing a consultant is the subject of a different discussion. For now, we are concerned about factors that can positively influence the outcome of an outsourced project.

That sounds really simple, doesn't it? Yet this single item is the first point of failure on many outsourced projects. You know your business. You understand how it works. You know all you need to make your business perfect is to create a Web application that will integrate your legacy mainframe policy application with your CRM software and the new time and billing application. Or it may be even easier than that. You may be running a single-location agency, and all you "need" is a Web site that will drive more business to your location. So, you hire consultants, sit down with them for about an hour, and wait anxiously for their proposal to build out your project. Correct?

There are two different approaches to determining the scope and deliverables of an IT project. You can assemble an in-house team of subject matter experts (SMEs), IT staff, and decision-makers to create:

o A business case for the project.

o Use cases that describe the project in detail.

o Detailed inputs and outputs expected.

o Deliverables required to achieve the goals of the business case.

o A functional map of the project.

With this information in hand, you can produce a request for proposal (RFP) and ship it out to a number of vendors on your A list to see which comes back with the best plan at the best price. On the surface, this approach is good. No one knows your business like you. No one can understand your needs like you can. You have involved all of the stakeholders, so you have all your bases covered. Right? Maybe.

There are a couple of pitfalls with this methodology. First, it takes a truly dedicated team to make it work. You may use hundreds (or thousands) of hours of corporate resources pulling it all together from employees who already have full-time jobs. The resource cost is significant. Second, if you just turn over a set of requirements to a vendor and say, "Build it," you run the very real risk you have missed something. You actually may be too close to design the project properly. Without an in-depth knowledge of your business, the vendor may or may not catch the missed requirement. If the vendor does catch it, you are faced with a change request and concurrent change in budget. If it isn't discovered until delivery or late in the project, you have a failed project that will be blamed on the vendor.

A second approach is to retain the consultant early on to define and design the project for you. You provide broad marching orders and turn your SMEs over to the vendor, which essentially creates your RFP. This process has the added benefit of closely involving the vendor in your business before a project reaches implementation stage. A vendor that understands your business is better equipped to recommend and build a solution. This used to be called systems analysis. The downside here is it is expensive. The hourly rate charged by the vendor probably is going to be higher than your internal rate. It also easily can lead to a much bigger project than is really needed. If you put a vendor in front of an SME and that SME tells the vendor he needs XYZ, the vendor will design a project with XYZ. That may or may not be a good thing. In fact, XYZ may not be necessary to the success of the project.

Then there is the perceived value of such an exercise. An in-depth, nicely bound report and recommendation generated by this process ends up on the desk of the CEO, who can be heard muttering: "We paid $XXX for these guys to tell us all this stuff we already know!" And the only answer is yes, collectively you knew everything in this report, but it was not available in a documented, cogent fashion that could be used to create an IT project. However true these statements may or may not be, the project already is off to a bad start.

In fact, the best projects use a combination of the above methods. You need to do your homework so you really do know what the high-level goals and deliverables of the project are before you bring in a consultant. You must build most of those artifacts listed in the earlier bulleted list.

Once you engage vendors, you should expect those vendors to validate these requirements. They will want to meet with the same SMEs and stakeholders as before, but in this case, they will be validating and building on your framework. The vendors then should return their own design document to you so, independently of the vendors, you can validate their understanding of your needs and requirements. When both parties agree on the scope, design, and deliverables of the project, you have set the stage for a successful engagement.

I have seen countless projects that begin with a list of "nos." A consulting firm is retained, and then it is told it really isn't going to be allowed administrator rights on a server or sysadmin on a database. It is told having service accounts with nonexpiring passwords sounds great, but Sarbanes-Oxley has made that impossible–at least that was the excuse. This is a true story. A software application that was used by some 20,000 people globally was down for hours because the password on the service account expired. To further exacerbate that problem, a request for multiple service accounts was disallowed (once again because of SOX), and so, when that service account went down, it took down Web applications, database connectivity, and middleware. I was told only certain god-like individuals are allowed to terminal onto a server and I should just say what I need.

I once was at a major insurance carrier installing an application on a staging Web server (which was sitting on the floor of the cubicle I was visiting). In my frustration, I actually touched the keyboard and started to type in some necessary commands. I was instructed under no circumstances was I allowed to touch the keyboard. I had to dictate my needs to a sysop whose typing skill was even worse than mine (and that is no mean accomplishment). I can't imagine what type of security this company enforced at its data center. Ex-Cali Cartel enforcers with Kalishnikovs? The point is, do not throw unnecessary roadblocks in front of a consultant trying to do a good job for your organization.

If you aren't going to trust consultants on your database server, then don't hire consultants to do any database work. If you are building Web applications, don't keep them off your Web servers. Once you begin to tell a vendor that it cannot use the tools it needs to do its work, you have sabotaged the product. Of course, you will blame the vendor when the project is late or fails, but where does the fault really lie? Would you expect your landscaper to manicure your lawn in the dark with a yard-sale mower and half a tank of gas–and then complain when the results aren't perfect? Of course not. That sound silly, but that is exactly what happens in many software projects.

The whole concept of trust also involves fulfilling all the needs of the vendor and the project. If the signed specifications call for a dual processor dual core 64 bit physical box with 16GB of RAM ready on the third day of the project, don't deliver a single processor 4 GB VM on Day 16 and say it is out of your control. That is, don't do it if you want a good project.

You need to treat your consultant as a partner, not as a hired resource. In a partnership, everyone benefits from success. If a consultant is treated as a hired gun, you probably will get exactly what you pay for but no more. You retained a consultant in the first place because you did not have the resources available to complete the project. Listen to your consultants. In most cases, they will have significant experience in various verticals and in various organizations solving the same sort of problems with which you are faced.

Working collaboratively with a skilled team is by far the best way to work (think Manhattan Project). Conversely, do not hesitate to distance yourself from a vendor that arrogantly dictates the "best" way to do everything. Nobody knows the best way to do everything. Good vendor/client relationships are characterized by the realization that to complete the project successfully, tasks A to Z will be accomplished. Who actually accomplishes those tasks is largely irrelevant. The vendor and the client collaboratively will manage the project and collaboratively decide who accomplishes a particular task, when it is accomplished, and how the vendor is compensated for that task.

Consulting firms are an absolute necessity in a world where IT needs can turn 180 degrees every few years. Don't fear consultants–embrace them–but not until you have laid the proper foundation and established a mindset and culture that will foster success. After all, it is you and your organization that stand to gain or lose the most. Next month, next year, your consultants already are engaged with their next client. You will be basking in the glow of a successful project–or working on your r?sum?.