A very common situation faced by consulting and project teams is the addition of a new team member after the project is already underway. There are a variety of reasons for this situation: the project plan called for the addition of a resource at this point in the project, the scope of the project changed necessitating more resources, someone on the project leaves for whatever reason and the space needs to be back-filled, etc. Regardless of the reason, the urgency now exists to get the new resource ramped up and productive as quickly as possible. This assumes that the new resource has the necessary skill set to do the required job, so the key is to get this resource up to speed so that his/her skills can be leveraged as soon as possible.

This ramp up, or process of becoming familiar with the project, includes understanding the situation from a historic and high level and then drilling down to the relevant details about the client, project, management, team members, client participants, solution, and technologies. A fast and effective way to do this is to compile a set of information that can be reviewed within an hour or two with the new team member. I suggest that the day-to-day project manager complete the review with the new team member.

Of course, there will likely be some additional study time required to read and review relevant documentation so that the team member can be educated to the appropriate level. However, this orientation will also set the stage to make those types of activities more productive and effective.

The overall outline and flow of information is shown here in outline form with details and examples for each section. The overall objective is to provide information to new members so that they can walk in the door (being confident they know which door to walk in!) and do their jobs without being distracted. Ideally, they won’t be wondering what everyone else is doing, how their tasks fit in to the overall project, where the bathrooms are, or what political landmines they need watch out for. The following outline attempts to cover both the project-related business and technical information as well as the simple logistical issues one encounters when working at a new location or with a new group of people.

New Member Orientation Outline:

• Initiative Background and Overview
  
  
• Project Plan Summary (i.e., Time Lines and Deliverables)
  
  
• High-Level Solution Architecture
  
  
• Organizational Chart(s)
  
  
• Team Member Roles and Responsibilities
  
  
• Team Member Work Assignments
  
  
• Team Member Contact Information
  
  
• Communications Plan (Status Reports, Meetings, Tracking Documents, Information Sharing, Issues Log)
  
  
• Initiative/Client-Specific Policies
  
  
• Initiative/Client-Specific Logistics
  
  
• Initiative/Client-Specific Technologies and Standards
  
  
• Team Member Expectations

This information can be easily compiled into a slide deck of roughly twenty slides or so and reviewed in less than two hours. I recommend building one, then using it as a template that can be updated for each new project. To get a better idea of what is included in each section, I’ve included a more detailed description and/or some examples below.

Initiative Background and Overview

Describe the history of the initiative and why the team is doing the project. For example: How was your company or this group of individuals selected to do this work? What are the drivers behind the need for the project? What benefit is the company expecting?

Project Plan Summary (i.e., Time Lines and Deliverables)

This can include both a high-level Gantt chart timeline and/or a detailed project plan. It should also include the schedule of deliverables and milestones.

High-Level Solution Architecture

This is usually a diagram that shows the key physical components of the solution along with some description of what each component does within the architecture. For example, in a data warehousing solution, you would want to show the data sources, the ETL process from each, the database server(s), the reporting platforms, and any other significant components all in one picture that shows how they are connected and how they interact.

Organizational Chart

This organizational chart should include the project team members and the key people with whom they interface. If the team is integrated with other company personnel, consultants, and contractors, all appropriate people should be identified on the chart, along with the reporting hierarchy. It is also helpful to have the executive sponsor and project manager identified (if such positions exist for your project).

Team Member Roles and Responsibilities

This can be a simple table that lists each team member, the name of their role on the project, and some bullet points listing their responsibilities.

Team Member Work Assignments

Similar to the roles and responsibilities, this table lists each team member specifically and the actual tasks or deliverables they are working on. Team members may have more than one task. Some tasks may be in parallel and others may be sequential, so be sure to include date ranges with the assignments.

Team Member Contact Information

The contact information should include the primary types of contact, as well as backups. The primary contact types should include the phone number (cell or office) and email address. A trend that is becoming more prevalent for consultants is that their clients are insisting on issuing them laptops that have the appropriate security restrictions already configured. Additionally, the client may prefer that the consultant use the client’s internal email system. So the consultant may end up supporting more than one email, have a client office phone, and also have his or her own cell phone. The contact information sheet should list which email and phone are the preferred ones to use for this project. The secondary emails and phone numbers can be used when urgent contact is needed, but the team member is not reachable via the primary contact channels.

Another common communication channel is instant messaging (IM). It is useful to have team members all agree to use a certain instant messaging service, and then include IM user names in the contact information sheet.

Communications Plan (Status Reports, Meetings, Tracking Documents, Information Sharing, Issues Log)

This section can include several sub-sections. The key for this section is to help new members understand who they need to communicate with, what information they should be conveying, and where they can find information.

Team Status – Team status information is typically managed through status reports and team meetings. New members should understand when and what type of information they should be sharing with their project manager, and when and how the project manager expects to receive it. For example, the following may be the standard status reporting instruction for the team members:

Team members will submit one status report each week. Reports should be emailed to the project manager (ProjMgr@client.com), who will consolidate and post them in our shared document library that day and will also use these status reports to develop the weekly client status report.

Report due every Friday by 4:00 p.m.

• Planned work location(s) for the next week
  
  
• Meeting schedule, including participants, for the next week
  
  
• Planned tasks
  
  
• Deliverables due next week
  
  
• Issues/concerns/delays
  
  
• Tasks completed this week
  
  
• Other tasks worked on (in scope, out of scope)

Team Meetings – The standing team meetings should be identified. Required information should include when the meetings occur, location and/or dial in information (such as conference call number and code), participants, and discussion topics. Members should know what they will be expected to be prepared to discuss in these meetings.

Tracking Documents – Team members should be aware of what documentation is used to track project progress and manage project information. For example, the official project plan should be identified and its location and access defined so the team has appropriate access to it. Likewise, each team member should know how to create, read, and update issues in the issues log.

Information Sharing – Access to project information is vital to the smooth operation of the project. Most projects use some type of common location to store and share documents and information. Each team member should know how to access this shared location, how information is organized, and how to either use or store information at that location. Information stored on this site should include the project tracking documents (such as the project plan and status reports), background documentation, project work in progress, and project final document deliverables.

It is also important to set expectations about usage of this site and standards for posting documents and information. Make it clear if it is expected that everyone has their current work in process stored daily on the shared site, or if it is preferred to only post final deliverables. Also, clarify if each team member is expected to visit the site daily to look for group announcements or if group announcements will be emailed to everyone. A sample of communication protocols is shown here:

Purpose: Help ensure that communication actually occurs when needed and intended

• The weekly status reports will be stored in the document library on Monday by project manager.
  
  
• Each team member should regularly (i.e., several times per day) check their preferred email address(es) for new messages.
  
  
• Each team member should review the meeting schedule shared by the other team members to help ensure that redundancy is reduced as much as possible.
  
  
• All acquired and developed documents and materials should be stored in the project shared site by the team member who creates/manages the document.
  
  
• Anyone that will be out of touch for a period of time should notify the rest of the team via preferred email addresses.
  
  
• Be proactive in seeking help and sharing information.
  
  
• After looking for information on the shared site, check with project manager before making information requests in order to minimize redundant requests or requests for information we have already received.
  
  
• Keep chief architect informed completely of any and all architectural discussions and issues.
  
  
• Never discuss XYZ with the client! They are very sensitive to this issue. If it comes up in conversation, please refer the client to project manager.

Communications Protocol – Oftentimes in projects there are a number of clients that interact at different levels within the project team. To avoid the situation where people on the project are giving the client potentially conflicting information, it is a good idea to identify who on the project team should talk with whom on the client side. Each project will have its own unique set of circumstances that dictates the best way for the project team to communicate with the client; but whatever that plan is, it should be clearly defined for the project team.

Initiative/Client-Specific Policies

Each client will have its own set of policies that need to be followed by the team. These should be listed out clearly. For example, list the travel policies (such as preferred hotels, permission for travel, and meal reimbursement). The project may also have time tracking policies that should be clearly spelled out.

Initiative/Client-Specific Logistics

This section includes some of the simple little pieces of information that are often ignored because they seem obvious to those people who have been around for a while. Here is a sample of the types of information that could be addressed in this section.

Initiative/Client-Specific Technologies and Standards

Each client and project has its own set of technologies and technical standards that are being used. Here is a sample of what this section might look like.

Project Shared Site

• A shared project site has been established: http://www.sharedsight.com/project
    User name:
    Password:
  
  
• This site contains all project artifacts and appropriate client documentation

Technology

• Documentation:
• Project Management:
• Email:
• Calendar:
• Data Modeling:
• ETL:
• DBMS:
• Data Profiling:

Connectivity

• Lotus Notes – contact John Doe: 303-XXX-YYYY x232
• Network – contact Joe Dilbert: 303-272-XXXX x233
• Oracle Server – contact John Dilbert 303-272-XXXX x234
• Shared Project Site – contact Joe Smith 303-272-XXXX x235

Team Member Expectations

This section should discuss how the team members are expected to work on the project. Information should include expectations regarding level of independence within the team, types of decisions that must be run through the project manager, and quality of work expected to be delivered. Different people have worked in different environments with very different expectations. Try to make sure everyone on your team knows what you expect of them. You may be a manager who only wants to hear from a team member when an urgent matter arises, or you may be one who wants a daily status regardless. Your team members just need to know your preferences.

In my experience, these are the types of questions that come up with just about any project. Of course, you may have run across others, so feel free to include those as well. Also, include more or less detail as is appropriate for your project. By covering these topics with your new team members, they should quickly develop a comfort level with the team, the client, and the environment that will enable them to focus their energies on doing their jobs as effectively as possible.

Recent articles by Todd Saunders

• Business Intelligence Team Structure Phase Alignment