CTO/CIO perspectives

Here’s a disquieting little secret that few of us ever really acknowledge, maybe because it’s rather painful and also an unavoidable part of the fabric of our existence in IT. I don’t know how to say it more eloquently (or less bluntly), so here goes: being in information technology is hard. In our day-to-day dealings with stakeholders, with end users, with management, even within our own ranks, it’s common to hear some pretty discouraging and recurring things, voiced either explicitly or implicitly. For example,

• “what have you (IT) done for us lately?”;
• “what do you (IT as a whole) do all day?”;
• “we’ve been asking for that system for years now and not gotten it”;
• “how can that be so hard? Why can’t you just …”;
• “at my last company we did that in just [names an absurdly short amount of time] and it worked really well.”

Read the rest of this entry »

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).

Read the rest of this entry »

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 of course 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:

Read the rest of this entry »

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:

Read the rest of this entry »

I’m going to unabashedly steal someone else’s anecdote for this post. I’ll justify doing so on the grounds that the anecdote has stuck with me since I heard it; I’ll talk about why, and why I tend to repeat it to my staff at opportune moments. Starting with this post, I plan to follow on with additional posts discussing more nuances of this very critical topic of buy vs. build.

About 5 or more years ago, I went to a CIO forum hosted at Sun Microsystems by their then-CIO, Bill Howard, who has since retired. At the time, Howard ran IT for Sun, with a staff that probably numbered in the thousands. His anecdote was about how he was frequently nagged by Sun chairman Scott McNealy about the size of his IT staff. Scott, according to Bill, was of the decided opinion that Bill could accomplish all he needed simply by having himself and an assistant, and outsourcing all the rest to external parties.

Read the rest of this entry »

I’ve written before on how the most important thing that a CTO/CIO deals with is the proper allocation of resources. I’ve discussed how doing proper resource allocation isn’t just a matter of deciding exactly what Sam or Mary will work on this week, but actually figuring out the whole project portfolio, including sustainment activity, and determining the general picture of what portion of resources will be dedicated to each chunk. That project portfolio management concept is a meta-level above, and arguably more important to focus on than, the nuts-and-bolts action of allocating the time and tasks for individuals.

Here’s another critical meta-layer to the overall issue of how to properly allocate resources: how is work spawned, initiated, defined, before it goes through the various approval steps involved in portfolio management? Where does the work stem from, and how does it enter the stream? Who decides that the suggested project is worth pursuing at all? Does simply anyone’s suggestion count as a way to spawn work? Lots of organizations don’t have a very clear path for this. The result is that lots of stuff ends up getting worked on informally, and resources get overcommitted and stretched, and both quality and timely delivery suffer greatly.

I’ve found over the years that it’s best to have a single, formalized conduit: yes, a dreaded form, collecting basic initial information about the intended project or need, and capturing important facts and assumptions about the approach, cost, sponsorship, and likely return on investment.

Read the rest of this entry »

Just a quick one, this time, in what may become an ongoing motif of describing some of the pet peeves I’ve developed in this role.

For years now, I’ve been unable to answer my desk phone. Or rather, I’ve been unwilling to answer it, at least for calls that I can tell are coming from sources external to my own company.

Nineteen times out of twenty, any external call is almost certainly a cold call from a software or hardware or services vendor. It’s as bad as dinner hour used to be at home, before the advent of the National Do Not Call list. Sometimes I even detect the telltale blank pause that occurs while the automated outbound dialer, robotically jumping for joy at having landed a live one, is routing the call to a real person. The caller is often obviously reading from a script, rapidly.

They want to impart things along the following lines:

Read the rest of this entry »

Trust. It’s important. And a company typically instills a huge amount of trust in its IT department, particularly (as is often the case today) if that IT department is responsible for the operation of systems (such as web sites) that contribute significantly to the bottom line.

I’ve been at the helm of several IT departments that operated the product of the company: social networking or other web sites. And that’s when I learned how vital it is to “air the dirty laundry” internally throughout the company about the stability of the key systems. Too often, I have seen IT staffs that were reluctant to announce that the system was down, in the hopes that it wouldn’t be such a big deal if they could only get it fixed quickly. Of course, often a quick fix wasn’t in the cards, and users started to a) notice the outage; and b) wonder if anyone in IT was even aware of it.

My response to this is to insist on the airing of dirty laundry. Less euphemistically: timely, comprehensive, broad-audience notification of all system outages and impairments. Specifically, emphasize the following:

Read the rest of this entry »