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:

[Read more…]

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:

[Read more…]

Buy vs. build, and why Scott McNealy thinks the CIO doesn’t need a staff

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 more…]

Cementing a formal work initiation process for IT projects

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 more…]

Is there any CIO/CTO out there who is still inclined to answer a desk phone?

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 more…]

Why the CIO should air the dirty laundry

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 more…]

Software development’s classic mistakes and the role of the CTO/CIO

Here’s a post of a type I rarely do: a reaction to an item recently posted to the Internet. Specifically, a day or two ago, Steve McConnell’s firm Construx, Inc. released their update of McConnell’s list of classic software development mistakes. This survey and its results is worth everyone’s time to read (and ponder) carefully. Their summary of the paper is as follows:

“Classic mistakes are ineffective software development practices that have been chosen so often, by so many projects, with such predictable results that they deserve to be called classic mistakes. Steve McConnell first introduced this concept in Rapid Development in 1996. Construx recently updated McConnell’s original list of classic mistakes and then conducted a survey to assess the prevalence and impact of these mistakes. This white paper shares survey results–both expected and surprising–and analyzes the survey findings.”

The Construx survey results document pretty much speaks for itself, and provides interesting detail that I won’t repeat here. Hence, this is a bit of a “piling on” kind of post, in part because I respect McConnell’s work in the extreme, but also because I want to add some “color” to what he intentionally presents with (relatively speaking) a “just the findings” deadpan dryness.
[Read more…]

End-of-year Peterisms for the CTO/CIO

One habit I’ve picked up as a CTO/CIO, a habit that usually comes out in the many meetings that make up my work week, is that of leading through aphorism. Over the years, I’ve accumulated a number of pithy sayings that, like the proverbial picture being worth a thousand words, succinctly express key concepts and lessons that I’ve learned throughout my career. And I pass those on, sometimes repeatedly. My staff in more than a few of my jobs have started to call these sayings “Peterisms”, although I certainly can’t claim that I’ve invented most of them. So for a light-hearted end-of-year blog entry, in what may become a recurring flavor of post, here’s a few of them, with some discussion about what they connote in my personal Darmok-like management code.

[Read more…]

Mastodon