Notes from The IT Consultant: A Commonsense Framework for Managing

the Client Relationship, by Rick Freedman, Pfeiffer 2000

PART A

PREFACE
There is no more customer-intimate business relationship than consulting. To excel
in our profession, we must gain our clients trust. Like doctors or lawyers, we must
help our clients feel comfortable enough to confide in us, to tell us things that may
not be easy to acknowledge or discuss. And, as in medicine or law, client and
practitioner must work together to achieve results. Either one working on his or her
own, no matter how expert and diligent, will fail. Only by forming a partnership, by
heeding each others advice and counsel, and by keeping each other focused on the
goal, will we succeed.
Information technology consulting is a profession on a par with engineering and
architecture. Professional standards must be applied once a consultant has
accepted a consulting engagement. Advisory skills, which enable us to develop
relationships of trust and confidence with our clients, are as important to our
success as mastery of technical disciplines. There are proven practices and common
sense techniques that help consultants deliver the benefits of information
technology in a way that would be impossible otherwise.
There is an organized approach to the client/consultant relationship, which may be
called the IT Consulting Framework. This framework is biased toward collaboration,
communication, and results. The IT Consulting Framework, however, is designed to
stress the human factor. The phases of the IT Consulting Framework are as follows:
1.
2.
3.
4.
5.
6.
7.

Approach the Client,

Negotiate the Relationship,
Visualize Success,
Understand the Clients Situation,
Design Solution Options,
Collaborate to Select the Solution, and
Deliver Business Results.

IT consulting engagements succeed or fail based not on the technology, but on the
ability of the consultant to create a relationship with the client that encourages
collaboration, communication, and results. By focusing on the relationship aspects
of consulting, we keep in mind that each engagement is unique, because each
person is unique and each situation is unique. We make a commitment to the
success of our clients, with the unshakable intention of getting results together.
Delivering white papers or findings documents, or even installing functioning
information technology, is not enough for uswe must share in the clients vision
for success and collaborate to deliver it. We must also remember that to earn the
customers trust we must deserve it.

What qualities define a superior IT consultant? The answer typically depends on the
technical specialty of the group being addressed. If the audience is a team of
network designers, their answers focus around expertise in firewalls, routers, and
protocols. If the audience is composed of programmers, the qualifications include
the ability to write a Java applet or to code in C. However, IT consulting is most
successful when advisory skills, rather than purely technical ones, are stressed. The
definition of IT consulting needs to be expanded beyond the technician-for-hire
model, or IT contracting. A contractor fulfills a contract by bringing his or her
technical competence to work every day, to be directed and managed by the client.
A consultant counsels and advises. Technical competence is essential for
professional IT consultants, but it is not sufficient. Technicians, to become
consultants, must master communication, collaboration, and human relationship
skills; in short, they must become skilled and trusted advisors.
As the profitability is squeezed out of the business of selling computer hardware,
many resellers are trying to migrate to a services-based business model. These
resellers and small consulting shops all have skilled systems engineers on their
teams, with long experience and deep technical expertise. Yet these technicians
struggle when expected to perform as consultants. Many of them have developed
exceptional customer skills, yet few can engage with clients in discussions about
business strategy or objectives. They are skilled at uncovering technical
requirements, but inexperienced in unearthing business needs. These prospective
consultants need to understand what it means to be a professional advisor; they
need coaching in fundamental consulting skills; and they need a discipline for
delivering consistent IT results.
Consulting is not mysterious; indeed, we consult with professionals all the time.
When we talk to a doctor, lawyer, or accountant, we are consulting with a technical
specialist. At the core, our consulting process as IT advisors is identical to the one
followed by other professionals. Whether we are consulting our doctor about a
runny nose or our accountant about a pending IRS audit, the consulting process
consists of five steps (although each of these steps may be broken down into
dozens more):
a)
b)
c)
d)

Understand the current state;

Define the desired state;
Analyze the gap between these states;
Recommend an action plan to move from the current state to the desired
state; and
e) Partner with the client to implement the action plan.
When we visit our doctors, its typically ill health thats the problem, and the doctor
proceeds to perform an analysis of the current state by asking us our family history,
our medical background, and our current ailment. The desired state is clearly a
return to good health. The doctor performs a gap analysis, or diagnosis, based on
technical expertise. Once he or she has decided on a diagnosis, a doctor prescribes
a therapy that we, as patients, are responsible for following. Think of the basic steps
your doctor follows, and you have a model of the process of consulting. By
analyzing the patients current situation, applying technical expertise to developing

a diagnosis and prescribing a cure, the doctor demonstrates how a professional

advisor goes about business.
Yet the superior physician does more. He or she knows the patient well enough to
decide how to communicate the diagnosis effectively. Based on knowledge of the
patients lifestyle and character, a doctor weighs the treatment options and
prescribes a therapy with the most likelihood of being followed. Doctors set up a
monitoring program to ensure that the prescription is effective and develop an
education and wellness program to help patients understand, maintain, and
optimize their health. These same qualities, of intimate customer knowledge,
thoughtful communication, careful selection of appropriate solutions, and partnering
for results, characterize the superior consultant.
Consulting is more than expertise in a technical discipline or a craft. We all have had
experience with the supremely qualified technician who cannot explain in plain
English whats wrong or how to fix it. Who hasnt worked with a talented craftsman
who had no understanding of working within a defined budget, or of the basic
courtesies such as timeliness? In the IT world as well, there are plenty of technicians
who can design and implement the most complex multi-site data networks, yet lack
basic skills in communication, project management, time management, or human
interaction.
Many IT organizations promote employees based on progressive achievement as a
technician. A technical engineer proceeds from fixing PCs to installing desktop
operating systems through setting up networks and corporate architectures, with
promotions from technician to network engineer to system consultant along the
way. Have these technicians become consultants, simply because theyve reached a
certain level of technical proficiency? I believe most clients, if asked that question,
would answer No. In the eyes of the client, engaging a consultant promises more
than just renting competent technical skills. Clients want a technical expert they can
trust to guide and advise them.
There is another area in which the doctor and the consultant must be successful:
achieving results. Consultants whose only deliverable is a set of findings or a
comparative white paper have not fulfilled their obligation to their clients. Part of
what clients look for from a technical expert is help in designing
a solution to their problem. Many clients, however, are unable to move from
selecting a solution to implementing it; they need help translating their chosen
strategy into a plan of action. Information technology consultants need a consistent,
repeatable consulting process so they can help clients turn ideas into results. The
superior IT consultant collaborates with the client to develop a solution, and then
devotes just as much skill and creativity to building an operational business system.

Chapter 1: The Business of Advice

Its widely acknowledged that doctors, lawyers, engineers, and architects are
professionals. Their certifications by government and trade organizations proclaim
it. The respect and admiration they receive from their communities demonstrates it.
The pay scales they command confirm it. What is it about the work they do that
characterizes these experts as professionals? It is their mastery of a specialized

discipline, their role as personal advisors, their duty to the client, and the
requirement to follow a set of professional standards that define these as
professional callings.
Is IT consulting a profession? IT consultants also draw from a highly specialized body
of knowledge that is sufficiently obscure so as to be understood only by a small
cadre of specialists. Like doctors, lawyers, and engineers, we spend a significant
part of our working lives explaining complex technical subject matter to clients. Our
clients rely on the advice we give to be successful in their careers or businesses. We
also have a responsibility to provide complete and correct advice. Yet the IT
consultant is rarely thought of in the same context as the doctor or architect. Nor do
most IT consultants think of themselves that way. The process of applying
professional standards to the advising of clients is rarely the key skill IT workers
think of when they consider becoming a consultant. We consider ourselves
consultants because of our technical skills.
Clients also focus on the technical, rather than the advisory, aspects of a
prospective consultants skills. They often ask a consulting candidate, Do you know
UNIX? or Are you a Certified NetWare Engineer?, but rarely, How do you
overcome resistance to a new data system? or How do you ensure that the
systems you design remain secure and operational after they are installed?
Yet we know, from working with auto mechanics and plumbers, dentists and tax
advisors, that technical expertise alone does not make one a good and trusted
advisor. Weve all had experiences with good and poor consultants. Ive had doctors
who walked in the room staring at a clipboard, asked a couple of questions in a
mechanical tone, ticked off a checklist, and only then glanced up to see who the
subject of the interview was. One often wonders whether these advisors cared
whether one was a man, a woman, or a horse. You also might have had experience
with doctors who took the time to know you, your preferences, your personality, and
the way you feel about your medical condition, and then prescribed therapies that
you might actually implement. Good and poor advisors may be equally competent
in their subject matter. Its their ability to give personalized advice that influences
the clients perception of the experience, and the ultimate success of the
relationship.
There exist similarities in the process of advising, whether used by a doctor,
architect, or IT consultant. Each of these professionals must use some process of
interviewing, documenting, analyzing, recommending, and communicating to be an
effective advisor. Many professionals have learned this process through trial and
error, as it is not typically a subject covered in depth as part of their training and
certification. For the skilled practitioner, advising becomes an ingrained and
instinctual skill that is rarely thought of as a separate process. For the less skilled, it
is a hit-or-miss process that often leaves crucial factors undiscovered or critical
decision criteria poorly understood by the client. Everyone understood the
technology, but nobody managed the relationship or the delivery process.
There are five basic concepts that can serve as a foundation for the IT advisory
process:

Focus on the Relationship. Identifying who the client is and understanding the
motivations, culture, history, fears, and goals of both the human being and the
organization is one of the most difficult tasks in consulting. Your success in this task
has much more bearing on the success or failure of your engagements than the
technical discipline involved.
Clearly Define Your Role. Setting the expectation with the client regarding exactly
what you are there to accomplish, what tasks you are making a commitment to
perform, what tasks you expect the client to perform, and where the boundaries of
the relationship lie, is a key success factor.
Visualize Success. It is the consultants central role to help the client draw a mental
picture of the desired result of the engagement. Failure to do so results in the
dreaded scope creep, in which the engagement never concludes because the
expectations keep changing. Visualizing a successful result creates a common goal
that all participants can agree on and strive for together. Like the championship ring
for a sports team, it is an unambiguous and motivational end point that clarifies the
effort and helps clear away extraneous issues and barriers.
You Advise, They Decide. One of the most difficult tasks for consultants is to cast
aside emotional attachment to their own advice. Many technicians fall in love with a
particular solution or technology and then lose interest in, or respect for, the client
who decides to take another approach. We must always remember that the client
understands the complexities of his or her own environment and lives with the
result of the decision, while we move on to the next assignment.
Be Oriented Toward Results. Consulting is more than advising: It is assisting clients
to reach a goal. While some advisory relationships are strictly informational, most
clients want us not only to recommend solutions, but to help implement them.
Politics is often described as the art of the possible, a good definition for resultsoriented consulting as well. By considering implementation issues throughout the
life of the engagement, we keep our eye on the realm of possibility, avoid getting
sidetracked into the theoretical, and prepare the client throughout the process for
the real-world issues of implementation and system operation.
FOCUS ON THE RELATIONSHIP
Like the impersonal doctor described above, some advisors believe that parachuting
into a client situation, peeking around, making some profound pronouncements,
and sending a bill constitutes an advisory relationship. This has been called the
oracle approach to consulting. As with the Oracle of Delphi in ancient Greece, oracle
consultants deliver obscure and mysterious declarations, which may or may not be
pertinent to the subject at hand, and then leave it to the client to interpret and
implement the advice. But success as a consultant is based on the ability to apply
your technical specialty to the clients unique situation. Without focusing on the
relationship and developing the trust and confidence that enable the client to reveal
the problem, this is impossible to achieve.
The relationship with the client determines both the content of the advice and the
manner in which it is given. The client will tell you how to give advice successfully, if
you are alert enough to listen and observe. Obviously, the client knows the

environment and corporate culture and the history and the personalities that have
gotten the organization to the state its in. And the client probably has an idea of
where he or she wants to end up. Clients know their priorities. In this particular
engagement, is schedule, cost, performance, ease of implementation, lack of
disruption, data safety, or personal prestige at the top of the list? Get to know your
client, because there will be many points in the engagement at which youll need to
make a judgment about what your client will prefer, how your client will react, and
how to present problems or alternatives.
The successful advisor also alters the method of advising to fit the client. Many
clients have constraints on the amount of time they can devote to meetings,
interviews, and data-gathering tasks. Some clients may prefer a blunt, take-noprisoners approach to the consulting relationship, while others may be extremely
sensitive to their teams reaction to your advice. Some clients or stakeholders may
be threatened or distracted by the consulting process. You may need to spend a
significant amount of time educating the client in the consulting process, to set
expectations, and to build in the assurance factors.
Clients who are experienced in the use of consultants may be ready to engage fully
in the process, prepared to give trust freely and to disclose fully the information
required. For these clients, a monthly progress report may be sufficient to ensure
that you are on track. For clients who are inexperienced in the consulting process,
frequent assurances that you are remaining on task and producing the expected
deliverables may be required. Weekly progress meetings and complete status
reports may be necessary to reassure these clients continually that they are getting
value for money. As an advisor, you must be mature enough to understand the
clients need for assurance and not to interpret it as the client breathing down my
neck.
Focusing on the relationship aspect of advising will also help clarify one of the most
problematic aspects of consulting, namely Who is my client?
Information
technology consultants are frequently engaged by managers to create systems for
the departments they lead. Who is the client in these casesthe manager who
hired you or the clerk or telemarketer who is the ultimate user of the system? In
most cases the answer is Both. The managers requirements for schedule, budget,
and reporting are driving factors that must be accounted for in the result, yet the
users need for functionality and convenience must be considered or the system will
end up unused. All consultants should step back when entering into an engagement
and ask themselves who the client is, who determines whether or not the
engagement was a success, and who will pay the bill. The ability to keep multiple,
and often conflicting, success criteria in mind is one of the hallmarks of the
professional consultant.
As in any relationship, it is critical to take the measure of the man. What is the
personality of the individuals with whom you will be engaged? Some folks are
naturally quiet, others are talkative. Some are slow to trust and reticent to reveal.
Others will tell you more than you ever wanted to know. Some will act as though
youre an intruder in their private domain, others will treat you like a long-lost
friend. Human diversity is what makes the relationship aspect of consulting so

challengingand ultimately so rewarding. The most successful consultants develop

strategies for dealing with both the reluctant and the cooperative client.
CLEARLY DEFINE YOUR ROLE
A clear understanding of the role of both the client and the consultant serves as a
guide through the advisory process. It focuses the efforts of the consultant and the
client. Ive seen many relationships that could have been mutually beneficial go off
the rails for lack of role definition. The client may believe, for instance, that, as a
paid advisor, the consultant will be available for emergencies in his or her area of
expertise. If a consultant is advising a client on a network design, does that mean
the consultant will answer the phone in the middle of the night when the current
network goes down? If that is not the expectation, client and consultant had better
define that up-front. If it is part of the consultants role, then the consultant must
ensure that the client can get in touch when required and must negotiate a pay rate
for that 3:00 am call.
Clients expectations of what you will deliver as an IT consultant are wide open to
misinterpretation. Does the agreement to consult on the selection of new computer
equipment imply assistance in procuring that gear? Does it imply installation? Does
it imply ongoing support once implemented? Many clients assume that
recommendation means implementation: Why would I want you to recommend
something if youre not going to install it? Some customers believe that if you
recommend a $99 software package, youre committed to rectifying any bugs that
arise for the rest of the customers life! While this is an extreme case, when you
recommend and implement complex technology, the client is justified in expecting
some level of ongoing assistance. What is the appropriate expectation? Its the
consultants role to define that.
You must clearly determine the clients availability to work on the project. Its
obviously going to be very difficult to make recommendations if the client and other
organizational members are unavailable for work sessions to define their goals and
objectives. Clients will often state in the negotiation phase that their internal team
will take on a multitude of tasks to save money. Then, when the project is underway,
these staffers are unavailable, and the assumption is that you will take on their
commitments. So carefully consider and document any assumptions about client
participation.
It may be clear to you, as a practicing consultant, what the roles and responsibilities
of client and consultant are. The customer, however, may be a novice to the
consulting process or may have had advisory relationships with very different
ground rules. Especially with new clients, roles, availability, access, and disclosure
should be negotiated with the same diligence as contracts and fees. Due to the
importance of this part of the process, Ive devoted an entire chapter to negotiating
the relationship.

VISUALIZE SUCCESS

The visualization of a successful result is a technique that is frequently used in the

world of sports. Many Olympic athletes and coaches believe that imagining
themselves performing their event flawlessly, walking through the entire process in
their minds, is a key factor in their success.
Like a good coach, a consultant must help the client see the end at the beginning.
This technique is valuable for more than the confidence it inspires that the
engagement can be successful, as important as that is. It also can be a method for
controlling expectations, for ensuring that secondary, wouldnt-it-be-nice-if goals
dont complicate and confuse the primary objectives of an engagement. In any
project, the fear of scope creep should concern the consultant. Anyone who has
attended a project management seminar has seen the statistics regarding the
number of projects that fail to deliver their expected result. The blame for these
failures is often placed on creeping specifications, the moving target of client
expectations.
Working with clients to visualize success is the primary technique recommended for
managing scope and expectations. By creating a clear vision of what the client will
have when the engagement is done, consultants can help focus the clients mind on
the critical success factors. Try to create a tag line for a project, a single sentence
that characterizes the goal of the engagement. In Hollywood its often said that a
screenwriter who cant create a tag line for a script has not thought it through
sufficiently. This is also true of consulting projects. Projects that require a two-page
mission statement may be in need of refiningor may need to be divided into
multiple projects.
A vision of success is also critical for communication. Most engagements require the
participation of many representatives of the client organization, and often of many
consultants or subcontractors. The clear and simple visualization of success creates
a goal that concentrates the efforts of all involved. This is not a new-age meditation
technique, but a process of mutual agreement on a clearly stated end point, so that
all can agree when the engagement is complete.
YOU ADVISE, THEY DECIDE
There is an old saying that When all you have is a hammer, everything looks like a
nail. In IT consulting, this can be restated as When all you have is NetWare,
everything looks like a server. The predisposition to a specific solution is a real
issue in our industry. How can a firm be, for instance, a Microsoft-centered reseller
and also claim to be an independent consultant? Client-focused consulting requires
vendor and solution neutrality. All problems do not have the same solution, for
which we should be glad; if they did, IT consultants would not be needed. Apart
from the natural tendency to recommend a solution with which we have experience,
there is also the entanglement of emotion to complicate the issue. Many
consultants feel slighted if the recommendation they make is discounted or ignored.
The ability to look beyond our own emotional need for status and validationand to
focus on the cultural, political, and prestige needs of the clientdifferentiates the
professional from the amateur in consulting.
BE ORIENTED TOWARD RESULTS

There are many advisory relationships in which all the customer is buying is advice
or research. We are engaged many times in creating a white paper report that
outlines various options and the pros and cons of each. When we deliver that paper,
our task is done. We have no role in the ultimate decision or the implementation of
the system, and often have no idea whether the work was utilized or stuck in a
drawer and forgotten. In the vast majority of engagements, however, the client
wants more than advice. The client wants a result. And, while its critical to keep an
open mind and not pre-decide the solution before performing the analysis, there are
certain techniques that pave the way for a successful implementation.
Very often consulting projects are done in complete isolation from the intended
recipients of the new system. Its not an uncommon experience for system users to
first be exposed to the new system when an installer shows up at their desk. This
can be an outcome of some corporate cultures, in which decisions are made by
managers in closed sessions and then sprung on the user community by
management proclamation. In many cases, managers just are not used to
considering the reaction of the troops when making technology deployment
decisions. It is in the best interest of the enterprise for the consultant to insist
(diplomatically, of course) on communication with the user community. When users
are sold on the benefits of the new technology, when they understand how it affects
their duties, and when they are involved in scheduling the rollout, the odds for
success are enhanced tremendously.
An orientation toward results also means designing training, support, and
maintenance into your solutions from the beginning. When we talk about
operational issues from the start, users are reassured that they wont be left
twisting in the wind. When we advise clients to announce the training program at
the same time as they announce the creation of a new system, users feel that their
welfare, effectiveness, and productivity matter to the organization and so are less
inclined to resist or snipe at the new technology. By advising the client to consider
these issues, consultants add value far above the purely technical. They help clients
create an environment that is primed for success, and they demonstrate that they
can participate at a strategic level, thus elevating their stature as a business
advisor.
The IT Consulting Skill Set
What do we sell when we sell consulting? We may be selling technical skill, a project
implementation, or a report comparing different technical options. For any
consultant who has worked for a professional services firm, theres no question what
the product is: Like a lawyer or an accountant, were selling billable hours. When it
comes to the profit-and-loss statement, the consultants ability to sell enough
billable hours to be profitable is, literally, the bottom line. In every management
meeting at consulting firms worldwide, as the partners review results and make
forecasts, the conversation inevitably turns to the utilization rates of the staff.
Among managing partners and team leaders, it is an axiom that some individuals
are consistently able to keep their billable utilization high, while others, often with
similar technical skills, can never seem to achieve their targets. Some consultants
are so well-trusted that clients will wait for them to become available, even though
other, similarly trained practitioners are unengaged. In some cases, clients will

schedule their internal projects based on the availability of a particular consultant,

or will actually kick off projects ahead of schedule rather than risk losing a certain
consultants services to another client.
What are the characteristics that allow some consultants to remain highly utilized,
while others struggle month after month to meet their targets? As with most
questions concerning the profession of consulting, a view from the clients chair is
instructive. Lets gaze out from the point of view of a client we all can identify with,
a doctors patient. Patients are typically not medical experts. They usually cannot
judge, except by results, the quality of the medical advice they receive. As patients,
we assume that the diplomas and board certifications hanging on the doctors walls
assure us that they are qualified to practice. Patients can, however, judge certain
other attributes that doctors bring to the relationship. Because of the patients lack
of expertise with which to judge the doctors technical mastery, these attributes
often take on added weight in our evaluation process. These qualities are
sometimes referred to as bedside manner. We may not be able to define this
precisely, but We know it when we see it. Its typically a combination of
personality, communication skills, qualities of empathy and caring, and a holistic
approacha focus on treating the patient rather than the disease.
This analogy to a doctors bedside manner gives us some guidance about the
qualities clients look for in an advisor. Obviously, technical expertise is a deciding
factor. Without it the practitioner is clearly out of the running. The ability to
communicate effectively is also a key in both the doctor/patient and the
consultant/client relationship. The doctor, or the consultant, who cannot ask the
right questions, listen effectively to the responses, interpret what is said, and
develop a dialogue based on trust is severely limited in the ability to diagnose and
prescribe. The holistic approach in medicine is analogous to a business-centered
approach in IT consulting. The consultant, who focuses on the technological
symptoms, without considering the business context, is in danger of offering a
prescription that will never be filled.
Project management, like consulting, was once thought to be un-teachable. One of
the proverbs in the early days of project management was the idea that project
managers are born, not made, and that success as a project manager was driven by
personality, not methodology. Proponents of this school of thought stated that You
cant teach someone to ask the right questions, to resist scope changes, to be firm,
to analyze the clients situation and come up with meaningful solutions, to
estimate, etc. This opinion stands in sharp contrast to the disciplines and training
that are now available for aspiring project managers. Organizations like the Project
Management Institute and its Project Management Body of Knowledge and Project
Management Professional certifications have shown that project management is in
fact a system of thought and practice.
Certain character traits are important in the aspiring project manager or consultant.
Success at these endeavors is largely based on a set of skills and methods that can
be learned. The skills critical to a consultant are:
a) Advisory,
b) Technical,

c) Business, and
d) Communication
TECHNICAL SKILLS
Successful professionals, whether accountants, doctors or musicians, are typically
strong in the technical discipline of their craft. These skills are the focus of all the
training, certifications, and diplomas. Frankly, this is the endeavor that we are
drawn to by our character and desire. Most professionals select and concentrate on
a particular craft because they cannot help it, because its the field where joy,
talent, and aspiration converge. In the IT field especially, its been my experience
that most conversations about how folks get into the business usually boil down to
Once I was exposed to it, I knew I belonged.
Technical expertise is a process, not an event. The technology changes so quickly
that those who master a current skill set and stop there are doomed to
obsolescence. Technical training in IT must be looked at as a lifetime learning
experience, and one hopes curiosity and the joy of scholarship will motivate the
consultant to stay current. In the real world of commercial consulting, its critical to
remember that clients become more sophisticated all the time, and they expect
their highly paid consultants to be at least one step ahead of them. Five years ago,
knowing how to install a PC and a printer was enough to generate consulting
engagements.
Consultants often say, I dont need to know all about the subject, I just need to
know more than the client. This is one school of thought, and even achieving this
can be challenging. But the real value-adding consultant strives to do more, to gain
depth as well as breadth in the technologies that drive competitive advantage for
clients around the world. By subscribing to the IT trade magazines, scouring the
bookstores, searching the Internet, attending vendor presentations and user-group
meetings, and networking with your colleagues, you can ensure your ability to add
insight to your clients decisions. In the professional world of doctors, lawyers,
architects, and engineers, continuing education is a baseline requirement that is
acknowledged and accepted as a cost of entry into the field. So must it be with IT
consulting. The aspirant or ambitious veteran must come prepared to make the
investment of continuous development in order to remain a viable player in the
competitive world of commercial consulting.
As in all commercial enterprises, the market is the ultimate arbiter. If you find that
your technical skill set is not bringing in the volume of business opportunities that
you expect, perhaps you need to broaden your technical scope. Learning new skills
and technologies can not only increase your value to the marketplace and to each
client, but can also be a powerful antidote to boredom and to the same-old, sameold syndrome.
BUSINESS SKILLS
One of the common themes in the current business press is the shortage of IT
professionals in the labor market. Hundreds of thousands of IT jobs go begging
every year for the lack of qualified technical candidates. How much rarer still is the
technical candidate who also has an understanding of business issues. The clich of
the computer nerd who must be kept in the back room with a screwdriver in his

hand is, like most clichs, based on a nugget of truth. Many talented IT practitioners
have never mastered basic business skills, and many managers did not consider
these skills relevant to the IT function. One is not sure if they understand:
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)

Their companys mission,

Its competitive strategy and position,
Its sales and profitability,
Its key clients,
Whether it is publicly or privately held,
Its stock price and performance,
Its organizational makeup and key managers,
How managers are compensated and motivated,
Its history, and
Its strategic priorities for the coming year

This is also the most glaring insufficiency that clients note when they work with
rookies: How can this person deliver a solution that contributes to my business
without any business experience? The clients desire for gray hair as an indicator of
experience can be a stumbling block for novices. Its often unfair in terms of the
business value and technical expertise that a particular consultant can bring to the
table. Most clients, however, are prepared to be advised by youngsters if they can
be convinced that the young man or woman brings an understanding of business
context to the project. Obviously, experience is the best teacher. For many technical
professionals, however, the opportunities to be exposed to business functions other
than IT are limited. Some techniques for overcoming this difficulty and for
expanding your understanding of business issues are to read General Business
Magazines and use the Internet.
Include the Basic Business Questions Above in Every Consulting Engagement. This
is the most important way to illustrate to the client that you approach the consulting
relationship as a business-savvy strategic partner, and not just as a technical hired
gun.
These suggestions are focused on general business understanding. In the context of
an impending engagement, however, knowledge about the specific company,
industry, and project issues for the client company are critical to success. I
recommend that consultants develop strong research habits as they prepare to
engage with a specific client. Nothing develops client confidence and assurance
more potently than a bit of pre-project homework by the advisor. Consultants who
walk in the door with some knowledge of the clients industry, company history,
stock price, and competitive position create the image of an experienced and
competent professional from the beginning of the relationship.
COMMUNICATION SKILLS
Consulting is communication. Without clear, open, and effective communication
between the parties, consultation cannot take place. The ability to help customers
articulate their needs, understand the capabilities and constraints of technology,
and create a clear and compelling project vision are tasks central to the advisory
process. Yet, the popular picture of an IT professional depicts the opposite. The
clich is that the IT staffer needs to be kept in the back room, that IT people are

either going to talk in technical jargon that will put the CEO to sleep or compare the
clients business strategy to an episode of Star Trek.
Most IT professionals are intelligent individuals, folks who have mastered a difficult
and demanding craft that has required diligent study and training. The idea that
they cannot also be trained to communicate well is nonsense. People develop those
skills for which they are mentored, compensated, and judged. Superior
communication skills have not, until recently, been a requirement of the IT
profession. In the mainframe days, IT teams worked in the infamous glass room,
talking mostly among themselves, usually with a manager from the finance
department to act as their interpreter. As computing moved to the desktop,
however, and the ability to provide support and service to users in a language they
could understand became a valuable skill, communication came to the forefront.
Those technicians who could avoid jargon, who could communicate clearly with the
secretary, clerk, salesperson, and manager, became valuable commodities. In short,
the desktop PC revolution forced IT to become more consultative.
The IT consultant, in a typical day of practice, will need to interview a client to
understand his requirements, to examine a candidate and assess her suitability for
a spot on a project team, and to report on project activities to a manager or project
sponsor. In between these oral communication tasks, the consultant will probably be
sitting at a desk preparing a status report, a scope of work document, a proposal, or
some operational documentation. The skill central to all of these tasks is the ability
to communicate.
Communication can be taught and learned. It can be taught by example: by
showing the novice consultant how it is done in a client situation. It can be taught
by practice: by having consultants in a team setting deliver presentations on their
technical specialties, by forming Journal Clubs to report on what was read, or by
organizing facilitated work sessions to let teams review customer engagements and
develop solutions together. I often say that no single consultant owns a project;
the team owns all projects. This viewpoint encourages every consultant to bring
problems and experiences to the team and to work them through as a group. There
is no better communication training than this.
For the single practitioner without access to a supportive team of colleagues, these
options are less viable. Even the solo consultant, however, can join local user
groups and technical associations and make a habit of sharing ideas. In the final
chapter of this book some of the fundamental techniques that consultants and
advisors have developed over the years to improve their skills at interacting and
communicating with their clients and teams are described in more detail.
The fundamental purpose of developing a consistent consulting methodology is to
prepare IT professionals to excel in the central skill of consultingcommunication.
Business consulting has gone from an esoteric practice employed by a few experts
to one of the fastest-growing job categories in our economy. During this period of
explosive growth, practitioners have learned through experience some commonsense techniques that predispose consulting engagements toward success. Each of
the steps of the IT Consulting Framework we will review in the chapters to follow is
primarily an attempt to codify these communication practices into a system that

consultants can follow to establish a clear, collaborative, and mutually beneficial

relationship with their clients.

Chapter 2: Approach the Client

WHY DO CLIENTS ENGAGE CONSULTANTS?
There is inherent tension in the initial meeting between any two people. No matter
how self-assured, confident, and experienced an individual is, approaching an
unknown person creates some degree of apprehension. Will this new acquaintance
be friendly or cold, cordial or rude, open or reserved, wise or foolish? Will my ego be
soothed, threatened, or bruised by this encounter?
Now imagine how this anxiety is magnified in a business setting, where livelihood,
prestige, and power are at risk. By the time a client approaches a consultant for
advice, that client has acknowledged some things which may not have been easy or
flattering. The client may have recognized some or all of these deficiencies in his or
her organization:
a) They lack the technical expertise to solve their problem without outside help;
b) They lack the business experience to apply whatever technical knowledge
they do have;
c) They lack confidence in their ability to evaluate the options;
d) They cannot convince their management or team that a particular solution is
valid, and so need independent verification;
e) They do not have the staffing or the time to address the problem or
opportunity; and/or
f) They doubt their ability to implement the solution.
Information technology consultants must take care not to assume that lack of
technical expertise is the only issue. As a technology consultant, its easy to
conclude that the client wants to buy your technical knowledge and advice. When
developing a relationship with a new client, IT consultants need to keep in mind
both the inherent anxiety of the initial human contact and the full range of
deficiencies with which the client may need help.

ASSESSING THE POTENTIAL FOR SUCCESS

The initial client contact is an assessment session as well as a work session. The
formal agenda for an initial client meeting is always focused on the project issues,
such as objectives, scope, fee arrangements, and the like. But the client and the
consultant are also evaluating one another. The client is seeking technical
competence, of course, and questioning will typically center around that. But the
client is also wondering, Can I trust this individual? Will this person work well with
me? Does the consultant understand what I need to get from this relationship? Will
the person fit into my corporate culture? Of course, the consultant is also stepping
through a range of concerns: Does the client understand how to work with
consultants? Does the client understand the technology well enough to make the
necessary decisions? Is the person interested in partnering in this endeavor or will
he or she come looking for a blame agent if things go wrong?

As expressed by Euripides in the opening aphorism, the outcome of the entire

engagement can be tainted by poor handling of the initial contact. On the positive
side, consultants can tip the scales significantly in favor of success through
thoughtful treatment of the initial sessions.
As consultants proceed through this dance of evaluation and counter-evaluation,
they should consider the following questions:
a) With which of the deficiencies described above is the client asking for help?
b) What is the clients demeanor? Casual and open, or formal and restrained?
c) Are there any clues to indicate the clients time pressures? A client who
appears rushed and must run to the next meeting will participate in the
project in a different way than a client who relaxes and wants to go into great
detail.
d) Is the client excited and enthusiastic about the possibilities of this
engagement? Or does it seem like another burden that was dumped on the
client?
e) What are the physical clues? Does the clients office have a childs finger
paintings on the wall, a fine art poster, or a picture of the local football team?
Using powers of observation effectively is one of the critical success factors for a
consultant. Important clues can be gathered from observing the clients reaction to
the simplest of questions, such as, Where shall we meet next? or Who should be
in our next meeting? If the client wants to get out of the office to have your next
conversation, how do you interpret that? Does it mean that the client wants to avoid
interruptions and give complete attention to you? Or does the client want to make
sure that others dont hear your conversation? Is the client including or excluding
staff based on their need to participate, or to protect power and prestige? All of
these questions demonstrate the nuances of human relationships that are at the
heart of every engagement. And, as when you first meet your brother-in-law or your
new auto-mechanic, you must use your sum of experience and your own character
to make these interpretations. Its obvious that, if either the clients evaluation of
the consultant is negative or vice versa, the relationship will never get off the
ground. There are some simple rules a consultant can follow to positively influence
the clients evaluation:
Give Confidence to Receive Confidence. Tell your client about yourself and be
forthcoming and engaging if you want your client to reciprocate. This refers not to
the false backslapping of the huckster, but to a genuine attempt to connect as an
individual with the client. Help the client understand the advisory process you are
about to engage in. Help the client see the context of the questions you ask. Help
him or her understand why you need to know and what you will do with the
information. Give the client an opportunity to ask questions.
Dont Push the River. Let the story either trickle or flow in a torrent, as the customer
desires. At this stage of the relationship, dont be too concerned about getting the
total picture. As we engage, we will follow a process for performing a full analysis.
Dont budget too tight a time frame for these initial contacts, so youre not trying to

push the client through the process. Listening, caring, and not taking undue control
of the conversation are critical to building trust.
Dont Prescribe Before Diagnosing. Inexperienced consultants want to assure their
clients that they get it and that they have a solution on the tip of the tongue.
Veterans have seen similar situations so many times before that they feel they
know the answer by the time the first sentence is uttered. Both of these impulses
must be resisted. Talking later and less, but talking judiciously and with complete
knowledge of the situation, is the sign of a skilled advisor.
Test Your Understanding. Repeat the clients goals and concerns in your own
language to ensure that your interpretation and the clients are harmonious. These
human interaction issues are a key success factor in any advisory relationship.
Information technology consulting, however, is still a technical discipline, and it
requires not only rapport with the customer, but a clear understanding of the
business situation. In many instances, the consultant is but one member of a team
that will be addressing the clients needs. Additionally, if the consultant works for a
professional services firm or inside a corporation, he or she must report to a
management chain. For all of these reasons, its critical to use a structured method
of profiling the engagement during the initial contact.
Dont confuse this task with the full analysis activities that come later in the
process. Well dig down into the nitty-gritty details then. This is the preliminary
contact, but it must be fruitful and complete in its purpose, which is to take the
initial measure of the engagement.
The initial meeting is the place to request any additional data youll need in later
phases. Bring a list of documents youll want to review, including technical data
such as network diagrams, application manuals, policies and procedures, or
contingency plans, as well as corporate data such as organization charts or annual
reports. Its also critical that the engagement be put into context of the clients
overall business strategy from the start. Ive always been amazed at the number of
technical consultants who will meet with their customers, have detailed
conversations about system requirements, data, and applications, but cannot tell
me what business the client is in. Just as a patient would not be comforted by a
doctor who only treated the injury and not the person, a consultant who only
addresses the technology issues without understanding the business context will
not gain the customers confidence. Always remember that clients are applying
technology to serve a business need.
Remember that the role of an advisor is a role of influence and power. Like any such
role, there is the potential for harm as well as good. An IT consultant is a
professional and must follow a professional code of conduct. In many cases the
client is inexperienced in partnering with a consultant, is in immediate crisis and is
reaching out desperately for help, or does not understand the technology. In each of
these cases, the clients judgment can be clouded. It is up to you to advise your
client well, not only within the technical disciplines, but also within the advisory
relationship. If the client is engaging with unreasonable expectations, is clutching at
straws to save a job, or is expecting magic instead of technology, you need to

identify that. This meeting may not be the appropriate forum to raise those issues,
but at least they must be recognized. Even if you merely cant work with this
person for whatever reason, you need to take that impression seriously. The
consultants responsibility to assess the potential effectiveness of each engagement
must be taken in earnest. Just as a scrupulous judge will recuse himself from trying
a case in which he cannot render impartial justice, an ethical consultant will
sometimes need to walk away from an engagement if there are factors that make it
impossible or unethical to continue. It is an exercise in frustration to engage with a
customer whom we cannot advise properly; it is also a breach of professionalism.
Your initial contacts with the client must result in a deliverable such as the
Engagement Profile Form. You should have a record of the problem, opportunity,
clients requested services, and all of the other basic information outlined in this
chapter, and you should use it to open a project file. If you are a member of a
consulting team, a team meeting should be held to review the information youve
gathered and to begin the process of defining a scope of work, a task list, a
schedule, and budget. Solo practitioners should also get into the discipline of
preparing written records of their client interactions. In the next step of this
framework, you will be negotiating your role with the client. To prepare for this
process, you must analyze the clients needs and document your approach. A major
part of your role is to assist the client in building an engagement that can be
successful for both of you.

Chapter 3: Negotiate the Relationship

CONSULTING IS AMBIGUOUS
When an IT manager hires a C++ programmer for an internal software development
team, the manager has a clear idea of the role that employee will play and the skill
set offered. The programmer has probably gone through a rigorous series of
interviews with technical staff members, managers, and HR personnel. Credentials
and references were reviewed. The IT managers expectation is that, under the
direction of the software development manager, this programmer will perform the
tasks assigned with talent and skill. The relationship between manager and
programmer is well understood by both, as are the remedies for poor performance.
When the same IT manager engages a consultant to design an Internet connectivity
strategy for the organization, the roles and responsibilities are much less clear. Is
the consultant going to deliver a strategic white paper or design and implement an
intranet? How will the consultant learn about the organization in order to make the
best recommendations? Who from the clients team will need to be involved, and for
how long? How will the client know what kind of budget to set aside for the
consultants time or for the solutions recommended? When does the relationship
begin (When does the meter start running?) and when does it end? What is the
consultants responsibility to deliver a quality result, and how is that enforced?
During the course of the engagement, how will the client know that theyre on
track? Does the client have any remedies if the consultant turns out to be
unqualified, unprofessional, or just a poor fit with the clients organization?
The contrast between the clarity of an employer/employee relationship and the
ambiguity of the client/consultant relationship should make it clear why negotiating

is a skill every consultant must master. Consulting is vague and prone to

misunderstanding; all consultants must grasp this baseline concept, for it forces us
to take seriously our obligation to clarify our roles with clients. As the preceding
litany of questions illustrates, the client approaches the advisory relationship in
need of guidance and assurance from the consultant about the nature of the
association. The most successful consultants are skilled in helping clients
understand how the process will work, reassuring them that together they will reach
the desired result, and ensuring that expectations on both sides are clearly
delineated.
Clarifying Expectations
The clients expectation of the role you will play determines the style you bring to
the engagement. A consultant who has negotiated a role as a strategic IT policy
advisor to the CIO will engage differently than will a programmer for hire. If your
role is to write a time-card module in Java, its probably not a good idea to be
spending your efforts (and the clients money) making recommendations on an ecommerce strategy. The clients style of engagement will also be affected by the
roles negotiated. The IT manager should expect to engage more closely, and on a
different level, with the strategic policy consultant than with the Java programmer.
When defining roles, we must focus on the roles of both the consultant and the
client. The clients expected contribution to the project effort, in availability, access,
and resources, must be defined plainly if the consultation is to be successful.
Its also important to define the boundaries of the relationship. Does a
recommendation for a particular brand of network router imply that, if it
malfunctions at 3:00 am, the client can expect the consultant to run by and fix it?
This is one possible scenario, but if the relationship is not negotiated as such, one of
the parties will be disappointed when that telephone rings. In an IT advisory
situation, almost any assistance that the consultant agrees to provide can imply any
of several different levels of service. Does the design of an accounts payable
system imply a link to the clients existing general ledger program? This area of
implied or obvious linkages is an area of IT consulting fraught with the danger of
miscommunication. Its easy for the client to assume that if youre recommending
hardware you can supply it, and if youre supplying hardware you can fix it.
Consultants must dig into every service theyre proposing to the customer and
make sure that there are no implied tasks or results that could be misunderstood.
Ask the Client
Most of the questions a consultant asks his clients focus on two points: (1) How I
can help, and (2) What results are you looking for? These should be asked in
different ways, What can I do to help with that problem? What role would a
consultant play in that effort? or What would be the best result of that project if all
went perfectly? If youre lucky, the client can clearly articulate the problem or
opportunity, why the organization has decided to seek an advisor, and what the
expected outcome is. In many cases, however, the client does not have a clear
understanding of the problem, has never worked with a consultant before, and is
not sure what you can do to help.

Every practicing consultant will eventually be faced with an even stickier situation,
in which the client does not really believe there is a problem, and does not believe
an outsider can add anything, but has been instructed by a manager to bring in
specialized help. Whether the client is an old hand at the use of consultants or is a
reluctant participant in the process, the consultants responsibility does not change:
to gauge the clients expectations, to guide the client through the advisory process,
and to focus on the best interests of the client and the clients organization
throughout the engagement. Wherever on the spectrum a particular engagement
may lie, listening to the client tell the story from his or her own perspective will help
you formulate an appropriate strategy.
Just as it is important to evaluate who the client is when we consider taking on an
engagement, it is also critical to understand who we must negotiate with to frame a
successful outcome. Is it sufficient to negotiate our role with the project sponsor,
who may be paying our bills, or do we also need to negotiate with representatives of
the users or the IT staff? Remember that many unsuccessful systems are designed
by managers behind closed doors, without team participation or support. Be sure in
every engagement that you understand the other constituencies you will need to
deal with, your access to them, and what role they will play in a successful rollout.
In situations in which your negotiations include a large team of client
representatives, like a selection committee or project team, observe carefully the
team dynamics. Learn who the decision makers or thought leaders are, who may or
may not be your advocate, and which interests are over-represented or underrepresented. Be alert to the tone and atmosphere of your conversation with your
client. If you sense that the client wants to keep you away from others for the wrong
reasons, such as the fear that they may have a different idea of the problem or may
disclose things that damage his or her prestige, you may need to negotiate contact
with them in order to do justice to the advisory relationship.
With all these cautions about negotiations, we must not lose sight of the bottom
line: The agreement we negotiate must result in a successful engagement. In living
up to the standards of our profession, we must guide the customer toward an
agreement that is attractive and motivating for us as consultants and that grants us
the access, information, and authority to deliver the business results that the client
expects. This sometimes requires us to push back a bit against the clients
misapprehensions or unrealistic expectation.
THE SIX RULES OF NEGOTIATION
There are a few key points to remember when negotiating:
Avoid Imposing Your Role. Attempting to unilaterally define the relationship by
telling the client what role youre prepared to take, what the client must do, and
how the work will be done is not an effective method of building cooperation,
confidence, and trust. In any negotiation, trying to impose a settlement on the other
party is bad form and as likely to elicit resistance as cooperation. Start with the
attitude that everything is on the table, and then negotiate out the elements that
you believe are not in the best interest of the engagement.
Avoid Having a Role Imposed on You. The position of the consultant is that of a
service provider, but that does not mean that the customer is always right. In fact, it

is a key role of the consultant to protect a client from bad impulses or

misperceptions. Usually, the client is expecting guidance on what is possible and
appropriate. In some cases, the customers expectations of what you can do may be
dead wrong. Either way, firmness in steering the customer toward reasonable roles
and a beneficial relationship requires diplomacy, determination, and mental
toughness, but its in your mutual best interest.
Take Out the Emotion and the Ego. If you see every negotiation as a contest that
you must win, your projects (and career) will lose. Focus on the best interest of the
client and the engagement. That must be your only agenda whenever you engage
as a consultant. Anything else is unprofessional.
Negotiate Creatively. There are many approaches to the same goal. Reach for the
unexpected compromise that shows your commitment to the project and
demonstrates that you are more interested in professional success than in victories
at the bargaining table. Some of the most effective negotiating tactics involve
giving a concession to demonstrate confidence in your skills. For instance, offer to
perform an assessment and deliver a design document that the customer can then
shop to your competitors. You demonstrate your conviction that you are the best
person to do this job and your confidence that the customer will be satisfied and will
want you to continue. You may offer to perform services on a try-before-you-buy
basis, especially if this is a client you have targeted or a project you are particularly
interested in. Show the client you want to figure out a way to make the engagement
work.
Table the disagreements. Dont turn negotiation into argument. If you sincerely
disagree, back off and offer to sleep on the issue and see whether you can devise a
compromise. Sincerely consider the sticking point issue and see what you really
need to have. Then offer a compromise. If the issue is a must have, develop a
justification that the client will understand and appreciate. Document Your
Agreements. Take notes, or have an assistant present who can scribe the
negotiations. No agreement is final until it is documented, reviewed, and initialed.
THE DELIVERABLES
These points address the advisory skills you bring into the negotiation process. The
next question is: What exactly are we negotiating? Your preliminary meetings with
the client should have resulted in your creation of an Engagement Profile, as well as
some preliminary task, schedule, and budget estimates. Now you must review those
with the client, to define in detail the services and results youre committing to
deliver. The outcomes of the negotiating process must be, at a minimum, the
following:
Preliminary Vision Statement
The clients description of the compelling event for seeking an advisor and the
benefits to be achieved by doing so are a vision statement. This will be refined later
in the process, but its important to test your understanding of the overall objective
at the very beginning of negotiations.
Preliminary Scope of Work Document
The Scope of Work Document is the crux of the agreement on the technical
deliverables of the engagement. It must be complete enough to present a clear

picture to the client team regarding exactly what they are buying from you. If you
need to perform an assessment or a system inventory before you can know what
the complete scope is, say so here.
Preliminary Schedule
The expectations of completion dates for the phases of the project should be
couched as a preliminary schedule subject to significant modification based on the
results of discovery and data collection activities.
Preliminary Budget
This is an estimate of the billable fees the client will incur for engaging you and your
associates. Obviously, this is closely tied to the scope and schedule. If you are only
engaging for an assessment phase and will renegotiate based on the results of that,
state so clearly and present a budget for that phase only. This number will stick
indelibly in the clients mind, so make it undeniably clear what you are including in
this budget and which deliverables, such as hardware, software, support services, or
other additional services, are excluded.
Deliverables Document
This is a description of the deliverables you are committing to produce. This will
typically include project plans, communications or internal marketing plans, status
or milestone reporting, as well as the technical deliverables you are contracting to
render, such as an Internet strategic plan, an asset management database, or a LAN
implementation plan. All activities in a consulting relationship have deliverables!
Verbal reports, conversations, work done on a server in the middle of the night, or
other informal or intangible deliverables are unprofessional. In addition, they are
extremely hard to display in case of disagreement at billing time. For clarity, for
professionalism, and for your own protection, produce a tangible deliverable, such
as a report, manual, or customer acceptance sign-off sheet, at every phase of the
engagement.
Roles and Responsibilities Statement
A clear statement must be produced describing which tasks and deliverables the
consultant is chartered to take ownership of and which the client and team will
commit to producing.
Assumptions
This defines some of the basic needs of both parties and will typically include the
facilities the client will be providing as work space, access and a guest ID to the
clients computer network if required, and expected review and approval turnaround
time on documents submitted by the consultant. If you assume that the client will
allow access to a data center or to payroll and billing records or to the source code
for inventory software, say so here.
TEST YOUR AGREEMENT
Even when you believe you have reached agreement, that agreement must be
tested and confirmed. Present a first draft of a Scope of Work Document or Letter of
Engagement, including the elements outlined above, to the customer for comment.
This step is vital, for it tests your understanding of the deal youve negotiated and
flushes out faulty assumptions and miscommunications. Communicate clearly that

you are expecting the clients response to these deliverables and stress the
importance of a critical review to ensure that you are still in agreement. Any
misinterpretation of the clients expectations must be renegotiated, and the
documents must be reissued, until they conform to your mutual understanding of
the engagement. Once accepted, these documents form the contract you will work
from. They may not be a legal contract, but the legal issues are not our focus here.
The documents are a professional contract, a promise to perform at a professional
level the tasks to which you have committed.
As with most components of the consulting relationship, we are negotiating both
hard, factual elements, like the scope, budget, and schedule, as well as less
tangible ones, such as executive sponsorship and support. Do not confuse what is
tangible with what is important. The support and commitment issues are as critical
to success as scope and schedule. The risks surrounding lack of support may be
more dangerous than an ill-defined scope. Scope can always be refined if the
commitment to success and partnership is there.
TIPS ON SCOPING A PROJECT
Scope refers to the total effort you will put forth to assist the client. A detailed
Scope of Work Document between client and consultant is the most important
element in determining success or failure of your engagement. No other component
of your negotiation does more to set true or faulty expectations. The information
technology consultant, who can define a scope that addresses the clients needs
totally, and clearly documents the services and results expected, is protecting the
client as well as himself or herself.
Scope can be determined in many ways. In engagements that result from an RFP,
the client has documented objectives, and the consultant then needs to interpret
those objectives into roles, tasks, and results. In cases in which the client is less
sure of the problem or its possible solution, you must help the client shape a
relationship that will achieve the objectives. By working in a top-down manner with
the client, defining overall goals first and then focusing on specific tasks and results,
you can work with the client to build a scope that will serve as a blueprint of the
project.
Remember that scope also must address the boundaries of your enquiry.
Consultants often get in trouble by being overly ambitious, like the Java
programmer previously mentioned who wanted to design an e-commerce strategy.
Remember that the customer is inviting you in, solike any good guestdont start
going through the drawers. In the course of writing an accounts payable module,
you may notice that the clients network infrastructure is token ring, and you
believe they would be better off with ethernet. Unless evaluating the status of the
network topology is in your scope, your comments will not be welcome, and the
client will not relish paying you for the time you spend outside your mandate.
Clearly understand not only your scope, but also its limits.
It is critical that you negotiate a scope that is neither too broad nor too narrow. Be
sure that the expectations are not broader than the time and resources you, or the
client, are prepared to invest. Also ensure that the scope is not so narrow that you
cannot deliver a meaningful business benefit. Ive had clients ask me to perform

network design reviews, but been explicitly notified that cabling was off limits or
that the network addressing scheme could not be changed. Boundaries that make
it impossible to succeed must be exposed to the light of day and explicitly dealt
with in negotiation.
Scope definition is an ongoing process. There are elements of scope that will be
impossible to predict until you begin to assess the current state. At this point, you
should aim to get a general sense of the clients objectives, the business goals of
the project, the extent of the role the client is offering you, and the boundaries of
your efforts. Consulting engagements must be properly scoped from the start, but,
if the relationship is open and cooperative, scope can be refined as an organic part
of the process.
The time to introduce the concept of scope changes or unexpected impacts to the
project is at the beginning of the relationship. It is well known among consultants
and project managers that scope creep is the virus that infects and kills
engagements and relationships. Like most viruses, however, a little prevention is
usually much more effective than after-the-fact attempts to cure the damage. As
you work together, the vision that each of you had of the problem and its solution
may change. Assuring the client that you have an orderly process for managing that
event is critical. It is another assurance factor that will make the client feel that
youre a pro who has been through this before.
BUDGET
It is a proverb among salespeople that you must keep the customer focused on the
value rather than on the cost. This is equally true for the consultant, where the
client is buying service, an intangible, rather than, say, a piece of hardware that can
be touched. Consultant fees are high, in many cases substantially more per hour
than the client is paid. The client is not going to do the calculations required to
understand that the consultant has to pay for downtime, research time, continuing
education time, benefits, and marketing time with that $125 per hour fee. The client
just sees a very expensive meter running as you work, chat, write, research, and
communicate. Take the clients money seriously; you can be sure the client does.
Keeping the client focused on the value is a process that takes place throughout the
relationship. During the negotiation phase, it is a good practice to not only help the
customer define the projects objective, but also its justification. While the objective
states the function of the proposed new system or software, the justification
describes, in financial terms, why it makes business sense to spend money on the
project. How much faster does the client expect to get paid with the new accounts
receivable system, and what is that worth in dollars? How much incremental
revenue can be generated with the new e-commerce website?
The negotiation phase is not the right time to perform a detailed cost/benefit
analysis, but it is the time to start the client thinking about the metrics that will be
applied to the final product, to determine whether it delivers the benefits expected.
Will it be enough that the new network is robust, reliable, fast, and secure, or will it
also need to be 20 percent cheaper to maintain than the mainframe it replaces? If
so, its better to know that now than at the end, when your success as a consultant
will be judged based on a measurement you had no part in defining. The budget

that will be presented as a deliverable of the negotiation phase should be

preliminaryand must be clearly labeled and communicated as such. Different
types of engagements will be more or less difficult to estimate. If you are engaged
to do a revision of a software module for a customer youve worked with before in
the same capacity, and you have good visibility into the systems, interfaces, and
personalities youll be dealing with, you can safely present an estimate. Doing so
would not be prudent with a complex project utilizing cutting-edge technologies for
a new customer. You need to honestly ask yourself how much you know, and how
much you need to know, before you can put a budget in front of the client (where it
will be remembered forever!).
The purpose of fixed-bid or not-to-exceed pricing engagements is to move the risk
from the client to the consultant. By building in status reporting, regular budget and
expenditure reviews, and other ongoing assurance factors, you can reassure the
customer that you will advise continuously on how much is being spent and that
you are prepared to make adjustments as you go. This seems a fair way to control
client expenditures without putting yourself at an injudicious financial risk. As with
scope, define in your budget not only what is included, but what is excluded. Be
sure the client understands how hardware, software, subcontracted labor, travel
expenses, maintenance contracts, and any other projected expenditures are being
represented in your budget. Financial surprises are the worst kind of surprises for
the client/consultant relationship and are devastating to the trust and confidence
you have worked diligently to build. Clearly categorize and document all projected
costs and over-communicate so there are no missed expectations.
PRIORITIES
Scope, budget, and schedule are often called the triple constraint in project
management literature. One of the important outcomes of the negotiating process
is a sense of the clients priorities. A particularly vivid way of referring to scope,
budget, and schedule in the context of prioritization is the question: Does the client
want it good, fast, or cheap? Good refers to the projects performance
specifications, fast refers to the speed of developing the solution, and cheap is
obvious. Once we agree on the definitions, then the question is: which of these is
the higher priority, because you can only achieve two:

If the client wants it good and fast, it wont be cheap.

If the client wants it good and cheap, it wont be fast.
If the client wants it cheap and fast, it wont be good.

This is a cynical and glib way of looking at this. It clarifies the choices we
consultants need to make when we help our clients prioritize the objectives of an
engagement. Tactfully probe the client with questions such as What would the
impact be if this project could not be delivered in the time frame you envision? or
How would you handle a situation in which the technology available could not
deliver the functionality you expect? These are not literal questions to ask
verbatim, but as examples of diplomatic explorations of the clients priorities and
expectations. The key is to get a flavor for the clients tolerance for risk and change
and for the clients order of precedence of cost, schedule, and functionality.

Negotiation is not an incident that occurs and is done. As circumstances,

understanding, and personnel change, and as trust and confidence grow (or
diminish) between the advisor and client, the roles and responsibilities can shift
and shift again. Perhaps the Java programmer will gain the clients trust to the
degree that the programmer has an opportunity to devise an e-commerce solution
after all. As the due diligence and discovery process moves forward, insight may be
gained that sheds a new and different cast on the entire engagement. As hours are
expended and the client sees the budget reserve diminishing, he or she may ask for
a reduction in the consultants efforts. As the options and recommendations start to
take shape, the client may begin to realize that the technology was not what was
expected. The skilled consultant is prepared to negotiate and renegotiate
throughout the engagement. By remaining flexible, by having the maturity to resist
personal disappointment or ruffled feathers due to the need to revisit
expectations, by keeping everyones eyes on the prize, the skilled consultant
becomes a valued partner.
Chapter 4: Visualize Success
IT INERTIA
Question: How was God able to create the world in six days?
Answer: He had no installed base!
Conventional wisdom would suggest that having a base of dedicated users of your
technology would be an advantage. Wouldnt it be easier to sell this captive
audience upgrades to your systems? Wouldnt you have a database of registered
users to whom you could market additional products and services? Couldnt you use
an installed base to build an empire of supplementary products?
Well, yes and no. The advantage of having an installed base, especially if your
system is proprietary or closed, is that the costs of switching to another technology
can be so prohibitive that you essentially create a captive market. If youve done a
reasonably good job of servicing and supporting your customers and have kept up
with the current innovations in technology while maintaining compatibility
throughout the old and new product line, you indeed can build an empire around
your base products. But theres the rub. Eventually your responsibility to protect
your existing clients investments, by maintaining compatibility and not forcing
them to throw out their existing systems to benefit from new technologies, becomes
a drag on innovation. How many programmer hours did Microsoft spend carrying
DOS compatibility into the Windows universe?
Anyone who recalls the slow migration from DOS-based personal computing to
Windows will also remember the cry and protest from the installed base at every
step of the way. The fact that users would need more memory and hard disk space
was a scandal! The fact that Windows sometimes crashed was an outrage! The
introduction of the local area network, while obvious and useful, was also cause for
protest in the computer press. Whatever happened to the pure idea of a computer
for every person? Wasnt that what the personal computer revolution was all
about?

No matter what your opinion of Microsoft; theres now little doubt that graphical,
network-enabled computing has brought huge benefits. People did not resist these
benefits because they were stupid or short-sighted. They resisted them for a couple
of very human reasons:
a) Existing systems represent a substantial investment in hardware, software,
training, and hard-earned process knowledge.
b) People resist change.
c) Even technically sophisticated people cling to the familiar. Remember Ken
Olsen of Digital Equipment and his famous comment that nobody would ever
need a computer on the desktop, or Xeroxs well-known failure to take
advantage of in-house innovations like the graphical user interface and the
mouse (known inside Xerox as fumbling the future)?
The combination of vested interest, hard-won expertise and experience, sunk
investment in both hard and soft assets, and human resistance to change
creates an inertia that any action-oriented consultant must learn to counteract.
PROJECT VISION
The opposite of inertia is momentum. So far in our process, weve typically been
working with a single client or a small project team, reaching agreement on roles
and goals. But the fact that the project sponsor, an executive committee, or the
project team has reached a consensus does not automatically turn inertia into drive.
A common vision, clearly articulated, of success and its benefits is what creates
momentum in the organization. This chapter will help you help your client to
develop and communicate a vision of what will be gained when your advice is
followed.
Dont make the mistake of assuming that visualizing success is a soft goal, not on
a par with hard deliverables like a project plan or network design. As former
president George Bush can attest, the vision thing can be the difference between
winning and losing. Barriers to change are significant, inertia is a powerful force,
and the consultants job is evolving from that of a technologist to that of a business
strategist. As strategists, we must do more than devise systems in a roomful of
managers. If the study of organizational change over the last twenty years has
taught us anything, it is that vision, communication, and consensus regarding
change are critical to success.
Because we believe that a project vision provides a central communication and
motivation factor, we recommend that consultants help their clients to do the
following:

Create the tag line for the engagement;

Build project sponsorship teams;
Create a vision communication plan;
Cascade communications throughout the organization.
Create the Tag Line for the Engagement

Many books on consulting recommend creating a mission statement for every

project. Although this can be a powerful technique, the downside is that these

statements, rather than cutting to the heart of the clients requirements, end up
being a compendium of primary and secondary goals, nice-to-haves, feel good
objectives, and dreams and wishes. Your goal during the visualization process is to
simplify, to get to the core objective that the client sees. I begin by asking my client
or project team, When this engagement is successful and we go our separate
ways, what will we have delivered? This phrasing calls on the client to use
imagination, to see the moment when the completed system is up and running and
all the benefits are delivered. In short, it forces the client to visualize.
The most important guidance you can give your client at this stage is to make the
vision statement compelling. The projects compelling event may be related to
competition, customer service, comparative costs to other enterprises in the
industry, the inability to enter new businesses due to insufficient systems
infrastructure, or any other business-driven need. The vision of the end state must
be compelling enough to build sponsorship, drive internal marketing, and create
organizational enthusiasm. If the vision does not portray the benefit as greater than
the pain of change, inertia will triumph over momentum. Help your client keep an
eye on the ball, which is the need for a vision that can build impetus toward change
in the enterprise.
The goal of this exercise is to help your client draft a tag line, a one or two sentence
declaration of what the project will deliver. For example:
The X Corp E-Commerce Project will create a web-based platform to allow our
clients to view our complete catalog, order our products, and gain access to expert
assistance using our products.
Try to refine your clients definition of project success into a concise and persuasive
statement, then repeat and polish it together until the client feels it expresses a
vision of the projects success. The key is, when you have flushed out the core
success factor, and phrased it in a compelling way, you have the basis for the
communication and consensus building to follow. You also have a light at the end
of the tunnel to point to, when the client decides it would be nice if the system also
brewed coffee and mowed the lawn.
Build Project Sponsorship Teams
Change doesnt just happen; it must be lead. Executives cannot lead change unless
they are committed to it themselves. Once they are on board, they must then gain
the commitment of the troops. As Jack Welch, CEO of General Electric, has said,
The job of the leader is to ...articulate the vision to employees. Information
technology consultants can differentiate themselves from their colleagues by
helping clients obtain the executive sponsorship they need.
Every IT project that crosses departmental lines or is visible at an executive level
should include the creation of a project sponsorship committee. For instance,
consultants implementing enterprise resource planning software or other
technologies that require business-process reengineering need the support and
authority of a senior project committee to make decisions that transcend the
departmental. This committee should be recommended during the project
negotiation period, and should be composed of departmental management from the

functional areas involved, senior company management, and client IT specialists.

Most companies can be sold on bringing a committee together to periodically review
the status of important IT projects. By bringing the committee to consensus on the
project vision, the committee can then help broadcast to the organization a
consistent, persuasive project message. Assisting clients to utilize structures like the
project sponsorship committee creates an opportunity for the IT consultant to
operate at the level of a true management consultant.
Large organizations can have dozens of departments that could be affected by a
project. A hospital relocation project, for instance, can involve office workers, sales
teams, research and development scientists, clinical lab workers, and radiology
technicians. Participants from internal IT departments could include desktop
support, the data center team, the telecom group, and the network architecture
team. Each of these constituencies can have a sharply dissimilar view of whats
important in planning the move. In these situations I recommend the creation of an
integration team, whose role is to ensure that all share a common goal and that
project planning and activities are coordinated and working together. This team is a
crucial component of any organizational communication plan, bringing together all
stakeholders in a forum that allows interaction, debate, and knowledge sharing.
Consultants should ensure that not only the senior executives, but also the local
departmental managers and IT thought leaders are involved in sponsoring and
communicating the vision. By creating an integration team and scheduling regular
integration meetings, we assure that the vision of the project is received in the
same way by each group and project lead, and that the overall enterprise goal does
not become consumed in conflicting departmental agendas.
Create a Vision Communication Plan
At this stage of the engagement, it is your role to help lead the steering committee
and the integration team to agreement on the core success factors of the project.
Your client has engaged you because he or she believes you can help clarify
expectations. The members of these teams and committees expect you to bring
experience with the technology and its implementation, with the gotchas and
pitfalls as well as the benefits. You must use these teams, and your facilitation and
leadership skills, to carry the vision of what can be achieved to this level of
stakeholder. By asking the question posed earlier (What will have been achieved
when this is over?) and facilitating a discussion about the inevitable differences in
conception, you can assist these teams in developing a shared vision of a successful
conclusion.
When agreement has been reached, it is again important to distill that to a tag line.
This may be exactly the same as the tag line you developed with the project
sponsor, or it may differ significantly. Its important that these teams understand
that this tag line will be a key component of your communication program. That fact
will influence the phrasing and emphasis. This is a process of incremental
refinement, by which we help the client arrive at a vision of success that can be a
banner throughout the engagement.
When project sponsors, executives, and team leaders all agree on a vision of
success for the engagement, its time to cascade that vision to the next level of
stakeholder, the population of employees. If I were to rank the causes of project

failure Ive seen in my career, ineffective communication would top the list. Poor or
absent communication directly causes rumor, gossip, fear, division, confusion, and
ultimately resistance. Conversely, nothing can have such a positive influence on the
chances for success as a well thought out, clear, targeted, consistent, and continual
communication strategy. In consultant teams I work within or lead, I absolutely insist
that one of our deliverables be a communication plan. Any engagement that lacks
this element is setting the stage for defeat.
Cascade Communications throughout the Organization
Every communication plan must contain a number of fundamental components.
Foremost is linkage to the guiding strategy. Simply stating that we are, for instance,
migrating from a mainframe-based to a client/server-based accounting system tells
people what were doing but not why. The benefits, goals, and objectives must be
declared and marketed to those affected. Note the key word marketed. The point
of this exercise is to build enthusiasm for the result weve visualized. This requires
more than just a statement of fact. As in any marketing effort, it requires the
building of demand.
Communication must be consistent. If we merely recommend that all team leaders
let their teams know that were going to perform a migration, were exercising no
guidance over the form and content of the message. Competent consultants will
instead advise clients to compose a uniform message that is designed not just to
inform, but also to persuade. By uniform I dont mean that the R&D group, for
instance, will receive the same message as the production workers, word-for-word.
Rather, the underlying linkage to strategy should be consistent. Inconsistent
communication of the vision is as bad as no communication at all, as it confuses
people and fosters resistance rather than momentum. (If they cant even get the
message straight, how are they going to implement a complex system?) Consistent
communications do not happen by accident.
They are the result of agreement by all the parties that communication is a key
success factor, worthy of planning and coordination. Communication should be a
recurring agenda item for the teams that control the engagement.
Honesty is central to effective communications. It is a common conceit of managers
that they can spin the negative aspects of a project so that the disturbing
elements wont be noticed. The fact is that people are not stupid, and they will draw
their own conclusions. It will be obvious to folks that a massive outsourcing effort
will result in some job loss. Denying or ignoring this fact in your communication will
just shed doubt on your entire message. It is only fair to prepare people for the
results of your initiative, both good and bad. Competent consultants help their
clients frame their messages so they are truthful without being demoralizing.
Communication should be constant and should be transmitted through many
mediums. I cannot count the number of project sponsors Ive known who send out a
memo and think their communication tasks are complete. One of the key adages of
communication is that rumor fills a vacuum. If communication is not kept up
throughout the life of the engagement, gossip and hearsay will take the place of
fact. When planning communication, plan for the message to be sent by memo, email, poster, meeting, video, lunch and learn, and whatever other medium is

available in the organization. With the availability of intranet technology, a project

website can be an effective medium for both message transmission and group
interaction. Ongoing updates, chat sessions, frequently asked questions (FAQs),
interviews with managers, and Q & A e-mail boxes can create an interactive
community focused on the progressing changes.
Finally, communication is not a solo exercise. A memo that falls in the forest with no
one to hear it makes no sound. Without the opportunity to respond, ask questions,
make comments, and complain, the employees will not feel as if they have been
communicated with. Consensus, enthusiasm, and momentum toward change
cannot be decreed. Build opportunities for feedback and interactivity into your
communication plans.
LESSONS IN CHANGE
Organizational change has become a discipline in its own right, gaining the focus of
top business minds such as Michael Porter, Peter Drucker, and Michael Hammer. The
Business Process Reengineering (BPR) movement has emphasized that managing
change is a fundamental business skill. One of the fundamental tenets of BPR is the
requirement to apply information technology to the correct processes. Turning cow
paths into superhighways is the disparaging term used by BPR consultants to
describe companies that automate inefficient and unproductive processes.
Reviewing the underlying processes themselves, ensuring that they add value and
are not redundant or unnecessary is a central element of any effort to improve
efficiency and quality. The lessons of the BPR movement must be understood by IT
consultants. We do our clients a disservice if we do not question (at least in our own
minds or with our teammates) the value and productivity of the processes we are
computerizing.
Another lesson of the BPR movement is that technology is an enabler, not a driver,
of competitive advantage. When the case for change is made based on business
justification rather than the availability of new technology, communication is easier,
gaining consensus is simpler, and the results are better. The introduction of
Enterprise Resource Planning (ERP) software, including products by SAP, Baan, JD
Edwards, Peoplesoft, and others, creates an environment in which it is no longer
advisable to create pockets of incompatible and isolated systems within
departments of the organization. Enterprise resource planning software, and its
cousin customer relationship management (CRM), require the technology consultant
to apply significant business analysis skills. These modern classes of enterprise
software focus on the entire operation and its complete chain of business processes,
and so require deep understanding of the following:
a) The business integration points, where functions and processes meet and
interact,
b) The boundaries, where functional, political, and cultural divisions exist, and
c) The details of current financial, organizational, system, and product strategies
and tactics
d) Not all IT consulting projects will require this level of complexity or strategic
analysis.
e)

Many, perhaps most, IT consultants are focused on a technical specialty and are
engaged to bring that specialty to bear on a discrete problem or opportunity. The
expert in HTML requires some basic business background, as weve discussed, but is
usually task-focused. The network infrastructure designer may need to grasp a
broader scope of enterprise issues, as the network will probably cross internal
departmental borders. The expert in groupware and messaging systems must delve
still deeper, as the issue is not just network plumbing, but also issues regarding
team interaction and human communication needs, as well as the mapping of
existing processes onto a new technology. The consultant who tackles major change
projects such as ERP implementation must also understand underlying political and
human issues that will affect the ability to integrate functions and cultures
successfully. These are not judgments on the worthiness or importance of these
specialties. Each is meaningful and delivers benefits within its own scope. But the
mix of technical and business skills required are driven by the engagements we take
on, and vice versa.
Information technology consultants are well-trained and certified in their technical
specialties. They are typically not as well-versed in advisory skills. The clients with
whom you will engage as a consultant are, in many ways, in the same boat. They
have historically been proficient in the financial analysis, organizational, and
marketing skills that are emphasized in the typical MBA program. The softer skills
of motivating people, dealing with the ambiguity of human emotion and fear, and of
communicating a common vision may be outside of their comfort zone. The practice
of visualizing success, of agreeing on a clear goal, and creating organizational
momentum toward fulfilling it is a value-added service, outside of the strictly
technical, that the effective consultant can learn and then teach clients, leaving
them with a valuable skill that will endure beyond the engagement at hand.

Chapter 5: Understand the Clients Situation

THEORIES INTO FACTS
Sherlock Holmes, the timeless literary creation of Arthur Conan Doyle, has been
called the father of fictional detectives. But, if you believe the master detectives
own words, he considered himself a consultant. In fact he remarks, in A Study in
Scarlet: Im a consulting detective, if you can understand what that is.
To the practicing consultant, however, there is a more instructive quote from
Holmes: It is a capital mistake to theorize before one has data. One begins to twist
facts to suit theories, instead of theories to suit facts (from A Scandal in Bohemia).
Unfortunately, until now we have been committing Holmes capital mistake. We
have been proceeding based on conjecture. Our client has given us theories about
the cause and probable solution to a problem. We have applied theories, usually
based on the biases we bring into the engagement, about the technology that might
be used to solve those theoretical problems. We have hypothesized with our client
about what the organization might look like when we are done with our project and
what benefits might accrue.

All this speculation is an integral part of the consulting process. In addition to the
obvious fact that we have to start somewhere, each of these theories is in its own
way a fact. It is a fact that the client perceives the problem to be as described. It is
a fact that the sponsors have individual visions of the end point. The fact that these
perceptions and preconceived notions exist will be an important factor for us to
consider as we progress. More importantly, the trust, confidence, and sense of
shared mission we have created during negotiation of our role and visualization of a
successful conclusion will be critical to the more intrusive activities we are about to
begin. We as consultants have an important role to play in turning theories into
facts. We can, if we are skilled, perform a detection process that will guide us, and
the client, to the best choices for solving the problem at hand.
We use the terms data collection, discovery, and due diligence
interchangeably to describe the activities in this section, but I want to bring special
attention to the concept of due diligence. Accountants or bankers can be held
legally liable for actions that are in conflict with their professional duty to act in the
best interest of their clients. As emphasized earlier, consulting is a profession, like
accountancy, with a similar responsibility to act in the best interest of our clients, to
protect them from their lack of knowledge about our specialty, and to inform them
of risks that we uncover in the performance of our tasks. There have been cases of
consultants being sued by clients for not informing them of Year 2000 risks that the
consultant should reasonably have uncovered, even though the consultant was not
hired to do Y2K work. You must perform due diligence, well, diligently. Include
enough time in your estimate and project plan to uncover and analyze the data, so
you can make an informed decision about risks and special situations in the clients
environment. Have the courage to dig a bit deeper and to be the bearer of bad
news if you discover situations that threaten the project. Develop a relationship of
mutual trust by being truthful and thorough in your investigations. Protect yourself,
your consulting firm, and your client by communicating risks with diplomacy, but
with urgency.
AN APPROACH TO THE DISCOVERY PROCESS
Before we begin to develop an organized framework for collecting the necessary
data and gaining an understanding of the as-is state, we need to again clarify the
goals of this framework as they relate to this phase. There are libraries of books that
present methodologies for discovering and understanding the complex interactions
of systems in the enterprise. Structured Systems Analysis, Business System
Planning, Information Movement and Management, System Architecture and
Investment Planning, Enterprise Information Management, and many others
have added insight and process to the task of understanding information systems.
This framework, however, is not designed for that. The intent here is to offer an
approach to the tasks of due diligence and discovery. The questions answered here
are:
a) How do we gain a better understanding of the clients culture and norms of
behavior, so that our diagnosis is correct and my recommendations are
followed?
b) How do we develop a holistic view of the as-is state, so we can make
recommendations that are in their proper business context?

c) How do we set the client up for successful project results by the actions we
take during the data-collection process?
This is not to slight the formal disciplines. For most IT professionals, our specialties
require that we apply a rigorous and precise process to the collection of current
state data. This framework is a layer, to which the consultant must add the project
management, data collection, analytical, and technical tools pertinent to the field.
THE ENTERPRISE IT MODEL
Like architects, consultants need to think in layers. Most structured programming
methodologies recommend that complex problems be divided into smaller and
simpler parts, so they can be conquered more easily. It may be overwhelming to
think of designing an integrated accounting application, but writing a module to
print checks may not seem so intimidating. Those of us who have been exposed to
networking technology are familiar with another divide and conquer reference
model, the Open Systems Interconnect (OSI) model. This common illustration of
network functionality is based on a layered approach, with the physical medium of
communicationthe wire and the network interface cardat the bottom,
successively higher layers representing more abstract functions, and the application
that the end user works with at the top. This way of partitioning an intricate system
into successive layers is a potent aid to understanding.
Deconstruction also makes sense when trying to understand an organizations data
systems. Before any data collection begins, we should think about the clients
business systems in their component layers. The bottom-up assembly of elements is
the Enterprise IT Model. Technology infrastructure is the bottom layer, succeeded by
Data, Applications, Processes, and Business.
Technology Infrastructure:
For those businesses that are not automated, only the process and the business
layer are pertinent to this discovery phase. For the majority of our clients, however,
some systems will be in place. Whether its an IBM mainframe, with channelattached cluster controllers and CRTs or a multi-site, multi-domain wide area
network, each business has an infrastructure, its IT plumbing.
Data
The next component is the data that is transported through these pipes. For those
of us, such as network designers, who are primarily concerned with data
connectivity and throughput issues, the infrastructure and data levels are the most
relevant.
Application
The applications that the client uses to run the business are a level up in this model.
For the consultant engaged in software design and programming, the
implementation of new programs, or the migration to a new release, understanding
this level is crucial.
Processes
The processes and procedures that control use of the systems and their information
is the next level we need to understand. For the business process consultant, the

ERP specialist, the groupware and messaging expert, and the intranet or website
designer, the work flows, rules, and culture under which work is done must be
analyzed, documented, and understood.
Business
Finally, for the strategic IT consultant and the management consultant, an in-depth
analysis of the enterprise, its strategic vision, and its business model is central to
the task.
As emphasized previously, even the IT contractor, such as a programmer for hire,
should not implement IT in a vacuum. No matter what layer of the systems
architecture you are primarily focused on, it is your duty to the client to understand
the business context within which you operate, to ensure that your
recommendations and finished systems address the right need in the right way. The
more you understand all these layers, both those above and below the one at which
you perform your role, the better a partner you will be for your client. This does not
contradict the earlier assertion that you should stay focused on the tasks for which
you have been contracted. It is part of the art of consulting to make a judgment
about how much investigation and discovery your role calls for. Always keep the
clients wallet in mind, and make sure you dont put yourself in a position in which
you have to justify investigations into areas that were outside your scope. Its just
as important, however, to be prepared to negotiate for access to data that is clearly
pertinent to the project. If the client, or any participant, is trying to manipulate the
outcome by building barriers, this is a cause for alarm, for diplomacy, and possibly
for renegotiation.
DATA-COLLECTION METHODS
There are some basic data-gathering methods that apply at each layer of the
Enterprise IT Model:
Review of Existing Documentation
This includes analyzing existing reports, output, plans, diagrams, manuals,
procedures, forms, flow charts, and other documents related to the system.
Observation
Watching the flow of activities that make up the systems and processes under
discovery.
Inventory
Counting and documenting the physical components of the IT architecture.
Surveys
Questionnaires that are sent to a representative sampling or the entire community
for information on the system under discovery
Facilitated Work Sessions
Group working meetings, led by a facilitator, to discuss and uncover required
information about the systems under review.
Interviews:

One-on-one conversations relating to the engagement

The less intrusive activities should take place at the beginning, when you are first
building an understanding of the client organization. Once you have performed the
early phases of your due diligence process and the relationships and processes start
to take shape in your mind, you can engage more interactively with individuals and
teams. My experience has been that clients and work teams consider it
unprofessional and distracting for you to ask them basic questions about things that
could be learned from documentation, surveys, and inventories. By performing our
basic discovery procedures up front, and then using our face time to clarify and
amplify, each conversation and team session is efficientand a further display of
our professionalism. Remember also that each of these data-collection methods is
better applied to certain parts of the enterprise, and each is inappropriate in some
circumstances.
Review of Existing Documentation
Clearly this part of the discovery process touches all of the enterprise layers
described above. For engagements that involve the physical plant itself, such as the
move of a data center from one building to another, power and HVAC diagrams may
be meaningful. For the design of a reporting module, the review of building
blueprints is obviously deeper than we need to go.
Following is a list of some of the existing documents that might be collected,
depending on the engagement, when reviewing each layer of the enterprise IT
architecture:
Infrastructure
a) Product standards lists,
b) Asset management or purchasing data,
c) Network diagrams,
d) Network addressing schemes (such as IP schemas and subnets),
e) Domain and directory structures,
f) Building blueprints and schematics,
g) Cabling plant diagrams,
h) Wiring closet blueprints and port diagrams, and
i) Facilities documents, such as power and HVAC schematics
Data
a) Data dictionaries or schemas,
b) Data warehouse documents,
c) Standard reports, and
d) Network analysis (sniffer) dumps.
Applications
a) Standard application lists,
b) Manuals or training materials,
c) List of nonstandard applications in use, and
d) Asset management reports
Process

a) Process or procedures manuals,

b) Flow charts,
c) Forms,
d) Backup and recovery procedures, and
e) Contingency plans.
f) Business
g) Annual reports,
h) Strategic plans,
i) Competitive analyses,
j) Organization charts,
k) Team rosters,
l) Job descriptions,
m) Training materials, and
n) Marketing materials
This is a comprehensive list that will be overkill for many engagements. The
purpose of this list is to guide your thinking. Ask for and review the relevant
materials before you begin to interview and survey. You will avoid looking
unprepared and asking redundant questions, thus annoying and unnerving your
client. The trust, confidence, and vision aspects of the data-collection process must
always be included in your calculations. By doing your homework, you elevate your
services in the eyes of the client.
Observation
This is a good place to quote Yogi Berra, who remarked that You can observe a lot
just by watching. Its also a good spot to mention one of the most effective
management techniques in use today, MBWA, which stands for Management by
Walking Around. All great consultants have one thing in common: a keen power of
observation. More can be learned about the strengths and challenges of a company,
or a team, by observing the atmosphere and environment than by poring over flow
charts all day.
Any reader who has a background in physics will recognize Heisenbergs
uncertainty principle, one tenet of which is that systems are modified by the act
of observation. You dont need to be a physicist to know that if the boss tells the
team that a consultant will be watching them work, what that consultant sees will
be different from the norm. This makes observation a difficult practice to structure.
Care must be taken not to disturb the patterns of work youre trying to observe.
Rather than walking through the workplace taking notes on a clipboard, which will
surely influence the outcome, observation should be a casual and unobtrusive
exercise. Try to observe:
The Environment: Is it a noisy shop floor or a dignified office? Can the teams
communicate normally or do they need to shout?
The Atmosphere: Is work done in an informal, collegial way? Are workers selfdirected, or is a shop supervisor monitoring the activity?
The Work Flow: Is it automated and process-driven, or manual and relationshipdriven? Is there a high level of interruption or does work flow smoothly?
The Attitudes: Is there a team atmosphere with everyone chipping in to assist their
mates, or is there a contentious atmosphere, with everyone keeping track of how
long their co-workers take for lunch?

One of the first questions to be asked to the consulting teams when they return
from working on an engagement is: Whats the atmosphere? This may seem like a
less-than-rigorous method of analysis, but the attitudes toward consultants, toward
IT in general, toward the company, the team, and the work are indicators of the
potential for success. As we discussed in the opening chapters, advice must always
be adjusted to suit the audience, and our observations of attitude and atmosphere
will influence the content and style of our counsel. Organizations with a formal
atmosphere, where everyone wears a business suit and all communication flows
from the top down, will be less than tolerant of informal grooming, dress, or
expression. In a contentious atmosphere, where co-workers are checking each other
to assure that nobody takes too long a break, formal time accounting and
justification of tasks are a critical component of the consulting relationship. If, on
the other hand, the atmosphere is collegial and trusting, and the client is an old
hand at partnering with consultants, interaction can be less rigid and covering your
back may not be an appropriate use of your time. Your assessment of atmosphere
will also influence the formality of the processes and procedures you design into
your systems. By heeding your observations on organizational culture, you can build
the appropriate amount of system checks, balances, and status reporting into your
work flow and processes to suit the clients requirements.

Inventory
Performing an enterprise inventory can be the most frustrating exercise in an IT
consultants life. When we start the process, we know that as we complete each
section, it becomes outdated. When we try to convince the clients that an inventory
is necessary, they will reply that they have complete records in their asset
management database. When you review the asset management at a base, it will
consist of furniture and typewriters, plus four Apple IIs and an Atari 800. Network
documentation will be superficial or incorrect. Standards enforcement, especially in
the realm of distributed computing, is lax or nonexistent. Employees will consider it
a disruption to have to allow a technician to crawl under their desk and start noting
serial numbers or data ports. When your team shows up to inventory a PC, that user
will have a report due to the CEO in an hour.
With these inefficiencies and frustrations acknowledged, lets also concede that
there are circumstances under which an inventory is indispensable. When
performing a workstation standardization project that requires us to replace any
workstation not capable of running Windows 98, for example, we need to know
which ones fit into that category, exactly how many there are, where they are, and
who owns them. The level of complexity increases if an upgrade of existing systems
is an option, because rather than simply replacing all noncompliant machines, we
now need to understand them at a component level to determine whether theyre
worth upgrading. In either case, we also need to know what applications are running
on them all, so we can ensure that the user retains access to programs and data.
We need to know whether the data resides on the local hard disk or on the network,
so that we can migrate the data to the new or upgraded machine. This information
will not be collectible from a survey, because most users wont know the answers to
the questions.

There are some organizations that have implemented asset management and can
supply a reasonably accurate report on their installed base of hardware and
software. In these lucky cases, I still recommend at least a random representative
sampling to ensure the accuracy of the data. Asset management will not record
whether data storage is local or networked, for example, so some follow-up will still
be required, if the project needs those details.
Each consultant will need to determine the level of detail required based on the
engagement at hand. When a detailed inventory is required, the fundamental
questions to consider before setting out are:
Exactly what do we need to capture, and at what level of detail? As shown in the
previous example, an upgrade project may require that data to the component level
be captured, while a move project may just need a system count.
What level of application data do we need? A migration between different
operating systems at each desktop may need more data than an application
upgrade.
Do we need to understand how data is flowing and where it resides?
Once weve answered these questions, the design of an inventory project will
typically have these components:
A Schedule: This outlines when inventory teams will collect data on each
department, work group, or geography. Remember to consider business timing
issues. Dont plan to inventory the tax department in April, for instance. Also have a
plan for those times when you arrive as scheduled and the user has a priority task
that cannot be interrupted.
A Communication Plan: This is used to inform users that an inventory is about to
take place. Performing an inventory is intrusive. Be sure that users are informed and
persuaded that this is a meaningful activity so they cooperate with the process.
A Database to Collect the Information: There are several commercially available
inventory programs, such as Tally Systems, that have pre-designed database
schemas to capture PC-based data. If your inventory project is not PC-based, you
will need to create a schema and select a database system for managing this data.
A Collection Form or Program: Systems like Tally can create a walk-around diskette
that allows technicians to visit each PC and collect its data on a diskette. Other
systems collect data on log-in or over the network. For older systems or non-PC
environments, a checklist or form may be required.
An Inventory Strategy: Will this be an ongoing process during business hours or a
SWAT team approach with a large team descending overnight to collect data?
A Reporting Structure: Who needs to see the output of this data and in what format?
Web-based output can be quite useful, especially if the client is the audience for the
data collected.

An Update Mechanism: In projects for which the data will become out-of-date during
the course of the discovery, it may be necessary to plan a procedure for revisiting
some sites to confirm findings. When it is critical that the data be accurate, I
recommend negotiating a moratorium on new hardware and software installations
during discovery.
Information technology advisory services, such as The Gartner Group, that analyze
and report on efficient use of computing resources, have established that asset
management enables organizations to save money and to more effectively manage
their technology assets. By advising your clients to take the long view and look at
inventory activities not as a one-time event tied to a specific project, but as an
opportunity to consider implementing an asset management strategy and so gain
control of their systems architecture, you can add significant value. If the climate is
right for this discussion, you can help your client move from a tactical to a strategic
model of IT management.
Surveys
Surveys are typically questionnaires pertinent to the environment under review. For
instance, when Im preparing to do a large desktop operating system migration, my
team needs to know what applications are in use to prepare for compatibility and
data-migration issues. It would be another complete project to do a desk-by-desk
inventory, and in many organizations users are scattered all over the globe. The use
of a targeted questionnaire can elicit a response inexpensively and quickly. Surveys
are useful in situations in which:
a) A knowledge holder can respond. Although it makes sense to survey users
about the applications at their desktops, who would you survey to ask about
the age and status of the cabling plant?
b) Different elements need different collection techniques.
c) Knowledge holders are scattered.
d) The time to perform an inventory or interviews is not reasonable based on
the schedule.
e) The budget to perform an inventory or interviews is not available.
f) A wide statistical overview is required.
g) Opinion and comment are invited. Besides the obvious fact that those on the
front lines have the most knowledge about how processes really work, the
chance to submit anonymous comments can build an atmosphere of giveand-take, communicating that those affected have a voice.
Some of the advantages and disadvantages of using surveys are listed below:
Advantages of Surveys
a) Inexpensive
b) Unobtrusive
c) Can be reviewed and tabulated by administrative staff, saving client money
d) No interviewer bias to distort the analysis
e) Little opportunity to influence attitudes by explaining or marketing the project
vision

Disadvantages of Surveys
a) Questions can be misinterpreted
b) Data is reviewed in a vacuum, without the chance to meet and observe the
individual and the workplace
c) Low response rates
d) Low interaction
e) Little opportunity for clarification or amplification
Designing surveys would seem to be a simple exercise. If you need to know what
application the subject is using, just ask. If you want to know what role the person
has in the process, just put in a question that asks: What role do you have in the
work flow? Unfortunately, most employees dont think of their jobs as part of a
work flow and may not know what happens to the reports they produce, or whether
Microsoft Word is an application, an operating system, or data.
This is not to imply that they are not bright. They just think of their jobs in a
different language and context than we, as IT analysts, would. When designing
surveys, we need to think through the following points:
a) Who are the subjects of this survey? Is it everyone, a sampling by
department, a random sampling of the whole enterprise, managers or
production workers only? How do we decide?
b) What is the use of the data we collect?
c) Exactly what are we trying to discover?
d) How will we communicate to the subjects of the survey what we are trying to
accomplish and why they should care? (For instance, in most cases a cover
letter from the president of the company will get a better response than a
letter from some consultant no one knows.)
e) How do we ensure that the questions are clear, direct, unbiased, inoffensive,
and jargon-free?
f) How do we arrange the questionnaire so the data collected can be easily
analyzed?
g) How do we make it as convenient as possible for the subject to respond? This
can mean multiple-choice questions, check offs, pre-addressed forms and
response envelopes, and so on.
Surveys can be valuable tools in the data-collection kit, but they should be applied
under the right circumstances, with the understanding that they are impersonal and
that a majority of those contacted will never respond. Also consider that, unless
there has been substantial communication, the appearance of surveys makes
people nervous and can set off the rumor mill. Never neglect to take into account
the facts that gossip fills a vacuum and that people are naturally nervous about and
resistant to change. If a survey arrives out of the blue with no previous discussion,
there will be a contingent of folks who interpret the question What is your job
function? to mean that they are about to lose their jobs.
Facilitated Work Sessions
When we have reviewed any existing documentation, done some management by
walking around, and analyzed survey results, we should be starting to develop a
mental picture of the clients business and work flow. Typically at this point, we will

start to recognize the gaps in our understanding, where only a meeting with the
client teams will help us grasp the nuances of culture, the undocumented
processes, and the shadow hierarchies that exist in every company.
Looking at a company flow chart of the PC procurement cycle, for instance, may not
tell us why it takes three months to get a PC on a users desk. As an example, I was
contracted by a large Midwestern bank to help them optimize their PC acquisition
process. Although their purchasing process followed a documented procedure and
should have taken a couple of weeks from order to delivery, it was taking them up
to one hundred and twenty days. Their acquisition and configuration process looked
clean, and after some review it seemed that the purchase orders were becoming
bogged down somewhere between the department managers approval and their
arrival in purchasing. During a work session with a group from the purchasing
department, one of the agents told me, Mr. Van Kamp (the bank president) fancies
himself a technology buff. He likes to look at every PC order to see what kind of
hardware people are buying. So purchase orders for less than $2,000 were piling
up on the bank presidents desk while users waited for their PCs. This is the sort of
out-of-process hang-up that never makes it to the flow chart.
Whether in interviews or group work sessions, the consultant will eventually reach
the point in the discovery process at which its time to test his or her understanding
and move beyond the official, documented procedure to uncover how work is really
done in this organization. The consultant will need to meet with employees, teams,
and managersin short, with the knowledge-holders. The facilitated work session is
the ideal forum for exploring the reality behind the organization chart and the
procedures manual.
Facilitation skills will also be important when we move to the creative process of
solution design. Facilitated work sessions will be an important tool as we work with
our design team to create a solution, and as we partner with the client to select and
implement technology.
I use the term facilitated work session here, instead of simply meeting, advisedly.
Before facilitation techniques became well-known, meetings were prone to
unproductive behaviors such as:

Poor or late attendance,

Lack of clear goals,
Lack of consensus,
Lack of direction,
Dominance of strong attendees or of managers,
Interruptions,
Hidden agendas,
Lack of clear resulting action items, and
Undocumented results, to name a few

All business people have had the experience of walking out of a two-hour meeting
with the question, What was the point of that? With no leadership and no
methods, meetings dont achieve results. Facilitation is the practice of structuring

and managing meetings with the aim of achieving a goal. By following some basic,
common-sense techniques, meetings can be conducted in a way that is more likely
to:
a)
b)
c)
d)
e)
f)
g)
h)

Obtain agreement on the objective of the meeting,

Encourage dialogue,
Discourage hidden agendas or rank from sabotaging group objectives,
Involve all members,
Clearly document the issues raised,
Record the outcome,
Provide concrete action items, and
Facilitate the achievement of the best results possible.

Most facilitation techniques are based on common sense. Although expert

facilitation is an art and the accomplished facilitator has mastery of complex
methods and tools such as multi-voting, force-field analysis, and decision matrices,
in this discussion well stick to the basics like listening, probing, questioning, and
recording. A hallmark of the professional is preparation. Every meeting called with
the clients team is an imposition on their time and productivity. This project may be
your only mission, but most of the people you engage from within the client
company have other jobs that are probably of higher priority. Therefore, use their
time respectfully.
Some Hints on Meeting Preparedness
a) Do Your Homework. Know your goal, how you intend to get there, and why
these people are involved.
b) Prepare Your Team. Make sure that all representatives of the consulting
organization are on the same page so you dont have embarrassing
disagreements or gaffes in front of the client.
c) Provide Pre-Reading. Distribute agendas and background materials ahead of
time so that everyone is prepared and understands the purpose of the
meeting.
d) Adhere to a Time Contract. Estimate the time you will need, inform the
participants up front so they can plan their time, and respect the contract.
e) Set Reasonable Goals: Divide and conquer so that meetings are focused
and so that everyone leaves with a sense of accomplishment instead of
frustration. Five focused meetings with the right goals and attendees are
more productive than one marathon session with unreasonable expectations.
f) Prepare the Meeting Space: Get your flip charts, markers, pads and pencils,
audiovisuals, and other materials in place so you dont waste your clients
time searching for an eraser.
g) Bring in an SME: If youre dealing with technical material, have a subject
matter expert ready to drive that part of the conversation.
h) Be a Gracious Host: Provide food, drinks, bathroom breaks, phone breaks, and
so on. Allow participants some informal moments to chat and bond.
When the meeting is underway, the facilitator will focus on ensuring that everyone
understands and agrees on the goal and on managing the process of achieving that

goal. Easier said than done, of course, so lets review some of the skills that aid us
in facilitation:
Questioning
Asking questions is the basic method for fostering participation. Open-ended
questions such as: Why do you think we have a bottleneck here? or What does
the team think about this application? encourage opinions, feelings, and reactions.
Open-ended questions such as: Why is that? or Could you give me an example?
allow you to probe more deeply and to challenge assumptions by requesting
specifics. Closed questions such as: Have we covered this in depth? or Does
everyone agree on the goal? allow us to bring closure to a topic and test the
groups willingness to move on.
Summarizing
Restating and consolidating remarks and ideas gives you the chance to test your
understanding and to direct the group to the next agenda item.
Inclusion
To ensure that everyone participates and that stronger personalities or ranking
figures dont dominate, use techniques such as directly asking quiet members for
their opinions or going around the room so all have a chance to contribute.
Impartiality
Be sure to keep your facilitation pure by not telegraphing your acceptance or
disapproval of suggestions and by preventing your biases or preconceptions from
censoring the teams direction.
Listen Actively
Dont allow the demanding role of facilitator to dilute your focus on the messages
being conveyed. Dont interrupt, and dont think ahead to your response.
Demonstrate by your attitude and body language that you are receiving the
communication.
Record Diligently
The flip charts and whiteboard are the official record of the meeting. The facilitator
must ensure that open issues, decisions, and action items are documented. I prefer
using a scribe to manage the recording process, although this is a matter of style.
Some facilitators choose to do the recording themselves and use this function as a
potent technique for managing the meeting. Keep a parking lot of unresolved
issues, and be sure to agree on a method for revisiting them, whether its another
meeting, a memo, a vote, or assignment of issues for follow-up.
Structure the meeting in phases, with a defined beginning, middle, and end. In fact,
a meeting is a microcosm of an engagement, with an approach, a negotiation, the
joint creation of a vision, and the use of a framework for driving to a result. As in an
engagement, focus on the relationship and the human interaction aspect, as well as
on the content.
As the meeting gets started, perform the following tasks:

a) Go around the room and do introductions. Even if all the participants know
one another, they probably dont all know you and will be interested in how
you describe your role.
b) Agree on the agenda. You have informed the participants of your purpose for
calling this meeting, but let them restate it so you are sure they understand.
Stop and work through any misunderstandings or disagreements. Its as
important to start the process with clarity as it is to reach a predetermined
schedule or end point.
c) Explain the role of the facilitator and the scribe.
d) Review logistics. Explain details such as meals, bathroom breaks, phone
breaks, pager and cell-phone etiquette, and so on.
While reviewing work flow in a discovery session, ask questions such as: What
triggers this action? and When youve completed your tasks on this, where does it
go next? The purpose is to get a picture of both the official and unofficial work
flows and relationships. As the meeting progresses, it is your role as the facilitator
to keep the group focused on the goal and to use your judgment regarding when to
let conversation flow and when to move on. This is the art of facilitation: knowing
when the creativity and value has been exhausted from a topic. By watching the
body language, the flow of ideas and interaction, and by making some value
judgments, you will learn from practice how to focus the discussion. Before a
facilitated session wraps up, ensure that the following tasks have been completed:
a) Consensus on and documentation of all decisions;
b) Agreement on action items (action items must be assigned and scheduled,
not just listed);
c) Schedule for next meeting, if appropriate;
d) A brief feedback session (for example, ask: Did this go as you expected it
to? and Were there issues you thought we should have discussed that were
neglected?).
Each meeting, like each engagement, has an atmosphere and a flow of its own.
Some teams will instantly gel and work together cooperatively and freely to achieve
superior results. Some will congeal like sludge and spend an hour sullenly staring at
their hands. Beginning facilitators will be nervous or experience stage fright when
managing a large team gathering. As your skills as a facilitator grow, you will
develop strategies for dealing with different meeting situations. The key is to relax
and let the flow be what it is. Dont take it personally when meetings are
unproductive; some mixtures of personalities just dont take. By remaining alert,
focused, and compassionate, you will evolve into a skilled facilitator and learn to
help teams contribute at their highest potential.
Interviews
Interviews are the most intrusive and intimate encounters of all. They should be
used to obtain final clarification from key knowledge holders or final decisions from
executives or sponsors. Interviews should be the final step in the discovery process,
after all data from the other sources mentioned above have been tabulated,
analyzed, and digested. Interviews are critical in filling any gaps in your
understanding of any of the layers of the Enterprise IT Model.

Interview front-line doers as well as supervisors, to get a real-world understanding

of the informal as well as the official work flow. Try to select the best representative
of the function you are examining, someone who has experience in the function and
can articulate its meaning and boundaries.
As with all data-collection activities, prepare thoroughly. Interview preparation
should include the following steps:
a) Make a Roster and Schedule. Create a roster of interviewees, then set up a
schedule.
b) Assign Interviewers. If working in a consulting team, assign interviewers who
have familiarity with the functional area or subject matter that is the focus of
the interview.
c) Be Clear. Have a clear idea of the objective for the interview and
communicate that to the subject and the interviewer. If this session is to
clarify or amplify a particular topic, communicate that as well so the subject
can be prepared. If appropriate, design an interview form for data collection.
d) Be Prepared. Gather any materials, such as organization charts, flow charts,
forms, reports, or other material that may be needed in the interview session.
e) Use Good Meeting Etiquette. Of course, follow the good meeting behaviors
described earlier.
Facilitation skills are as valuable in a one-on-one encounter as they are in a group.
The ability to set the expectations for the interview clearly, to manage the
interaction towards an agreed objective, to reach consensus on the outcome, and to
record that outcome requires some of the same listening, questioning, and probing
skills we have just reviewed. The advisory, human relationship building and
preparation skills are again the deciding factor in building trust and cooperation.
Each interview should result in a record, either a form that is filled in or a narrative
transcription of the session. Remember that conversation is subjective and subject
to interpretation, so be sure that you allow the interviewee to review your record of
the session and to confirm or deny its accuracy.
THE AS-IS MODEL
The final activity in the discovery process is the creation of the as-is model, a
compilation of the data that youve been collecting into a detailed description of the
enterprise that corresponds to the Enterprise IT Model. The extent of your
engagement will dictate the depth of your modeling. Your team size will also
prescribe the process for compiling this data. If you are working as a solo
consultant, you will spend some hours working through the data youve collected
and ensuring that you have an understanding of the issues that are pertinent to
your project. If you are part of a consulting team on this engagement, then the
facilitation skills we reviewed earlier should be applied to the creation of an as-is
model. Bring your team together and facilitate a session wherein you review the
material, put all the flows, processes, and systems on the board or flip charts, and
come to a consensus on your findings.
One popular method of doing this is the brown-paper session, where a roll of
brown butcher paper is tacked to the wall and team members can either write
directly on it or stick Post-it Notes to it, depicting the major systems, their

interactions, and any open questions or concerns. This is a particularly open and
involving type of facilitated session, and it can be a creative expression and a teambuilding experience. The natural tendency will be to try to move to the to-be
model, so focus the group on documenting what they have found before they start
to fix it. Remember what Sherlock Holmes said, and dont try to fit the facts to the
theories!
The client deliverable to come out of these deliberations should be a findings
report with diagrams, flow charts, and descriptive material about your discoveries
and how they relate to the project at hand. You may want to assign different parts of
the deliverable to different team members. Each IT consultant or team will apply
specialized disciplines to this activity, whether its the network design team using a
graphic design tool to depict the current network architecture, or a software
designer using structured system analysis tools to prepare diagrams of the process
and logic of a customer order-processing application. The element that
differentiates the technical craftsman from the consultant is the focus on
communicating to the client in the clients own language. While you as the software
designer may need data flow diagrams to visualize the interactions between
systems, your client needs clear, business-oriented language in order to feel
included in the design and decision-making process.
Be sure to review the deliverable for accuracy, pertinence to the engagement, and
for correct expression. If you have found processes that are not working, say so
directly but diplomatically. If you want to say that only an idiot would run an
accounts payable operation like this, please review your language carefully!
Remember again that you are a guest in the clients house, so dont call the baby
ugly! Take your emotion and ego out of the process. Have humility and compassion
for the history and personalities that have brought your client to the current state.
Review, and then review again, the document that you are preparing to submit.
Consider the total potential audience for your findings, from clerks to CEOs, and
make sure that each of them would find it accurate, dispassionate, inoffensive, and
helpful. The discovery process is difficult and rigorous. It can be intrusive and
contentious. Consultants who can master the arts of facilitation, surveying, and
interviewing will have developed advisory skills that will place them ahead of their
competition. The successful completion of the due diligence process sets us up for
the next phase, the most creative activity in consulting, the design of IT solutions.