Inform IT - Management.

IT Management
Introduction
Last updated Jul 9, 2004.
This is the inaugural edition of a new Management Reference Guide. The purpose of this
guide is to serve as a source of current, meaningful information covering the entire
spectrum of IT management. Ive arranged the guide in a logical manner starting with
strategic management and following with other key management subjects dealing with
customers, processes, suppliers, and other topics. As much as possible, the guide includes
industry best practices with actual business examples.
The intended audiences for this guide are team leads, supervisors, managers, and
executives working in or closely associated with IT departments. One of the challenges in
presenting material designed for such a wide variety of audiences is gearing it to a degree
thats not too detailed for seasoned executives, and not too high-level for entry-level team
leads. With this goal in mind, I tried to align most topics with the level of expected
audiences. For example, strategic management by its nature discusses items at a higher
level, while infrastructure processes are handled at a more detailed level.
I encourage readers to submit comments and weblog entries. Ill respond to these
submissions as quickly as possible, usually within 48 hours. The true value of a reference
of this type often arises from spirited, interactive discussion among readers whose own
experiences can confirm or alter the positions taken here.
I hope you enjoy this guide and find it beneficial to whatever position you hold, and in
whatever type of IT environment you work. I expect to add or modify at least one new
topic every week. This week I introduce strategic management and its associated
activities: planning; the setting of goals and objectives; and the use of mission, vision,
and value statements.

2004 Pearson Education, Inc. InformIT. All rights reserved.
800 East 96th Street Indianapolis, Indiana 46240

IT Management
Strategic Management
This section describes the various aspects of IT strategic management. I realize that team
leads and supervisors in many corporations may not be directly involved in these
activities. On the other hand, Ive worked with several small companies or startups in
which the CIO, IT manager, supervisor, and team lead are all the same person. In these
organizations, the realm of management planning spans the spectrum from strategic,
long-range activities down to day-to-day tactical operations. So even if IT professionals
are not currently involved with strategic planning, they may very well be after the next
job change.
I begin this section with a discussion of a primary responsibility of strategic management:
establishing goals, objectives, and strategies. This part offers a definition for each of
these three terms, shows how to distinguish one from another, and illustrates them with
some common examples.
The second part of this section describes how IT goals can and should be aligned with
those of the business enterprise. While this theme is frequently heard in IT executive
planning circles, IT managers often bypass, overlook, or undermine this topic (either
intentionally or unintentionally) by focusing on technology issues rather than business
issues. This section describes how to avoid these pitfalls and gain partnerships with the
business units of the enterprise at the same time.
The third segment presents several techniques for conducting effective planning sessions,
including how to customize and enforce brainstorming rules; how to utilize a powerful
methodology to identify, prioritize, and analyze a departments strengths, weaknesses,
opportunities, and threats; helpful hints to improve the management of planning
meetings; and how to determine appropriate logistics and attendees to make planning
efforts successful.
The final three segments present the purpose and benefits of mission statements, vision
statements, and corporate values, and provide proven processes for developing these
strategic guideposts. I placed this segment last because not all companies embrace the
importance of such statements. In fact, Ive seen companies do more harm than good with
these statements by implementing them poorly and then contradicting their intents. But in
many cases Ive seen such tools used effectively, and they can make a difference. These
sections include numerous examples of these types of statements currently in use by well-
known American companies.
Ill provide additional sections in future updates to this guide on such topics as proven
techniques to instigate realistic budgeting practices, an overview of how to implement
and enforce necessary policies and procedures in support of strategic management, and a
discussion of how to stay current with the ever-changing landscape of legal and privacy
issues.


IT Management
Establishing Goals, Objectives, and Strategies
One of the primary responsibilities of IT management is the establishing of goals,
objectives and strategies. These words often have different meanings to different
individuals. For the purpose of clarity, lets begin with some descriptions and examples to
help distinguish these three terms.
An IT goal is usually a statement of a major activity that an IT organization wants
to accomplish over a long time period, normally two to three years. This may
entail a shift in how technology is used to meet business goals such as
investigating the feasibility and implementation of wireless devices for a
companys sales force. Or it could involve a changeover in technology. One
company recently had an IT goal to migrate its critical and extensive imaging
system off of optical storage and on to the more scalable platform of magnetic
disk arrays.
An IT goal may also indicate a direction in which an IT organization wants to go.
For example, a company may set a goal to meet its rapidly increasing application
development demand by utilizing offshore programming, as many companies are
beginning to do today. Other examples of IT goals include improving overall
customer satisfaction, reducing overall chargeback costs to users, and outsourcing
ancillary infrastructure functions.
An IT objective is usually short in duration, normally within a one-year
timeframe, and is much more quantifiable than a goal. For example, the
implementation of any number of application systems with specified completion
dates is a very common IT annual goal. Reducing costs in specific areas,
improving availability, and increasing the number of level-one problem
resolutions to an IT call center are other good examples of IT objectives.
Objectives should be measurable, reviewed periodically, and modified as needed.
Managers normally establish goals and objectives during planning sessions
conducted prior to the start of a new fiscal year. Because goals usually extend
over several years, managers often review, refine, and reinforce long-range goals
during these sessions. On the other hand, managers expect their staffs to complete
objectives within a single year and usually create new objectives during each
annual planning effort. Managers frequently link the successful completion of
objectives to performance appraisals and recognition programs. In some cases,
executives tie an individuals performance on objectives to salary compensation
and promotion opportunities. Team leads and supervisors can also adopt this
philosophy of management and performance by objectives.
Strategies are the methods and approaches to be used in accomplishing short-term
objectives and longer-term goals. For example, one of my clients needed to
improve recovery time from a major disaster from 12 hours down to 4 hours. This
was their objective. Their strategy was to replicate data cross-country, and to test
it every six months. The determination of these methods lends itself to the
identification of other necessary requirements to accomplish goals and objectives.
These requirements may include training, budgets, and allotments of time and
resources.
References
Good to Great: Why Some Companies Make the Leap...and Others Dont (HarperCollins,
2001), by James Collins.


IT Management
Aligning IT Goals with Corporate Business Goals
One of the characteristics that best demonstrates an IT departments value to a company
is the degree to which IT has aligned their goals with those of the corporation. There are
several reasons why its important for an IT organization to forge this alignment:
It encouragesif not outright forcesIT to better understand the directions,
priorities, and constraints of various business units as well as the corporation as a
whole. This kind of knowledge can enable IT managers to plan projects more in
line with corporate goals. If a business impact analysis has been conducted, this
information can also be used to assess the relative priorities and value of various
business functions.
Business units are more likely to buy into IT projects that are outside of their
areas (such as infrastructure upgrades) when they're assured that IT understands
the business environment in which they're operating.
Aligning IT and business goals can prevent some projects from being delayed,
replaced, or even canceled, because their dependencies and sponsorship are so
closely tied to corporate goals that are not as likely to change.
An obvious prerequisite to this alignment is a thorough working knowledge of corporate
business goals on the part of IT executive management. World-class IT organizations go
to great lengths to ensure this understanding and alignment, but many companies fall
short in this regard. Following are three of the most common causes of IT organizations
not aligning their own goals with those of the corporation:
Corporate or business unit executives are sometimes less than willing to share all
of their goals, or the details of some of their critical goals, with IT senior
management. This sometimes happens when the relationship between IT and
other departments has become strained, indifferent, or hostile. Regardless of
whether the blame is on one side or the other, the relationship needs to be repaired
if long-term alignment of goals is to be realized.
Strange as it may sound, IT executives are sometimes unwilling to share all of
their knowledge of corporate business goals with their IT senior management,
even if the executives have a thorough understanding of these goals. For some IT
executives, this knowledge represents power that they only selectively share with
subordinates to safeguard political positions. This can be a risky and dangerous
approach that middle managers can mitigate by insisting on more full disclosures
of business goals.
The most common cause of IT goals not remaining aligned with corporate
business goals is senior managers being more committed to their own priorities
than to those of the corporation. This is often an insidious process. Well-
intentioned managers may find themselves shifting priorities or becoming
enamored with a new technology, or simply have a pet project that becomes all-
consuming. Before they know it, corporate goals are pushed back to secondary
status, and any hopes of alignment are lost.
Although the obstacles to aligning IT goals to corporate business goals are real and
prevalent throughout industry today, they can be overcome. It remains the responsibility
of executive IT management to ensure that they fully understand the business goals of
their company, to communicate them to their staffs, and to facilitate them as part of their
own IT strategic planning.
References
Built To Last: Successful Habits of Visionary Companies (HarperBusiness, 1994), by
James Collins and Jerry I. Porras.


IT Management
Utilizing Effective Planning Techniques
A number of techniques exist to help transform marginal or mediocre strategy meetings
into successful, effective planning sessions. This section provides some proven methods
on the use of brainstorming rules; on helpful hints about meeting management; on
determining the best set of meeting logistics; on how to invite all, and only, appropriate
individuals to meetings; and on the analysis of strengths, weaknesses, opportunities, and
threats of an organization. These techniques can help to turn an average strategy meeting
into a very worthwhile planning session. Gatherings of this type can be expensive, time-
consuming, and wasteful. With a little bit of planning and foresight, these sessions can be
transformed into the efficient use of valuable staff time.
Brainstorming Rules
Almost any successful brainstorming session has a common set of rules to govern
behavior, logistics, and results. This certainly applies to a strategic planning session. The
following helpful ground rules are not necessarily unique or groundbreaking, but
ensuring total buy-in to all of them prior to the start of any discussions, and adhering to
strict enforcement throughout the gathering, can provide a smoother-flowing meeting
with more successful results:
Agree on the clear objective(s) of the brainstorming.
Stay focused on the objectives(s).
Treat everyone as equals.
Listen respectfully to each persons input.
Participate honestly and candidly.
Maintain confidentiality when appropriate.
Keep an open mind; suspend personal agendas.
Ask anythingthere are no dumb questions.
Question anything you don't understand.
Only one voice at a time; no side conversations.
Ensure that everything relevant is written down.
If prioritizing, agree on specific techniques.
If attempting consensus, agree on voting method.
Start and end on timesession, breaks, lunch.
Critique the brainstorming session for improvements.
Meeting Management
An effective meeting of any kind doesnt happen by accident. It seems only right that a
meeting whose objective is to discuss strategic planning issues should be thoroughly
planned for in the beginning. Following are twelve tips to more effective meetings:
1. State the objective of the meeting. Know what you hope to accomplish and the
type of meeting you plan to conductstatus, brainstorming, presentation, or
evaluation.
2. Identify appropriate participants. Based on the objective and the type of
meeting, determine all (and only) appropriate individuals. This topic is covered in
more detail in the next section.
3. Schedule well in advance. Depending on who the participants are, the number
who need to attend, and the availability of rooms, schedule the meeting well
enough in advance to accommodate everyone's needs.
4. Provide an agenda. Develop an agenda. In some instances a timetable of key
meeting events may be appropriate. Include the meeting objective. Distribute the
agenda to all attendees. If an online calendaring facility such as Outlook is
available, take advantage of its confirmation feature.
5. Assign a scribe. Arrange with an attendee to take notes. In the case of a
brainstorming session, you may want to assign more than one if multiple
flipcharts will be used.
6. Assign a timekeeper. Fast-paced, free-flowing meetings often run out of time
before all key issues have been addressed. An assigned timekeeper can help
prevent this problem by keeping the meeting on track.
7. Clarify issues and move on. Not all issues can be resolved in a single meeting.
Highly intelligent individuals usually have strong opinions and want to be heard.
A balance frequently needs to be struck between giving everyone a chance to
contribute and knowing when to move on to more important topics.
8. Agree on action items. Identify, assign, and schedule completion dates for all
action items.
9. Summarize results. Wrap up the meeting with a review of the results, especially
confirming the assignment and completion dates of action items.
10. Critique the meeting. Set aside a few minutes at the end of the meeting to
critique its value. Take note of what could be improved at future meetings.
11. Send out meeting minutes. The scribe or the person conducting the meeting
should distribute meeting minutes as soon as possible to everyone who was
invited, and anyone else deemed appropriate. Note who was invited and who
actually attended.
12. Follow up on action items. Depending on the number of action items and their
completion dates, follow up on them at an appropriate frequency.
Meeting Logistics
The logistics of a meeting can often spell the difference between a rousing success and a
dismal failure. One of the first steps to take is to thoroughly understand the purpose and
type of meeting to be conducted, the number and makeup of the attendees, and the
estimated duration of the session. From those details, you can determine the best day of
the week and hour of the day on which to schedule the meeting; the best location in terms
of room size; the best method of facilitation to use; and whether to hold the meeting in-
house or offsite. Another consideration is the importance of meeting setup, visual aids,
laptop hookups, lighting, acoustics, and so on. Finally, include provisions for meals,
drinks, and refreshments if appropriate.
TIP
A possible alternative way to go offsite at marginal cost may be to use a company facility
at another campus or in another area in close proximity.
Appropriate Meeting Participants
The type and purpose of a meeting normally dictate who the appropriate meeting
attendees should be. In the case of a strategic planning meeting, this group may include
representatives from senior or middle management, technical leads, and subject matter
experts. In some instances it may also include members from applicable business units or
from appropriate nonIT support groups such as human resources, finance, facilities,
contracts, or legal. Some strategy sessions may also include input from suppliers or
outside consultants. In these cases, an additional concern is to ensure that agreements of
confidentiality and disclosure are fully understood and adhered to.
Analyzing Strengths, Weaknesses, Opportunities, and Threats (SWOT)
SWOT analysis is a process to identify the relative strengths, weaknesses, opportunities,
and threats of a person, a small team, a large organization, or an initiative, normally in a
business environment. Many companies find the process useful as a preparation for
strategic planning. The results of a SWOT analysis can be used to help an organization
build on its strengths, minimize its weaknesses, exploit opportunities, and mitigate
threats.
A highly efficient SWOT session usually consists of four subprocesses:
"Round robin" method to identify items. Round robin is a fast-paced method to
quickly identify items during a brainstorming session. The proper use of this
process results in virtually no lost time in gathering meaningful information. The
two keys to its success are brevity and handoffs. Participants sitting around a table
must choose to briefly offer a response or to hand off to the next person. One or
more assigned scribes record all responses. Individuals typically have only 1015
seconds to offer a suggestion, so short, quick responses are a necessity. Handoffs
are very common, especially during the first few rounds. Rounds continue until
three full passes are made with no new responses.
Author/group consensus scheme to merge items. Some responses may turn out
to be similar to ones previously mentioned. The author/group consensus scheme
looks at those responses that may be merged and negotiates with the author of the
response and the group to gain consensus on it.
Nominal group technique to prioritize items. The nominal group technique
effectively prioritizes large lists of items in a short time by having each individual
apply a point value to just a few of their top choices. What may normally take
hours to accomplish with other methods can be done in 1015 minutes using this
method.
"Common threads" approach to categorize items. Once the items have been
identified, merged, and prioritized, they can be grouped into major categories
according to common threads that stand out from the prioritized lists. This process
also should only take a few minutes to accomplish.
References
IT Systems Management: Designing, Implementing, and Managing World-Class
Infrastructures (Prentice Hall PTR, 2002, ISBN 013087678X), by Rich Schiesser.


IT Management
Developing Worthwhile Mission Statements
Last updated Sep 2, 2004.
This section discusses what a mission statement is, describes some of the benefits and
drawbacks of mission statements, shows how to develop an effective mission statement
for almost any organization, and presents several examples of commonly known (or
perhaps not so widely known) mission statements.
Introduction to Mission Statements
A mission statement is a concise description of who an organization is and what it does.
When properly constructed, a mission statement can provide a clear, concise description
of an organizations overall purpose. This can enable large groups of individuals to work
in a unified direction toward a common cause.
There are a few other entities that are often associated with mission statements. The most
common of these are vision statements and corporate values, each of which is covered in
other sections of this guide. Other related items include charters, policy statements, and
slogans:
A charter describes what an organization is expected to accomplish, usually over
a specific timeframe, and usually specifies the amount of authority and
responsibility given to the participants. Team leads, supervisors, and project
managers often use charters to clearly define the overall purpose of teams,
activities, initiatives, and projects that they are heading.
Policy statements are rules of engagement or enforcement for issues involving
employee behavior and the use of corporate assets.
Slogans are usually short-lived marketing-oriented statements that apply to a
specific product or service. Slogans often are tied directly or indirectly to the
organizations mission statement.
Mission statements can apply to a wide diversity of organizations whose size, scope, and
geography can vary greatly. For example, a huge multinational corporation may have one
mission statement for the entire company, other mission statements for each of the
divisions, additional mission statements for each business unit within a division, and still
others for each department in the business unit. Despite the variety of mission statements
that may exist within one corporation, common attributes help to make any mission
statement worthwhile. In addition to ensuring that the various statements support each
otheror, at the very least, don't contradict each otheran effective mission statement
has these key characteristics:
Clear: No complex words; no awkward wording.
Concise: The fewer words the better; less than 25 if possible.
Catchy: Snappy sounding without using slang or colloquialisms.
Memorable: Easy to recall; easy to explain.
Steps To Developing Effective Mission Statements
The following procedure is a proven method for developing an effective mission
statement for almost any organization.
1. Select a representative group to brainstorm an initial draft.
2. Concur on brainstorming ground rules.
3. Agree on what your organization is and what it does.
4. Identify key phrases.
5. Draft an initial mission statement using most or all of the key phrases.
6. Wordsmith the initial draft to reduce words and redundancies.
7. Digest the initial draft for a day or two.
8. Finalize the initial draft.
9. Submit the finalized statement to an appropriate authority for final approval.
Following these nine steps can help any group to create a useful mission statement that is
easy to market, quick to implement, and simple to apply.
Sample Mission Statements
The following are ten current mission statements considered to be effective in terms of
their form and content. Note their common characteristics of briefly describing who they
are and what they do. These are all taken from a variety of well-known American
companies. How many of these organizations do you recognize, or could identify based
solely on their mission statements? The answers will be given next month.
A month has now gone by, so now it's time to reveal the companies who are the owners
of the following mission statements. How many of these did you answer correctly? Just
in case you want to try one final time to determine the identity of these companies, I will
list the answers at the very bottom of this section. So don't scroll ahead. For each answer
listed, I will offer a brief comment about characteristics of the mission statement and its
relationship to the organization it describes.
a. Ladies and gentlemen serving ladies and gentlemen.
b. Our business is renting cars. Our mission is total customer satisfaction.
c. The primary mission is to expand our world-wide leadership position in the spice,
seasoning, and flavoring markets.
d. To be Americas best quick service restaurant chain. We will provide each guest
great tasting, healthful, reasonably priced fish, seafood, and chicken in a fast,
friendly manner on every visit.
e. To provide any customer a means of moving people and things up, down and
sideways over short distances with higher reliability than any other similar
enterprise in the world.
f. To offer all of the fine customers in our territories all of their household needs in a
manner in which they continue to think of us fondly.
g. Provide shareholders a secure investment with a superior return.
h. We will be our customerschoice for high-value, high-quality data, voice and
video communications.
i. To offer the fast food customer food prepared in the same high-quality manner
world-wide, tasty and reasonably priced, delivered in a consistent, low-key dcor
and friendly atmosphere.
j. To offer the best possible personal computing technology, and to put that
technology in the hands of as many people as possible.
The companies to whom the above mission statements apply are:
a. Ritz-Carlton Hotels - This is one of the briefest yet most effective mission
statements ever developed. With a mere seven words, it describes who they are
and how they expect their employees to behave; what they do; and the identity
and treatment of their customers.
b. Avis Rent-a Car - This statement distinguishes the company's business which is
rental car focused, from the company's mission of total satisfaction which is
customer focused.
c. McCormick and Company - This statement implies that the company has several
missions of which expanding its world-wide leadership is primary.
d. Long John Silver - This says it simply wants to be the best. It stresses the
healthful nature of fish and chicken.
e. Otis Elevator - This is a rare business-to-business mission statement. Their
primary delineator is high reliability.
f. Wal-Mart - In keeping with its well-guarded image, Wal-Mart's mission statement
is very down-home and wholesome sounding with phrases such as 'fine
customers' and wanting to be thought of "fondly'.
g. Exxon - This is short and direct: provide secure, profitability investments.
Interesting in that nothing is mentioned about the quality of their petroleum
products.
h. Bell South - This emphasizes the value and quality of their products and lists the
core products.
i. McDonald's - This statement stresses the consistency of their food preparation and
of their surroundings. Similar to Long John Silver's, it also emphasizes low price,
speed and friendliness.
j. Apple Computer - Two simple ideas here: provide the best technology to the
maximum number of people. In light of the many discounts and donations that
Apple made early on, its interesting that it does not emphasize maximizing sales
and profits, but maximizing the number of recipients.
The above list provides describes mission statements from a variety of companies
covering a diverse cross section of industries. Below are 13 additional statements from
wide assortment of organizations.
1. To provide quality financial products and services that create value by achieving
superior customer satisfaction and sustainable financial returns in a challenging
and rewarding environment for our associates. (Option One Mortgage
Corporation.
2. United Community Center is a human service agency providing emergency
assistance, daycare, social services and recreational activities for low-income
children and families at risk in inner city Atlanta, Georgia. (United Community
Center)
3. To achieve quality land management under the sustainable multi-use management
concept to meet the diverse needs of people. (United States Forest Service)
4. The YMCA of San Francisco, based on Judeo-Christian heritage, seeks to
enhance the lives of all people through programs designed to develop spirit, mind
and body. (San Francisco YMCA)
5. Minimize the exposure to risk and maximize the capability to respond to events
that threaten or harm personnel, property, data or business continuity.
6. (California Independent Systems Operator (ISO))
7. To market vehicles developed and manufactured in the U.S. that are world leaders
in quality, cost and customer satisfaction through the integration of people,
technology and business systems and to transfer knowledge, technology and
experience throughout GM.
8. (Saturn Division of GM)
9. Our mission is to work for the success of people we serve by providing our
customers reliable electric service, energy information, and energy options that
best satisfy their needs.
10. (Public Service Company of New Mexico)
11. The mission is to improve the equality of human life; to enhance self-reliance and
concern for others; and to help people avoid, prepare for, and cope with
emergencies.
12. (American Red Cross)
13. To develop a reliable wireless network that empowers people with the freedom to
travel anywhere--across the hall or across the continent--and communicate
effortlessly.
14. (McCaw Cellular Communications)
15. To provide all banks, S&Ls and investment firms with error-free financial
instruments delivered in a timely fashion. Error-free means absolutely no errors;
timely means a 48-hour turnaround. (Deluxe Checks)
16. To provide economy and quality-minded travelers with a premiere, moderate-
priced lodging facility which is consistently perceived as clean, comfortable, well
maintained, and attractive, staffed by friendly, attentive and efficient people.
(Courtyard by Marriott)
17. To appeal to a younger-thinking, style-conscious, moderate and better priced
customer by providing trend merchandising and superior service. Trend means
private labels, fast reaction, measured risks; service means warm, friendly, helpful
people in a convenient, efficient environment. (Dayton Hudson)
18. To satisfy our customers by providing quality cars & trucks, developing new
products, reducing time it takes to bring new vehicles to market, improving
efficiency of all our plants & processes, & building on our teamwork with
employees, unions, dealers, & suppliers.
19. (Ford Motor Company)
References
"What Should Our Mission Statement Say?" by Ron Meshanko. Internet Nonprofit
Center, 1996.


IT Management
Developing Worthwhile Vision Statements
Many companies use a vision statement as a companion proclamation to their mission
statements. This section begins with an introductory discussion of what a vision
statement is, how it differs from a mission statement, some of the benefits a vision
statement can provide, and some common characteristics of a worthwhile vision
statement. I follow this up with an explanation of the steps that managers can use to
develop an effective vision statement. The final portion shows several examples of vision
statements used by a variety of organizations.
(This section should be inserted in Strategic Management. It is an extension of the
original section on Vision Statements. The first two parts (1.5.1 and 1.5.2 are the same as
before. The part in 1.5.3 has been extended.)
Introduction To Vision Statements
A vision statement usually addresses one or more of the following three questions: where
an organization wants to go; what an organization wants to become; or what an
organization wants to accomplish. It differs from a mission statement in that a mission
statement focuses on what an organization does, what business it is in, and what product
or service it offers. A mission statement emphasizes the here and now, whereas a vision
statement points to the future. The primary benefit of a vision statement is that it can
focus an entire organization on a common goal, a worthwhile achievement, and the
means of measuring when the objective has been reached.
The following list explains some common characteristics of a worthwhile vision
statement. You may note that they are similar, but not identical, to those of an effective
mission statement.
a. clear (no complex words; no awkward wording)
b. concise (the fewer words the better; less than 15 if possible)
c. catchy (snappy sounding without using slang or colloquialisms)
d. memorable (easy to recall; easy to explain)
Steps To Developing An Effective Vision Statement
The following steps are a proven method for developing an effective vision statement.
a. select a representative group to brainstorm an initial draft
b. concur on brainstorming ground rules
c. agree upon Where We Want To Go, What We Want To Accomplish, and How
We Plan to Measure Its Completion
d. identify key phrases
e. draft an initial vision statement using most all of the key phrases
f. word-smith the initial draft to reduce words and redundancies
g. digest initial draft for a day or two
h. finalize the initial draft
i. submit to appropriate authority for final approval
Sample Vision Statements
The following are actual vision statements used currently or in the past. They are
excellent examples of effective statements that clearly present where an organization
wants to go, what it wants to accomplish, and how it will measure its results. These are
all taken from a variety of well-known American institutions and individuals. How many
of these do you recognize, or could identify based solely on their vision statements? The
answers will be given next month.
Over a month has now gone by, so now its time to reveal the companies who are the
owners of the following vision statements. How many of these did you identify correctly?
Just in case you want to try one final time to determine the identity of these companies, I
will list the answers at the very bottom of this section. So dont scroll ahead. For each
answer listed, I will offer a brief comment about characteristics of the vision statement
and its relationship to the organization it describes.
1. To be widely recognized as the premiere provider of innovative financial products
and services.
2. Within the next 3 years grow our company into a $40 million home products
company specializing in manufacturing and distributing custom and replacement
garden windows and skylights for the upscale home and baby-boomer markets.
3. Land a man on the moon and safely return him to earth by the end of this decade.
4. I have a dream that all men will be judged by the merit of their character, not by
the color of their skin.
5. To become the premiere supplier of reliable, high-quality, complex military
defense systems and commercial aerospace products.
6. To be the worlds best in chemicals and electronic imaging.
7. To build the premiere financial services company in the U.S.
8. To be the lowest cost producer of aluminum & to outperform the average return
on equity of the Standard & Poors industrial stock index.
9. To become the most competitive enterprise in the world by being number one or
number two in market share in every business the company is in.
10. To become a low-cost, medium-size gold producer, producing in excess of
125,000 ounces of gold a year and building gold reserves of 1,500,000.
11. To achieve return on equity at 20% or above, "real" earnings growth averaging
5% or better over time, be a leading marketer of strong consumer brands, and
improve the profitability of low-return businesses or divest them.
The organizations or individuals who used the above entries as their vision statements
are:
1. Option One Mortgage - The three adjectives of widely, premiere, and
innovative define this companys desired scope of recognition, its expected
quality level as a provider, and how it hopes to delineate its products and services
from its competitors.
2. Colorado Garden Windows Company - This is a good example of using very
specific quantities in a vision statement. In this case it gives a precise timeframe,
an exact sales level, and specific products and markets.
3. President John F. Kennedy - This is the famous challenge President Kennedy
issues to NASA in 1961. Note the simple, specific task and timeframe.
4. Rev. Dr. Martin Luther King - This is an exerpt of the famous I Have a Dream
speech that Dr King gave at the conclusion of his Civil Rights march on
Washington, D.C. While no timeframe is given, it is nonetheless very visionary in
nature.
5. Northrop Grumman - The first part of this statement voices a common theme of
wanting to become the premiere supplier of their products, but they distinguish
themselves with their descriptors of reliable, high-quality, and complex.
6. Eastman Kodak - Simple yet powerful vision to be the best. Compare to be the
worlds bestto just being recognized as being the worlds best.
7. Nations Bank - This companys statement is not to be the premiere company, or
even to be recognized as the premiere company, but to build the premiere
company implying it is very much in a growth phase. This is an example of a
company that will likely modify its vision statement in a few years after
successful building has been accomplished.
8. Alcan - This statement has very specific financial visions, almost bordering on
goals and objectives. Reducing average product costs, and improving on the
average return on equity are easily measurable and understandable.
9. General Electric - This statement was the famous challenge that CEO Jack Welch
issued to his division heads in the mid 1980s. Several divisions were shutdown as
a result including the controversial RCA television division.
10. Atlas - This statement combines generic attributes as in low cost, medium-size
with specific goals for quantities of production and reserves.
11. Quaker Oats Company - This statement also combines specific financial goals for
return on equity and average earnings growth, with the more generic
characteristics of market leadership and improved profitability.
References
http://www.onepagebusinessplan.com, Writing a Great Vision Statement, 2003


IT Management
Instituting Practical Corporate Values
This section discusses the concept of corporate values, covering the following topics:
What corporate values are and how they can benefit an organization
Steps that managers can use to identify and elaborate on a set of values that best
suits their particular environment
Some factors that can undermine corporate values
Examples of corporate values in use today by a variety of companies
Introduction to Corporate Values
Corporate values are the core beliefs and principles that govern the behavior and
characterize the essence of an organization. These value statements are intended to
provide a foundation for guiding the actions of people across the organization. Two
characteristics that form the cornerstones of effective corporate values are content and
context.
Content refers to the meaningfulness of corporate values. Values having strong
content are specific, authentic, tangible, and easily applicable to the everyday
corporate life of all employees. Values with poor content are generic and
disconnected from any meaningful guidelines to behavior.
Context refers to the degree to which values can be woven into the everyday
thoughts and behaviors of employees. Values with strong context are realistic and
totally compatible with the operating principles of an organization. Values with
poor context are too idealistic to be practical, too incompatible with the core
beliefs of the organization.
Factors That Undermine Corporate Values
The two factors that most undermine the effective application of corporate values are lack
of credibility and poor communication. Executives who espouse values that they
themselves fail to exhibit can do more damage to employee morale and to their own
credibility than if they had proposed no values at all. Similarly, values that are poorly
communicated to staffs result in misunderstandings about what the values really mean
and the likelihood that some employees learn nothing about the values.
Sample Corporate Values
Following are nine sets of current corporate values from companies with a wide variety
of size, scope, and industry. The diversity of these companies also reflect the diversity of
corporate values in terms of style, format, and length. Each set is similar to all others in
that each conveys those attributes of corporate culture that all of these organizations
cherish and strive to achieve.
1. Do what is ethical, fair, and makes good business sense. Do our best. Treat others
as we want to be treated. Stimulate, anticipate, and embrace change. (Option One
Mortgage)
2. Deliver superior customer satisfaction. Exhibit integrity in all business dealings.
Design high quality into all products. Provide effective leadership consistently.
Value all Northrop Grumman People. Partner with suppliers. (Northrop
Grumman)
3. We are committed to the delivery of innovative, proven solutions that enable our
customers to achieve their potential and do business in new and exciting ways.
(Microsoft)
4. Our customers: We are driven by our customersneeds. We understand the needs
of our customers and deliver innovative products and services to meet those
needs. Our people: We respect each other. We work together as one BellSouth
team. This team reflects the diversity of the communities we serve. Our
communities: Everywhere we do business we strive to make our communities a
better place to live, work, and grow. Excellence: We strive for excellence in
everything that we do, including excellent customer service for our customers, a
great place to work for our employees, and outstanding performance for our
shareholders. Integrity: Every action we take reflects the highest ethical standards.
We interact with our customers, our employees, and our shareholders with
honesty and integrity. (BellSouth)
5. Cooperation. Integrity. Lifelong learning. Continuous improvement. Respect.
Flexibility. Personal accountability. Creating appreciative customers. (Bentley
Networks)
6. Customers. Innovation. People. Commitment. (JCA Software)
7. Honesty. Integrity. Excellence. Trust. (Unocal-76)
8. Service: To deliver outstanding and continuing service to our customers.
Commitment: To achieve strong, sustainable results. Continuous improvement: To
continuously improve our performance, our products, and our services. Long-term
outlook: To evaluate each endeavor and its impact on our long-term outlook.
Teamwork: To communicate openly and work as a unified team to attain common
goals. (Del Monte Foods)
References
"Corporate Values, Revisited," Dewar Sloan, 2002.
"Make Your Values Mean Something," by Patrick Lencioni. Harvard Business Review,
July, 2002.
"Developing Value Statements: Lessons From War," by Scott Valentine.
http://www.refresher.com, 2001.


IT Management
Budgeting Considerations in an IT Environment
This section of the IT Management Reference Guide was written by Edward Galang.
Budgets play a critical role in any type of organization. This is especially true in an IT
environment as companies grow more dependent on IT for higher productivity, greater
competitive advantage and increased profits. This section provides a brief, high-level
insight to the budgeting process from my perspective and experiences as an IT executive.
Many IT leaders feel that budgeting is a long and painful process with very little return
on investment for the level of effort made. This feeling often stems from the immaturity
of the organizations budgeting process and the lack of its understanding by IT leaders. It
is imperative that IT managers recognize and treat IT budgeting as a process, and realize
that enhancements to the IT budget process can produce significant rewards.
Factors that Undermine the Budgeting Process
I have worked for many different IT organizations over the years and have observed the
following four factors that consistently undermine the budgeting process:
1. Insufficient time - Most organizations provide insufficient time to plan and
prepare a budget adequately. One company I worked at began their annual
budgeting process three months into the fiscal year and expected the budget to be
completed within two weeks.
2. Ad-hoc perception In this case the process is perceived as a one-time 'fire-
drill' exercise. A former client of mine had the idea that once the budget was
complete, tracking of variances and forecasting trends were not required since the
budget already was approved. The thinking was that this exercise was not
necessary until next year and further enhancements to the process would be a
waste of time and resources.
3. Undefined expectations This arise when expectations from senior
management are not defined. Specific criteria, timeframes, and approval cycles
should be clear and understood. I worked at one firm that developed its budget in
a total vacuum. With no direction from the business units as far as strategic
initiatives for the upcoming year, expectations were not clearly defined which in
turn affected both capital and operating expenditures.
4. Lengthy expenditure process - Once the budget is approved, you may still be
subjected to a long and frustrating process to execute on the approved
expenditures. This happened to me at a company that did not utilize the formal
budget process effectively. After enduring a long and arduous budget process, a
requestor had to endure another lengthy approval process for each purchase order
generated.
Enhancing the Budgeting Process
As an IT organization matures with its processes and standards, the budgeting process
becomes more continual. The following are some of the enhancements one can make to
the budgeting process as an organization matures.
Consistently allow for sufficient time to plan. For example, start your budgetary
process in the same timeframe each year enterprise-wide such as the third quarter
of your fiscal year.
Establish a standard template and format of the information being requested. For
instance, ensure senior management clearly defines the data to collect and the
factors to consider.
Gather historical information that pertains to the budget and create a baseline
from which to build.
As IT continues to evolve, organizations are realizing that previous budgeting decisions
are no longer valid and applicable. The passing of new governance laws and regulations
are forcing organizations to implement a more comprehensive financial management
methodology framework. In light of recent developments, here are a few suggestions to
enhance the IT budgeting process:
1. Use the investment portfolio approach. The investment portfolio
approach treats IT as a revenue generating entity. The objective is to ensure that
IT arrives at optimum decisions and realizes the desired results within the
expected timeframes and budgets. The payoff is a strategic and long-term outlook
that treats IT as an investment asset instead of an expensive liability; managers
compare costs against longer term requirements, needs and benefits.
2. Develop a consolidated projects list. - The IT budgetary process begins
with the organization identifying projects needed to grow their specific business
lines. The next steps are to prioritize the projects for IT to perform an assessment,
gather requirements, design both physically and conceptually, perform QA
testing, and implement into production. The objective is to provide the IT leaders
the complete picture of all proposed projects, the cost associated with these
projects, and their prioritization. This provides a level of objectivity in the
decision-making process that is lacking in many organizations. The payoff is that
it enables IT leaders to have all the information needed to demonstrate that the
business units, and not IT, are driving the costs.
3. Identify key costs and resource data. - Managing the IT budget provides
key costs and resource data. The objective is to have the ability to view both
project related and recurring costs that are essential to formulate budgetary
justifications. Managers can monitor these costs against the plan to identify
deviations that can be addressed or corrected instantaneously. The payoff, like the
previous suggestion above, provides IT leaders and management with a clear
picture of initiatives and their total cost of ownership. This enables a more
extensive analysis to be performed during planning and implementation. IT
leaders gain insights in lieu of subjective or unreliable information.
IT leaders do not have to be subject matter experts when it comes to the budgeting
process, but they must understand the basics. Upon acquiring this understanding of
fundamental budgeting concepts, IT leaders then have some of the necessary tools needed
to improve IT planning and management.


IT Management
Customer Management
This section describes the various aspects of IT customer management. It begins with a
discussion of internal and external customers. The first two segments describe how to
identify these individuals, and, more importantly, how and why to distinguish and limit
them to only a handful of key customers.
In future updates to this guide, Ill provide additional sections on customer management.
Topics include how to meet the needs of Internet and intranet customers, negotiating with
customers, managing customer expectations, and building and utilizing a
customer/supplier matrix.


IT Management
Identifying Key External Customers
One of the best ways to ensure excellent customer service is to consistently meet or
exceed the expectations of your key customers. While this may sound like an obvious and
almost trite statement, it incorporates some valuable aspects of customer service that IT
professionals often overlook or choose to ignore. The statement touches on three separate
but highly critical activities:
Knowing who your key customers are is an identification activity.
Agreeing on expectations of your customers is a negotiation activity.
Consistently meeting or exceeding expectations is a measurement activity.
Each of these activities requires different skills and disciplines. The identification activity
is the topic of this section. The upcoming section on service levels covers the subject of
negotiation. That section, in concert with the section on process metrics, describes
measurement activities.
In transitioning to a service-oriented environment, infrastructure professionals sometimes
struggle with identifying who their key customers are. These IT professionals frequently
rationalize that since most company employees in one way or another use IT services,
then all company employees must be their key customers. There is an inherent problem
of practicality with this approach. The best method to know and understand who your
customers are and what they expect is to personally meet and interview them. But it
simply is not practical or even possible to meet with hundreds of individuals on a regular
basis.
But one technique can give you almost the same results as interviewing large numbers of
customers: identifying key, representative customers of your services. These key
customers can then provide you with meaningful information about the quality of
services you provide; the services they truly need; their expectations of your services; and
to what degree you are meeting, exceeding, or missing their expectations.
Usually just a small number of key representative customers can serve as a barometer for
good customer service and effective process improvements. For example, an operations
group responsible for restoring files that users may have accidentally deleted doesnt need
to interview every user to gauge the quality of their needs. Knowing how to identify a
small, representative group of users can save time and effort in measuring the true value
of what an IT department provides.
I developed this key customer identification process while heading up the main IT
infrastructure department at Northrop Grumman. The process evolved into what we
called a customer/supplier matrix (CSM). It was so effective and successful that it
eventually became a corporate standard for the entire company.
TIP
In defense contracting, this is no small accomplishment. Standards at defense contractors
are firmly set by defense department auditors, military specialists, and corporate
compliance people.
Customer/Supplier Matrix
Key Customers Key Services Key Processes Key Suppliers
Customers whose
use of IT services
is critical to their
success and whose
expectations are
reasonable
Described in the
section "Service
Management"
Described in the
section "Process
Management"
Described in the
section "Supplier
Management"

One of the reasons that the CSM is so successful is its simplicity. It basically directs you
to learn all of the following:
Who your customers are (key customers)
What services they need (key services)
What processes provide these services (key processes)
What suppliers feed into these processes (key suppliers)
Key customers are customers whose use of IT services is critical to their success and
whose expectations are reasonable. Key services and processes pertain to both external
and internal customers, just as the key suppliers pertain to both external and internal
suppliers. (Ill focus on key customers here, and discuss key services, processes, and
suppliers in later sections.)
The next part of this section describes criteria that can be used to identify key external
customers. In this case, external customers are defined as users of IT services that reside
outside the IT department. These individuals may be within or outside of the company,
but in either event they arent a direct part of IT.
Criteria for Identifying Key External Customers
There are various criteria to help in determining which of your numerous customers
qualify as key external customers. While these criteria are applicable to most IT
environments, an IT department should determine those criteria that are most suitable for
identifying the key customers in their particular environment. The following criteria are
useful in most IT environments for identifying the key external customers of an IT
organization.
Someone whose success critically depends on the services you provide.
Infrastructure groups typically serve a variety of departments in a company. Some
departments are more essential to the core business of the company than others,
just as some applications are considered mission-critical and others arent. The
heads or designated leads of these departments are usually good candidates for
key customer status.
Someone who, when satisfied, assures your success as an organization. Some
individuals hold positions of influence in a company and can help market the
credibility of an infrastructure organization. These customers may be in
significant staff positions such as those found in legal or public affairs
departments. The high visibility of these positions may afford them the
opportunity to highlight IT infrastructure achievements to other nonIT
departments. These achievements could include high availability of online
systems or reliable restorations of inadvertently deleted data.
Someone who fairly and thoroughly represents large customer organizations.
The very nature of some of the services provided by IT infrastructures results in
these services being used by a large majority of a company's workforce. These
highly used services include email, Internet, and intranet services. An analysis of
the volume of use of these services by departments can determine which groups
are using which services the most. The heads or designated leads of these
departments would likely be good key customer candidates.
Someone whoor whose organizationfrequently uses your services. Some
departments are major users of IT services by nature of their relationship within a
company. In an airline, it may be the department in charge of the reservation
system. For a company supplying overnight package deliveries, the key
department may be the one overseeing the package tracking system. During the
time I headed the primary IT infrastructure groups at a leading defense contractor
and later at a motion picture studio, I witnessed firsthand the key IT user
departmentsdesign engineering (defense contractor) and theatrical distribution
(motion picture company). Representatives from each of these groups were solid
key customer candidates.
Someone who constructively and objectively critiques the quality of your
services. It's possible that a key customer is part of a department that doesn't have
a critical need for or high-volume use of IT services. A non-critical and low-
volume user may qualify as a key customer because of a keen insight into how an
infrastructure could effectively improve its services. These individuals typically
have both the ability and the willingness to offer candid, constructive criticism
about how best to improve IT services.
Someone who has significant business impact on your company as a
corporation. Marketing or sales department representatives in a manufacturing
firm may include key customers of this type. In aerospace or defense contracting
companies, it may be advanced technology groups. The common thread among
these key customers is that their use of IT services can greatly advance the
business position of the corporation. For many other companies, particularly those
involved with e-commerce, these customers are the actual buyers of the products
or services marketed by the company.
Someone with whom you have mutually agreed-upon reasonable
expectations. Most infrastructure users, both internal and external to either IT or
its company, may qualify as key customers if the customer and the IT
infrastructure representative have mutually agreed-upon reasonable expectations.
Conversely, customers whose expectations are not reasonable should usually be
excluded as key customers. The old adage about the squeaky wheel getting the
grease does not always apply in this caseoften just the reverse turns out to be
the case. In many cases, managers understandably dismiss customers with the
loud voices who insist on unreasonable expectations. These managers
appropriately favor listening to the constructive voices of more realistic users.
These seven criteria apply to any IT environment, regardless of size, scope, platforms,
locations, or maturity levels. The primary issue in applying any of these criteria is to
couple the identification of these key external customers with the services they use.
References


IT Management
Identifying Key Internal Customers
You can use many of the criteria from the description of key external customers to
identify key internal customers. The obvious difference is that key internal customers
reside within an IT department instead of being external to it. Many individuals working
in an IT organization dont realize that they have key customers within their own IT
department. For example, you may design a change management process that dozens or
even hundreds of programmers use to control software modifications. But you would
probably need to involve only a handful of key programmer representatives to assist in
designing the process and measuring its effectiveness.
Criteria for Identifying Key Internal Customers
As mentioned previously, an IT department should identify those criteria that are the
most suitable for identifying the key customers in their particular environment. The
following criteria are useful for identifying the key internal customers of an IT
organization. Internal customers may reside within any department of an IT organization.
Someone whose success critically depends on the services you provide.
Infrastructure groups typically serve both their department and those of
applications development within an IT organization. At any point, some
application groups may be working on more critical projects than those of other
groups. The heads or designated leads of these areas are usually good candidates
for key internal customers, rather than meeting with an entire systems
development organization.
Someone who, when satisfied, helps assure the success of an organization.
Some individuals hold positions of major influence in an IT department and can
help market the credibility of an infrastructure or development organization.
These internal customers may be in significant staff positions such as chief
technology officer or systems manager. Satisfying these individuals usually
indicates that robust, well-executed processes and planning are in place. The high
visibility of these positions may afford them the opportunity to highlight IT
development and infrastructure achievements to other areas within the IT
department. These achievements could include high availability of online
systems, successful implementation of upgrades, or reliable restorations of critical
databases.
Someone who fairly and thoroughly represents large customer organizations.
The very nature of some of the services provided by IT infrastructures results in
these services being used by a large majority of a companys workforce. These
highly used services include email, Internet, and intranet services. An analysis of
the volume of use of these services by departments can determine which groups
are using which services the most. The heads or designated leads of these
departments would likely be good key customer candidates.
Someone whoor whose organizationfrequently uses IT services. Some IT
departments are major users of their own services by the nature of their position
within IT. A web design team, for example, depends on the reliability of their
companys intranets and extranets, and all of their associated components, ito be
successful in their work. Similarly, a customer service desk within IT depends on
reliable voice and data networks to perform their jobs diligently.
Someone who constructively and objectively critiques the quality of IT
services. Its possible that a key customer may be a part of IT that doesnt have a
relatively critical need for or high-volume use of IT services. A non-critical and
low-volume user may qualify as a key customer because of a keen insight into
how different parts an IT organization could effectively improve its services.
Groups that would fall into this category include planning, finance, business
continuity, and administration. Individuals in these areas typically have both the
ability and the willingness to offer candid, constructive criticism about how best
to improve IT services.
Someone who has significant business impact on IT as an organization. The
managers of the major departments within an IT organization can serve well as
key internal customers due to their unique positions to view and influence IT as a
business. Their input can be invaluable in improving the overall management of
and the quality of services from IT. This group would include the heads of
applications development, applications maintenance, web development,
infrastructure, risk management, and administration. The common thread among
these key internal customers is that their use of IT services and their position
within the organization can greatly advance the business position of IT.
Someone with whom you have mutually agreed-upon reasonable
expectations. As mentioned previously, most infrastructure users may qualify as
key customers if the IT customer and the IT supplier both have mutually agreed-
upon reasonable expectations. Conversely, customers whose expectations are
unreasonable should usually be excluded as key customers even if they reside
within the IT organization.
These seven criteria apply to any IT environment, regardless of size, scope, platforms,
locations, or maturity levels. The primary issue in applying any of these criteria is to
couple the identification of these key internal customers with the services they use.
References

IT Management
Negotiating with Customers and SuppliersPart 1: An
Introduction
This is the first of two sections on the topic of negotiating. Both sections present helpful
tips on negotiating agreements with customers. These agreements could include service
levels, project schedules, system requirements, software budgets, or a variety of other
business propositions. The ability to negotiate effectively is a valuable skill to acquire
and use by most any IT manager. It is particularly important for IT managers to master
this trait for dealing with customers whose expectations may be unreasonable and whose
demands may be unrealistic.
This section describes two important aspects of negotiation: common barriers and
building rapport. I begin with a brief explanation of common barriers to reaching
agreement on any negotiable issue, and continue by describing a few methods for
building rapport between two negotiating parties. The discussions of both aspects include
practical applications to an IT environment.
Some of the material in this section is from the Harvard Negotiation Project sponsored by
the Harvard Business School. Harvard initiated the project as a result of the high number
of expensive lawsuits that were being litigated across the country. Project participants
found that enabling litigating parties to settle out of court through effective negotiation
was far more beneficial, and economical, then conducting expensive, time-consuming,
and often frivolous lawsuits. The concept of the project was that the more that people
understood and practiced sound negotiating skills, the better off society would be in
general.
Barriers to Reaching Agreement
Past experiences, personal preferences, emotions, prejudices, assumptions and cultural
upbringing all have the potential of creating barriers to reaching an agreement between
two opposing parties. These barriers fall into the two broad categories of physical and
cognitive. Physical barriers include impediments such as poor eyesight or difficulty in
hearing. An individual can usually mitigate these types of physical barriers through
various corrective means such eyeglasses or hearing aids. Cognitive barriers stem from
how individuals think about themselves and events around them, and represent by far the
majority of barriers to negotiated settlements. A recent study by Harvard University
determined that 94% of all negotiation breakdowns occur because of cognitive barriers.
The cornerstone of cognitive barriers is a persons belief system, comprised of those
beliefs an individual values the most. Beliefs, by definition, are based more on faith than
knowledge and therein lay the potential conflict. Two people attempting to negotiate an
agreement may have vastly different belief systems. One may have very strong beliefs
based primarily on faith. The other may have few faith-based beliefs and rely mostly on
factual knowledge. The instance of a faith-based person negotiating with a knowledge-
based person is a common source of conflict, and of failed negotiations. Another source
of conflict can arise when a faith-based person has knowledge of a fact that a knowledge-
based person can only have faith about. As an old adage states, the expectant wife has
knowledge that she is the childs mother but the husband can only have faith that he is the
father. Recognizing and understanding your own personal preferences and biases, and
those of the person with whom you are negotiating, can help the conversation approach a
more common level of communication.
For example, a detailed-oriented analytical type of person from an Information
Technology (IT) department may need to negotiate a service level with an end-user who
is very big-picture oriented and not at all interested in details. If the negotiation is not
going well, the IT person could try to steer the conversation to more high level issues
before arriving at the details of the service level. The degree to which cognitive barriers
undermine a negotiation will vary from case to case, but the more you learn about your
own barriers, and particularly those of the party with whom youre negotiating, the
greater the likelihood of a successful agreement.
Building Rapport
Building rapport with the person with whom you are negotiating is an important pre-
requisite to arriving at a mutual agreement. I define rapport as a mutual sense of
connection, trust, and empathy between two individuals. Rapport is important in
negations because two people in rapport with each other tend to move together in the
same direction, at the same pace, toward a common goal. We all establish rapport,
consciously and sub-consciously, with visual, auditory, tactile, and behavioral cues. With
only one chance to make a first impression, the physical cues we exhibit are extremely
important. We cannot not communicate when interacting with someone for the first time.
The appropriateness of our clothing, the sound of our voice, the feel of our handshake,
and our posture and facial expressions all combine to make a successful or unsuccessful
first impression. This initial encounter either supports or undermines our ability to build
rapport.
Another aspect of building rapport with someone is to recognize which of the four
primary personality types best describe you and that person. These types are:
1. driver/adventurer characterized by a strong, hard-driving, results-oriented
personality; interested in the big picture rather than small details; moderate need
for social interaction; an example may be a manager on a manufacturing line with
whom you are negotiating service levels.
2. expressive/builder characterized by a very animated, outgoing personality; an
example may be a marketing person who is negotiating time, effort and costs with
you to spice up the company website.
3. amiable/catalysts characterized by a very empathetic, nurturing, patient
personality; an example may be a human resources person negotiating IT
requirements with you for an employee benefits program.
4. analytical/explorer characterized by a quiet, serious personality; technically
oriented; an example may be a programmer with whom you are negotiating
backup and testing procedures.
A number of simple surveys and tests can help determine an individual's primary
personality type. Two of the most common of these are the Jung-Myers-Briggs modal
profile test, and the Keirsey temperment study. While most people's personalities are a
combination of these four categories, there is usually one dominant type that influences
the behavior and demeanor of an individual.
Understanding your own dominant personality trait can allow you to adjust it to be more
effective in negotiations, and to help recognize the dominant personality trait of the
person with whom you are negotiating. For example, if you are highly analytical and are
negotiating with a driver-type individual, it would be more effective for you to steer clear
of details and anecdotes and get right to the bottom line. This does not mean that you
should dispense with establishing some initial rapport, it just means to be quick, direct
and mindful of the driver's normal sense of urgency.
Combining both of these techniques of establishing rapport and factoring in personality
types can make your IT negotiations more productive and successful. In part two of this
series on negotiating, I will discuss three useful methods for reaching agreements:
positional bargaining, determining alternatives, and identifying zones of agreement
References
Fisher, R., Getting To Yes: Negotiating Agreement Without Giving In, 2
nd
Edition,
Houghton Mifflin Company, 1992 (Based on the Harvard Negotiation Project)
Ertel, D and Fisher, R., Getting To Negotiate: The Getting to Yes Workbook, Houghton
Mifflin Company, 1995
Gallway, T., The Inner Game of Work, Random House, 1999
http://keirsey.com
http://www.humanmetrics.com

IT Management
Negotiating With Customers and SuppliersPart 2:
Reaching Agreement
This is the second of two sections on the art of negotiating. Part one offered a brief
explanation of common barriers to reaching agreement on any negotiable issue, and
continued with some methods for building rapport between two negotiating parties. In
this section I explain three important aspects of negotiation: positional bargaining,
determining best alternatives, and identifying zones of possible agreement.
As previously mentioned, some of the material in this section is from the Harvard
Negotiation Project sponsored by the Harvard Business School. Harvard initiated the
project as a result of the high number of expensive lawsuits that were being litigated
across the country. Project participants found that enabling litigating parties to settle out
of court through effective negotiation was far more beneficial, and economical, then
conducting expensive, time-consuming, and often frivolous lawsuits. The concept of the
project was that the more that people understood and practiced sound negotiating skills,
the better off society would be in general.
Positional Bargaining
Positional bargaining involves the choices you make on a variety of issues prior to the
negotiation, positions that can help or hinder the progress of the discussions. Some
typical issues are: do you view the opposing party as a friend or an adversary; do you
perceive the end goal to be an agreement or a victory; will you be offering concessions to
cultivate the relationship, or demanding concessions as a condition of relationship; will
you be making offers, or offering threats. The initial position you take often determines
the pace of progress in a negotiation. When two opposing parties take a very hard line
with their initial positions, stalemates frequently occur. For example, an end-user may
insists that their online system cannot be down over a weekend even though an IT
database specialist insists that if he does not perform mandatory maintenance databases
will likely become corrupted. These two relatively hard lines will result in a deadlock
until one or both parties adjust their positions.
An approach referred to as negotiating on merits adjusts a persons position by trying to
find a middle ground between the extremes of positioning bargaining. This technique
attempts less at compromise and more at trying new approaches, e.g. instead of viewing
the opposing party as either a friend or a foe, view him as a collaborative problem-solver;
rather then agreement versus victory, try to arrive at a worthwhile outcome that is
efficient and amicable. In the example of the end-user and database specialist, they may
determine that only one database needs to up during the maintenance period, and that a
temporary copy can be used and later imported back into the original set.
A real life IT example of negotiating on merits occurred with me a few years ago when I
headed up the infrastructure group of a major company. We had run on company Xs
servers satisfactorily for several years, and were at a point where we needed to triple our
capacity for much needed, and long over-due, enterprise applications. Factoring in
anticipated growth over the next five years brought our estimated costs for new servers
between $2-3 million. I approached company X with my requirements, fully expecting
they would offer a competitive bid to remain the incumbent vendor. Their only serious
competition came from company Y who began marketing their products and services
very aggressively. We had never used company Ys products where I then worked.
My initial position was that I really did not want to bring in a second vendor. We were
already locked in to company X with our legacy systems that would be around for several
more years. Going with a new vendor would mean additional costs for training, or hiring
experienced staff, or both. But along the way, two surprising things happened. One was
that company Y was far more aggressive than I had anticipated, slashing their purchase
and maintenance costs down to incredibly low figures, extending the give-back period
from 3 months to 6 months, and putting in writing their claims of industry-setting
performance and scalability. The other was the surprising lack of any significant
marketing efforts by company X, the incumbent. They presumably felt that they had the
deal wrapped up, and while their offering would have been competitive in a normal
bidding situation, it was no match against what company Y was offering.
The upshot was that I eventually awarded the contract to company Y. Its claims about
support, performance, reliability and scalability all proved to be true, and validated the
decision. If I had not adjusted my original position from a very rigid hard-line of not
being open to considering a non-incumbent vendor, the company would have lost a great
opportunity. As it turned out, the company and the vendor both ended up winning on this
deal.
Determining Best Alternatives
An important part of preparing for a negotiation is determining possible alternatives to
the desired outcome. One should include in this the bottom line value, sometimes referred
to as the best and final offer. The reason this best alternative is so important is because it
needs to be the firm amount (or the final term or condition) from which you will walk
away from the negotiation if it is not met. In the IT arena, this may be the point at which
you escalate your negotiation to senior management.
An experience I had evaluating large-volume storage suppliers will serve to illustrate.
The company I worked for was enjoying rapid growth and approved substantial funds in
my in infrastructure budget for a huge disk storage contract. My technical support team
itemized all of our requirements in a request for proposal (RFP), and sent it out to five
well-known disk suppliers. One of our non-mandatory requirements suggested that the
prospective bidder provide an onsite demonstration of their equipment. This would allow
us to kick the tires so to speak by verifying the units compatibility with our own
equipment and validating its performance claims. Four of the five vendors agreed to
conduct these onsite tests.
My first reaction to the vendor who declined was that this would not help their cause.
Their explanation only made matters worse. They stated that since their inventory was
low and demand for their product was high, they could not afford to free up valuable
equipment for a proposal that was not yet a sure thing. The arrogance of the vendor
continued with its total unwillingness to reduce its inflated costs for purchase and
maintenance. The enterprise I worked at was a Fortune 50 company that would be a
marquee account for any of the bidders, yet this particular vendors marketing team was
making little effort to secure what most considered a plumb of a contract.
During the course of the evaluations, we eliminated two other vendors who could not
meet several of our mandatory requirements. We eliminated a third after confirming poor
performance results with independent laboratories who conducted extensive tests for
clients at their labs in northern California. Down to the last two, we conducted thorough
customer interviews with 5 to 10 clients of each finalist. Surprisingly, the vendor who
refused to test onsite received far and away the highest reviews from their customers.
Even customers who acknowledged the vendors high price and low marketing skills had
to admit the product practically sold itself.
One of my initial negotiating alternatives was to go with the vendor who would be most
cost competitive and still meet our performance goals. But my best and final alternative
prior to evaluations centered on high availability. With all of our critical applications
running on this new storage, we simply could not afford lengthy or frequent outages. In
this category the vendor with the arrogant attitude was head and shoulders above all the
others. Total redundancy of components, remote diagnostics, and impressive proactive
maintenance all combined to make their product the most reliable on the market. These
features supporting high availability eventually won them the contract. The performance
and reliability of the product exceeded even our high expectations, so much so that we
procured more of the same two years later. While the company did improve their
marketing skills and cost competitiveness over time, the incident confirms the value of
determining your best alternatives prior to the negotiation.
Identifying Zones of Agreement
Identifying zones of agreement is a negotiating technique in which the two parties try to
explore common interests and mutual values that help move the negotiation forward.
These areas of commonality may not be a direct part of the negotiation but significant
enough to encourage meaningful dialogues when talks bog down.
President Jimmy Carter used this technique very successfully in attempting to further
negotiations between Egyptian President Anwar Sadat and Israeli Prime Minister
Menachem Begin. The common zone of agreement among all three parties was their deep
belief in religion. Even though they practiced three very different faiths, they shared a
mutual respect for each others convictions. While there were numerous other factors
involved, this common area of religious beliefs helped lead to the historic Camp David
Accords in 1978 and the signing of a peace treaty with Israel in 1979. Though the signing
eventually ended in tragedy when fundamentalist assassins gunned down President Sadat
two years later, historians agree that the act of getting these two arch-rivals together to sit
and negotiate is one of President Carters greatest achievements.
A few years ago I began negotiating a contract with an IT disaster recovery service
provider for a major client. Initially, the positions of the service provider and me seemed
to have little in common. I preferred local testing on equipment identical to that of my
client, with easy access for my technical staff. The vendor could not offer any of these.
Their testing facility for this type of equipment was across the country; their models of
computers would be upgraded levels from what we were running; and only limited
personnel could be admitted.
In exploring these differences further, however, we realized that testing remotely would
help us to simulate an actual disaster more realistically since some disasters would
require a remote recovery. Running on upgraded equipment would likely enhance
performance rather than degrade it. The vendors technical support proved to be excellent
and eliminated the need for several of my staff to travel to the remote recovery site. By
searching for zones of agreement in our negotiations, we found we had more in common
than not, leading to a worthwhile five-year contract. This technique of finding common
areas and mutual interests can be a powerful tool to add to your negotiating arsenal.
This second of a two-part series on negotiating covered the three important aspects of
positional bargaining, determining best alternatives, and identifying zones of possible
agreement. The first part two explained two additional facets of barriers to agreements
and how to build rapport. Whether used individually or in combination, these five
elements of bargaining can help anyone negotiate more successfully.
References
Fisher, R., Getting To Yes: Negotiating Agreement Without Giving In, 2
nd
Edition,
Houghton Mifflin Company, 1992 (Based on the Harvard Negotiation Project)
Ertel, D and Fisher, R., Getting To Negotiate: The Getting to Yes Workbook, Houghton
Mifflin Company, 1995
Gallway, T., The Inner Game of Work, Random House, 1999

IT Management
Service Management
This section describes the various aspects of IT service management. It begins by
identifying key services for business users. The second section offers tips on developing
service-level agreements (SLAs) that really work.
Ill add other sections on service management to this guide over the summer and fall of
2004. The focus of these articles is establishing mutually beneficial service metrics, help
desk services, network services, infrastructure services, and web services.


IT Management
Identifying Key Services for Business Users
Earlier sections of this guide described the need and prescribed a methodology for
identifying key customers of an IT department. The next step after identifying key
customers is to identify their key services. This section offers suggestions on how best to
identify these services, including the need to meet face-to-face, the importance of sound
interviewing techniques, and the value of negotiation.
Techniques for Identifying Key Services
Identifying which services key customers of an IT department use sounds obvious. But
many IT managers merely presume to know the key IT services of their key customers
without ever verifying which services those customers need most. Only by interacting
directly with their key customers can managers understand the wants and needs of these
customers.
As I mentioned earlier, a customer/supplier matrix such as the one as below can be an
extremely effective technique in improving the quality of customer services, as well as
the processes and suppliers that feed into them. The first essential aspect of using the
CSM is to identify your key customers and to negotiate reasonable expectations. In this
section I describe the second essential aspect: identifying key processes that produce key
services (processes that are critical to a customers success and whose delivery meets
customer expectations).
Customers whose
use of IT services
success and whose
expectations are
reasonable
IT services that are
critical to a
customers success
and whose delivery
meets customer
expectations
Described in the
section "Process
Management"
Described in the
section "Supplier
Management"

Infrastructure managers need to clearly distinguish between services their customers need
to conduct the business of their departments, and services that they want but may not be
able to cost-justify to the IT organization. For example, an engineering department may
need sophisticated graphics software to design complex parts, and want to have all of the
workstations support oversized color monitors. The IT infrastructure may be able to meet
their expectations of the former but not the latter. This is where the importance of
negotiating realistic customer expectations comes in.
Before any effective negotiation can occur, an IT service representative needs to arrange
a face-to-face interview with needs to be set up. Again, this may seem straightforward,
but a surprising number of IT leads and supervisors are reluctant to engage in personal
interviews with customers. IT staffers offer a variety of reasons for this reluctance,
including the difficulty of scheduling a time or place, inability to interview effectively,
the convenience of a phone call, or the quickness and documentary value of email. In the
end, there is really no substitute for the personal dynamics that a one-on-one meeting can
generate.
IT professionals seldom place interviewing techniques high on their list of skills to
develop. Yet effective interviewing is often paramount for reaching consensus on exactly
which IT services are critical versus those that are simply desirable. Once a meeting is
arranged and underway to discuss key services, the issue of the quality of services often
arises. The two traditional aspects of IT services used to center on online availability and
online response times. But these days, with so many core competencies dependent on IT
services, a whole range of quality measures have been added: schedule and cost of new
projects, ease of use, training, response times for help tickets, escalation of extended
problems, and so on.
The final aspect of identifying and eventually agreeing on the key services that IT
customers truly need involves the art of negotiation. Substantial literature is available on
the skills required for successful negotiation (the reference section includes some
suggested reading). While some IT managers may feel that their focus should be on
technical or business matters, there is no doubt that skillful negotiations with a customer,
particularly one with unreasonable requirements, is an invaluable tool.
References
You Can Negotiate Anything (Bantam, 1982), by Herb Cohen.
Getting to Yes: Negotiating Agreement Without Giving In, Second Edition (Penguin, 1991), by Roger
Fisher, et al.
IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures (Prentice
Hall PTR, 2002, ISBN 013087678X), by Rich Schiesser.
IT Services: Costs, Metrics, Benchmarking, and Marketing (Prentice Hall PTR, 2000, ISBN 0130191957),
by Anthony F. Tardugno, Thomas R. DiPasquale, and Robert E. Matthews.
Trump, Donald J., The Art of the Deal

IT Management
Service-Level Agreements That Really Work
This section presents some helpful tips on how to generate service-level agreements
(SLAs) that are mutually beneficial to both the IT department offering them and the user
department that monitors them. The initial discussion traces the evolution of IT
departments into service organizations. Its important to understand how IT evolved into
its service orientation of today, and how SLAs became a natural progression of this
advancement. The second part of this section presents helpful tips on how to develop
effective SLAs. The final portion explains the important steps to follow when negotiating
SLAs.
How IT Departments Evolved into Service Organizations
Most IT organizations began as offshoots of their companys accounting departments. As
companies grew and their accounting systems became more complex, their dependency
on the technology of computers also grew. The emphasis of IT in the 1970s was mostly
on continually providing machines and systems that were bigger, faster, and cheaper.
During this era, technological advances in IT flourished. Two factors led to very little
emphasis on customer service.
First, in the 1970s the IT industry was still in its infancy. Organizations were struggling
just to stay abreast of all the rapidly changing technologies, let alone focus on good
customer service. Second, within most companies the IT department was the only game
in town, so to speak. Departments that were becoming more and more dependent on
computersfinance, engineering, and administration, for example were pretty much at
the mercy of their internal IT suppliers, regardless of how much or how little customer
service was provided.
By the 1980s, the role of IT and customer service began changing. IT was becoming a
strategic competitive advantage for many corporations. A few industries such as banking
and airlines had long before discovered how the quality of IT services could affect
revenue, profits, and public image. As online applications started replacing many of the
manual legacy systems, more and more workers became exposed to the power and the
frustration of computers. Demand for high availability, quick response, and clear and
simple answers to operational questions gave rise to user groups, help desks, service-level
agreements, and eventually customer service representatives, all within the confines of a
corporate structure.
Good customer service was now becoming an integral part of any well-managed IT
department. By the 1990s, most users were reasonably computer literate, PCs and the
Internet were common fixtures in the office and at home, and the concept of customer
service transitioned from being hoped for to being expected. Demands for excellent
customer service grew to such a degree in the 1990s that the lack of it often led to
demotions, terminations, and outsourcing.
IT had evolved from a purely accounting and technical environment into a totally service-
oriented environment. This transition caught many IT professionals off guard. Their traits
and specialties consisted mostly of technical skills. They had little to offer in the area of
interpersonal relations and customer service. Companies hiring IT professionals today
often look for traits such as empathy, helpfulness, patience, resourcefulness, and being
team-oriented as requirements for the job. The extent to which these traits are in evidence
frequently determines an individuals or an organizations success in IT today.
A natural progression of this trend toward greater customer service was the development
of service-level agreements.
Tips for Developing Effective Service-Level Agreements
Following are six tips to help in developing effective service-level agreements. Some of
these suggestions, such as the use of penalties, are more applicable to some IT
environments than to others. The judicious use of these recommendations should result in
SLAs that can be mutually agreed upon.
Make it understandable. One of the first things that turns off a customer to an
SLA is poor writing, technical jargon, and phrases only an IT professional would
understand. Make sure that your wording is clear, concise, and understandable.
Insist on reasonableness. Managing customer expectations is one of the key
benefits of an SLA. Expectations need to be reasonable from the standpoint of
both parties. Failure to agree on the reasonableness of customer expectations
should be escalated to both partiesmanagement.
Use meaningful metrics. Include service metrics that are meaningful to both IT
representatives and customers. These metrics are the basis for determining
whether target levels have been met, and should be precise enough as to remove
ambiguity and clear enough to be easily understood.
Keep it brief. Short, straightforward sentences work best. Some of finest SLAs
written have only been a page or two long.
Consider use of penalties. This principle normally applies when chargeback
systems are used. Creative individuals employ penalties for IT departments not
meeting their service targets even if a chargeback system is not in use. These
penalties may be in the form of reduced costs to customers of new projects,
reduced bonuses for IT personnel, or adjusted maintenance fees from suppliers.
Maintain regular reviews. IT representatives and their customers should review
their SLAs periodically. For most shops, this is done at least annually, though
some perform this review on a quarterly basis.
Steps To Negotiating Worthwhile Service-Level Agreements
The issue of reasonable expectations is a salient point and cuts to the heart of sound
customer service. When IT people started getting serious about service, they initially
espoused many of the tenets of other service industries. Phrases such as the following
were drilled into IT professionals at many companies embarking on a commitment to
customer service:
"The customer is always right."
"Never say no to a customer."
"Always meet your customers expectations."
As seemingly obvious as these statements appear, the plain and simple fact is that rarely
can you meet all of the expectations of all of your customers all of the time. The more
truthful but less widely acknowledged fact is that customers sometimes are unreasonable
in their expectations. IT service providers may actually be doing more of a disservice to
their customers and to themselves by not saying no to an unrealistic demand. This leads
to the first of two universal truths about customer service and expectations.
An unreasonable expectation, rigidly demanded by an uncompromising customer and
naively agreed to by a well-intentioned supplier, is one of the major causes of poor
customer service.
This scenario occurs time and again within IT departments throughout various industries.
In their zest to please customers and establish credibility for their organizations, IT
professionals agree to project schedules that cannot be met, availability levels that cannot
be reached, response times that cannot be obtained, and budgets that cannot be reduced.
Knowing when and how to say no to a customer is not easy, but techniques are available
to assist in negotiating and managing realistic expectations. While heading an extensive
IT customer service effort at a defense contractor, I developed with my team a simple but
effective methodology for negotiating and managing realistic customer expectations. The
first part involved thorough preparation of face-to-face interviews with selected key
customers, and the second part consisted of actually conducting the interview to negotiate
and follow up on realistic expectations. Changing the mindset of IT professionals can be
a challenging task. We were asking them to focus very intently on a small number of
customers when for years they had emphasized doing almost the opposite. The criteria
helped immensely to limit their number of interviews to just a handful of key customers.
Getting the IT leads and managers to schedule the interviews was even more of a
challenge for us. This reluctance to interview key customers was puzzling to our team.
These IT professionals had been interviewing many new hires for well over a year and
had been conducting semiannual performance reviews for most of their staffs for some
time. Yet we were hearing almost every excuse under the sun as to why they could not
conduct a face-to-face interview with key customers. Some wanted to conduct it over the
phone, some wanted to send out surveys, others wanted to use email, and many simply
claimed that endless "phone tag" and schedule conflict prevented successful get-
togethers.
We knew that these face-to-face interviews with primary customers were the key to
successfully negotiating reasonable expectations that in turn would lead to improved
customer service. So we looked a little more closely at the reluctance to interview. What
we discovered really surprised us. Most of our managers and leads believed that
interviews could easily become confrontational unless only a few IT-friendly customers
were involved. Many had received no formal training on effective interviewing
techniques and felt ill-equipped to deal with a potentially belligerent user. Very few
thought that they could actually convince a skeptical user that some of their expectations
may be unrealistic and yet still come across as being service-oriented.
This turn of events temporarily changed our approach. We immediately set up an intense
interview training program for our lead and managers. It specifically emphasized how to
deal with difficult customers. Traditional techniques such as open-ended questions, active
listening, and restatements were combined with effective ways to cut off ramblers and
negotiate compromise, along with training on when to agree to disagree. We even
developed some sample scripts for them to use as guidelines.
The training went quite well and proved to be very effective. Leads and managers from
all across our IT department began to conduct interviews with key customers. From the
feedback we received from both the IT interviewers and our customers, we learned what
the majority felt were the most effective parts of the interview. We referred to them as
validate, negotiate, and escalate:
Validate. Within the guidelines of the prepared interview scripts, the interviewers
first validated their interviewees by assuring them that they were, in fact, key
customers. They then told the customers that they did indeed critically need and
use the services that we were supplying. Interviewers then went on to ask what
the current expectations of the customers were for the levels of service provided.
Negotiate. If customersexpectations were reasonable and obtainable, the parties
discussed and agreed on the type and frequency of measurements to be used. If
the expectations were not reasonable, negotiations, explanations, and
compromises were proposed. If these negotiations didnt result in a satisfactory
agreement, as would occasionally occur, the interviewer would politely agree to
disagree and then move on to other matters.
Escalate. After the meeting, the interviewer would escalate the unsuccessful
negotiation to his or her manager, who would attempt to resolve it with the
manager of the key customer.
The validate/negotiate/escalate method proved to be exceptionally effective at negotiating
reasonable expectations and realistic service levels. The hidden benefits included clearer
and more frequent communication with users, improved interviewing skills for leads and
managers, increased credibility for the IT department, and more empathy of our users for
some of the many constraints under which most IT organizations work. This empathy that
key customers were sharing with us leads me to the second universal truth I embrace
concerning customer service and expectations:
Most customers are forgiving of occasional poor service if reasonable attempts are made
to explain the nature and cause of the problem, and what is being done to resolve it and
prevent its future recurrence.
As simple and apparent as this principle may sound, it still amazes me to see how often
this basic concept is overlooked or ignored in IT organizations. I have known managers
who believed that customers would be more upset if told the honest details of an outage.
One operations manager with whom I worked was especially candid. He shared with me
his belief that telling his customers an operator error caused a lengthy outage would
reflect badly on him for not training his staff better. In my many years of infrastructure
management, I have yet to experience a customer who didnt appreciate a truthful
explanation of what went wrong, and how we planned to prevent a recurrence.
Customer-Centric Versus Systems-Centric Service-Level Agreements
A service-level agreement can be either customer-centric or systems-centric. A customer-
centric SLA is directed toward one major customer department such as human resources,
payroll, engineering, or marketing, and covers all of the applications used by that
business unit. The business unit in question usually recommends the scope of the SLA
based on the variety and criticality of applications covered in the agreement. For
example, the engineering department at one aerospace company used only a few highly
sophisticated software applications and entered into an SLA with its IT department that
represented all engineering users. A different aerospace firm had specialty engineering
groups that required separate SLAs for the various kinds of engineering disciplines. The
head of the user department or a suitable user representative normally signs the SLA in
partnership with a representative of the IT department. Many IT groups now have
customer service representatives for specific business units that serve as signatories for
SLAs.
A systems-centric SLA involves a single application, usually an enterprise resource
planning (ERP) system such as corporate financials, timekeeping, or employee benefits,
regardless of the variety of business units that may use it. While less common than a
customer-centric SLA, companies running ERP systems such as SAP, Oracle, or
PeopleSoft often use this kind of service agreement. The IT manager responsible for the
support of the ERP in question usually signs the SLA as the IT representative along with
the CIO. The user departments that use the ERP system the most normally sign the SLA
as the user representatives. The number of user signatures can vary from one or two up to
eight or ten. In this case, service metrics are distributed to each of the user departments
signing the document.
Sample Service-Level Agreement
The following figure shows a sample of a customer-centric SLA.
Figure 1

References
You Can Negotiate Anything (Bantam, 1982), by Herb Cohen.
Getting to Yes: Negotiating Agreement Without Giving In, Second Edition (Penguin,
1991), by Roger Fisher, et al.
IT Services: Costs, Metrics, Benchmarking, and Marketing (Prentice Hall PTR, 2000,
ISBN 0130191957), by Anthony F. Tardugno, Thomas R. DiPasquale, and Robert E.
Matthews.
Trump: The Art of the Deal (Random House, 1987), by Donald J. Trump and Tony
Schwartz.


IT Management
Process Management
This section explains the various aspects of IT process management. It begins by
describing how to develop robust processes in general and goes on to show how to
establish process metrics that are mutually beneficial to both the owner and the users of a
particular process.
In future updates to this guide, Ill include additional sections on process management.
There will be a separate section for each of the ten key infrastructure processes:
High availability
Performance and tuning
Change management
Problem management
Storage management
Network management
Configuration management
Capacity planning
Strategic security
Business continuity


IT Management
Developing Robust Processes
One of the primary characteristics of a world-class IT environment is that its key
processes are well-developed and robust. These processes include those that are part of
the infrastructure such as change management and problem management. They could also
include application development processes such as production acceptance and the
software development life cycle. These processes could also include business continuity
and information security. This section prescribes how to develop robust processes,
regardless of their placement in IT.
Robust processes have a direct tie-in to customer satisfaction in the following manner.
We can satisfy our customers by meeting or exceeding their reasonable expectations. To
do this, we need to deliver quality services consistently. The quality and consistency of
our services are a direct result of the robustness of our processes. The customer/supplier
matrix shown below can demonstrate the importance of processes that produce the key
services that key customers require.
Customers whose
use of IT services
success and whose
expectations are
reasonable
critical to a
customers success
and whose delivery
meets customer
expectations
Processes that
produce the key
services that key
customers require
Described in the
section "Supplier
Management"

The first segment of this section describes 24 characteristics associated with a robust
process. The second part explains how to differentiate a formal process from that of an
informal one, and the importance of doing so.
Characteristics of a Robust Process
The following is a fairly exhaustive list of attributes that characterize the robustness of a
process. In this sense, robustness refers to the resiliency and durability of a process to
withstand abuse, enforce compliance, and be able to measure its effectiveness. In the
common vernacular of IT, it refers to a process as being bulletproof. The intent of these
attributes is not to categorize the robustness of a process as all or nothing. As with many
items associated with technology, the robustness of a process comes in degrees. Missing
a few of these characteristics doesnt mean that a process is weakly designed or poorly
executed. In general, the more of these attributes that are present, the more robust a
process is.
1. The objective is identified. An early step in creating a robust process is to state
its overall objective, document it, share it with all appropriate parties, and ensure
that all process-design participants agree to it and clearly understand it. The
objective should answer the questions of what problem the process solves, which
issues it addresses, and how the process adds value and quality to the
environment.
2. The executive sponsor is identified and involved. Each process needs to have
an executive sponsor who is passionate about the successful design and ongoing
execution of the process. This person provides support, resources, insight, and
executive leadership. The executive sponsor arranges for any required
participation or communication with other groups, either inside or outside the
infrastructure. This individual is often the manager of the process owner.
3. The process owner is identified and given responsibility for and authority
over the process. This person leads the team that designs the process, identifies
its key customers and suppliers, and documents its use. The process owner
executes, communicates, and measures the effectiveness of the process on an
ongoing basis.
4. Key customers are identified and involved. Key customers are those individuals
who are the immediate users and direct beneficiaries of the process. For example,
suppose youre designing processes to request the restoration of a file or the
resetting of a password. Key customers for these processes may be users who are
most likely to request these services on a regular basis. Their involvement in
developing the process is important to ensure practical design and ease of use.
5. Secondary customers are identified and consulted. Secondary customers are
those that may use a process less frequently than primary customers or who may
be the eventual rather than immediate beneficiaries of the process. Using the
example in item 4 above, if administrative assistants are making the original
requests for file restorations, then their managers are likely to be the secondary
customers of the process. Their consultation can be helpful because they may be
the ultimate users of the process.
6. Process outputs are identified. These are the specific deliverables or services
that the process provides to the primary and secondary customers. Service metrics
usually measure the quality of the delivery and the content of these outputs.
7. Process inputs are identified. These are the specific input entities that the
process requires. They may take the form of soft inputs such as data, information,
or requests, or they may be hard inputs such as floppy disks, tapes, or other
physical entities.
8. Process suppliers are identified and involved. Process suppliers are the
individuals who provide the specific inputs to a process. These suppliers may be
o internal to an IT infrastructure (for example, data entry departments)
o external to an IT infrastructure but internal to IT (such as a development
group entering change requests)
o external to IT but internal to a company (for instance, an outside user
group supplying report modification information)
o external to a company (such as hardware and software vendors who may
provide details about how an upgrade is to be performed)
9. The process is described by a sound business model. In simple terms, a robust
process should make common business sense. The benefits of using the process
should exceed the cost and efforts expended to design, execute, and maintain the
process. The business side of a robust process sometimes involves leasing
agreements, maintenance agreements, and service-level agreements.
10. Process hierarchy is understood. Some processes have secondary processes or
subprocesses underneath them. Individuals who are developing well-designed
robust processes know and understand the relationships between the primary and
secondary processes.
11. Execution is enforceable. Almost any process, regardless of design, needs to be
enforceable to be effective. Whenever possible and practical, software techniques
such as passwords, authorizations, audit trails, or locks should enforce compliance
with a process. When technical enforcement is not practical, management support,
review boards, metrics, or other procedural techniques should ensure
enforcement.
12. The process is designed to provide service metrics. Most processes measure
something associated with their output. Often this involves a quantitative measure
such as transaction processes per second or jobs completed per hour. In addition,
a robust process focuses on qualitative measures that are oriented toward the end
user. These metrics show the relative quality of the service being provided.
For example, service metrics involving a report-delivery process may include not only
how often the report is delivered on time, but whether it was delivered to the right
individual, in the correct format, with accurate content, and on the proper media. Service
metrics should measure the benefits of the process to the end users in their own terms.
Designers should orient the metrics toward the customer and should focus on measuring
the right thing; that is, these metrics should exhibit effectiveness.
1. Service metrics are compiled and analyzed, not just collected. Mediocre
infrastructures often invest a fair amount of time, money, and energy to collect
and compile metrics; then they do little to analyze them. The real value of
meaningful measurements comes from thoroughly and consistently examining
these metrics for trends, patterns, and relationships and then applying the results
of the analysis to improve the effectiveness of the particular service being
measured.
2. The process is designed to provide process metrics. Robust processes include
not only service metrics but process metrics. The key difference between a service
metric and a process metric is that a service metric focuses on how effective a
process is with regard to a customer, and a process metric focuses on how
efficient a process is with regard to a supplier.
3. Process metrics are compiled and analyzed, not just collected. We need to
compile and analyze process metrics, just as we do with service metrics. Analysts
sometimes overlook the importance of analyzing missed process metrics when the
associated service metrics are met. This could be the case in terms of a service
metric involving output delivery being met, even though the job and its output had
to be reprocessed numerous times. As with service metrics, the real value of
meaningful process metrics comes from thoroughly and consistently examining
them for trends, patterns, and relationships and then applying the results of the
analysis to improve the efficiency of the particular service being measured.
4. Documentation is thorough, accurate, and easily understood. Documentation
is one of the fundamentals that clearly separate mediocre infrastructures from
those that are truly world-class. Well-written documentation facilitates the
training, maintenance, and marketing of key processes. Progressive shops hold
appropriate staffs accountable for reading and understanding key documentation
by making it part of the performance review. These shops also have their new
employees test the clarity and readability of the writing while ensuring that senior
analysts and technical leads have validated the accuracy of the material.
Thorough documentation eases the tasks of removing all nonvalue-added steps and
verifying that all required value-added steps are present. Effective documentation can
come in various forms, including online and hardcopy narrative procedures, diagrammed
illustrations such as flowcharts or bubble charts, and web-enabled help menus. IT
analysts and technical writers can evaluate documentation in a variety of ways. Future
sections of this guide will explain some of these methods to evaluate documentation more
formally.
1. The process contains all required value-added steps. To use a legal analogy,
value-added steps are to a robust process what the truth is to the testimony of a
credible witness: The process should contain the value-added steps, all of the
value-added steps, and nothing but the value-added steps. Two key attributes of a
robust process are effectiveness and efficiency. Process effectiveness means that
all existing steps are adding value to the end result. Key customers, suppliers, and
process owners should meet prior to and after development of the documentation
to identify all the value-added steps. This group should also ensure that they have
inserted all value-added steps into the final process.
2. The process eliminates all nonvalue-added steps. If a step is not directly
contributing value to the overall objective of the process, process designers should
eliminate that step. This procedure is critical to eventually automating the process.
Designers need to perform two activities to completely eliminate all nonvalue-
added steps. First, they need to identify all the steps in a process, regardless of
how small, even if previously undocumented. This comprehensive list of the exact
steps of a procedure is commonly referred to as the informal process. Second,
they need to evaluate each of these steps closely with an eye toward eliminating
any steps that don't directly contribute to the desired outcome of a process.
3. The process guarantees accountability. Analysts should use process metrics,
performance charts, and trending reports to quickly identify when a department or
an individual is not following the prescribed procedure, with direct feedback to
and consequences from management. For this design to work, process designers
and owners need to give management sufficient tools to carry out enforcement. In
turn, management needs to follow up with fair, timely, and appropriate actions to
ensure process compliance in the future.
4. The process provides incentives for compliance and penalties for avoidance
or circumvention. One of the most effective incentives for compliance is
efficiency. If it takes more time and effort to go around a process than to go
through it, most employees choose to go through it; that is, use the process. The
challenge is to remove the obstacles normally associated with using a process and
to insert roadblocks for circumvention. Properly streamlining and then automating
a process can encourage its use. Security measures such as passwords and locks,
as well as management measures such as exception reports and accountability,
can discourage circumvention.
5. The process is standardized across all appropriate departments and remote
sites. Designers may develop some processes at different remote sites at different
times. This may cause the processes to have slightly different standards of
implementation. For example, one of my clients had an older change-management
process at a remote site based on an email system and a newer version at the
central site based on an Access database system. Before optimizing either process,
analysts had to agree on a standard. Nonstandard processes often come into play
as a result of acquisitions, mergers, or takeovers. The technical challenge of
implementing an agreed-upon standard is often much easier than the political
challenge of actually reaching that consensus in the first place. This is because
resolving a technical issue, for most IT professionals, is far easier and more
desirable than resolving a political issue.
6. The process is streamlined as much as possible. Streamlining a process
involves removing all nonvalue-added steps, eliminating redundant steps,
placing the steps in the most efficient sequence, and streamlining individual steps
as much as possible. For long-established processes, this goal may be difficult to
achieve because users have employed inefficient practices for so long. Here are
three of the most common responses that IT professionals get about why a
particular process cannot or should not be changed:
o "We've always done it that way."
o "It seems to work most of the time, so why bother changing it?"
o "Analyst X designed this process, and only he can change it."
This last response can occur even after analyst X has left the department.
These explanations are not adequate justifications for keeping a process the same
when improvements through streamlining are clearly warranted. Once we remove
nonvalue-added steps, streamlining proceeds in this order: eliminate redundant
steps, place the steps in the most efficient sequence possible, and streamline
individual steps as much as possible.
7. The process is automated wherever practical, but only after streamlining.
Automation can end up being either beneficial or detrimental, depending on how
the automation is designed and implemented. Automating a poorly designed
manual process results in a poorly designed automated process.
8. The process integrates with all other appropriate processes. Several processes
within systems management naturally complement each other. For example,
problem and change management are separate processes, but they often rely on
each other for optimum effectiveness. Similarly, performance tuning and capacity
planning are almost always closely related.
Formal Versus Informal Processes
Most IT professionals are familiar with the concept of a formal process. By this we mean
a procedure or methodology in which all of the major steps are explained and
documented. The write-up is normally signed by a manager in authority, disseminated to
appropriate members of the staff, and made accessible for future reference in either
electronic or hardcopy form. Written procedures on how to reboot servers, initiate online
systems, or back up and restore data are common examples of formal processes.
An informal process is a far more detailed account of its corresponding formal process.
An analogy from the culinary arts serves to illustrate this difference. Suppose you decide
to duplicate a specialty of a gourmet cook by following her published recipe. You adhere
precisely to each of the prescribed steps and create a dish that looks exactly like the
original. But after the first bite, you know immediately that something just doesnt seem
right. Its close but just a bit off the mark. Soon afterward you have the opportunity to
watch this chef prepare the same dish in person. With her recipe in your hand, you note
how she follows the steps in the same order as you did. But occasionally she swirls the
pan briefly or adds a pinch of this and a dash of thatsteps so seemingly insignificant as
to almost be ignored. In this case, the recipe listing the steps is the formal process, but if
the small, seemingly innocuous steps that make the dish taste just right are included in the
directions, you have the informal processthe sum of all the actual detailed steps
involved.
Documenting the small, critical steps of a process, little known and almost rarely
recorded, is a prerequisite to effective process improvement, streamlining, and eventual
automation. Shops unaware of the complete informal procedure associated with a systems
management process often fail in their attempts to redesign it into a robust process due to
tiny but significant steps being left out.
References
A Practical Guide to Information Systems Process Improvement (CRC Press, 2000), by
Anita Cassidy and Keith Guggenberger.

IT Management
Establishing Mutually Beneficial Process Metrics
This section shows the value of process metrics and discusses how they can be
established. I define process metrics by comparing and contrasting them to service
metrics. Robust processes include not only service metrics but process metrics. The
following table points out the differences between a service metric and a process metric.
Differences Between Service and Process Metrics
Service Metric Process Metric
Focuses on the customer Focuses on the supplier
Gauges levels of effectiveness Gauges levels of efficiency
Measures the proper entities Measures the entities properly
Deals with the quality of output Deals with the quality of input
Examples: system availability, response
times, accuracy of content, on-time
delivery, network access, database integrity
Examples: job and transaction throughput,
elapsed cycle times, quantity of resources
consumed, abnormal job terminations,
rerouting of problems, reruns, reprints,
restores

The concept of differentiating service metrics from process metrics is important because
many IT departments focus all of their measuring activities solely on customer-oriented
service metrics. There is no question that service metrics are essential. They are the basis
of most service-level agreements, can help solidify customer relationships, and can
accurately document the quality of IT service. But process metrics can measure the
quality of the process being used to provide the services. By measuring and continually
improving the productivity of a process, analysts can keep increasing the efficiencies of a
process, which eventually leads to increased service quality.
A process metric indicates the productivity of a procedure by measuring such details as
resources consumed or cycle times. The frequency of on-time delivery of reports is a
service metric because it measures the end result of the process (which is what the
customer gets and is therefore customer-oriented). The number of times the report had to
be reprinted to obtain acceptable quality is a process metric because it measures the
amount of effort required to produce the end product. Common examples of process
metrics include abnormally ending job processing, rerouting problems, rerunning jobs,
reprinting reports, and restoring files.
We can look at a slightly revised version of our customer/supplier matrix to help
reinforce the concepts of service metrics and process metrics. Service metrics measure
the quality and effectiveness of services with regard to the customers who use them.
Process metrics measure the quality and efficiency of processes with regard to the
suppliers who feed into them. Users of this version of the CSM sometimes refer to the
customer or service side of the matrix versus the supplier or process side.
Key Customers Service Metrics Process Metrics
Key Services Key Processes Key Suppliers

Customers whose
use of IT services
success and whose
expectations are
reasonable
critical to a
customers success
and whose delivery
meets customer
expectations
Processes that produce
the key services that key
customers require
Described in the section
"Supplier Management"

References


IT Management
Change ManagementPart 1
This is the first of a three-part series on change management, one of the most critical
processes within IT management. A recent survey of 240 senior IT directors at the May,
2004 IT Directors Forum listed change management as the biggest challenge in IT this
year. This section introduces the major aspects of this important infrastructure activity. I
begin with the definition of change management and explain the subtle but significant
difference between change control and change management. Next I summarize the 13
steps required to design and implement an effective change management process.
The first nine of these steps are preparatory to process design. I discuss each these steps
in the remaining portion of this section. Part two will describe in detail step ten which
comprises the actual design of a change management process. Part three will cover the
remaining three steps of implementing and maintaining the process, along with a method
to assess the change management environment of an IT infrastructure.
Definition of Change Management
Change managementa process to control and coordinate all changes to an IT
production environment. Control involves requesting, prioritizing, and approving
changes; coordination involves collaborating, scheduling, communicating, and
implementing changes.
A change is defined as any modification that could impact the stability or responsiveness
of an IT production environment. Some shops use the terms change management and
change control synonymously, but there is an important distinction between the two
expressions. Change management is the overall umbrella under which change control and
change coordination reside. Unfortunately, to many people the term change control has a
negative connotation that warrants some further discussion.
To many IT technicians, change control implies restricting, delaying, or preventing
change. But to system, network, and database administrators, change is an essential part
of their daily work. They view any impediments to change as something that will hinder
them as they try to accomplish their everyday tasks. Their focus is on implementing a
large number of widely varying changes as quickly and as simply as possible. Since
many of these are routine, low-impact changes, technicians see rigid approval cycles as
unnecessary, non-value-added steps.
This apparent dichotomy is a challenge to infrastructure managers initiating a formal
change management process. They need the individuals who will be most impacted by
the process and are the most suspect of it to buy into the process. This is why marketing a
change management process properly by pointing out its benefits, and by gaining early
buy-in by those most affected by it, is so important.
Steps To Implementing a Change Management Process
There are 13 steps required to implement an effective change management process; they
are listed below in Figure 1. I discuss each step in some detail and augment where
appropriate with examples and forms.
1. Identify executive sponsor.
2. Assign a process owner.
3. Select a cross-functional process design team.
4. Arrange for meetings of the cross-functional process design team.
5. Establish roles and responsibilities for members supporting the design team.
6. Identify the benefits of a change management process.
7. If change metrics exist, collect and analyze them; if not, set up a process to do so.
8. Identify and prioritize requirements
9. Develop definitions of key terms.
10. Design the initial change management process.
11. Develop policy statements.
12. Develop a charter for a change review board (CRB).
13. Use the CRB to continually refine and improve the change
management process.
Figure 1 Steps Required to Develop a Change Management Process
Step 1: Identify an Executive Sponsor.
An effective change management process requires the support and compliance of every
department in a company that could affect change to an IT production environment. This
includes groups within the infrastructure such as technical services, database
administration, network services, and computer operations; groups outside of the
infrastructure such as the applications development departments; and even areas outside
of IT such as facilities.
An executive sponsor must garner support from, and serve as a liaison to, other
departments; assign a process owner; and provide guidance, direction, and resources to
the process owner. In many instances, the executive sponsor is the manager of the
infrastructure, but he or she could also be the manager of the department in which change
management resides, or the manager of the process owner.
Step 2: Assign a Process Owner.
As I mentioned previously, one of the responsibilities of the executive sponsor is to
assign a process owner. The ideal process owner will possess a variety of skills and
attributes to accomplish a variety of tasks. These tasks include assembling and leading
teams, facilitating brainstorming sessions, conducting change review meetings, analyzing
and distributing process metrics, and maintaining documentation. High on the list of
desirable attributes are the abilities to promote teamwork and cooperation and to
effectively manage highly diverse groups.
Step 3: Select a Cross-Functional Process Design Team.
The success of a change management process is directly proportional to the degree of
buy-in from the various groups that will be expected to comply with it. One of the best
ways to ensure this buy-in is to assemble a process design team consisting of
representatives from key functional areas. The process owner, with support from the
executive sponsor, will select and lead this team. It will be responsible for completing
several preparatory steps leading to the design of the initial change management process.
Step 4: Arrange for Meetings of the Cross-Functional Process Design Team.
This sounds routine but it actually is not. The diversity of a well-chosen team can cause
scheduling conflicts, absentee members, or misrepresentation at times of critical decision
making. It is best to have consensus from the entire team at the outset as to the time,
place, duration, and frequency of meetings. The process owner can then make the
necessary meeting arrangements to enact these agreements.
Step 5: Establish Roles and Responsibilities for Members of the Process Design Team.
Each individual having a key role in the support of the process design team should have
clearly stated responsibilities. The process owner and the cross-functional design team
should propose these roles and responsibilities and obtain concurrence from the
individuals identified.
Step 6: Identify the Benefits of a Change Management Process.
One of the challenges for the process owner and the cross-functional team will be to
market the use of a change management process. If an infrastructure is not used to this
type of process, this will likely not be a trivial task. Identifying and promoting the
practical benefits of this type of process can help greatly in fostering its support. Figure 2
lists some examples of common benefits of a change management process.
Step 7: If Change Metrics Exist, Collect and Analyze; If Not, Set Up a Process to Do So.
An initial collection of metrics about the types and frequencies of change activity can be
helpful in developing process parameters such as priorities, approvals, and lead times. If
the existing environment is not producing meaningful metrics, then process design team
members should gather some initial set of metrics, even they must collect them manually.
Step 8: Identify and Prioritize Requirements.
One of the key preparatory tasks of the cross-functional design team is to identify and
prioritize requirements of the change management process. Prioritizing is especially
important because budget, time, or resource constraints may prevent all requirements
from being met initially. The Strategic Management portion of this guide contains
techniques for effectively brainstorming and prioritizing requirements. In Table 1
1. Visibility. The number and types of all changes logged will be reviewed at each
weeks CRB meeting for each department or major function. This shows the
degree of change activity being performed in each unit.
2. Communication. The weekly CRB meeting is attended by representatives from
each major area. Communication is effectively exchanged among board members
about various aspects of key changes, including scheduling and impacts.
3. Analysis. Changes that are logged into the access database can be analyzed for
trends, patterns, and relationships.
4. Productivity. Based on the analysis of logged changes, some productivity gains
may be realized by identifying root causes of repeat changes and eliminating
duplicate work. The reduction of database administration change is a good
example of this.
5. Proactivity. Change analysis can lead to a more proactive approach toward change
activity.
6. Stability. All of the above benefits can lead to an overall improvement in the
stability of the production environment. Increased stability benefits customers and
support staff alike.
Figure 2 Benefits of a Change Management Process
I present some examples of prioritized requirements from a composite of
prior clients.
Step 9: Develop Definitions of Key Terms.
Change management involves several key terms that should be clearly defined by the
design team at the beginning to avoid confusion and misunderstandings later on. Table 2
shows some common terms and definitions used by several clients. Planned and
emergency changes are especially noteworthy.
This concludes the first of the three part series on change management. As mentioned
previously, part two will continue with a detailed description of step ten which comprises
the actual design of a change management process. Part three will cover the remaining
three steps of implementing and maintaining the process, along with a method to assess
the change management environment of an IT infrastructure.
References
ComputerWeekly.com, Change Management is Biggest Challenge This Year, June 22,
2004
John Jones, DeAnne Aguirre, Matthew Calderone, Resilience Report-Strategy+Business,
Booz Allen Hamilton, February, 2004
Schiesser, Rich, IT Systems Management, Prentice Hall, 2002


IT Management
Change Management: Process Design
This is the second of a three part series on change management. Part one described the
first nine steps of the 13 required for planning, designing, implementing and maintaining
a robust change management process. This section discusses the tenth step which consists
of the actual design of the process and includes the prioritization of changes, action
matrices for approving and communication changes, and a sample change request form.
Designing the Initial Change Management Process
As mentioned in part one, there are 13 steps needed to implement an effective change
management process. Figure 1 below lists these steps.
4. Arrange for meetings of the cross-functional process
design team.
5. Establish roles and responsibilities for members
supporting the design team.
7. If change metrics exist, collect and analyze them; if not,
set up a process to do so.
13. Use the CRB to continually refine and improve the
change management process.

Figure 1. Steps Required to Develop a Change Management Process
This section will focus on step 10 which focuses on the design of the initial change
management process. I use the term initialbecause the process is very much a living
entity that expands and alters its scope as infrastructure environments change. Several of
my clients decided to pilot their new change management processes using just a small
subset of their total IT department changes to get a feel for how the process is going to
work. One financial company decided to only process infrastructure hardware changes at
the outset. They soon realized that software changes also needed to be included to
prevent undocumented and untested changes from jeopardizing system stability. Many
companies elect to pilot infrastructure changes first and to add applications development
changes later. In my experience I recommend starting slow and small but to include all
departments on the design team who will eventually be participating in the final process.
Step 10: Design the Initial Change Management Process.
This is one of the key activities of the cross-functional team because this is where the
team proposes and develops the initial draft of the change management process. The
major deliverables produced in this step are a priority scheme, a change request form, a
review methodology, and metrics.
The priority scheme should apply to both planned changes and emergency changes (these
two categories should have been clearly defined in the previous section). A variety of
criteria should be identified to distinguish different levels of planned changes. Typical
criteria includes quantitative items such as the number of internal and external customers
impacted, as well as the number of hours to implement and back out the change. The
criteria could also include qualitative items such as the degree of complexity and the level
of risk.
Some shops employ four different levels of planned changes to offer a broader variety of
options. Many shops just starting out with formalized change management begin with a
simpler scheme of only two levels. Table 1 lists some quantitative and qualitative criteria
for four levels of planned changes, and Table 2 does the same for two levels.
Table 1. Criteria for Four Levels of Planned Changes
Priority Level Criteria
1 2 3 4
Narrative descriptors Very High
Substantial
Significant
Substantial
"A"
High
Major
Important
Principal
"B"
Medium
Moderate
Standard
Nominal
"C"
Low
Minor
Optional
Time-Permitting
"D"
Percent of total external > 90 % 5090 % 1049 % < 10 %
customers impacted
Type of total external
customers impacted
Customers of
critical apps
Customers of
high-prty apps
Customers of
med-prty apps
Customers of
low-prty appls
Percent of internal users
impacted
> 90 % 5090 % 1049 % < 10 %
Type of internal users
impacted
Customers of
critical apps
Customers of
high-prty apps
Customers of
med-prty apps
Customers of
low-prty apps
Critical applications
impacted
Yes No No No
Noncritical application
downtime required
Yes Yes No No
Amount of additional
budget required
> $10,000 < $10,000 0 0
9. Hours to implement > 8 58 14 < 1
Backout plan required Yes Yes No No
Hours to back out > 4 < 4 n/a n/a
Broadness of scope Very high High Medium Low
Extent of impact Very high High Medium Low
Degree of complexity Very high High Medium Low
Level of risk Very high High Medium Low
Strategic value Very high High Medium Low

Table 2. Criteria for Two Levels of Planned Changes
Impact Level of Planned Changes Criteria
High Low
Any impact to subscribers Yes No
Percent of total external
customers impacted
> 25 % < 25 %
Type of total external
customers impacted
Customers of critical apps,
and high- & med-prty apps
Customers of low-prty apps
Percent of internal users
impacted
> 50 % < 50 %
Type of internal users
impacted
Customers of critical apps,
and high- & med-prty apps
Customers of low-prty apps
Critical applications
impacted
Yes No
Noncritical application Yes No
downtime required
Amount of additional
budget required
> $1,000 < $1,000
Hours to implement > 4 < 4
Backout plan required Yes No
Broadness of scope High Low
Extent of impact High Low
Degree of complexity High Low
Level of risk High Low
Strategic value High Low

I have worked with some clients who prefer only the two-level priority scheme, other
who prefer only the four-level scheme, and still others who start out with a two-level
scheme and then revise it over time to three or four levels. The type of priority scheme an
organization uses depends on factors such as how experienced they are with
infrastructure processes, the number of changes executed each week, the number and
variety of customers, the number and variety of applications, and the ratio of emergency
to planned changes. Smaller, less diverse shops usually start with a lower level of priority
scheme than larger, more complex shops that use higher level priority schemes.
After the team determines priority levels, it will need to develop lists of actions to be
taken depending on the level of planned or emergency change. These actions include
such items as who will approve changes, when the approvals will be made and who will
be notified about the change. Table 3 shows some sample actions for planned changes by
impact level and time frame. An IT department will customize these actions to suit its
individual needs. Similarly, Figure 2 describes sample actions for emergency changes.
Table 3. Action Matrix for Planned Changes
Impact Level/Time Frame Actions
Low/Anytime High/Prior to Review
Meeting
High/After
Review
Meeting
Types of
approvals
required
Supervisor of
implementer
Supervisor plus 2 board
members or reps,
preferably 1 familiar with
change and 1 familiar
with impact
Change
Review Board
Advance
approval time
1 hour 1 day At CRB
meeting
Advance
notification
time
n/a 1 day 1 day
Groups to be
notified
n/a Customers impacted Customers
impacted
Preferred time
of change
Anytime Not prime shift Not prime shift
Backout plan
required
No Yes Yes

1. If not an emergency change, then follow the actions in
the action matrix for planned changes.
2. Implementer or recovery team rep notifies all
appropriate parties, including the support center of the
emergency change.
3. Recovery team should initiate recovery action within 2
hours.
4. Recovery team should determine problem status update
interval for support center.
5. If status interval is exceeded, recovery team rep updates
support center.
6. Support center to notify all appropriate parties of the
update.
7. Repeat steps #5 and #6 until problem is resolved.
8. Support center issues final resolution to all appropriate
parties.
9. Implementer logs activity as an emergency change.
10. CRB issues final disposition of the emergency change
at the next meeting of the CRB.
11. Change manager records the boards final disposition of
the change into the emergency change request record.

Figure 2. Action Procedure for Emergency Changes
The team next develops a change request form. Two characteristics are always present in
such a form: simplicity and accessibility. The form needs to be simple enough to use that
minimum explanation is required, yet thorough enough that all pertinent information is
provided. The form also needs to be easily accessible to users, preferably through a
companys intranet or in a public email folder on a shared drive. Change requests should
be stored in a database, preferably a relational database, for subsequent tracking and
analysis. Figure 3 shows a sample change request form.
Information Technology Change Request Form
Requester_______________________ Request Date_________Priority_______
Summary Description of Change ______________________________________
__________________________________________________________________
Customers Impacted ________________________________________________
Systems Impacted __________________________________________________
Expected Start Date/Time of Change ___________ Estimated Duration______
Actual Date/Time of Change ___________ Actual Duration ________
Detailed Description of Change_______________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
===============================================================
For Low-Priority Changes, Requesters Managers Approval_______________
Disposition of Change ________________________________________________
===============================================================
For High-Priority Changes, CRB Approval _______________
Backout Plan in Place?_________ Downtime Required?________
Estimated Time to Back Out?________ Downtime Notices Sent Out?________
Final Disposition of Change___________________________________________

Figure 3. Sample Change Management Request Form
A recent client of mine involved in law enforcement developed an in-house electronic
form for change management that is now widely used in his organization on their
Intranet. The client has enhanced the form, called eChange, to include electronic
signatures, automatic distribution, and provisions for feedback and help commands. If
you are interested in more information on this home-grown enhancement, please contact
me and I will put you in touch with him.
The next part of this step involves the establishment of metrics for tracking, analyzing,
and trending the number and types of planned and emergency changes occurring every
week. Shops with robust change management processes place special emphasis on the
analysis of these metrics, particularly the ratio of emergency to planned changes.
The final task for the cross-functional team is to devise a methodology for reviewing all
changes. Most shops constitute a Change Review Board (CRB) that meets weekly to
review the prior weeks changes and to discuss upcoming changes. Steps 11 and 12 of
this process discuss policy statements and the charter of the CRB, respectively. Part three
of this series covers both of these steps in more detail, along with step 13 on how to use
the CRB to continually improve the change management process.
References
2004


IT Management
Process Implementation
This section discusses the last three steps of the 13 required to design and implement an
effective change management process. These steps include the development of policy
statements and of the charter for the change review board (CRB), how to use the CRB to
continually improve the change management process, and the topic of emergency
changes. The section concludes with a technique to assess the change management
process of any infrastructure.
As mentioned previously, there are 13 steps required to implement an effective change
management process; they are listed below in Figure 1. This section will describe the last
three of these 13 steps.
4. Arrange for meetings of the cross-functional process design team.
5. Establish roles and responsibilities for members supporting the design
team.
7. If change metrics exist, collect and analyze them; if not, set up a process
to do so.
13. Use the CRB to continually refine and improve the change management
process.

Figure 1 Steps Required to Develop a Change Management Process
Step 11: Develop Policy Statements.
Regardless of how well the cross-functional team designs a change management process,
it will not be effective unless there is support, compliance, enforcement, and
accountability. These are the objectives of policy statements. They are what give a
process visibility and credibility. These statements should reflect the philosophy of
executive management, the process design team, and the users at large. Figure 2
illustrates a set of sample policy statements for change management.
1. All hardware and software changes that could potentially impact the
stability or the performance of the company xs IT production
environment are to go through the change management process.
2. The senior director of the infrastructure department is the executive
sponsor of the change management process.
3. Employee y is the IT change manager. In employee ys absence,
employee z will serve as the IT change manager.
4. The IT change manager is responsible for chairing a weekly meeting of
the CRB at which upcoming major changes are discussed, approved,
and scheduled, and prior weeks changes are reviewed and dispositioned
by the board.
5. The IT change manager will have sole responsibility of entering the
final disposition of each change based on the recommendation of the
board.
6. All CRB areas serving in either a voting or advisory role are expected to
send a primary or alternate representative to each weekly meeting.
7. All IT staff members and designated vendors implementing production
changes are expected to log every change into the current IT tracking
database.
8. Board members are required to discuss any unlogged changes they
know about at the weekly CRB meeting. These unlogged changes will
then be published in the following weeks agenda.
9. All planned changes are to be categorized as either high-impact or low-
impact based on the criteria established by the CRB. Implementers and
their supervisors should determine the appropriate impact level of each
change in which they are involved. Any unplanned change must comply
with the criteria for an emergency change described in the document
mentioned in this item.
10. The IT change manager, in concert with all board members, is expected
to identify and resolve any discrepancies in impact levels of changes.
11. Approvals for all types of changes must follow the procedures
developed and published by the CRB.
12. The change manager is responsible for compiling and distributing a
weekly report on change activity including the trending and analysis of
service metrics and process metrics.

Figure 2 Sample Policy Statements for Change Management
A recent client took this notion of policy statements a step further by tying the
compliance of change management policies to the performance review and raises of
affected managers. This may seem extreme to some, but it certainly resulted in full
observance of the organizations policies.
Step 12: Develop a Charter for a change review board (CRB).
The cornerstone of any change management process is the mechanism provided for the
review, approval, and scheduling of changes. In almost all instances this takes the form of
a change review board (CRB). Figure 3 shows a sample CRB charter. The charter for the
CRB contains the governing rules of this critical forum and specifies items such as
primary membership, alternates, approving or delaying of a change, meeting logistics,
enforcement, and accountability. During the initial meeting of the CRB, a number of
proposals should be agreed on including roles and responsibilities, terms and definitions,
priority schemes and associated actions, policy statements, and the CRB charter itself.
1. Review all upcoming high-impact change requests submitted to the
CRB by the change coordinator as follows:
o Approve if appropriate.
o Modify on the spot if possible, and approve if appropriate.
o Send back to requester for additional information.
o Cancel at the discretion of the board.
2. Review a summary of the prior weeks changes as follows:
o Validate that all emergency changes from the prior week were
legitimate.
o Review all planned change requests from the prior week as to
impact level and lead time.
o Bring to the attention of the board any unlogged changes.
o Bring to the attention of the board any adverse impact an
implemented change may have caused and recommend a final
disposition for these.
o Analyze total number and types of changes from the prior week
to evaluate trends, patterns, and relationships.
3. CRB will meet every Wednesday from 3:00 p.m. to 4:00 p.m. in room
1375.
4. CRB meeting will eventually become part of a systems management
meeting at which the status of problems, service requests, and projects
are also discussed.
5. Changes will be approved, modified, or cancelled by a simple majority
of the voting members present.
6. Disputes will be escalated to the senior director of the infrastructure
department.

Figure 3 Change Review Board Charter
A number of companies with whom I worked evolved the membership of their CRBs. In
most cases the first few meetings were attended by the CIO or the head of the
infrastructure. This naturally resulted in almost full attendance. After a month or two,
attendance may decline as executives start to delegate the conducting of the meeting to
the designated chairperson. This is where the policy statements come into play. Another
way to avoid this is to have the executives who attend at the start allow their chairperson
to actually run the meeting. That can be difficult for executives to do, but its effective at
giving the chairperson, and the meeting, much needed credibility.
Step 13: Use the CRB to Continually Improve the Change Management Process.
Some time should be set aside at every meeting of the CRB to discuss possible
improvements to any aspect of the change management process. Improvements voted on
by the CRB should then be assigned, scheduled for implementation, and followed up at
subsequent meetings. Small, quick wins should be publicized to show the progress of the
process.
Emergency Changes Metric
One of the most significant metrics for change management is the number of emergency
changes occurring each week, especially when compared to the weekly number of high-
impact changes and total weekly changes. There is a direct relationship between the
number of emergency changes required and the degree to which a shop is proactive. The
higher the number of emergency changes, the more reactive the environment. While
numbers will vary from shop to shop, in general, if you are executing more than four or
five emergency changes per week, your shop is more reactive than proactive. Just as
important as the raw numbers is the trending over time. As improvements to the change
process are put in place, there should be a corresponding reduction in the percentage of
emergency changes.
A few years ago a client of mine used only emails for his change management process.
He had no idea of how many emergency changes his staff was making because the data
was not collected. After a few weeks of tracking these numbers, we learned that almost
40% of his changes were of an emergency nature. After totaling overhauling his change
management process, he was able to reduce his emergency change ratio down to under
10%. He and his staff both noticed the subtle change of his environment from that of
reactive to proactive.
Assessing an Infrastructures Change Management Process
The worksheet shown in Figures 4 presents a quick and simple method for assessing the
overall quality, efficiency, and effectiveness of a change management process. For details
on the use of this worksheet, please refer to Assessing a Production Acceptance Process
in the Application Section of this reference guide.
Change Management ProcessAssessment Worksheet
Process Owner________________ Owner's Manager_________________ Date
________
Category Questions for Change Management Weight Rating Score
Executive
Support
To what degree does the executive sponsor
show support for the change management
process with actions such as attending CRB
meetings, analyzing trending reports, and
ensuring that applications, facilities, and
outside vendors use the CRB for all
changes?

Process Owner To what degree does the process owner
exhibit desirable traits and effectively
conduct the CRB and review a wide variety
of changes?

Customer
Involvement
To what degree are key customers involved
in the design of the process, particularly
priority schemes, escalation plans, and the
CRB charter?

Supplier
Involvement
To what degree are key suppliers, such as
technical writers and those maintaining the
database, involved in the design of the
process?

Service
Metrics
To what degree are service metrics analyzed
for trends such as availability, the type and
number of changes logged, and the number
of changes causing problems?

Process
Metrics
To what degree are process metrics
analyzed for trends such as changes logged
after the fact, changes with a wrong
priority, absences at CRB meetings, and late
metrics reports?

Process
Integration
To what degree does the change
management process integrate with other
processes and tools such as problem
management and network management?

Streamlining/
Automation
To what degree is the change management
process streamlined by automating actions
such as online submittals, documentation,
metrics, and training; electronic signatures;
and robust databases?

Training of
Staff
To what degree is the staff cross-trained on
the change management process, and how is
the effectiveness of the training verified?

Process
Documentation
To what degree is the quality and value of
change management documentation
measured and maintained?

Totals
Weighted Assessment Score = (TS/(SW*4)) =
(SW)

(TS)

Figure 4 Sample Assessment Worksheet for Change Management Process with
Weighting Factors
This concludes our three-part series on change management. As always, your comments
and own experiences are always welcomed.
References
2004


IT Management
Audit Reconnaissance: Releasing Resources Through
the IT Audit
This section of the IT Management Reference Guide was written by Jim Salladin.
They are not going away. As much as you wish it, as much as you dream of a world
without IT audits, they are coming. If you have recently gone through an audit, you know
that ignoring the findings just will not work. If you have not had the pleasure, now is the
time to prepare.
The business world is now inextricably linked to the IT world. We all know that
information systems are no longer peripheral to your business success; they are central to
the continuance and growth of your company. That is good news for job security, but it
means that IT will increasingly be in the cross hairs of risk managers and audit
committees. Sarbanes-Oxley, Gramm-Leach-Bliley, and other recent legislation only
further guarantee that no CIO or IT Director will escape talking to auditors.
But what if Audit was not a word of fear and dread? What possibilities could open up for
your IT department if instead of running from auditors, you understood them and forged
a mutually beneficial relationship? What would happen if you could leverage the
influence of the auditors to secure the required resources for the projects that just never
get done?
This section will not solve all of your audit problems, but I do want to point out a simple
resource that can help you move from being a reactive victim of the audit report to being
a proactive participant that leverages your audit findings to improve your IT
environment.
The suggestion is simple: research IT audit materials. I did not understand auditors until I
sat down and read some of their books. As I saw how the author explained IT concepts, I
began to understand their interests and how I could more productively communicate with
them. I know, reading their books and materials sounds like a ridiculous waste of time.
After all, you are not the one that needs to learn about IT; perhaps the auditors should
read some of your books. You may be right on that point. I am not suggesting that you
read their manuals so that you can learn about IT. I am suggesting that by reading their
books you will be able to get inside their minds, do a little reconnaissance work, and
discover ways to communicate more efficiently. With improved communication, you will
complete the audit more quickly and potentially use it to further the projects that are most
critical to your company. So, here are four benefits of reading IT audit manuals and
websites:
IT audit materials show you how auditors think and what they are
looking for.
Just like any relationship, a good experience with auditors will require good
communication. You will never communicate well with auditors until you learn how they
think. Generally, auditors have not taken the same classes you have. They probably did
not come up through the same ranks as those of you who are programmers or engineers.
When IT professionals think of the words Information Technology,their minds go to an
innovative world where business problems are solved in creative and nearly heroic ways.
When auditors think of the same words, their mind connotes a smorgasbord of risks. Each
one of these risks carries the potential of causing business failure. It is no wonder that
auditors and IT people seldom communicate as well as we would like. The auditor learns
the right questions to ask by reading and researching appropriate IT controls. Ask them
what their central resources are. What books have they read? What websites do they
use? What classes have they taken? What methodology guides them? If you can get a
hold on these resources, then you will know precisely how the auditor is thinking about
your IT environment. This will enable you to anticipate the questions and concerns. As
soon as you can anticipate your auditors concerns, you begin negotiating from a point of
strength.
IT audit materials will provide you a new vocabulary for you to
persuasively demonstrate your strengths.
Now that you understand their starting point, you can direct them to your areas of
strength. This is not about dishonesty or self-protection, it is about showing the auditors
that you are concerned about IT controls, that you have an awareness of the risk issues,
and that management takes this seriously. This will place the entire audit in the right
light. It will also help to establish a rapport between the auditor and the IT engineers. The
engineers need to know that the auditor is not out for blood, and the auditor needs to
know that the engineers are not clueless about the concept of IT controls. Once you have
highlighted these strengths, then lead the auditor to your weaknesses.
IT audit materials will enable you to point auditors to your weaknesses,
and secure more resources.
I know it goes against human nature, but in order to establish a good and mutually
beneficial relationship with auditors, you will need to demonstrate a transparent and open
attitude about the areas that require improvement. Remember, just as engineers and
programmers are trained to solve IT problems, the auditors are trained to sniff out
business problems. They produce findings with the same passion that you produce up-
time. As soon as auditors sense resistance or hear an adversarial tone, they will put on the
detective hat until all that is hidden is revealed. So rather than vainly trying to hide these
issues, expose them. But expose them with intentionality. Before you lead the auditor to
the issues, identify precisely what will be required to fix the problems. Do this with a
strategic mindset toward the future of your department. If you need more employees,
articulate the need when you expose the problem. If you need a new data center, include
it as a solution. In this manner you can transform your weaknesses into resources for the
future.
On-going relationship will shorten your audits.
The more you foster a close working relationship with your auditors, the less time you
will spend arguing back and forth with them. This will allow you to focus more energy
on what makes the company money. Of course, this will require more time on the front
end, and it will not eliminate the inevitable negotiations on the back end, but it will
streamline the process. Besides, if the audit report can become a resource provider for
you, it will be far easier to justify spending time talking to those who write it.
Given the fact that we cannot escape to a land without audits, it makes sense to prepare
for them. One of the best and easiest ways to do this is to research the same materials that
auditors are using. Identify one of your employees to be the designated audit contact, and
have that person read the auditors books and summarize the central concerns. Once you
have this report, sit down and strategize how you can leverage these concerns to highlight
your strengths and gather resources for your weaknesses. If we cannot escape audits, at
least we can leverage them to release resource. And the first step is as simple as a little
audit recon.
References
Here are a couple websites that will help jump-start your own research. Of course, the
most important thing is to find out what your auditors use for reference.
http://www.isaca.org/cobit.htm
http://www.coso.org


IT Management
Supplier Management
IT supplier management is the focus of this section. We begin with a discussion of
internal and external suppliers: how to identify these individuals, and, more importantly,
how and why to distinguish and limit them to only a handful of key suppliers.
During the summer and fall of 2004 Ill provide additional updates on supplier
management. These updates will include utilizing the synergy of multiple suppliers,
insourcing versus outsourcing, generating requests for services, evaluating and selecting
suppliers, managing supplier performance, and merging suppliers into the
customer/supplier matrix.

IT Management
Identifying Key External Suppliers
The first three steps to good supplier management are identifying all of your suppliers,
grouping them as external or internal, and delineating your key suppliers. While these
steps may sound like an easy and obvious starting point, its surprising how many shops
cannot adequately accomplish them. Rapid growth, acquisitions and mergers, and the
sheer number of suppliers and subcontractors can catch an IT organization off-guard in
terms of knowing the identity of all of their suppliers.
Its important to identify all suppliers because its impossible to manage the overall IT
environment effectively if some suppliers slip through bureaucratic cracks.
Unfortunately, such slippages are not uncommon. Robust change-management and
configuration processes can help significantly with identifying and managing all
suppliers.
Separating external suppliers from internal suppliers is necessary because different
processes are used to manage them. External suppliers usually revolve around contracts,
dealing with such issues as purchasing versus lease, single-year versus multiple year, sole
sourcing versus alternate sourcing, insourcing versus outsourcing, and a myriad of
maintenance and support options. IT personnel have a variety of alternatives to exercise
with supplier contracts. Managers can renew, modify, upgrade, downgrade, extend,
shorten, renegotiate, cancel, ignore, or bid on a contract. External suppliers include not
only hardware, software, and consulting companies, but facilitation companies, public
utilities, police and fire, business recovery services, and emergency response groups.
Once your external suppliers are identified, its worthwhile to designate those who are
considered key suppliersthose who feed into key processes. This identification is the
fourth element of good customer service, following the identification of key customers,
key services, and key processes, as shown in the following customer/supplier matrix.
Customers whose
use of IT services is
critical to their
success and whose
critical to a
customers success
and whose delivery
Processes that
produce the key
services required by
key customers
Suppliers who feed
into the key
processes
expectations are
reasonable
meets customer
expectations

References
Essentials of Supply Chain Management (John Wiley & Sons, 2003), by Michael H.
Hugos.


IT Management
Identifying Key Internal Suppliers
The preceding section described the importance of identifying all suppliers, the necessity
of separating external suppliers from those who are internal to an IT environment, and the
value of designating which external providers are considered to be key suppliers. This
segment complements that section by focusing on internal suppliers.
Key internal suppliers, similar to key external suppliers, are those individuals who
provide direct input, in terms of products or support, into key processes. As previously
mentioned, key processes feed into the key services of key customers. The
customer/supplier matrix below emphasizes the importance of the relationships between
key internal suppliers, key processes, key services, and key customers. As previously
mentioned, its impractical to interview hundreds of customers in order to improve the
quality of services. Similarly, its impractical to interview hundreds of suppliers to
improve the quality of processes. But we can interview a handful of key suppliers, and
this is normally all it takes to dramatically improve the efficiencies of processes.
Customers whose
use of IT services is
critical to their
success and whose
expectations are
reasonable
critical to a
customers success
and whose delivery
meets customer
expectations
Processes that
produce the key
services required by
key customers
Suppliers who feed
into the key
processes

We place much emphasis on the management of external suppliers, and appropriately so.
But this sometimes leads us to overlook or to deemphasize internal suppliers. Yet internal
suppliers residing within an IT department provide much of the quality of service that key
customers desire and demand. Key internal suppliers need to be held up to the same level
of scrutiny and accountability as key external suppliers. While we normally associate
legal contracts and negotiable provisions with an external supplier, there are other means
by which we can manage internal suppliers effectively. One of these means is the concept
of an operations-level agreement. This agreement is similar to a service-level agreement
with customers except that in this case the customer is the IT group responsible for
customer service, and the suppliers are the IT support groups.
Another set of often-overlooked key internal suppliers are those that provide services to
other departments within their own IT shop. One reason for overlooking this group is that
many IT departments concentrate so hard on supplying services to outside customers that
they forget about internal customers. It stands to reason that when one IT department
correctly identifies another as one of its key customers, then by definition the former
department is a key internal supplier to that department. An example is the database
administration group being a key internal supplier to the development group.
References
Essentials of Supply Chain Management (John Wiley & Sons, 2003), by Michael H.
Hugos.


IT Management
Application Management
This section discusses the various aspects of IT application management. It begins with a
thorough discussion of the production acceptance process, the method that robust
infrastructures use to deploy application systems into a production environment. The
reason this process is described first is because its initial steps begin at the initiation of a
new application.
The next three sections discuss the system development lifecycle (SDLC), the
fundamentals of project management, and the differences between these two. I will
provide these sections during June and July of 2004. These topics are of prime
importance to overall application management.
During the summer and fall of 2004 Ill supply additional sections on applications
management, including how to quantify the business value of applications; simple ways
to determine return on investment, cost benefit analyses, and breakeven points; basics of
building business cases; selecting the right database for a given application; utilizing
offshore programming; and generating and evaluating worthwhile documentation.


IT Management
Production Acceptance
No matter how well we design and test an application, the firstand often lasting
impressions that users form about that application come from how successfully we
deploy it into production. Developers and operations personnel sometimes let
unnecessary obstacles divert their focus from the goal of a successful deployment. This
section begins with a definition, from a management perspective, of the process of
production acceptance. It then describes many of the benefits such a process provides to a
variety of groups both inside and outside IT. Next I describe each of the 14 steps required
to design and implement an effective production acceptance process. The section
concludes with a guideline on the use of this process concerning new applications versus
new versions of existing applications.
Definition of Production Acceptance
The primary objective of systems management is to provide a consistently stable and
responsive operating environment. A secondary goal is to ensure that the production
systems themselves run in a stable and responsive manner. The function of systems
management that addresses this challenge is production acceptancea methodology to
consistently and successfully deploy application systems into a production environment
regardless of platform.
Several key words are worth noting. While the methodology is consistent, it's not
necessarily identical across all platforms. There are essential steps of the process for
every production deployment, and then there are other steps that can be added, omitted,
or modified depending on the type of platform selected for production use.
Deploying into a production environment implies that the process is not complete until all
users are fully up and running on the new system. For large applications, this could
involve thousands of users phased in over several months. The term application system
refers to any group of software programs necessary for conducting a company's business,
the end users of which are primarily (but not necessarily) in departments outside IT. This
rule excludes software still in development, as well as software used as tools for IT
support groups.
Benefits of a Production Acceptance Process
An effective production deployment process offers several advantages to a variety of user
groups. The following table lists the beneficiaries of production acceptance and the
specific benefits they acquire.
Beneficiaries and Benefits of Production Acceptance
Beneficiary Benefits
Applications Ensures that adequate network and system capacity is available
for both development and production
Identifies desktop upgrade requirements in advance to ensure
sufficient budget, resources, and timeframe
Specifies detailed hardware and software configurations of
both the development and production servers to ensure that
identical environments are used for testing and deployment
Ensures that infrastructure support groups (systems, networks,
solution center) are trained on supporting the application weeks
prior to cutover
Executive
Management
Quantifies total ongoing support costs prior to project startup
Reduces overtime costs by identifying upgrade requirements
early
Increases the likelihood of deploying production systems on
schedule by ensuring thorough and timely testing
Infrastructure Identifies initial system and network requirements early on
Identifies future infrastructure requirements, enabling more
cost-effective capacity planning
Identifies ongoing support requirements early on
Customers Involves customers early in the planning phase
Ensures that customer equipment upgrades are identified early
and scheduled with customer involvement
Ensures satisfactory user testing
Suppliers Involves key suppliers in the success of the project
Identifies and partners key suppliers with each other and with
support groups
Provides suppliers with opportunities to suggest improvements
for deployment

Steps To Implementing a Production Acceptance Process
The following 14 steps describe how to implement a world-class production acceptance
process. These steps are based on actual industry experience and entail many of the best
practices associated with this type of process. This procedure is applicable to IT
organizations of various sizes, scopes, and platforms.
1. Identify an executive sponsor. Production acceptance is one of a handful of
systems management processes that directly involve departments outside the
infrastructure group. In this case, the applications development area plays a key
role in making this process effective. An executive sponsor is necessary to ensure
ongoing support and cooperation between these two departments. Depending on
the size and scope of the IT organization, the sponsor could be the CIO, the head
of the infrastructure group, or some other executive in the infrastructure.
We should note that an application manager could be an excellent sponsor,
provided that the head of the infrastructure agrees with the selection. In this case,
executives from both the applications and infrastructure departments should
concur on the choice of process owner, who needs to be from the infrastructure
group.
In general, the higher the level of executive sponsor, the better. Senior executives
have less available time than managers at lower levels, so you should plan support
sessions well to ensure that they are straightforward and to the point.
The executive sponsor must be a champion of the process, particularly if the shop
has gone many years with no structured turnover procedure in place. He or she
needs to persuade other executives both inside and outside IT to follow the lead.
This individual is responsible for providing executive leadership, direction, and
support for the process. The executive sponsor is also responsible for selecting the
process owner, for addressing conflicts that the process owner cannot resolve, and
for providing marketing assistance.
2. Select a process owner. One of the first responsibilities of the executive sponsor
is to select the production acceptance process owner. The process owner should
be a member of the infrastructure organization, because most of the ongoing
activities of operating and supporting a new production application fall within this
group. This person will be interacting frequently with programmers who
developed and will be maintaining the system.
This continual interaction with applications makes a working knowledge of
application systems an important prerequisite for the process owner. Being able to
evaluate applications documentation and to communicate effectively with
program developers are two additional characteristics highly recommended in a
process owner. These attributes and priorities may vary from shop to shop, but
should emphasize the importance of predetermining the traits that will suit your
organization best.
3. Solicit executive support. Production acceptance requires much cooperation and
support between the applications development and infrastructure departments.
The executive sponsor should solicit executive support from both of these
departments to ensure that senior levels of management support and push down
policies, and that decisions about the design of the process are backed up and
pushed down from higher levels of management.
4. Assemble a production acceptance team. The process owner should assemble a
cross-functional team to assist in developing and implementing a production
acceptance process. The team should consist of key representatives from the
development organization as well as those from operations, technical support,
capacity planning, the help desk, and database administration. In cases where the
development group is larger than a few hundred programmers, multiple
development representatives should participate.
Its important that the cross-functional team represent all key areas within
development to ensure support and buy-in for the process. Appropriate
development representatives also ensure that the team identifies potential
obstacles to success and resolve them to everyones satisfaction. An effective
executive sponsor and the soliciting of executive support (steps 1 and 3) can help
to ensure proper representation.
At one company where I managed a large infrastructure group, there were more
than 400 programmers in the development department, grouped into the areas of
finance, engineering, manufacturing, and logistics. A representative from each of
these areas participated in the development of a production acceptance procedure;
each brought unique perspectives, and together they helped to ensure a successful
result to the process.
5. Identify and prioritize requirements. Early in my career, I participated on a
number of production acceptance teams that fell short in providing an effective
production turnover process. In looking for common causes for these failed
attempts, I noticed that in almost every case there were no agreed-upon
requirements at the start; when requirements did exist, their originators seldom
bothered to prioritize them. Later on, as I led my own production acceptance
design teams, I realized that having all participants agree on and prioritize their
requirements added greatly to the success of the teams.
6. Develop policy statements. The cross-functional team should develop policy
statements for a production acceptance process that the executive sponsor
supports and approves. This will help to ensure that compliance, enforcement, and
accountability will be issues that senior management supports and communicates
to the applicable levels of staffs.
7. Nominate a pilot system. When a cross-functional team designs and implements
a production acceptance process, particularly in environments that have never had
one, there is normally a major change in the deployment of application systems.
Therefore, its usually more effective to introduce this new method of production
turnover on a smaller scale with a minimal-impact pilot system. If a small system
is not available as a pilot, consider putting only an initial portion of a major
system through the new process.
8. Design appropriate forms. During the requirements step, the cross-functional
team will normally discuss the quantity, types, and characteristics of forms to be
used with a production acceptance process. Some shops elect to combine some or
all of these forms, depending on their complexity. The team proposes, designs,
and finalizes the forms. Specific requirements of the forms vary from shop to
shop, but the forms should always be simple, thorough, understandable, and
accessible. Many shops today keep forms like these online via their company
intranet for ease of use and access. The following figures show an example of a
three-page form used by two of my clients after implementing a production
acceptance process. The form outlines actions required during stages leading up to
the deployment process.
Figure 2a Figure 2b Figure 2c
9. Document the procedures. The documentation of any systems management
process is important, but its especially so in the case of production acceptance
because a large number of developers will be using it. The documentation for
these procedures must be effective and accessible.
10. Execute the pilot system. After the process design team identifies the pilot,
designs the forms, and puts appropriate procedures in place, its time to execute
the pilot system. User testing and acceptance plays a major role in this step, as
does the involvement of support groups such as technical support, systems
administration, and the help desk.
11. Conduct a "lessons learned" session. In this step, the process owner conducts a
thorough, candid "lessons learned" session with key participants involved in
executing the pilot system. Participants should include representatives from the
user community, development area, support staff, and help desk.
12. Revise policies, procedures, and forms. The recommendations resulting from
the "lessons learned" session may include revisions to policies, procedures, forms,
test plans, and training techniques for users and support staff. The entire cross-
functional team should agree to these revisions and implement them prior to full
deployment.
13. Formulate a marketing strategy. Regardless of how thoroughly and effectively
a cross-functional team designs a production acceptance process, it does little
good if development groups dont support and apply the process. Once the final
policies, procedures, and forms are in place, the process owner and design team
should formulate and implement a marketing strategy. The marketing plan should
include the benefits of using the process; the active support of the executive
sponsor and peers; examples of any quick wins as evidenced by the pilot system;
and testimonials from users, help desk personnel, and support staff.
14. Follow up for ongoing enforcement and improvements. Improvement
processes such as production acceptance often enjoy much initial support and
enthusiasm, but that enjoyment is sometimes short-lived. Changing priorities,
conflicting schedules, budget constraints, turnover of staff or management, lack of
adequate resources, and a general reluctance to adopt radically new procedures all
contribute to the de-emphasis and avoidance of novel processes. One of the best
ways to ensure ongoing support and consistent use is to follow up with reviews,
postmortems, and "lessons learned," to constantly improve the overall quality,
enforcement, and effectiveness of the process.


IT Management
Distinguishing New Applications from New Versions of
Existing Applications
Users of a new process understandably will have questions about when and how to apply
it. One of the most frequent questions I hear asked about production acceptance is this:
Should we use it only for new applications, or is it also for new versions of existing
applications? The answer lies in the overall objective of the process that is to consistently
and successfully deploy application systems into production.
A new version of an existing application will often have major changes that affect
customers and infrastructure groups alike. In this case, deploying it into production will
be very similar to deploying a new application. The process owner should ensure that
appropriate IT staff members have developed test plans, formulated customer acceptance
pilots, and identified capacity requirements well in advance. The guideline for deciding
when to use production acceptance is this: Determine how different the new version of
the system is from its predecessor. If users, support staff, and help desk personnel are
likely to experience even moderate impact from a new version of an existing application,
the production acceptance process should be used.


IT Management
Assessing a Production Acceptance Process
Over the years, many clients have asked me for a quick and simple method to evaluate
the quality, efficiency, and effectiveness of their systems management processes. In
response to these requests, I developed the assessment worksheet shown in the following
figure. It evaluates the robustness of a process, with a perfect score being 100%. This
particular assessment worksheet is for a production acceptance process. In later additions
to this guide, Ill provide similar worksheets that I have customized to fit each of the other
processes of systems management.
Figure 3
Process owners and their managers collaborate with other appropriate individuals to fill
out this form. Along the left-hand column are 10 categories of characteristics about a
process. The degree to which each of these characteristics is put to use in designing and
managing a process is a good measure of its relative robustness.
The categories that assess the overall quality of a process are executive support, process
owner, and process documentation. Categories assessing the overall efficiency of a
process consist of supplier involvement, process metrics, process integration, and
streamlining/automation. The categories used to assess effectiveness include customer
involvement, service metrics, and the training of staff.
The evaluation of each category is a very simple procedure. The relative degree to which
the characteristics within each category are present and being used is rated on a scale of 1
to 4, with 1 indicating no presence and 4 being a large presence of the characteristic.
Although the categories are the same for each of the processes, the type of specific
characteristics within each category varies from process to process. I address these
differences by customizing the worksheet for each process being evaluated.
In my experience, many infrastructures dont attribute the same amount of importance to
each of the 10 categories within a process, just as they dont all associate the same degree
of value with each of the 12 systems management processes. I refined the assessment
worksheet to account for this uneven distribution of category significanceI allowed
weights to be assigned to each of the categories. The weights range from 1 for least
important to 5 for most important, with a default of 3.
We calculate the assessment score as follows. The weight for each category is multiplied
by its rating to produce a final score. For example, if the executive support category is
weighted at 3 and rated at 2, its final score would be 6. We generate scores for the other
nine categories in a similar manner and sum the numbers in each column. We refer to the
sum of weights in the first column as the sum weight (SW). We next multiply the SW by
the maximum rating score, in this case 4. We call the product of SW*4 the maximum
weighted score (MWS). The MWS obviously varies as we change the weights of
different characteristics. Finally, we take the sum of ratings from column 3 (total score or
TS) and divide it by the MWS to produce our overall assessment score. For example, if
our sum of weights is 30 (MWS=120) and our sum of ratings is 90, the overall
assessment score will be the quotient of 90/120, or 75%.
Apart from its obvious value of quantifying areas of strength and weakness for a given
process, this rating provides two other significant benefits to an infrastructure:
It serves as a baseline benchmark from which future process refinements can be
quantitatively measured and compared.
The score of this particular process can be compared to those of other
infrastructure processes to determine which ones need most attention.
We can use the assessment worksheet to pinpoint areas of concern and to measure
amounts of improvement. For example, we can measure the effectiveness of a production
acceptance process with service metrics such as the amount of positive feedback from
users and the number of calls to the help desk immediately after deployment. Process
metricssuch as the frequency and duration of delays to deployment and the accuracy
and timeliness of documentation and traininghelp us gauge the efficiency of the
process. And we can streamline the production acceptance process by automating certain
actions such as the documentation of a new application and online training for it by
means of the intranet.


IT Management
Organization and Personnel Management
This section discusses how to organize an IT department and the management of the
personnel within such a department. The first section describes how to optimize various
organizational structures commonly found in a typical IT department.
Future updates to this guide will provide additional sections on organization and
personnel management and will include topics such as knowing when to organize by
function or by process, practical tips to retaining key personnel, the pros and cons of
using contractors, when to use contractors versus consultants, methods and value of skill-
set inventories, relative worth of degrees and certifications, methods of training managers
and technicians, implementing comprehensive career development, basic steps for
succession planning, recognizing and correcting problem behaviors, and effective
recognition and reward programs.


IT Management
Optimizing IT Organizational Structures
This section describes how to optimize various organizational structures found in a
typical IT department. A properly structured IT department has more effective
communication, higher productivity, more thorough planning, and a clearer
understanding of roles and responsibilities. A poorly structured IT organization can result
in just the opposite effects.
This topic begins with a discussion of three key factors that influence the decisions on
which potential reorganizations are based. Next, it identifies four key departments within
an IT infrastructure that may be located in various alternative areas within their
organization. Finally, this section describes the advantages and disadvantages of the
various restructuring alternatives for each of the four identified departments.


IT Management
Factors That Influence Restructuring Decisions
There are three key factors on which IT managers normally base their restructuring
decisions: departmental responsibilities, planning orientation, and infrastructure
processes. These factors tend to follow the normal evolution of an IT organization from
company startup to full corporate maturity. During a corporations early building years,
IT usually structures its organization into the two major departmental responsibilities of
applications development and infrastructure operations.
As the departmental responsibilities in these two groups continue to grow, the
applications department typically splits into application development and application
maintenance. The infrastructure department organizes itself between technical and
network services, and computer operations. As the company and the IT department both
mature, IT may add an administration department to its organization. Later, IT may add
planning to its charter of responsibilities. This is a key event because it marks the first
formal initiation of a planning responsibility within IT, although much of its early
emphasis will be on tactical, short-term planning.
As the company and the IT organization both continue to grow, the planning orientation
within the IT group will gradually shift from that of tactical to strategic planning.
Eventually, all strategic planning activities can be centralized in a separate department.
Over time, this department will likely subdivide into two groups along the lines of
business requirements planning and IT architecture planning. The ongoing growth of the
company and its customers would cause the applications, infrastructure, and
administration departments to similarly subdivide into dedicated groups. A final
modification to the IT organizational structure is the alignment of the applications areas
along business units. The intent of this increasingly popular refinement is to foster greater
empathy between end users and developers, as well as to increase their understanding of
user requirements. At this stage of a companys maturity, the IT organizational structure
is based on the two factors of departmental responsibilities as well as planning
orientation.
A third factor that influences IT departmental design is how the responsibility for
infrastructure processes integrates into the organizational structure. This often results in
the reorganizing of infrastructure departments. Few employees enjoy departmental
restructuring, and personnel working in IT are no exception. Although IT infrastructure
professionals are involved in one of the most rapidly changing of technical industries,
they still tend to be creatures of habit who, like everyone else, prefer stable and
unchanging environments.
But in the case of IT, restructuring is often necessary to support company growth,
increased customer demand, changing business requirements, acquisitions, mergers,
buyouts, or other industry changes. There are various ways to organize an infrastructure,
and no single structure applies optimally to all situations. This is partly because factors
such as size, maturity, and orientation of a firm and its IT organization vary widely from
company to company and directly influence how best to design the IT infrastructure.
Where some enterprises may combine the voice and data network groups, others may
keep them totally separate. Some firms incorporate IT-wide functions such as security,
planning, quality assurance, procurement, and asset management directly into the
infrastructure organization, while others keep these functions outside the infrastructure.
Often, the organizational position of a department can play an important role in
distinguishing a world-class IT organization from a mediocre one. Six departments where
this is particularly the case are the help desk, database administration, network
operations, web design, risk management, and systems management. The following four
sections examine the organizational reporting of each of these four areas.


IT Management
Alternative Locations for the Help Desk
The proper locationof the help desk is critical to the success of almost any IT
infrastructure. There are many reasons, but paramount is that the level 1 help desk is the
first encounter most users have with an IT organization. Placing the help desk higher in
the organization or merging it with other help desks can increase its effectiveness,
visibility, and stature.
The initial impression that customers form when they first dial the help desk number is
often long-lasting. Help desk specialists refer to this critical interaction as the moment of
truth: the point at which customers form their initial, andin the case of poor
encountersoften irreversible, opinions about the quality of IT services. The number of
rings before answering, the setup of the menu system, and especially the attitude of the
help desk agent responding to the caller are all factors that influence a user's perception
of the effectiveness of a help desk.
Another reason that the location of the help desk is so important is that it defines to what
degree multiple help desks may eventually integrate into fewer help desks, or into one
fully integrated help desk, usually referred to as a Customer Service Center (CSC).
During periods of initial growth, many IT organizations increase the number of help
desks in response to expanding services and a growing user base. One well-known
company had seven help desks: applications, operations, desktop support, technical
services, database administration, data network services, and voice network services. A
consultant specializing in this area assessed the feasibility of integrating some or all of
these help desks into a much smaller quantity. After assembling a cross-functional team,
this individual worked with team members to design and implement a single, totally
integrated help desk or CSC. Much discussion centered on where to locate this new
centralized help desk. Some thought it best to have it outside the infrastructure, or to
outsource it, but the majority saw more benefits with regard to control, staffing, and
measurement by keeping it within the infrastructure.
Some of the team members suggested that it go under computer operations in the
structure. The strongest argument for this alternative was that computer operations was
the only other group at the time being staffed 24/7 and this was the direction the team
wanted to take the CSC. But most of the calls coming into the CSC were desktop-
oriented rather than computer operationsoriented. In the end, the team elected to locate
the CSC in the infrastructure as a peer to the desktop support department. A major
advantage of this configuration was that it put the level 1 (CSC) and level 2 (desktop
support) support groups in the same organization. This structure facilitated handoffs
between levels 1 and 2, drastically cut down on the finger-pointing between these two
groups, and held each of them to higher levels of accountability.


IT Management
Alternative Locations for Database Administration
Many IT shops locate their database administration group in the applications
development department. The argument here is that the structure and design of the
database is more closely aligned to the requirements of the users with whom the
applications group works directly. But once database administrators define and design the
database, most of the ongoing maintenance involves performance and tuning issues; these
issues align themselves more with the technical services group in the infrastructure.
Some IT organizations have the database administration group reporting directly to the
head of the infrastructure group, but this normally works successfully only when the
database unit is unusually large and most mission-critical applications are running on
sophisticated databases. Another alternative that can work well with large database
administration groups is to put the architecture portion of the group (which is primarily
strategic and user-oriented) in the applications development group, and put the
administration portion (which is primarily tactical and technically oriented) in the
infrastructure's technical services group.


IT Management
Alternative Locations for Network Operations
The network operations group might seem to belong in the network services department.
After all, both groups are involved with providing reliable, responsive, real-time network
services. It makes perfect sense to initiate this type of network organization during the
startup of an IT department. But as the network operations group grows, and particularly
as network and computer operations assume critical 24/7 responsibilities, one could build
a compelling case to have network operations report to computer operations. Both groups
have around-the-clock monitoring and troubleshooting responsibilities; both can benefit
technically from cross-training each other; and both could give each other more backup
support. I recommend that IT organizations with mature infrastructures locate their
network operations group within computer operations.


IT Management
Alternative Locations for Web Design
The web design team is a relatively new organizational entity in many IT shops. Ten
years ago it was barely in existence; five years ago it was present mostly in dotcom and
startup companies. Today, the web design team is a major force in most IT environments.
The reporting structure of the web design team seems to change as both the company and
its IT organization mature. I have seen web designers initially report to the marketing
department, when the web team serves as little more than a public relations group. As the
responsibilities of the web designers expand to include intranets and extranets, the web
group sometimes moves over to the infrastructure group or to a middle-tier support
group.
More often than not, when e-commerce (the exchange of monies online) becomes part of
the web design team, the team finds its final resting place in the applications development
group. This seems to be an appropriate place in the IT organization for the web design
team, as it emphasizes more programming skills to meet the demand for interactive
content.


IT Management
Alternative Locations for Risk Management
Today's emphasis on business continuity, disaster recover, contingency planning, and
emergency response all require a strategic placement of risk management within a
corporation. The reporting structure varies among industries, depending on their core
business. In defense contracting, risk management is often placed within or closely
aligned to the IT department because the critical nature of information security is one of
the major risks continually assessed and managed. This is especially true when a
company deals with large amounts of classified, encrypted data.
Other industries such as banking usually place risk managementand its associated
departments of business continuity and information securityoutside IT. This design
separates the policy and procedure aspects of risk and security from IT's day-to-day
operation of information security administration. This structure eliminates the so-called
"fox guarding the henhouse syndrome" by ensuring that security audits, compliance, and
enforcement are keep separate from those engaged in the tactical activities of security
administration.


IT Management
Alternative Locations for Systems Management
The existence and location of a systems management group is one of the key
characteristics that make an infrastructure world-class. Many shops don't include such a
dedicated process group within their infrastructure, but those that do usually benefit from
more effective management of their key processes. The systems management group is a
separate department, solely responsible for those infrastructure processes determined to
be most critical to a particular IT environment. At a minimum, these processes include
change management, problem management, and production acceptance. Depending on
the maturity and orientation of the infrastructure, additional systems management
processessuch as capacity management, storage management, security, and disaster
recoverymay be part of this department.
This department usually reports to one of three infrastructure groups, depending on the
processes receiving the most emphasis:
When change management or production acceptance is the key process, this group
often reports to computer operations.
In a traditional mainframe environment, this department would have been called
production support and could have included batch scheduling, batch processing,
and output processing.
When problem management is the key process, this group usually reports to the
customer services or help desk department.
In a world-class infrastructure, a single systems management group is responsible for
managing all of the key infrastructure processes. Normally, this group reports directly to
the head of the infrastructure. This arrangement gives systems management the visibility
and executive support it needs to emphasize integrated process management.


IT Management
Practical Tips To Retaining Key Personnel
The competition for retaining highly skilled technicians has always been keen, and it will
only grow more intense as technical specialties such as network engineering, Internet
security, and website management continue to evolve. Traditional incentives such as
salary and vacation time are no longer the only factors that highly sought-after IT
professionals consider when considering to stay or leave for new employment
opportunities. As this section points out, dozens of other factors that come into play when
employers attempt to attract and retain the best of the best.
Once a key candidate has been found, been offered employment, and has accepted, the
challenge of staffing now shifts to retaining this person, along with all the other highly
talented personnel. IT departments and human resources groups have been struggling
with this phenomenon for years. As a result, some creative approaches have been used to
stem the tide of turnover and attrition.
Some of these new approaches involve creative compensation such as supplying
personnel with free cell phone use, remote Internet access from home, laptop computers,
or generous mileage compensation. Recent research suggests that several non-monetary
factors often come into play as much as the quantity of pure cash salary. These include
the amount of on-the-job training to be provided, the currency of technology used,
attendance at conferences and seminars, the meaningfulness and significance of the work
being performed, the likelihood of promotions, and the stability of the management staff.
More often than not, skilled technical professionals will change jobs because of some key
ingredient missing in the relationship they have with an immediate manager. We have all
heard the emphasis on the importance of communication, but it is hard to overstate its
significance. Over the years I have come to know several highly skilled IT professionals
who left an otherwise excellent job opportunity simply because of poor communication
with their managers. Lack of recognition, little career planning, and inability to convey an
organizations vision, direction, and goals are some other common reasons employees
give when discussing a poor management relationship.
A few years ago I headed up an outsourcing effort at a major entertainment company.
One of the unfortunate circumstances of the project was that a number of good employees
would need to be terminated and then re-hired by the prospective outsourcer. To mitigate
the adverse effect of this displacement, we requested that each prospective outsourcing
bidder itemize the employee benefits that they would offer to our former employees. The
quantity and quality of these benefits would become part of our evaluation criteria in
selecting an eventual winner of the contract.
To ensure that we were evaluating the proposed benefits appropriately, I also worked
with our human resources department to survey our employees to determine which
benefits meant the most to them. We jointly comprised what we all felt was a
comprehensive list of typical employee benefits, including those that would likely come
into play during a change in companies. We then asked each employee to indicate the
level of importance they would give to each benefit. The rating was to be made on a 1 to
5 basis where 5 indicated the most important and 1 the least important.
The results of the employee benefit survey were surprising, even to some of the more
seasoned human resources representatives. The responses provide some interesting
insight as to where employee priorities truly lie. Table 1 shows the results of the survey.
The benefits are ranked from most important to least important and the average scores of
each. As you can see, salary was not the highest priority benefit, although it was close to
the top. Medical care was first.
Table 1 Survey of Traditional Benefits for Employees
Rank Benefit Score
1 Medical coverage 4.76
2 Dental coverage 4.59
3 Base salary 4.53
4 Training in client-server 4.24
5 Vacation 4.24
6 Vision care 4.12
7 Career advancement 4.12
8 Company matching 401K 4.06
9 Training in networking 4.06
10 Sick leave 4.00
11 Proximity to home 3.88
12 Medical leaves 3.71
13 Training in
PCs/intranet/Web
3.65
14 Flexible work hours 3.53
15 Flexible work week 3.47
16 Training in operations 3.12
17 Personal leaves 3.12
18 Personal Time Off 3.06
19 Compensation time for 2.65
overtime
20 Distance to workplace 2.65
21 Opportunity for overtime
pay
2.47
22 Van pools or car pools 2.35
23 Bonuses 2.29
23 Absence of overtime 1.17

Even more surprising was the list of additional benefits that we asked employees to
propose. We felt we had compiled a fairly thorough list of traditional benefits and were
not expecting to receive more than two or three newly proposed benefits. As shown in
Table 2, we underestimated the creative talents of our staff as they proposed an additional
13 benefits. The suggestions also surprised our human resources representatives who
admitted that these types of responses were not what they expected and caused them to
re-think some of their recruitment and retention strategies.
Table 2 Additional Employee Benefits Proposed by Employees
Rank Benefit Score
1 Long-term disability 6
2 Life insurance 5
3 Floating or additional holidays 4
4 Bereavement leave 4
5 Direct deposit of paycheck 4
6 Pension plans 3
7 Attendance at conferences 3
8 Education reimbursement 3
9 Early retirement 2
10 Quality management 2
11 High degree of teamwork 1
12 Respect for all ideas and abilities 1
13 Training in mainframes 1

The main lesson learned here is that key employees may have totally different reasons for
staying with or leaving a particular company. The only certainty in this very un-precise
science is that until you ask, you likely never know. Finding out too late is an
unnecessary mistake that effective managers try to avoid. I have yet to meet the employee
who becomes upset when a manager asks him or her what would it take to get them to
stay.
References
Kern, Harris., Galup, Stuart., Nemiro, Guy, IT Organization: Building a Worldclass
Infrastructure, Prentice Hall, 2000


IT Management
Benefits and Drawbacks of Using IT Consultants and
Contractors
This section describes the benefits and drawbacks of utilizing IT consultants and
contractors. Events not directly related to the IT industry periodically occur that influence
the use of these IT specialists. The onset of the new millennium a few years back was one
such event. The current legislation of Sarbanes-Oxley is another such entity. This
segment will examine the advantages and disadvantages of bringing in consultants and
contractors to help meet these challenges.
Benefits of Using Consultants and Contractors
One immediate benefit of using consultants and contractors is that they provide readily
available technical expertise. Since they are under contract, you pay for only the time
they expend. As the demand for IT services continues to increase, it often becomes
difficult, if not impossible, to attract and retain skilled, knowledgeable, and highly
motivated personnel. This requirement becomes even more challenging as the diversity of
IT environments continues to grow. Shops are migrating from one hardware platform to
another or from one software architecture to anotherbe it applications, databases, or
operating systemsat ever increasing rates. In the midst of these many transitions, there
often may not be the necessary level of technical expertise onboard at the time to perform
the migration, support, or maintenance of these systems. Highly specialized consultants
can help alleviate this by the providing technical expertise needed in these diverse areas.
In addition to technical expertise, consultants can also provide management and financial
expertise. The recent Sarbanes-Oxley legislation that dictates extensive financial controls
are in place put increased emphasis on ensuring IT financial systems comply with
regulatory requirements. Many companies are bringing in consultants from major
accounting firms to ensure the company's systems are in compliance.
Another benefit that consultants and especially contractors offer to an enterprise is that
they can assist in accelerating critical development schedules. The schedule to implement
some major applications is often dictated by specific needs. For example, a critical
distribution system in a major toy company may have been cost justified based on its
absolute time deadline of being able to meet the Christmas rush. New systems that were
designed to correct the year 2000 software problem obviously had to be in place prior to
the start of the new millennium. Organizations may have the necessary quality of skilled
employees onboard, but simply not an adequate quantity of them to meet critical
schedules. In these instances, consultants and contractors may quickly be brought in to
assist in keeping projects on schedule.
One of the most highly publicized examples of an IT development effort missing its
critical deadline involved the Hershey Chocolate Corporation. A totally new and highly
advanced distribution system was slated to be implemented during the summer of 1999.
Teams of consultants and contractors were brought in to assist in this effort, but a series
of missteps undermined the progress of the project. Unanticipated problems, untimely
miscommunications, and a possibly overaggressive deployment plan all contributed to a
six-month delay in the launch of the system. Unfortunately for Hershey, the majority of
their annual sales comes during the month of October in preparation for Halloween. The
system was eventually implemented successfully, but long after the lucrative holiday
buying season, costing Hershey a substantial amount of lost sales.
Drawbacks of Using Consultants and Contractors
One of the primary drawbacks of using consultants and contractors is their high cost in
relation to onboard staff. The rates of critically skilled consultants from key suppliers or
major accounting firms can easily exceed multiple thousands of dollars per day per
individual. But if the need is of a high enough urgency, expense may not be a prime
factor.
Another drawback that occasionally occurs in larger shops is that it has an adverse effect
on employee morale. Consultants and contractors who are highly skilled in a critical
technical area may dismiss the need to be good team players. Their extremely high rates
may justify in their minds the insistence for priority treatment in order to optimize their
time on the clock. Thorough interviewing and reference checks can usually mitigate this
concern.
Since most consultants and contractors bill on an hourly or daily basis, there is always the
concern that some may not work as efficiently as possible. The more time a consultant
spends translates into more revenue earned. Three areas that are prone to inefficiencies
are email, voicemail, and meetings. Email is an excellent mechanism for distributing
simple, one-way information to many recipients. It typically does not lend itself to
activities such as brainstorming, problem solving, or personnel issues where tone,
emotion, and reactions can easily be misinterpreted. When consultants or contractors
engage in these latter activities instead of using email, a task that may have taken only a
few hours can often drag on for days or even weeks.
Voicemail is another area where consultants and contractors can be inefficient. They
neglect to employ a simple technique of leaving detailed messages on voice mail about
the nature of the call when a called party is not available and instead ask only to have the
call returned. This usually results in numerous rounds of time-wasting telephone tag.
Efficiency-minded consultants and contractors often can actually resolve issues with
voicemail by simply providing specific questions, information, or responses.
Meetings can be time wasters for consultants and contractors from two standpoints. The
first is simple mismanagement of meetings. Commonly accepted meeting practices such
as advance online invitations, an agenda, objectives, action items, minutes, and the use of
a scribe, timekeeper, and facilitator can significantly improve a meetings efficiency and
effectiveness. Although contractors, and especially consultants, need to conduct
numerous meetings as part of the performance of their duties, few follow many of the
common meeting practices described above. The second way to waste time with meetings
is to hold them when not needed. Often a brief face-to-face discussion or even a
telephone call may accomplish the same result as a costly and time-consuming meeting.
A final drawback of using consultants and contractors is the issue of hidden costs. The
total cost of employing a consultant or contractor is not always apparent when the initial
contract is drawn up. Some of these hidden costs include costs for office space, parking,
and long distance telephone use. Most consultants today have their own laptop computers
or access to a desktop. But an independent contractor who is employed primarily to do
coding work may require access to a company desktop computer, login authority to the
company network, and printing services. All of these activities require setup time,
administration work, and other expenses not specifically spelled out in the initial contract.
Table 1 summarizes the benefits and drawbacks of using consultants and contractors.
Table 1. Summary of Benefits and Drawbacks of Using Consultants and
Contractors
Benefits Drawbacks
Immediate availability
Pay only for effort
expended
Ability to accelerate
schedules
Can supply rare or
unique technical
expertise
High costs
Potential source of
morale problems
Occasional
inefficiencies
Hidden expenses

References


IT Management
Deciding Between the Use of Contractors versus
Consultants
As mentioned in the previous section, another alternative available to infrastructure
managers needing to fill critical IT positions is the use of consultants and contractors.
Their use in IT environments in general, and in IT infrastructures in particular, is
increasing at a rapid rate for a variety of reasons. Technical specialization, accelerated
time-tables for vital projects and recent legislation such as Sarbanes-Oxley are fostering
the use of consultants and contractors.
Other factors such as outsourcing, company downsizing, acquisitions and mergers, and
global competition are leading to significant reductions in full-time IT staff. This trend
toward reduced IT staffingespecially in larger, more established shopsis also feeding
the supply of ready consultants. Many of the previously displaced IT personnel elect to
become independent consultants. Frequently many of these former workers enter into
service contracts with their previous employers. Others market their skills to companies
with IT environments similar to their previous company to ensure a good fit between the
skills they can offer and the technical requirements needing to be met.
The explosive growth of the World Wide Web and the flood of Internet start-up
companies have also contributed to unprecedented demand for IT consulting services.
Integrating dissimilar architecturesdatabase software, desktop operating systems, and
networking technologies, for exampleoften requires specialized skills. In many cases
managers find it easier to contract with a consultant for these specialized skills than to
attempt to grow them from within. A heightened awareness of the benefits of new,
replaced, or migrated systems is pushing implementation schedules forward. Accelerated
schedules are well suited for the immediate availability and short-term commitments
offered by consultants and contractors. The shortened project life cycles of open system
applications, the rapid deployment of Web-enabled systems, and the intensifying of
global competition are some of the forces at work today that fuel this demand for
accelerated implementations.
Consultants come in a variety of types, and they contrast slightly with the notion of a
contractor. Understanding the differences between the two can help ensure a better fit
between the skills being offered and the business requirements needing to be met. The
term consultant normally refers to someone hired to do an analytical task such as a
capacity study, a security audit, or a re-engineering assignment. This contrasts with the
term contractor which generally refers to someone hired to perform a more specific task
such as coding an interface or developing a software enhancement.
Consultants are commonly supplied from one of the major accounting firms or from
major computer hardware or software suppliers. Contractors, on the other hand, are more
likely to come from software development companies or are in business for themselves.
Consultants tend to be oriented toward issues of strategy, service process, and
management. Contractors tend to be oriented towards issues of coding, documentation,
technology, and deliverables. These orientations then determine the specific type of
consultant or contractor to be hired.
Knowing the specific type of person to be hired helps in one other important areathat
of teaming with onboard employees. For example, a consultant hired to develop IT
customer service levels needs to show empathy toward the customers that he or she is
dealing with. Similarly, a contractor hired to work with an existing team of onboard
developers needs to be able to fit in with the members of the group. In this case, a
reference check or two from recent previous employers may prevent potential personnel
issues in the future with current full-time staff. This is particularly important if the
engagement is likely to be long-term, and involves much interaction between the
contractor and employees and users.
References


IT Management
Asset Management
This section describes the various aspects of IT asset management. It begins by
discussing the management of hardware and software inventories. Additional sections on
asset management in future updates to this guide will include topics such as the
management of brick-and-mortar facilities; the consolidation of hardware assets,
software, licenses, and data centers; the management of acquisitions and mergers;
managing the downsizing of assets; and staying current on emerging technologies.


IT Management
Managing Hardware Inventories
Most non-human IT assets can be grouped into two major categories: hardware and
software. This section describes a few basic principles of managing an IT hardware
inventory. We begin with an introduction on how such an inventory has changed in
recent years, and some of benefits of such an inventory. Then we consider how two
critical infrastructure processes can be used to help keep a hardware inventory database
accurate and up to date. The final section describes how a hardware inventory database
can be used as the primary tool to track the current versions and locations of various
hardware components.


IT Management
Introduction to Hardware Inventories
Managing hardware inventories has become more complex in recent years. A few
decades ago, the majority of IT hardware consisted of just a few large mainframes; a few
dozen disk arrays, tape units, and peripheral devices; and up to a hundred or so desktop
terminals. These days, even a moderate-sized company is likely to have hundreds of
servers and disk units, thousands of PCs, and a similar number of voice and data
communication components. Managing this large number of hardware units effectively
requires dedicated personnel, robust processes, and efficient tools.
The dedicated personnel needed to manage a hardware inventory of this size and
complexity usually reside in the infrastructure department, and may be spread across
various units, depending on the type of hardware. The two critical infrastructure
processes of configuration management and change management can play an important
role in managing hardware inventories, as explained in the next segment. One of the most
efficient tools available for managing this type of registry of equipment is a hardware
inventory database, discussed in the third part of this section.
Following are the six main benefits of maintaining a hardware inventory:
It provides an accurate record of the quantity and location of each hardware
component.
Knowing the types of features and capacity for devices such as desktop computers
can facilitate capacity planning for new applications.
This information is useful when planning moves, adds, and deletions.
It can improve hardware problem-solving and resolution.
It can simplify bids for recovery services by providing lists of critical hardware.
It can help negotiate more favorable contracts for the purchase, lease, and
maintenance of hardware by determining the exact number of devices involved.


IT Management
Processes To Manage Hardware Inventories
Two infrastructure processes play an important role in managing hardware inventories:
configuration management and change management. A truly robust configuration process
consists not only of hardware information, but all other relevant IT configuration items,
including descriptions of software, network diagrams, user manuals, organization charts,
and copies of other documentation.
When integrated with a well-designed change management process, configuration
management can ensure that all pertinent hardware information is accurate and thorough.
Thorough hardware information includes quantity, location, features, and lease and
maintenance agreements. The change component of this dual-process environment
ensures that all changes that affect hardware configurations, locations, or support are first
approved and then updated with configuration management before being executed.


IT Management
Use of a Hardware Inventory Database
There are a variety of ways to maintain a hardware inventory, from simple spreadsheets
to sophisticated online tools that integrate with multiple other departments such as legal
and finance. One of the available choices that is highly recommended, yet simple and
affordable to implement, is a hardware inventory database that is part of a larger,
relational configuration database. The advantage of this approach is that the configuration
database, when coupled with change management as described in the preceding section,
ensures that the hardware inventory is updated quickly and simply and therefore always
remains up to date. The following list shows a high-level sample of possible hardware
entries for a configuration database:
Computer processors
o Mainframes
o Midrange
o Workstations
o Personal computers
Computer peripherals
o Direct access storage devices
o Disk storage arrays
o Disk controllers
o Tape drives
o Tape controllers
o Plotters
o Network printers
Network devices
o Data network equipment
o Voice network equipment
Office equipment
o Copiers
o Projectors
o Television monitors
o Videocassette recorders
o Digital video cassettes
Miscellaneous hardware items
The level of detail in a particular companys hardware inventory obviously depends on
the companys size, scope, and maturity. Most importantly, the initial definition and
design of this database will depend on the objectives of the configuration management
process. Ill cover configuration management in much more detail in a future addition to
this guide.


IT Management
Managing Software Inventories
This segment complements the previous section on hardware inventories by discussing
similar techniques for managing software inventories. The section begins by describing
the benefits of such an inventory. The second part discusses how two critical
infrastructure processes can be used to help keep a software inventory database accurate
and up to date. The final portion describes how a software inventory database may be
used as the primary tool to track the current versions, releases, and maintenance patch
levels of various software components, as well as the equipment on which theyre
running.
Benefits of Software Inventories
A variety of benefits arise from a well-managed software inventory. These advantages
fall into two broad categories of costs and compatibility. On the cost side, an accurate
software inventory can save a company substantial costs by identifying the misuse of
expensive software licenses. Licenses may have been duplicated, may have expired, may
never have been used, or may warrant greater volume discounts.
On the compatibility side of these benefits, time and effort can often be saved by
maintaining an up-to-date software inventory. Knowledge of the current version and
release levels of each piece of software can prevent costly delays to the deployment of
software upgrades, or even new applications. Analyzing software inventories can also
lead to proactive management. For example, such analysis may identify the absence of
key software such as virus protection and other security software.
Processes To Manage Software Inventories
The same two infrastructure processes that play an important role in managing hardware
inventories, configuration management and change management, play a comparable
essential role in software inventory management. A truly robust configuration process
consists not only of software information, but all other relevant IT configuration items,
including descriptions of software, hardware, network equipment, user manuals,
organization charts, and copies of other documentation.
When integrated with a well-designed change management process, configuration
management can ensure that all pertinent software information is accurate and thorough.
Thorough software information includes version and release levels, maintenance patch
levels, upgrade compatibility, number and costs of licenses, expiration dates, and support
provisions. The change component of this dual-process environment ensures that
appropriate IT personnel first approve all changes that affect software costs,
configurations, or support, and then update the appropriate aspects of configuration
management before executing the change.
Use of a Software Inventory Database
There are a variety of ways to maintain a software inventory, from simple spreadsheets to
sophisticated online tools that update records automatically whenever a software change
is made. Similar to the recommended approach to hardware inventories, a software
inventory database that is part of a larger, relational configuration database is highly
recommended, yet simple to implement and affordable in cost. The advantage of this
approach is that the configuration database, when coupled with change management as
described earlier, ensures that the software inventory is updated quickly and simply and
therefore always remains up to date. This technique helps ensure software compatibility
at the lowest possible cost. The following list shows a high-level sample of possible
hardware entries for a configuration database:
Application software
o In-house developed
o Enterprise resource planning (ERP)
o Commercial off-the-shelf (COTS)
o Tools/utilities
System/control software
o Operating systems (O/S)
o Network operating systems (NOS)
o Database management systems (DBMS)
o Tools/utilities
Miscellaneous software items
The level of detail in a particular companys software inventory obviously depends on the
companys size, scope, and maturity. Most importantly, the initial definition and design of
this database depends on the objectives of the configuration management process. Ill
cover configuration management in much more detail in a future addition to this guide.
References

Inform IT - Management.

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Inform IT - Management.

Uploaded by

Copyright:

Available Formats

IT Management

You might also like