By Edward V. Berard
The Object Agency, Inc.
[This article originally appeared in the September 1993 issue of the Journal of Object-Oriented Programming.]
Your company or organization has decided that object-oriented technology (OOT) is critical to their future success. However, they have no real experience with OOT, and are unsure about the best way to proceed. A little research reveals several options, e.g.:
Maybe your company or organization is already applying OOT to real projects. Some may be currently working on their first OOT project, and still others may have already completed one or more object-oriented projects. However, your collective experiences have lead to a whole new set of questions, e.g.:
Again, you have all the options (and their corresponding problems) that we mentioned earlier.
One solution for both of the above situations is a consultant, specifically a consultant versed in one or more areas of OOT. There are, however, a number of different views as to just what exactly a consultant is, e.g.:
A common view is "the consultant as an oracle." Consultants, like oracles, are supposed to possess great wisdom. This wisdom is usually based on a mixture of research, training, and (most importantly) real-world, hands-on experience. Consultants filling the role of oracle do not perform the work of their clients, but, rather, guide the efforts of their clients. This requires both an appropriate understanding of their clients' needs and the timely dispensing of advice.
"Job shoppers" are relatively highly-skilled, temporary workers. Unlike "oracles," job shoppers perform project-related technical or managerial work for their clients. Job shoppers are commonly thought of as having both above average skills and a wide variety of experience. Unlike more permanent employees, job shoppers are usually hired for a specific task or project, and are often terminated upon completion of the task or project. Although they are well-paid, job shoppers are expected to provide their own benefits, and handle their own taxes.
It is common practice to refer to job shoppers as consultants. Although, unlike "oracles," job shoppers are often hired to accomplish, rather than guide, a particular task or project.
Trainers are often asked to provide advice as a normal part of the training effort. In an industrial setting (as opposed to a university setting), trainers are frequently asked about such things as programming languages, compilers, computer aided software engineering products, hardware configurations, management issues, and technology insertion. It is also not unusual for a trainer to be asked to comment on existing and planned in-house development efforts.
While many trainers might be eager to volunteer an opinion, those asking for that opinion should keep in mind that trainers may lack practical application of the skills they are teaching. Trainers are not required to have hands-on experience in the material they are teaching. (Remember the oft-quoted adage that "those who cannot do, teach.") To be sure, there are trainers who possess a significant amount of real world project experience. When asking the advice of a trainer, you should always ask about the background of the trainer.
Most organizations make the same mistake with consulting that they do with training, i.e., they try to delay it until the very last minute. For example, many companies delay the choice of an object-oriented methodology until their first object-oriented project has already begun. (These people usually also make the mistake of delaying training in an object-oriented programming language until the beginning of the coding phase of the life-cycle.) Consider the following:
One very large project with which I am very familiar had to re-engineer every existing in-house software development methodology document to accommodate object-oriented technology. This re-engineering took place during a real project. Needless to say, the software engineers did not appreciate the almost daily methodology and documentation changes.
On the other hand, there is a very short "half-life" for technical knowledge. If the training or consulting is provided too far in advance, and there is no time allocated for practice and changing of business practices, much of the knowledge provided by the consultants and trainers will be lost. The general guideline is to provide yourself with as much lead time as possible (giving you time to make choices), while at the same time making sure that you get as much hands-on practice as possible.
Of course, some consultants are brought in when things have gone horribly wrong. In these cases, the consultant is usually asked to diagnose the specific causes of the problems, and to either conduct a "post mortem" project analysis, or to recommend specific "fixes" for the problems.
There are consultants for just about every niche within OOT, from object-oriented database systems to the testing of object-oriented software. Some focus on the overall approach to the engineering of a software product, while others limit themselves to a particular programming language. Still others emphasize the management of an object-oriented effort. There are quite a few who specialize in the design of graphical user interfaces (GUIs).
If you are considering the use of a consultant, your first task will be to decide when and where you will need the services of a consultant. If you are adopting a systematic approach to the engineering of object-oriented software, for example, you may wish to identify a consultant for your chosen methodology, e.g., Rumbaugh, Booch, or Coad and Yourdon. A consultant for the management of an object-oriented software engineering effort, and a programming language consultant are also among the many possibilities.
If you are using more than one consultant, or more than one consulting organization, it is a good idea to strive for a good deal of compatibility in the advice you will be receiving. If you plan your selection of consultants ahead of time, you can encourage them to talk with each other regarding your project. Let your consultants know that you wish to keep conflicts in advice to a minimum. The more consultants you plan to use, the more difficult it will be to coordinate their guidance.
The one thing that a good consultant is more likely to have than your own in-house staff is perspective. This perspective is gained through the experiences of the consultant working with many different organizations and projects, and through the consultant's own object-oriented development efforts. Always ask to see a prospective consultant's client list. Realize that while the consultant may be bound by non-disclosure agreements, he or she should be able to provide you with discussions of how other organizations solved problems similar to your own.
Every consultant has their own set of biases. (Remember, you are hiring them for their opinions.) Take the time to understand the biases of your potential consultants. For example, do they favor a particular object-oriented programming language, do they advocate a particular object-oriented design methodology, are most of their experiences with one specific object-oriented database system, and do they seem to prefer one specific OO CASE tool? Be especially careful to ensure that you know about any financial interests that the consultant might have in recommending a particular product or service.
Technology insertion is the process of putting in place the knowledge, processes, tools, and techniques associated with a technology at a given location. Technology insertion is accomplished via properly trained professionals, an adequate and appropriate set of good quality tools, well-defined policies, procedures, and standards, and a sincere and continuing commitment on the part of management. People sometimes refer to technology insertion as "technology transfer."
One of the ulterior motives that many organizations have for hiring a consultant is technology insertion. Specifically, they want their in-house staff to acquire enough of the knowledge and skills provided by the consultant so that they will need less consulting in the future. Some consulting organizations even pitch themselves to prospective clients using technology insertion as a lure, e.g., "After your staff works with us on this first project, they will have acquired the skills to do it on their own for any future projects."
If one of your goals in hiring a consultant is technology insertion, make sure that you have a technology insertion plan before the consultant begins work. You need to know exactly what technology will be inserted, how it will be inserted, how successful the consultant thinks the technology insertion will be, and what factors will influence this success. If technology insertion is important, avoid consultants who cannot provide you with this information.
Watch out for "coding mercenaries." These are consultants who have little respect for the way you do business. They take almost no interest in your own in-house OOT standards, any training that your staff may have already received, and in technology insertion. They work very long hours, produce what (at first) look like elegant solutions, collect their money, and depart. Only after they have gone do you discover that: there is virtually no documentation, what documentation there is is out-of-date, standards have been ignored, and, overall, you do not have what you thought you had.
Consultants must have excellent oral and written communication skills. If the consultant is being hired with technology insertion in mind, you will get better results if the consultant is an effective communicator. Even if technology insertion is not a goal, both their progress reports and (most importantly) the products of the consulting effort (e.g., design documentation and source code) must be of very high quality.
During the interviewing process, make sure that your consultant knows that he or she will be expected to produce regular detailed progress reports. Also, stress your interest in quantifiable goals, e.g., what products will be available by what time. Some consultants think of themselves as "free spirits" or "software stylists." They have difficulty functioning in an organized environment. Once the consultant is hired, carry through with your requests for progress reports and quantifiable goals.
Good consultants always try to work themselves out of a job. Specifically, while providing excellent products and/or services, they strive for both effective technology transfer and results that are easily understood by those who need to understand the results. Unfortunately, some consultants are like drug dealers, i.e., they attempt to make an organization highly dependent on their products and/or services. It is the responsibility of those hiring the consultants, as well as the consultants themselves, to minimize these dependencies.
Some consulting clients, on the other hand, appear to use consultants as "security blankets," i.e., they insist on using consultants even when the consultants are clearly not needed. Just the physical presence of the consultant seems to be very reassuring to these clients. A good consultant recognizes when this is happening and takes positive steps to lessen the client's over-reliance on the consultant.
A general rule of thumb is to use consultants sparingly. Clients should work with consultants to determine when and where the consultants can be used most effectively. Further, consultants should be made aware of both other consultants on the same project, and any project-specific and organization-specific technical training. This should make the consultants' efforts more effective, e.g., conflicts will be avoided and duplication of efforts will be minimized.
An important component of technology insertion is staff confidence. At, or before, the conclusion of the project, the technical and managerial staff should feel comfortable with the technology that the consultant is supposed to be inserting. Heavy use of a consultant can result in lower staff confidence, e.g., were we successful primarily because the technology was effectively inserted, or primarily because of "consulting wizardry?" Consultants must take positive steps to ensure that the technical and managerial staff feels confident with the new technology, and that the staff can repeat their success on future projects.
Make sure that you are achieving your intended goals. Weekly progress reports furnished by the consultant should clearly and quantifiably describe progress towards the goals you identified when you brought the consultant on board. These reports should also describe any problems related to achieving these goals, and should also contain suggestions for resolving these problems.
It is often easier to quantify costs than it is to quantify benefits. The costs of a consultant begin with the consultant's daily or hourly fee, and any necessary travel and living expenses. There are other costs, including such items as materials, office space, and phone charges. Some costs may be somewhat hidden, e.g., staff time spent explaining and otherwise interacting with the consultant.
A consultant may advise that certain business practices be changed. If an organization takes this advice, this is not a cost associated with consulting, but rather "the cost of doing business."
The benefits of hiring a consultant are sometimes not obvious. For example, how much time and money was actually saved by following the advice of the consultant? For projects involving as few as three to five individuals the cost savings can be significant. Consider, for example, the cost of these individuals for a month. If the advice provided by a consultant can save at least one month by more effectively focusing their efforts, that may more than pay for the consultant.
As a general rule of thumb, you want the benefits provided by using a consultant to be at least twice the cost of the consultant, and preferably much more. Depending on the consultant, the organization, and the project, it would not be unusual for a consultant to save an organization 10 to 100 times the cost of the consultant. Organizations that hire consultants must also be sure to include the benefits of a consultant's advice on all future projects in their calculation of costs versus benefits.
Short term benefits of hiring a consultant can include:
Long term benefits of hiring a consultant can include:
Unfortunately, few software engineering organizations accurately track their costs -- much less keep metrics on other aspects of their software engineering. For these people, the benefits of a consultant will be more of an emotional uplifting than a quantifiable pay back. This does not mean that there will not be actual benefits. Indeed, those organizations that track and measure their software engineering efforts will see a significant pay back with the right consultant.
[Berard, 1993]. E.V. Berard, Essays on Object-Oriented Technology, Volume 1, Prentice Hall, Englewood Cliffs, New Jersey, 1993.