As much as any part of your company that supports the key prongs of the corporate mission (deliver product, sell the product, support the product), IT is constantly on the hook to deliver more and more. As I’ve written before, expectations are deservedly high, and getting higher all the time. And when expectations are so high, and the stakes for success equally so, the possibilities for disappointment are numerous.
No one wants to be disappointed, and no one wants to disappoint. Here’s how you, the business stakeholder, can help yourself and the company: don’t fall into the common traps with IT that will likely lead to you not getting what you really want.
Here comes a David Letterman list of these traps, consisting of only three items. There are, of course, a lot more traps than just three, but in my experience, these are the main ones.
3. Push hard on your IT organization to deliver on “trick plays”. Sorry for the sports metaphor, but it’s applicable. With respect to IT, “trick plays” mean mission-critical, high-profile projects like constructing new web sites or instituting major new back office systems such as a data warehouse or a new CRM system.
[Read more…]
How not to get what you want from IT
Using feedback loops to improve IT department service
As I’ve written here before, I strongly advocate thinking of IT in general as a service organization to the rest of the business.
Any service organization needs one or more forms of “feedback loop” to be able to gauge whether it is successfully accomplishing its mission. However, I’ve observed relatively few IT organizations that actively seek to implement such feedback loops on a regular basis. At best, the IT executive does it informally by consulting with his peers at the executive table. But with any such anecdotal feedback, the information gathered that way tends to be fleeting and unreliable, and it is especially influenced by strong personalities and emotions during crisis situations.
Here’s a better, and simple, suggestion, one that I’ve implemented to varying degrees at several firms with a good amount of success: Survey your constituents regularly and then publish the results.
Sounds daunting? I promise it really isn’t, not in this day and age of easy-to-use web-based surveys. With less than an hour of work, you can design and initiate a survey using a free service like Zoomerang or SurveyMonkey, and easily gather high-quality results (reports and statistics) in just a few days that can help you gauge (and present) how you’re doing. Here’s how.
Financial metrics for IT: the holy grail of ROI and how it misses the point: Part 2
As I promised in my previous post on this, and along the lines of the “intensely practical” goal of this blog, we’ll now take a look at the financial cost analysis for a specific project. This is only an example, with details changed or obscured, but it is based on a real proposal from a few years back, analyzing whether to swap out an existing infrastructure element (a storage array) for a newer and more capable unit.
As I’ve argued before, any proposal like this should really analyze and present several alternatives – e.g., sticking with the status quo, changing to vendor X, or changing to vendor Y. This example covers only one of those analyses, but I think you’ll get the point. Here’s what I see a lot of IT people forget: your goal here is to analyze and communicate and recommend the best choice for the organization, not just to justify what you already want to do in your gut. You need to be your own devil’s advocate in this process. If you can’t clearly understand all the benefits and outline all the costs, you’ll make poorer decisions, no matter what your gut tells you.
So let’s dive into the practical. Here’s the process: if you’ll recall, we want to look at hard benefits and hard costs of the proposal, and look at these over a five-year time horizon to get the big picture. On the benefits side, we talked about how benefits break down into increased revenue and decreased costs. Of course, the notion of actually increasing the company’s revenue based on an infrastructure change is unlikely, so we’ll leave that aside in this case. The whole purpose of this particular example proposal is to decrease costs, both in real terms and in terms of making personnel more productive. So let’s look primarily there for the benefits that will result from the proposal.
Financial metrics for IT: the holy grail of ROI, and how it misses the point: Part 1
Let’s talk some more about one of my favorite topics, project portfolio management (PPM). A lot of literature on PPM tends to focus on evaluating risks and returns. An excellent article on IT governance last week in The Wall Street Journal had the following sage advice:
“Create an IT portfolio by evaluating risks and returns. Just as an investor balances risk and returns in constructing a portfolio of investments, management should analyze the costs, benefits and risks of all IT projects to determine how to get the most benefit from the dollars invested in technology.”
I can’t argue with that. But I also like to talk about another major part of IT portfolio management, which focuses on juggling which projects can actually be resourced. It’s unfortunately easy to come up with ten distinct projects with positive return on investment (ROI), for example, in a situation where it’s really only feasible to do one or two of these a year. In some companies, the pressure to do any positive-ROI project becomes enormous, even if it means the company is biting off too much at once. So what to do?
The flip side of common myths: how some are perpetuated by IT
As promised, I’m going to follow up on my last post (“Optimism, resilience, stamina: the make-up of the CTO/CIO“), covering the myths IT deals with on a regular basis, by talking about its flip side: the ways that IT itself can unfortunately perpetuate or contribute to some of the myths I’ve been discussing.
Here’s a point-by-point discussion of some of the things I talked about last time, the discouraging statements you frequently hear from stakeholders.
Offshore development: aim for it, even if you never go there
As I wrote last time, a large part of my reason for opposing offshoring is because I’ve rarely, if ever, worked in a company where I felt the necessary prerequisites were in place to be able to even consider offshoring as a viable option. Let’s go into that in more detail now.
I’ve observed before that managing the incoming flow of projects is often reminiscent of trying to stuff eight pounds of manure into a five-pound bag. In other words, you have more to do than you could ever get done. You will constantly be challenged, and should be challenging yourself, to find ways out of that dilemma: either, how can you become a better stuffer, so to speak, or, how can you expand the size of the bag itself. I assume that you’re doing everything you can to maximize the effective allocation of your resources so that you are more efficiently stuffing the bag. So, what about increasing the size of the bag? Well, additional internal headcount is usually hard to come by, and it also takes a fair amount of management overhead to scale a department prudently. The push is usually for short-term delivery of a project; increasing your own headcount can work in the long run, but almost never in the short term (read Fred Brooks’ classic The Mythical Man-Month).
Offshore software development: the reasons why not
Of all the numerous cold calls I get, inquiries from potential offshoring partners lead the pack. Their main pitch, of course, is that I can lower my development (or support, or QA) costs by leveraging offshore labor at a third or less of domestic rates. This argument is tends to be all the more compelling the further up the management chain you go: CEOs and boards of directors will often ask why we haven’t dealt with cost issues by adopting an offshore development approach.
Although I can see both sides of the argument, this post will focus on the negatives. I’ve come to a very firm stance on the topic of offshoring: the risks and the hidden costs tend to far outweigh the potential advantages. To be sure, I may have come to that stance largely because I’ve rarely, if ever, worked in a company where I felt the necessary prerequisites were in place to be able to even consider offshoring as a viable option. More on that later.
The lure of offshoring depends on a number of implicit underlying management assumptions that in my view amount to myths or misunderstandings. To ascribe to these myths is to go against decades of lessons learned in the trenches of software development. At the risk of being perceived as setting up a straw man argument, here is a list of just a few of these fallacies:
The pitfalls of the implicit “buy” bias for IT systems and services
I wrote last time about how there are twin truths to the buy vs. build dilemma: outsourcing can be a superb way to leverage external expertise and keep your own team focused on core functions; yet, outsourcing is not an easy or friction-free choice, and it’s easy to simply substitute one set of problems with another.
Note that I’m not specifically addressing offshoring here; rather, my comments pertain to any time you engage an external entity (across the big pond or across town) to perform a development or operations task instead of using your own people. I’ll have more to say about the specific subject of offshoring soon.
As Scott McNealy basically challenged Bill Howard at Sun, why not outsource (i.e., buy) everything and build nothing yourself? If that’s now the implicit going-in position regarding IT systems and services for many of today’s executives, then here are a few important (and often overlooked) things to consider, pitfalls of the “buy” side of the equation:
