When you buy your next smartphone, what features will you compare to make your decision?

So far as I can tell, the dominant contrasts appear to lie in their cameras – cutting edge smartphones have, in addition to their main camera, ones for wide-angle, telephoto, and front-facing (selfie-mode).

Add to that a bunch of different image manipulation features and you have a complex comparison.

Next question: When you buy your next point-and-shoot camera, what features will you compare to make your decision?

Answer: Most likely you won’t buy your next point-and-shoot camera. You’ll upgrade your smartphone instead, and for higher-end photography you’ll buy a DSLR.

As a category, point-and-shoot cameras are, along with Monty Python’s famous Norwegian blue parrot, on the way to joining the choir invisible. Steadily-improving smartphone cameras are rapidly extinguishing them, just as steadily-improving digital cameras extinguished those that use film.

Which will get us to this week’s topic in a moment, right after we ask ourselves whether better product management on Nikon, Canon, or Olympus’s part might have staved off this category calamity.

The answer: Probably not. Product management is an in-category discipline, which is why Canon’s product line dominates the DSLR marketplace but doesn’t provide OEM componentry for any smartphone. More broadly, it’s why the major camera companies didn’t add telephone-oriented features to their point-and-shoot cameras.

Which (finally!) brings us to this week’s topic: Whether IT should organize according to software product management principles rather than software project principles (see, for example, this lucid explanation on martin.Fowler.com).

The answer? No, but IT shouldn’t continue to organize around software projects, either. As all enlightened members of the KJR community (if you’ll forgive the redundancy) know, there’s no such thing as an IT project. It’s always around business change or what’s the point?

Organizing IT around IT products is certainly better than organizing it around IT projects … product-mode thinking does expressly incorporate business improvement into its planning and governance practices, more easily incorporates agile thinking into the mix, and solves the problem of maintaining a stockpile of expertise instead of disbanding it once the initial implementation project has completed.

On the other hand, most agile variants keep teams in place until the backlog has shrunk beyond the point of diminishing returns, so this last “benefit” is something of a strawman.

Meanwhile, the product perspective brings with it a potentially crippling disadvantage – the inevitability of internal competition. Here’s how it works:

Imagine you’re the product manager for your company’s in-house-developed, highly optimized, strongly supported SCM (supply chain management) system. You and your team have deep expertise in its workings, which lets you respond quickly and efficiently when business needs change or new needs arise.

Meanwhile, as a result of several mergers and acquisitions, three other business units also have SCM systems and supporting teams, each with capabilities roughly comparable to what your team brings to the table.

And so, the CIO and IT planning committee decide it’s time to rationalize the applications portfolio, building out the architecture to a hub-and-spoke model anchored by Oracle ERP Cloud (this is, understand, just a ferinstance, not an endorsement).

Suddenly, your team’s expertise is irrelevant. And so, being savvy at the game of corporate politics, you invite the head of your business unit’s supply chain function to join you for conversational lubricants, in which conversation you explain the disadvantages of forcing his team to use a software vendor’s plain-vanilla SCM module instead of the finely-tuned application they’re used to.

Describing how this scenario plays out is left as an exercise for the reader. Suffice it to say, it wouldn’t be pretty.

Bob’s last word: More problematic than everything else, the product perspective leaves in place defining IT’s relationship with the rest of the business as a vendor dealing with internal customers. This is a bad idea, something I’ve been explaining since1996.

IT should be organized to support business optimization, where each business function defines optimization according to what it will take for it to run differently and better, and the company defines IT’s relationship with the rest of the business as partner and collaborator in delivering profitable value to Real Paying Customers.

Bob’s sales pitch: Not the first time I’ve mentioned this, and it won’t be the last – you’ll find an in-depth explanation of how to make this work in There’s no such thing as an IT Project: A handbook for intentional business change. And it isn’t just in-depth coverage of content that matters. Dave and I took pains to make sure it’s readable, too.

I’ve been heavily involved in application portfolio rationalization and management (APR and APM) over the past few years. They’re complex disciplines. As a consultant, I don’t mind a bit.

In case you aren’t familiar with APR and APM:

What’s the point? Rationalizing the applications portfolio accomplishes several useful results, among them identifying and making plans for dealing with: (1) unused applications that should be decommissioned; (2) weak applications that should be improved or replaced; (3) redundant applications that should be consolidated.

That’s APR. APM? The point of establishing an ongoing application portfolio management practice is to make sure the company doesn’t recreate the applications mess once the APR process has cleaned it up.

Why “portfolio”? APR and APM are built around the idea that your applications portfolio is analogous to an investment portfolio. The corporation invests in it and expects a return.

Also, like the funds and equities that make up a portfolio of financial investments, some applications are stronger than others. The mix continually shifts as time passes, and so, just as a fund manager sells weakening equities and buys newly promising ones, the application portfolio manager should constantly re-evaluate the applications that make up the company’s application investment portfolio.

It’s a persuasive argument, to the extent that arguing by analogy is ever persuasive. But it fails on three fronts (at least).

First, in a portfolio of financial investments, each individual holding has a market value that’s its only value. But in an application portfolio, holdings have value to the extent they support business capabilities, functions, processes, and practices.

Which means determining the financial value of an individual application is a challenging exercise in creative metrics. Unless some other topic distracts me, we’ll talk about this in more depth in future columns.

Second: The holdings that make up an investment portfolio are not dependent on each other. You can sell one without that sale having even a slight impact on the value of any of the others … unless, of course, you’re Warren Buffett and lots of other people pay attention to your investment decisions. (If you are Warren Buffett … call me.)

Where was I? That’s right: Independence. In an application portfolio, few “holdings” are entirely independent of other applications in the portfolio. You can’t just sell one that’s underperforming and expect everything else to seamlessly continue, nor can you add one without having to integrate it into others.

The Department of Redundancy and Duplication Department

Imagine you undertake a thorough APR assessment. Among the findings, you find seven different raw materials inventory management systems. Clearly, you need to establish a standard — either one of the seven, or an entirely new one — and consolidate.

Clearly, that is, until you take a closer look and realize each came along with one of seven business acquisitions that occurred over the past few years.

Consolidating inventory management systems means one of two alternatives — either standardizing the inventory management process across the seven independent business units that use them, or implementing an inventory management system that’s flexible enough to accommodate seven different ways of managing inventories.

Except that by the time you’ve achieved that level of flexibility the result might be just as difficult to support as, and far more disruptive than leaving the seven systems you have alone.

There’s no such thing as rationalizing the applications portfolio. My major premise is that there’s no such thing as an IT project. My minor premise is that rationalizing the applications portfolio would amount to chartering a bunch of IT projects. My conclusion: There’s no such thing as rationalizing the applications portfolio. Q.E.D.

Every single application in the portfolio is embedded in business functioning somewhere in the enterprise. Change any holding in the portfolio and you change how the business runs.

Oh, and, by the way, if you’re IT and want to rationalize the application portfolio, the portfolio changes had better result in more efficient and effective business functioning, because … aw, c’mon, you don’t need me to spell this out for you, do you?

Why not start with APM?

Here’s another binary choice in your APR/APM decision tree: You can rationalize the portfolio (APR) and then institute the means for preventing a recurrence of the problems you undertook the APR to solve (APM). Or, you can institute an APM practice and put it in charge of rationalizing the portfolio. It’s iterative and incremental APR.

APR first means documenting the current state, designing the desired future state, and planning a program to close the gap. APM first means constantly achieving better but never getting to best. But as the definition of “best” constantly changes, achieving it couldn’t be done anyway.

The KJR Conclusion: Better is better than best.

# # #

Do I have to say this? If you need help rationalizing your company’s applications portfolio, let’s talk. Because if you call anyone else you’ll hurt my feelings!