Five steps to integrating short-term consultants into your team

Your company expects to see clear benefits when it hires a consultant, whether in the form of a temporary staffing increase for short-term projects or in terms of expertise with emerging technologies. However, bringing a consultant on board doesn’t guarantee a successful project. Here are five points to consider when you’re looking to integrate “short-timers” into your team.

Clearly define the roles
If you are normally the lead developer and are used to running the show, you may need to share this mantle with the consultant. Even if your official role doesn’t change, clearly express to the team what the consultant will be responsible for. When delegating the responsibilities, consider these questions:

• Who is going to be responsible for shaping the overall system design?
• Do you expect the consultants to do this for you, or do you want them to code to your designs?
• Who will create test scripts?
• Who will manage change control? This includes more than just specific coding assignments; it is an agreed-upon division of responsibilities allowing everyone to claim ownership for his or her role.

Don’t skip these details even if you have used a particular consultant on previous projects. If you leave these questions unanswered, you open the door for potential problems.

Complete as much analysis as possible before the consultants begin
The consultants you hire may have the coding expertise, but they’re less likely to know your applications and business operations. For that reason, it’s crucial that you effectively communicate business logic to the short-timers. Unless your company is prepared to pay extra money for the consultants to do this research, or even worse, wait for you to do it, it should be completed before the consultants walk through the door. When I was a consultant during the Y2K craze, I was amazed at how much downtime we had while waiting for our client to complete project decisions and assign tasks. It’s fine for the consultant who gets paid by the hour, but it’s not so easy on your company’s wallet.

Take the time to complete this step early. It’s not only useful throughout development but will also improve the accuracy of project estimates. When you provide extensive business logic documentation, you steer both the company and the consultant away from oversimplifying a task. For example, if your original requirements only state, “Create a sales commission report,” the consultant is likely to come back with a small estimate. On the other hand, if your requirements are more detailed, as in “Create a sales commission report summarized by state with variable commission rates depending on salesperson experience and dynamic regional differentials,” the consultant should provide you with a more detailed—and more accurate—estimate.

Trust your own estimates
Even if your consultant’s proposal includes an estimate of time spent on development, your team should also complete an estimate and review differences between the estimates. A couple of factors can lead to an unrealistically low estimate: The consultant may want to please your company with an optimistic view of the completion date, or he or she may be underestimating the complexity of your business operations.

As shown in the previous step, you can control the second factor by having thoroughly documented requirements and business logic. Your only chance for catching an optimistic estimate is to complete your own estimates and evaluate the differences with the entire team. Even if estimates are adjusted throughout the project, people tend to remember the first estimate and use it to set expected deadlines.

Help them turn the project proposal into reality
On larger projects, consultants will often put together a formal proposal. These documents can include high-level project plans, methodology, and standards. Once management has signed it, keep the document readily available and updated during the project lifecycle—it won’t be useful to anyone tucked away on someone’s hard drive. Everyone on the team should keep it out and use it as a living project document that serves value beyond winning your company’s business.

With everyone aware of the goals and plans, you’ll be far more likely to avoid false assumptions that could jeopardize the project. If the proposal includes project management practices, coding standards, or testing strategies, it’s important to enact those plans and ultimately get what your company is paying for.

Document issues throughout the project
Projects that use consultants tend to be higher profile, and their progress and budget will likely be scrutinized. It’s wise to keep a journal throughout the project. Doing so takes only a few minutes at the end of each day. Note accomplishments, roadblocks, solutions, changes, and any other team issues.

If your team has clearly defined each individual’s role, established thorough requirements, and completed accurate estimates, then the documentation step can be used as a reference to your success, a precedent for future work—and great material for your next review. On the other hand, if your team is not so fortunate and encounters Murphy’s Law at every turn, this documentation will be critical to learning from the experience and, of course, will allow you to CYA as well. (For those of you unfamiliar with CYA, a project management instructor once told me the politically correct version: Cover Your Anatomical part.)

I hope you find these steps helpful and can add to them with lessons you’ve learned on your projects. The steps are based on two common themes: First, the extra effort you spend preparing for a project improves your chances of success by preventing surprises. And second, success with consultants is a two-way street; they can only succeed if you make it possible.