By

4 Comments

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

[Read more…]

Filed Under: Pillars of Purview, Process, Vendor management
By

3 Comments

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

Filed Under: Pillars of Purview, Process
By

Leave a Comment

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

Filed Under: Pillars of Purview, Process, Projects, Vendor management
By

3 Comments

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

Filed Under: Pillars of Purview, Process
By

4 Comments

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

Filed Under: Communication, Pillars of Purview, Process
By

1 Comment

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

Filed Under: Pillars of Purview, Process, Role definition
By

1 Comment

Budgeting maintenance and support for IT

What does IT do, anyway?

Well, among other things, IT spends money. In many modern companies, the expenditures made through IT are among the highest in the company, second only to salaries and marketing.

What does that mean? It often means that when cost-cutting time comes around (as it tends to do, in cycles, at most companies), there’s a particularly harsh spotlight that shines on IT expenditures, and a vast amount of pressure emerges to reduce these, quickly.

Unfortunately, the “quickly” part of that last sentence just isn’t realistic. A lot of IT expenditures can’t be turned off (or down) at a moment’s notice. In many or even most cases, the company has already signed (and paid for) maintenance agreements with hardware and software providers that typically last a year, if not longer.

[Read more…]

Filed Under: Financial, Pillars of Purview, Process
By

3 Comments

DWYSYWD: IT and the value of declaring victory

I saw a license plate recently that read DWYSYWD. I puzzled over it for a while (Google wasn’t handy), and then it suddenly flashed on me: Do What You Say You Will Do. I’ve since learned that this is a well-known phrase, used by people such as Colin Powell, among others.

How does this relate to IT and the CTO/CIO? Well, all sermonizing aside about how “Do What You Say You Will Do” is a great mantra in general for life, it particularly fits the rapidly swirling technical project world that the CTO/CIO copes with every day. In that world, as we all know, it’s easy to say that you’ll do things, and you’ll certainly be pressured to say you’ll do more and more. Actually getting them done, however, is a bit harder.

How important is it to Do What You Say You Will Do? I went into a CTO role once where I rapidly observed that I had inherited a team that wasn’t doing. In fact, the team wasn’t saying, either. Astonishing as it may seem, they had been allowed by company management to fall into the pattern of making no commitments for delivery, in anything other than the vaguest of possible terms, most of which had to do with stating noble intentions of working hard. In other words, they weren’t really putting themselves on the line. A major part of my approach there was to emphasize the importance of making, and then meeting, specific commitments for delivery. “Commit, Deliver, Track & Communicate” became the simply-stated, three-pronged “get well plan” in that situation. Easily stated, not so easy to achieve; but that’s a story for a different posting someday.

My major point here, though, and an important part of project delivery (doing what you say you will do) that occasionally gets lost, is declaring victory when the project is successfully launched. This declaration should be a relatively formal, executive-penned announcement of the launch, usually delivered via a broadly disseminated e-mail.

Insisting on declaring victory has a number of important purposes:
[Read more…]

Filed Under: Communication, Pillars of Purview, Projects
Mastodon