Managing IT in 2003
Thank goodness 2002 is over. The sun is shining, birds are
chirping and IT spending is back, right? Unfortunately, the economy continues to
drive IT behavior in 2003. So, how did you respond to the budget crunch of 2002?
Did you hunker down, hoping for better times, or did you try to make bits of
progress where you could? Many just hoped to keep the lights on and basic
services running. Will 2003 be any different? A study by Boston-based consulting
firm Aberdeen Group predicts a 4% increase in spending. However, a report by New
York investment banking firm Goldman Sachs predicts a 1% drop in IT spending.
The truth probably lies somewhere in between. What remains clear is that 2003
will continue to present its share of challenges.
But what happens when the economy turns around? How will you scale up and
help the business? Can you do more than just survive? The business will want to
take advantage of new opportunities. If you act smart, you can do more than just
survive today's downturn. You can help ready the business to take advantage of
In today's economic climate, it's results that count for both business and
IT. Results are measured in three ways: revenue, cost and quality. Software
vendors, in particular, have been hard hit by the economic slump. As we've seen
recently, the next opportunity may be a merger or acquisition. With revenues
tight, companies will focus on cash flow and cost containment, and sizeable
budget cutbacks have slowed IT progress to a crawl. Amid all this pressure,
quality has become an issue that needs more than lip service. With the current
marketplace stresses, companies have to get it right the first time or they're
out of business. Quality is critical in helping companies take advantage of
One place to start meeting the challenges of revenue, cost and quality is to
look for alignment with the business. This has been a hot issue with CIOs for
some time. Are you spending your time and effort on projects that directly and
immediately benefit the business? IT has had to become better at this during the
past year. When money is tight, it is important to make every dollar count. I
know of one CFO who began his evaluation of IT projects by demanding that the IT
team show how a project would add value to the business. If the team did that,
he would then demand to know how much value and when the company could expect to
see it. Projects with an ROI of more than 12 months need not apply. Was this
unreasonable? I think not. When the business is under pressure to demonstrate
results, the IT department should expect no less.
This approach to selecting projects will focus on those with an immediate
value to the business. But directly demonstrating value can be problematic.
Needed infrastructure projects typically get put on the shelf. Projects that
appear tangential to the immediate needs of the business need close scrutiny and
a clear connection to business value before they will be accepted. A holistic
enterprise architecture can help to show clear links between the customers and
markets served, the business capabilities needed to reach those customers and
markets, and the systems and underlying technologies necessary to support those
Unfortunately, if you don't have an enterprise architecture in place,
creating one could be viewed as a tangential, non-essential project. One
approach to this is to construct a high-level enterprise architecture and flesh
out the details a bit at a time as you work on linkages for particular projects.
This doesn't give you a base for evaluating all projects immediately, but it
does answer the linkages question, and it gives you a better chance of
demonstrating how the project will add value to the firm. It also provides a
base for future development.
Much of IT's focus in the past year has been on understanding and managing
costs, and it continues to be a concern. While many shops have a charge-back
structure to cover costs, understanding the true costs of managing and operating
a shop can be difficult. This is one area where an enterprise architecture can
pay for itself. For example, if you use something like the Zachman framework,
you have a context for understanding your systems, infrastructure, people and
operational requirements. The architecture can also help you to understand how
important any given system or operation is to the business. This is the
alignment issue once again. Let's face it, not everything we do is of equal
value to the business. Though we are masters of self-justification, current
times demand that we take a hard look at all our IT capabilities and focus on
those that add the most value to the business.
One way to do this is to use our architecture to evaluate how well we support
the business. This is opportunity identification. We may find processes or
systems that are not as efficient or effective as they should be. By identifying
these opportunities for improvement, we can select projects that are both
aligned with the business and prioritized to deliver the greatest value. For
example, CRM projects often address both revenue and cost issues. Businesses
need more revenue, and CRM systems can help to identify customers with the
greatest potential for generating additional revenue. This is 1:1 marketing at
work. CRM can also help to manage costs by helping the company focus on using
its resources to its best advantage. This type of project is fairly easy to
justify in terms of delivering business value.
Opportunity identification also allows us to evaluate or re-evaluate
technology. While many companies are not investing in new technology, a careful
review may be able to identify appropriate technology that will add additional
value to a project. For example, I've seen a company adopt Web services as a way
to create more flexible systems. The driving factor: The business was changing
processes as quickly as possible to meet changing market conditions. Flexibility
in using existing systems was required to meet this goal.
Quality often gets verbal support, but not the focus it needs to be taken
seriously. When the business operates on razor-thin margins or at a loss, there
is no place for miscues and ''do-overs.'' Quality of execution is critical.
Likewise, quality in the systems delivered and maintained by IT is critical for
current and future needs. Delivering systems that don't work right the first
time can kill a business. I've seen a number of shops that were woefully
unprepared for this focus on quality. In the past, software development
life-cycle (SDLC) methods and processes were often ignored, glossed over or
treated cavalierly. Solid, well thought out SDLC methods and processes are
critical to delivering quality systems time after time. Fortunately, there's no
need to start from scratch. There are a number of methods available. If you
don't already have one, or if the one you have is insufficient, select an
existing one that is the closest fit to your needs. It should provide a complete
framework for helping you to consistently deliver quality systems.
Will these approaches to meeting revenue, cost and quality goals still be
helpful when the turnaround comes? I think so. For example, when IT is aligned
with business, the business will be able to respond with more agility to the
changing demands of the marketplace. The current focus on demonstrating business
value helps us to achieve this alignment. Even when the economy turns around, a
focus on making people more effective and processes more efficient will still be
needed. Creating quality systems will also help us to prepare to scale up when
necessary. Although it is true that not all systems are scalable, you stand a
better chance of scaling one of good quality than you do of scaling one so
poorly constructed that it needs to be thrown away. And selecting appropriate
technologies can help. For example, Web-based systems scale more economically
than client/server systems.
What do you think? How will you face the challenges of
John D. Williams is a contributor to Application Development Trends. He is president of Blue Mountain Commerce, a Cary, N.C.-based consulting firm specializing in enterprise, domain and application architectures. He can be reached via e-mail at firstname.lastname@example.org.