How can IT management fail to understand business goals?

January 10, 2012

“Now more than ever, IT must invest the time to understand specific business goals and translate IT metrics to reflect an impact against these business goals.  Often there is a gap between what IT reports and what is of interest to the business.”   — An Introductory Overview of ITIL V3, itSMF, 2007, p. 38

There’s been a lot written about how IT and business are misaligned.  See for example, Susan Cramm’s excellent book.[1]  But how do they get that way?  One cause is that many IT people don’t understand business.  Another is financial invisibility of IT due to budgeting processes.  But these are not the big killer causes.

I believe there are three major causes:  physical distance, psychological distance, and IT overload.

Physical distance of IT from the business leads to isolation in many ways.  One of my client companies had their IT people in a city 750 miles away from the home office.  Not only did this impose communication barriers, it meant that the IT people were living in a different culture from the home office people – even though both locations are in the United States.  Of course, when you add in the distance to some of the offshore contractors who are handling some IT services, physical distance means even more cultural distance.

Psychological distance can be caused by having objectives that don’t relate to business goals and by being managed in a “silo.”  For example, IT may report in to the CFO, and management metrics may relate only to financial performance.  As long as IT is budgeted as an operational expense, then no amount of encouragement will get IT managers to view what they’re doing as a strategic investment.  This can be aggravated by failing to include IT people in business planning.  Finally, I’ve seen IT organizations where the business tools used by the rest of the business are not in use in IT.

IT management overload is the third major cause of misalignment.  Beyond the usual overload caused by rapidly changing technology and shifting responsibilities (associated with Cloud services, for example), IT management is typically trying to do more with less budget.  As the pressure to perform increases, IT management concentrates on operational measures rather than business metrics.  In addition, technology shifts are raising the cost and complexity of legacy system support.  So IT managers tend to focus on reducing these burdens, rather than looking for new initiatives to support.

Where can we start to correct the lack of alignment between IT and business?  After addressing physical location and reporting structures, the most productive way to get alignment is with common metrics.  Look for business metrics that are relevant to concrete business results and are particularly dependent on IT service delivery.  Then make sure that IT managers understand the business metrics.  Finally, make sure that they buy in to being measured by these metrics.  To do that, of course, it is best to include them in business planning processes – and not just as number-providers.

What are your experiences with IT – Business alignment?  I welcome your comments.

[1] 8 Things We Hate About IT by Susan Cramm, Harvard Business Press, 2010 http://www.eighthates.com/

Filed Under: Painless IT Tagged With: , , , , , ,

Complexity is good – or is it bad?

December 6, 2011

I grew up in a family of engineers.  My father studied electrical engineering in college, but never practiced it because he graduated from college during the Great Depression.  Two of my uncles are engineers, and my older brother preceded me in going to Cornell as an engineering student.

I have always felt that engineering is not only an honorable profession, it also leads to a practical lifestyle that values inquiry, problem-solving and efficient solutions to the challenges in life.  So you may not be surprised to learn that I am a fully qualified lifelong nerd.  I love examining things to discover how they work.  And the more complex the mechanisms, the more interesting they are.

This is where it gets to be a problem.  When I invent something new, like a part of a computer, I revel in the complexity of the thing I’m building.  As long as the complexity serves a purpose, such as actually making the thing do what it’s supposed to do, my brain is tweaked in pleasurable ways when I contemplate the complexity.

If you’ve been reading any of the recent pieces about Steve Jobs, you’ll have understood that part of his brilliance was being able to conceive of simple and easy-to-use products that “just work.”  I worked with Steve in the early days of Apple, and I can verify that it was a challenge being an engineer in a place where the visionary boss kept revising the product based on his latest concept of simple.  Yet even engineers have a principle they repeat to each other to counterbalance their tendency towards complexity – the KISS principle: “Keep it simple, stupid”.

A quote attributed to Einstein says “Make it as simple as possible, but no simpler.”  This teaching admonishes us to simplify our theories, but not so far that they no longer apply to the real world.  Jobs’ vision was to make products that contained complex technology but worked well and intuitively for the common person.  And from that basis, he led the creation of products that have changed the way the world works.

So does this mean that I’m giving up on complex ideas and mechanisms?  Not at all.  The mental contortions I need to undertake to understand complicated things still give me pleasure.  And I believe they keep my mind alive in important ways.  The key to living with such an engineering mind is to keep it from running my life.  I still listen to J.S. Bach’s music with satisfaction at the complexity of the counterpoint and harmonies.  But I also meditate on emptiness to keep the logical brain in check.

The next time you hold a complicated piece of consumer electronics in your hand – such as your mobile phone – take a moment to reflect on its complexity and its simplicity.  Encapsulating one of these in the other is an art.  And to accomplish that encapsulation, you need both engineers and artists.  Long may the engineers and artists work together.

John Levy works with Finance and Operations executives who are sponsors for new IT-based business capabilities.  He helps them to succeed with their projects and to transform their relationship with IT.

Getting business value from every dollar spent in IT is not easy.  You need a guide who is knowledgeable about technology and also speaks the language of business.  John specializes in rapidly getting IT to align with business strategy and to contribute efficiently to the success of the enterprise.

John has been consulting in industry for over 20 years.  His book on management for technology executives, Get Out of the Way, was published in May 2010. 

For more information, please visit https://johnlevyconsulting.com , email him at info@johnlevyconsulting.com , or call 415 663-1818.

 

Filed Under: Painless IT Tagged With: , , , ,

Business, Academia, Government – do we have the same problems?

August 10, 2010

Every one of us is dealing in one way or another with high technology. Whether it is by trying to develop a product, trying to deliver a service, or just preparing our slides for a presentation, we all deal with the high-tech world.  This usually means that we must communicate with high-tech people, and typically the results we get are dependent to some extent on how well the high-tech people do their work.

Communicating with high-tech people is a challenge. Not only do they speak their own brand of jargon, they also tend to be very literal.  Like the literalness of the computer itself, high-tech people seem to think that if you ask for a three-pronged left-handed widget (or a thingumbob, if you like), then if they deliver a three-pronged left-handed widget to you, you should be happy.

Unfortunately, it doesn’t work that way. With software, for example, the requirements are never completely known.  Typically, when the first working model of a new software system is shown to the people who asked for it, their reaction is: “Oh.  I see what you have here, but what I really want is something different.”

This can be frustrating for the technologists who worked for a long time on the development.  One of their countermeasures now is using Agile development practices, in which a working prototype is shown to the “customer” early and often.  This allows the developers to correct their course early and gain confidence that they are building something that will actually be useful.

But why is it so hard to specify what we want in advance? Is it because we don’t speak the same language as the techies?  Or is there something inherent in high-tech that obscures the simple outcomes that we know we want and we think we have asked for?

I believe it is both. Not knowing how high-tech stuff is constructed, we don’t know which jobs are hard to do and which are easy.  We also don’t know how elaborate the underlying structure has to be in order to get what looks like a simple result.  So we ask for things that we want and find ourselves puzzled by the groans from the technologists who see years of work ahead of them to satisfy the request.

We also don’t really know what we want when it comes to interactions with a computer-based system, because the possibilities are endless and the examples we’ve seen in the past color our view of what we think the interactions should be.  For example, if you’ve used Word Perfect for years to do your word processing work, you will not find it easy to switch to Microsoft Word, because the interactions and functions are different.

There’s a new discipline in computer systems development called user interaction (UX) design.  It calls on specialized skills ranging from graphical design, human perception and interaction protocol design, to database design and web programming.  But even as this new discipline is helping to make systems easier to interact with, no one can substitute for you, the user or customer, in defining what the system should do.

Sometimes you have to say, “I want it to be easier to use than this,” when you see how a system works, even when you don’t know how to make it easier.  If you challenge the development team to try different ways to make it easier, you will usually get something better.

But this poses a problem. If they are experimenting with various ways to make the system easier to use, how long will it take to get to the finish line?  How much will it cost?  The fact is that doing engineering and design requires creativity and experimentation.  And you can’t schedule a breakthrough.

So you have to settle for setting a limit on how long or how costly the project is to be.  An entrepreneur may run out of money before delivering a satisfactory system. But if you are constrained to actually get a working system, you want the best you can get within the constraints.

This comes back to the Agile approach. If you ask to be shown a working prototype often, you can do course-corrections frequently while you also gain confidence that the developers are meeting the most important criteria for your project, because you make them show you how the system meets those criteria first.

The Agile Management Bottom Line

Give up trying to specify everything at the start.  Begin by prioritizing the key features or results you need, and ask for frequent demonstrations of a working system.  You’ll end up with a lot more confidence in your high-tech developers, and they will be less frustrated with you.

—–

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering.  He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years.  John’s book on management for technology executives, Get Out of the Way, was published in May 2010.

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com , or call 415 663-1818.

Filed Under: Agile Management, Painless IT Tagged With: , , , ,

What’s the matter with IT?

July 27, 2010

Information Technology (IT) is a name that covers all the stuff (computers, networks, software) that makes businesses work.  As a key part of every business, IT has become a loved and hated department.  Loved because the capabilities of IT keep things humming in business.  Hated because there is something about IT that keeps it apart from the rest of the business.

Businesses keep IT separate for a number of good reasons.  IT needs technical specialists, and these specialists have to interact with each other.  IT has to maintain the systems and networks that keep things running, and these systems are often far from the home office.  Finally, managing IT people requires some kind of management specialists who know what makes technologists tick.

There are also some bad reasons for separating IT from the rest of the organization.  One is to keep business people at the operating level from having too much influence on what IT does.  After all, if you let a low level business manager ask for everything he or she wants from IT, IT might not have enough time to do the big projects planned by the top executives.  Another is the belief that IT doesn’t speak the language of business.

One of my client companies used to have the head of IT (the CIO) report to the head of Finance (the CFO).  This guaranteed that the CIO had a financial perspective on everything.  While that is the right perspective for a department that belongs under Operations (people who keep the buildings and the commuter buses running), it is not the best perspective for and IT department that is trying to contribute to the business bottom line by developing innovative software packages and better products.

This company had a large call center (people who answer the phone when you call for support) located 750 miles from the home office.  The whole IT operation, except for their offshore contractors, was located in the same building as the call center.  Upstairs from the call center were the software developers and managers who were implementing the latest web site upgrades and support software for their sales agents.

Software development is not Operations, it is Engineering.  If you treat software engineers the same way you treat call center operators, you discourage them, because they need a different working environment and a different set of criteria for their success.  Discouraged software engineers leave to find a better place to work.  The most experienced and most productive ones of them leave first.

IT needs to be integrated with the organization.  Not only does the management of IT have to be aware of and fully behind the strategic initiatives of the company, they should be actively proposing and executing projects that increase the competitiveness of the company.  The more that IT can sit side-by-side with their business-oriented peers in the company, the better the strategies and the results will be.

The Agile Management Bottom Line

Get IT out of its silo and into the main stream of your business.  If you don’t understand what IT does, start asking questions.  But don’t banish IT to the boondocks just because they’ve got a lot of funny-looking machinery in the closet.  You need them and they need you.  Start talking.

John Levy helps business managers who are frustrated because they are not getting what they need from their IT or Engineering organizations.  He helps them get predictable, consistent and innovative results from high-tech people in IT and product development.

John’s clients include companies in insurance and manufacturing, as well as software, computers and storage.

John’s book on management for technology executives, “Get Out of the Way,” was published in May, 2010.  His website is https://johnlevyconsulting.com and he can be reached at 415 663-1818 or info@johnlevyconsulting.com

Filed Under: Painless IT Tagged With: , ,

Metrics of Success in Development – Part 3

January 26, 2008

Today we’ll finish the list of ten questions that can give you a quick measure of your development group or department. The purpose is two-fold: to let you see how you measure up compared to other similar departments, and to suggest ways in which you can think about the stresses in your department.

Let’s launch into the final four questions, then we can total them up.

7. Viewed from other departments (outside of Development), how would managers rate your development managers and engineers in each of the following areas?
(a) Cooperativeness (with outside people)
Extremely cooperative – add 3 points
Very cooperative – add 2 points
Cooperative – add 1 point
Uncooperative or unavailable – add 0 points
(b) Flexibility (willing to work with and compromise with others outside the department)
Extremely flexible – add 3 points
Very flexible – add 2 points
Flexible – add 1 point
Inflexible – add 0 points
(c) Team-orientation (beyond the Development department teams)
Extremely team-oriented – add 3 points
Very team-oriented – add 2 points
Team-oriented – add 1 point
Not team-oriented – add 0 points

8. What percentage of the company’s gross revenues in the most recent year were allocated to Development (or R&D)? (If your company has no revenues, or if revenues are less than the Development budget, answer “over 10%”)
(a) over 8% – add 3 points
(b) 4 to 8% – add 2 points
(c) 2 to 4% – add 1 point
(d) less than 2% – add 0 points

9. Comparing this year’s Development budget to last year’s, how did it change?
(a) Increased by 20% or more – add 3 points
(b) Increased by 5 – 20% – add 2 points
(c) Stayed the same or changed by less than 5% – add 1 point
(d) Decreased by more than 5% – add 0 points

10. The number of concurrent development projects now in my department is
(a project is defined as an activity with a timeline and a goal which needs at least 1 full-time person to make progress towards the goal; if you have many small projects, you can count the number of project leaders instead)
(a) over 25 – add 0 points
(b) 15 to 25 – add 1 point
(c) 5 to 15 – add 2 points
(d) 1 to 4 – add 1 point
(e) none – add 0 points


If your total points add up to 52, you have a perfectly-performing development organization and have no need for improvement. For the rest of us, the points are probably in the following ranges:
Excellent: 37 to 52 points
Good: 22 to 36 points
Fair: 13 to 21 points
Poor: 12 points or fewer

How did you do? What does this mean? If you think about the stresses on your department, you can see that the point score is not as significant as the individual issues you’re facing. Are you having a lot of turnover? Slipped schedules? Complaints from other departments about your people? These can all be aggravated by declining budgets which are outside of your control.
Later we’ll examine some of these issues and how you can find ways to work around them. In the mean time, click on the Comment button and let us know how you scored.

Filed Under: Painless IT Tagged With: , , , , , , ,

Metrics of success in development – Part 2

January 26, 2008

Last time we listed the first three questions of a self-assessment questionnaire for Development managers. Those first three related to project completion, staff turnover, and how well the initial functional or feature list was met. If you are having problems delivering products, most likely you will experience problems in one or more of these initial three areas.

There is a less tangible measure that relates to suitability of the product to the customer. But I’m still trying to figure out how to ask about that in a way that leads to a consistent and useful measure. If you have any suggestions, please make a comment on this blog.

Here are the next three questions:

4. How many hours per week are put in by your project or program staff? This is to be answered in two parts: first for the average over the life of the project, and then for the peak of the project or program. Answer this for each of the most recent 3 projects or programs.

4a. Average over the project or program:
Over 60 hours/week (add 0 points per project)
50 to 60 hours / week (add 1 point per project)
40 to 50 hours / week (add 2 points per project)
less than 40 hours / week (add 0 points per project)

4b. Peak week during the project or program:
Over 80 hours / week (add 0 points per project)
70 to 80 hours / week (add 1 point per project)
60 to 70 hours / week (add 2 points per project)
40 to 60 hours / week (add 3 points per project)

5. How many direct reports do you have? (Direct reports include staff assistants, administrators, secretaries, project leaders, managers and interns)
Over 12 (add 0 points)
10 to 12 (add 1 point)
8 to 9 (add 2 points)
3 to 7 (add 3 points)
0 to 2 (add 0 points)

6. Of your direct reports, how many do you regards as “problem” employees (people you will replace when there is an opportunity)?
0 (add 3 points)
1 (add 1 points)
2 (add 0 points)

Questions 4 and 5 are searching for sustainability in your project loading. It’s OK to have peak weeks in which people are working 10 to 20 more hours than is typical during the project. But if you are driving everyone to work more than 60 hours per week on a long-term basis, you are not getting output that is sustainable. It may be time for you to institute metrics that measure results rather than inputs. Then you can experiment with different work schedules to see which ones result in the greatest output.

Sustainability applies to you and your management time, too. If you have more than 9 direct reports, the odds are that you are (a) not managing all of them as well as they could be managed, or (b) overloading yourself with management tasks that give you little time for planning and strategic analysis.

Next time we’ll complete the question list and tally the points for a complete score.

Filed Under: Painless IT Tagged With: , , , ,