 Hello
Readers,
A management position in IT means that you have to make frequent decisions that
permanently alter the direction of your company’s IT structure. These decisions
often involve large sums of money – and the vendors know this, too. Dave Stein
offers advice on separating fact from fiction when evaluating vendors and products.
Check out the first article for some valuable tips that will save you time, money,
and regrets.
Next up is an illuminating piece about geeks. IT departments simply wouldn’t run
without them, but they’re not like other employees. Geeks are often a source of
frustration for managers. Paul Glen offers tips for understanding their quirks,
and helps you discover what motivates them.
Disaster recovery – is your company ready yet? If not, check out today’s final
article. Last but not least, disaster recovery specialist Angela Devlen outlines
a twelve-point list of items that your enterprise-wide recovery program must include.
Enjoy the issue!
Beware of Vendors Bearing Solutions
by Dave Stein
Hype. Years ago we called it "leaning into the wind." It was a philosophy-maybe
even an art-that enabled software companies to be competitive, to build market
share, and to sell sufficient product in a timely enough fashion to fund ongoing
development. If you leaned too far into the wind, you fell on your face. If you
didn't lean far enough, you would watch their backs as your competition took the
market share upon which you built your dreams.
Leaning into the wind is a metaphor that used to mean announcing, marketing, demonstrating-even
selling-something that you calculate will be ready by the time the customer is
prepared to actually use it. It was a complicated calculation back then. Not quite
the "square root of development effectiveness times the standard deviation of
sales aggressiveness divided by the total number of competitors in your market
minus the pressure from the venture capitalists," but close.
Ten years ago business was done aggressively, but ethically. The intent with most
vendors was to deliver to the customer what they needed when they needed it, however
close to the deadline it was. Once in a while you were late, but you always made
it up to the customer. Always.
During the last five years, leaning into the wind has transmogrified itself into
a level of hype in the enterprise solutions marketplace that would make the aluminum
siding salesmen of the 1950's hide their wallets and run for cover. That hype
has been a major factor in the recent downfall of some of the enterprise application
industry's most illustrious players.
Were lie detector tests available to IT management today, fewer of them would
have to leave their former jobs in embarrassment, fewer companies would be at
the brink of survival due to new system implementation "snafus" and far fewer
vendors would be out there PowerPointing their way to the next quarter's sales
goal or the big IPO.
Read
the Full Article
11
Ways to Motivate Geeks
By Paul Glen of C2 Consulting
Every leader wants a motivated group, but many find that motivating technology
workers is quite different from motivating other employees. Here are a few tips
from my new book "Leading Geeks: How to Manage and Lead People Who Deliver Technology"
(www.leadinggeeks.com).
1. Select Wisely. The most important thing a
leader can do to encourage intrinsic motivation is to assign work to geeks who
have an interest in the work.
2. Manage Meaning. The second most important
thing a leader can do is to give a geek some sense of the larger significance
of their work. Without a sense of meaning, motivation suffers and day-to-day decisions
become difficult. It is easy for geeks to become mired in the ambiguous world
of questions, assumptions, and provisional facts characteristic of technical work.
3. Communicate
Significance. It is very important for managers to be explicit about
the role a new technology plays in a business otherwise some will misunderstand
the centrality of their work and others may develop delusions of grandeur.
4. Show Career Path. Many geeks have only a
vague sense that there’s more to advancing their careers than just acquiring new
technical knowledge. Be specific about what competencies a geek must demonstrate
in order to advance their career.
5. Projectize.
Projects help turn work into a game and geeks love games with objectives that
delineate both goals and success criteria.
Read
the Full Article
12 Key Elements of
an Enterprise-Wide Disaster Recovery Program
By Angela Devlen
In today’s business environment, organizations of
all sizes should be establishing a disaster recovery program. Due to increasing
dependencies on information technology for critical business functions, it is
important to understand the true scope of what a disaster recovery program entails.
Long gone are the days of a disaster recovery plan, which simply exercises data
back-up and offsite tape vaulting. Today that is only one small component. It
is important to understand that disaster recovery planning in today’s environment,
is a business process to be integrated into the lifecycle of every IT project.
Once the key elements of a comprehensive program are understood, it becomes clear
that disaster recovery planning is an ongoing process and no longer a function
that is performed for the benefit of auditors.
1. Regulatory
Requirements
To define the disaster recovery requirements of an organization, mandates set
by regulatory agencies must be documented and understood. While the finance industry
is recognized as one of the most highly regulated industries it is by no means
the only one. Although regulatory agencies for many industries require disaster
recovery plans, little guidance is provided on how precisely to accomplish this
goal. The responsibility falls on organizations to establish a strategy to achieve
regulatory compliance.
2. Strategy and Policy
Every organization needs a disaster recovery policy. Whether a disaster recovery
policy is currently in place or one needs to be created, an organization should
consider several things. First, it should reflect the objectives of the business
continuity program. The creator of the policy must understand the expectations
and limitations of the organization and it’s leadership. Also, the same
considerations should be taken when defining the disaster recovery strategy. The
strategies should drive the policy, and the policy if endorsed and enforced will
be effective and will serve as a guide to the program overall. When looking for
endorsement and enforcement, look no further than the senior management of the
organization. From a financial standpoint alone, management should understand
both the tangible and intangible losses of downtime. A policy that is enforced
will drive the development of disaster recovery plans, which minimize downtime
and support continuity of the most critical business functions, thus minimizing
financial losses and an organizations liability.
3. Asset Management
When establishing a disaster recovery program, the first step is maintaining an
accurate database of data center assets. It is extremely difficult to know what
to recover if an organization does not know what assets exist. An asset management
database will often include a great deal of information that does not apply to
disaster recovery. If such a database exists, a review of the fields of data captured
will provide a starting point. Fundamental information required will include server
names and configurations, as well as the platforms and applications on each server.
4. Application Analysis
Gathering an inventory of applications and knowing what servers house them is
not enough. It is imperative that it is understood the interdependencies of each
application. Larger organizations will find it overwhelming trying to understand
the interdependencies of the hundreds of applications that support all of their
business functions. However, it is important to point out this is necessary information
for the continuity or recovery of an organization’s most critical applications.
Knowing who maintains this data and ensuring they are part of the recovery team
in the disaster recovery plan is imperative.
Read
the Full Article |
|
