By

9 Comments

IT extremism strikes again: the odd resistance to bug tracking

In information technology and software development, how many of our wounds are self-inflicted?

Here’s what I mean.

What I’ve seen happen, recurringly, in IT over the years and decades: idealistic but inexperienced people come along (within IT itself or in other departments within a company), to whom IT systems and issues seem to be easier than they in fact are. They are smart and earnest and oh-so-self-assured, but they also seem blissfully unburdened by much real understanding of past approaches.

https://twitter.com/CompSciFact/status/602271417330225153

They are dismissive of the need for much (if any) rigor. They generalize often quite broadly from very limited experience. Most notably, they fail to understand that what may be effective for an individual or even a small group of developers often doesn’t translate into working well for a team of any size. And, alas, there’s usually a whole host of consultants, book authors, and conference presenters who are willing and eager to feed their idealistic simplifications.

Over the years, I’ve seen a subset of developers in particular argue vehemently against any number of prudent and long-accepted IT practices: variously, things like source code control, scripted builds, reuse of code, and many others. (Oh, yes, and the use of estimates. Or, planning in general.) To be sure: it’s not just developers; we see seasoned industry analysts, for reputable firms, actually proposing that to get better quality, you need to “fire your QA team.” And actually getting applauded by many for “out of the box thinking.” Self-inflicted wounds.

But let’s talk about just one of these “throw out the long-used practice” memes that pops up regularly: dismissing the value of bug tracking.

How can anyone argue against tracking bugs? Unbelievably, they do, and vigorously.

A number of years back, I came into a struggling social networking company as their first CTO. Among other issues, I discovered that the dev team had basically stopped tracking bugs a year or two before, and were proud of that. Did that mean their software had no bugs? Not when I talked to the business stakeholders, who lamented that nearly every system was already bug-riddled, and getting worse by the release.

Why did the development team shun bug tracking? That wasn’t quite so clear.

[Read more…]

Filed Under: Anecdotes, Industry trends, Process, Tools Tagged With: , , , , , ,
By

2 Comments

Starting points for the quantitative CIO: downloadable basic tools

Much as in any field, IT executives constantly have to seek a balance between idealism and pragmatism. Given a particular problem and the range of possible solutions, do we insist on “doing it right”, or do we buckle down and “just get it done”, even with gaps?

There’s obviously no single right answer, which is what makes IT consistently so fun and frustrating at the same time. Over time, though, my own approach has typically been to focus on the continuous improvement aspect of “doing it right”: whenever possible, get something going as a start, then hone it over time as you learn more about the problem and your situation.

Using spreadsheets as a management tool definitely falls on the “just get it done” side of this spectrum of approaches. Spreadsheets are seductively easy, omnipresent, and usable by people with a variety of skill sets and technical savvy.

But there’s a host of downsides: spreadsheets are frail creatures. Errors can creep in fairly easily, even for experienced users, as data and circumstances change, and spreadsheets are especially prone to the incursion of silent errors and omissions when undergoing revision.  And once implemented, in all their imperfection, spreadsheet-based solutions can broaden and become large-scale, long-term systems (I’ve seen this happen again and again).

Yet, I feel that every technology executive should be maximally fluent in spreadsheeting: simple tracking, analyzing, modeling alternatives, understanding costs and risks. The technology provides a readily available, easy way to knock out quick and dirty models that can clarify one’s thinking and approach enormously. They work well, as long as you keep in mind that the spreadsheet is usually a stop-gap, for those times when you are faced with a glaring need and you don’t have time, budget, or staff to implement anything deeper right away.

In an early blog post, I listed the seven areas where a quantitative approach is especially necessary for the technology executive:

[Read more…]

Filed Under: Financial, Metrics, Process, Role definition, Tools
By

26 Comments

Simple, more practical approaches to actual resource allocation

Anyone ever tell you that a simpler approach can often work better than a more complex one? Whoever it was, it probably wasn’t a project management software vendor.  But simplicity has its merits, and I’d like to point out a few of these when it comes to resource allocation.

Project management, at its core, is largely about resource allocation, and this gets tricky when you have multiple projects going on, as most organizations do. Almost as much as I’ve seen organizations drop the ball entirely on cross-project resource allocation (essentially, simply pretending that there will be no contention issues), I’ve seen organizations go to the other extreme: they dive into the depths of intense Project Management, in capital letters: taken too far too fast, this approach can spin up to a high level of rigor and overhead, involving often-expensive software packages, precise low-level estimates, diligent collection of actuals, and ornate project calculations of hours burned and hours earned.  At the end, there you stand, like Goethe’s Faust, “no wiser than before.”

[Read more…]

Filed Under: Pillars of Purview, Projects, Tools, Top 25 posts Tagged With: , , , , , ,
By

7 Comments

The Practical CIO: Difficulties in project prioritization & selection, part 2

OK, let’s assume you’ve gotten great at picking the right projects to do to benefit the company. How do you know you can actually accomplish the ones you’ve picked with the resources you have? If you’re like most companies I’ve seen, it’s done on a wing and a prayer. But there’s a better way.

Last time, I wrote about ways to pick projects that satisfy the company’s “SHOULD do” dimension: ones that are strategic, financially beneficial, risk mitigating, or legally mandated, for example. I set out practical guidelines for the process of selection in that dimension, to ensure as level a playing field as is possible.  And I left it for this follow-on post to discuss prioritization from the perspective of the other dimension, the “CAN do” dimension, which needs to calibrate the list of chosen projects to what can actually be accomplished by the available resources.

Both dimensions inform each other, of course; they’re not independent or sequential. In other words, the company might be able to tackle five smaller projects rather than one huge project, and figuring out if it’s a good idea to actually make that trade-off will be based on executive judgment of the benefits in both scenarios.
[Read more…]

Filed Under: Pillars of Purview, Process, Projects, Stakeholders, Tools, Top 25 posts
By

Start simple: a corporate desktop/laptop refresh model

Here’s a topic that frankly shouldn’t even merit a post — it’s that much of a no-brainer if you think about it.

Yet, in the real world, I’ve found that it’s anything but a no-brainer, at both small and large companies.  What I’m referring to is the need for organizations to track their laptops and desktops.

Shockingly, many/most organizations don’t do even close to a satisfactory job at this.  The U.S. State Department recently made the news for losing track of as many as 10,000 laptops.

OK, chalk that up to government, perhaps.  But admittedly, in any bustling, active enterprise, keeping tabs on machines, and who’s using what, isn’t a cakewalk. Even Microsoft has its issues in this arena, and turns to “rolling its own” applications as a stopgap.

Astonishingly, most organizations I’ve observed:

  • Don’t know how many machines they actually have
  • Don’t know their current penetration of laptops vs. desktops
  • Tend to budget by the seat of their pants for replacements for the coming year
  • Can’t tell you precisely where a specific purchased asset has been deployed
  • Don’t know the “aging profile” of their population of desktops and laptops (e.g., how many are more than a year old)
  • Don’t relate the actual handling of the asset (e.g., replacement after three years) to the financial handling (e.g., spreading the capital expense over three years from an accounting perspective). Replacement tends to be demand-driven, meaning (usually) crisis-driven.
  • Don’t have a solid process, or any process, for decommissioning a machine that is past its useful life.
  • Don’t have the ability to tell a given employee when his or her machine will be replaced.

[Read more…]

Filed Under: Pillars of Purview, Process, Tools, Top 25 posts
By

4 Comments

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.

[Read more…]

Filed Under: Financial, Metrics, Pillars of Purview, Process, Tools
Mastodon