Expert Consultants

Expert consultants are available to solve every conceivable type of problem. These consultant engagements tend to be for a shorter period of time than with a staff augmentation model. Because expert consultants have highly specialized (and often high-demand) skills, and the engagements tend to be for a shorter term, expert consultants are more expensive than consultants in a staff augmentation model.

Expert consultants come from two sources. Some consulting firms offer expert consultants in various areas because this is their primary line of business. Some vendors may also offer expert consultants. These consultants specialize in the tools and technologies offered by that vendor. Both of these are discussed in detail next.

Expert Consultants from Vendors

Depending on the vendor's business model, its consultants may command a premium. These vendors do not want to be in the consulting business. They offer consulting services strictly to promote use of the tools and technologies they offer. Another contributing factor to the higher rates from the vendor is the perception that the vendor is the best (and perhaps the only) source of expertise. This is not always the case. Many vendors have partnership arrangements with companies that offer the same consulting services. If cost is a limiting factor, consider using a partner company as an alternative source. It's not uncommon for these partner companies to have former employees of the vendor. This allows you to purchase the same expertise at a significantly lower rate.

Is there a risk in using a vendor's partner at a lower rate? One concern is if the tools or technologies from the vendor are new or unproven or are being used in an unusual way. The vendor's consultants will have more extensive resources to call on if problems occur. Otherwise, a partner's consultants provide a better value. Another possible reason to use a vendor's consultants is if your project (or other projects in your company) includes plans for future purchases from that vendor. In this situation, the vendor will bend over backward to ensure that the current engagement is as successful as it can be. Sometimes, the vendor will compensate partner companies for their involvement in promoting future sales as well. Be honest with your vendor. If you don't anticipate future sales, say so.

Getting the Best Value from a Vendor Consultant

Given the high cost of vendor consultants, it is important to make their time as productive as possible. To assist in this endeavor, consider the following:

• Keep the task well defined, with a clear entry and exit point. Make it clear what the objective is, and provide a written statement of the objective before the scheduled engagement.

• Work with the consultant to map out a schedule of events and tasks.

• Be prepared and ready for the consultant. Ask the consultant prior to the engagement what needs to be in place for the engagement to be a success. If the consultant will be conducting knowledge transfer sessions with your staff, ask if there is anything your staff can do to prepare ahead of time (such as receiving additional training and reading documentation).

• Make sure the consultant has access to any needed resources. For example, if the consultant will be installing software, alert a system administrator that you may need her services. That way, if the consultant runs into problems with a server, the system administrator can immediately work on the problem. If the consultant has idle time because of an environment problem, she will still charge for that time. Furthermore, if the consultant has to troubleshoot problems other than the intended ones, she might be working outside her area of expertise. This is inefficient and a poor use of the consultant's time.

• At the conclusion of the engagement, have the consultant deliver a write-up detailing her activities, any conclusions and recommendations for the next steps, and the current status of the work performed. This is important, because it represents a formal conclusion to the consultant's work. This is the last opportunity to ask questions and verify understanding.

As an example, on one project, a certain Commercial Off-The-Shelf (COTS) tool was chosen to produce reports based on information stored in an Oracle database. After the tool was chosen, it had to be installed and configured. No one on the project team had expertise with the tool. Training was scheduled, but it was at a late date. The project schedule indicated that the team would need to start working with the COTS package immediately after training. This left no time for the project team to install and configure the product.

A consultant from the vendor was retained to provide these installation and configuration services. Over a four-day period, the consultant installed and configured the software with a member of the project team "shoulder surfing." The project team member took notes and asked questions during the engagement. A problem was discovered with some settings on the server, which a system administrator quickly corrected.

At the conclusion of the engagement, the consultant created a summary write-up of the installation, all the settings determined at installation, and other pertinent facts. The project team members took this write-up to the training class. As a result, the project team was ready to use the product immediately after training, and they were highly successful.

Another example using an expert consultant involved technology rather than a specific vendor product. In this example, the project had a requirement that the user interface must be Section 508-compliant. Section 508 involves designing the user interface so that it can be used more easily by the vision-impaired. In addition, this application had to present a tremendous amount of information and allow users to act on it. Finally, the users of this application were minimally fluent with modern IT systems.

The project team was struggling with two issues. First, no one had experience with designing Section 508-compliant user interfaces. Second, the team had built prototype user interface screens. The problem was that the amount of information on the screen made the user interface complex. The prototype was presented to users, and the reaction was mixed. The team was having difficulty figuring out how to architect the user interface in a way that would make it easy and intuitive. The solution to both of these problems was found by retaining an expert consultant. A consultant was found who had experience with designing Web sites. The consultant had also built many Section 508-compliant user interfaces. What distinguished this consultant from many others was his extensive art and graphic-design background. It was a perfect fit.

During initial meetings with the consultant, the project team demonstrated the user interface prototype. The problem given to the consultant was threefold. First, we wanted to build a new user interface based on the prototype that would be Section 508-compliant. Second, we wanted the consultant to use his graphic-design background to design a user interface that was aesthetically pleasing and that would be easy for novice users. Finally, we wanted the consultant to deliver his work in the form of screen templates that could easily be used by the project team. The result was a user interface design that drew raves from the user community and that met the requirements for Section 508. The consultant documented how to use the templates and met with the team to review the document's contents.

Both of these examples were successful because each had a clear entry point and clear objectives to be accomplished. Also, the work performed by the consultant in each example was directly related and constrained to his primary area of expertise. In the second example, although the consultant was asked to indulge himself creatively, the prototype he received as input was helpful to illustrate the system's general concept and to provide focus for his efforts.

Expert Process Consultants from Consulting Firms

Some consulting engagements are less focused than in the preceding examples. A consultant can be an excellent resource for helping a project team shift to a new paradigm. Years ago, the new paradigm was object-oriented analysis, design, and programming. Today, a common goal of project teams is to move toward modern processes such as iterative and Agile development. The transition from one process to another is a major one, and most organizations struggle with it. Even with training, the circumstances on each project differ enough that a training class is insufficient. You need an experienced practitioner to guide the organization. These engagements tend to be fairly long-term (perhaps for the project's duration), and the consultants work closely alongside the rest of the team.

Choosing a Project Suitable for Working with a Process Consultant

Before you decide whether to work with a process consultant, you must choose a suitable project. The following characteristics are important when you select a project:

• The project should not be in the critical path of other important projects or events. Most companies choose an internal project for this purpose. By choosing an internal project, the company has complete control over schedule, cost, and staffing. Despite the project's noncritical nature, it should still be technically challenging and produce something of importance.

• Staff the project only with people who are interested in and motivated to learn a new process. They should expect some uncertainty on the project and should be willing to work with a consultant.

• The project must be one in which management is comfortable with an outside consultant being involved in every aspect of the project. To properly advise the project, the consultant needs to understand the project requirements, help develop the schedule, and understand the qualifications and capabilities of the people staffing the project. The consultant will be working closely with the project manager.

• The project should have flexible deadlines.

• The company's management (as well as the project's managers) should be willing to commit the time and resources required to achieve the project's goals. Changing a process is a difficult undertaking that involves cultural change and learning new ways of accomplishing a project's goals. Management must also have an interest in the outcome and be committed to the goals. I have seen too many of these efforts fail because of this one item. It is more than simply learning a new skill. It is a change in the organization's culture.

First Steps of a Process Consultant

Suppose your company has decided to change from traditional Waterfall lifecycle development to a modern methodology such as iterative or Agile. Before the project begins, the consultant must perform a significant amount of background work. The consultant must conduct an organizational assessment. This consists of the following:

• A review of the current process used on software development projects (if there is one). What methodologies, technologies, tools, and techniques are used on the project?

• A review of the track record on previous projects. What have the successes been? What have the failures been? What is the clients' satisfaction level?

• An analysis of any failures that have occurred. This takes some time to prepare, because the consultant must interview a number of people to understand the problems. It may be difficult, because there may be disagreement regarding the cause of the failure.

• An analysis of the skills of the people staffing the projects. It is important that the consultant be discreet during this activity. You do not want project staff believing that the consultant's purpose is to eliminate staff members. Even if a staff member's skills are insufficient for the role he plays on the team, his skills could be upgraded, or there may be other new roles for him on the project team.

• The consultant must develop an understanding of the organization's business goals and how the ability to develop software affects the accomplishment of these goals.

• The organization might want to focus on particular areas first. For example, it might want to improve its practices in one of the disciplines used in software development configuration management, requirements management, change management, or testing. In fact, some consultant engagements, at the client's request, are limited in scope to a specific problem in one or more disciplines.

• Any other issues, at the request of the client, should be prioritized and investigated.

Second Steps

The consultant should prepare an implementation plan for the organization and submit it to the organization's management for approval and comment. The implementation plan is the instrument that explains what is to be accomplished, by whom, and when. It is essentially a project plan defining the work the consultant will perform in conjunction with the team. Each consul-tant's implementation plan varies depending on the situation. The consultant probably has a template that will be used for the implementation plan. At a minimum, the implementation plan should contain the information described in the following sections.

Background

This section explains the work performed during the organizational assessment. If a separate assessment document was prepared, it can be referenced from this section rather than repeating the information. This section should describe what was done to assess the organization. It should answer the following specific questions:

• What was the assessment's primary purpose? Did it have a specific focus?

• How was the information for the assessment acquired? Were specific artifacts reviewed? If so, list them.

• Who was interviewed for the assessment, and how were they chosen? What are the roles of the people interviewed?

• Were any previous projects reviewed for the assessment? If so, which projects were examined, and why were they chosen?

• Explain the organization's goals. In other words, why has the consultant been asked to work with the organization?

Findings

This section describes the results of the assessment effort. The information in this section should identify any gaps in the existing business processes. Questions answered here include items such as the following: Are any activities missing or insufficient? What areas need improvement? How do these findings relate to the goals listed by the organization? Also, what processes are working correctly? In other words, what should not be changed? Most assessments seem to omit this information. Even the most dysfunctional organizations have something positive that should not change. This needs to be mentioned so that these items will be preserved. Also, given that the primary purpose of the assessment is to identify areas that need improvement or correction, the organization should be reassured to know that it is performing some activities correctly.

Recommendations

This section should list the recommendations the consultant has for the organization. It takes into account the findings and also the organization's stated goals as described in the background section of the implementation plan. This section should discuss the following information:

• Recommendations on various solutions to close the gaps discovered in the Findings section. This should be a prioritized list, beginning with the most important items. Under ideal circumstances, it would be best if every recommendation could be followed. The reality in most situations is that time and resources are limited. Therefore, it is important to focus on the most important changes first and follow up with the lower-priority changes as time and resources permit. An explanation indicating why the priorities are in the order given is important as well so that the organization can weigh the possible consequences of reordering the list or skipping the higher-priority items.

• A complete set of recommended tasks, including process changes, staffing adjustments, training, and acquisition (such as purchasing a configuration management or requirements management tool). Each recommended task should be tied back to the gaps identified and explain how the task will help close the gap. If training is recommended, what specific classes are recommended? Is a particular vendor's class recommended? How much does the training cost, and who from the project team should attend?

• Sequencing. Should the tasks be conducted in a particular order? Depending on the complexity of the tasks, it may not be possible or reasonable to attempt every task at once. A phased, or iterative, approach may be indicated.

• A list of the risks involved through implementing the tasks. What items should be in place before the tasks are undertaken? What could go wrong, and how can the risks be mitigated?

• Unrealistic goals. Has the organization stated goals (listed in the Background section) that are unreasonable or unattainable given the current set of circumstances? What must change first so that these goals are attainable?

• Missing goals. Did the organization fail to list any goals that should be considered? What should the priority of these new goals be, and why should they be considered in addition to the other listed goals?

• Goal conflicts. Did the organization list any conflicting goals? If so, why are the goals conflicting? Which goals should take precedence?

• Cost. What is the anticipated cost of implementing the recommendations? How long will it take to implement them? Are additional resources (besides the consultant) needed?

Presenting the Findings and Recommendations

The organization should expect a presentation by the consultant after management has had a chance to review the implementation plan. The presentation lets the organization ask questions to better understand the assessment and the implementation plan. Members of the organization should carefully review the documents supplied by the consultant and consider each of the recommendations made. Any questions should be formulated and asked during the presentation. To put it another way, the client needs to prepare for this presentation. This is an opportunity to correct any misinformation and to shape the implementation plan to better fit the organization's needs.

Third Step

After the organization has had a chance to attend the presentation and ask questions of the consultant, it must decide which recommendations, if any, to implement. This can be communicated to the consultant through a follow-up meeting. In addition, cost factors are often discussed at the meeting as well. Finally, a start date for the engagement should be discussed.

Fourth Step

After the consultant has been told which recommendations have been accepted and a requested start date for the services to begin has been determined, the consultant prepares a detailed schedule for the tasks to be conducted. This includes a list of the staff members who will be involved in the various activities. A list of assumptions and an updated risk list, along with the risk mitigation plan, should also be included. This package is submitted to the customer for approval. Then, it is time for the consultant and the project staff members to roll up their sleeves and begin work.

Working with the Consultant

Several artifacts have been generated: an assessment document, an implementation plan, a risk list and mitigation plan, and a schedule. On the start date, the project team should meet. The project manager should lead the meeting, with the consultant in attendance. Those project team members who have not met the consultant can be introduced. The implementation plan should be presented to the team. The consultant should explain the plan and go over the schedule. The team will probably have questions, which can be answered in this session.

With the preliminary introductions and orientations out of the way, it is time to begin the tasks. The following are suggestions for getting the most benefit from working with the consultant:

• The project team should review the list of risks and assumptions shown in the implementation plan. The project team should ensure that any dependencies and contingencies have been satisfied. This includes any training the consultant has recommended before work commences, any recommended software procured, and so on.

• The project team should review the schedule. Each member of the team should examine the schedule for any activities assigned to him and prepare to be ready to conduct those activities. In other words, don't wait for the consultant to tell you what to do. Take the initiative and prepare ahead of time. For example, if the next activity involves working with the consultant to identify candidate use cases for the project, start familiarizing yourself with any requirements and stakeholder requests you already have.

• The project manager should instill a sense of urgency in the project personnel. Even though this project may be an internal project, it is still important to set goals and deadlines just as you would for any project.

• Try to anticipate things that may go wrong, and have an action plan ready to solve problems that arise. If an activity involves installing and configuring software, have a system administrator available on standby in case a problem occurs with the system or environment.

• Be sure to document any important experiences or lessons learned from the consulting engagement. This information can then be reviewed later or placed in the project's history file. (This is discussed further in Chapter 15, "The Project Postmortem.") On many projects, schedules are hectic; if you don't document this information, the key lessons learned may be forgotten. Some consultants provide their own summary. However, you should still take notes to provide your own summary.