Dear Dr. Yeahbut …
Okay, I get it. APR (Application Portfolio Rationalization) is only half of straightening out the application layer of my organization’s technical architecture. I understand we also need holistic design as a complementary approach to figuring out which applications we need to support, and you gave enough hints last week that my team and I can figure that part out.
I think we’ve also figured out how to integrate APR and holistic design. Check me on this: We treat each business functional area’s applications as a separate “sub-portfolio,” and perform separate APRs on each of them. And for the bigger business functions we split them down more, into sub-sub-portfolios, assigning health scores and dispositions to the applications in each of them.
Are we close?
And we have one more question: Last week you said there’s a lot more to the APR story than integrating it with holistic design and producing a remediation roadmap.
But just the thought of what’s needed for the remediation roadmap is enough to make my head hurt.
So c’mon, give us a break. Or at least a hint.
– Seeker of More Free Wisdom
Seeker …
So far as integrating APR and holistic design you’re on the right track. There’s a lot more to it than that … establishing, a small but powerful set of design principles (whether you’re implementing a hub-and-spoke vs federated architecture, for example), and agreeing on the criteria that make an application healthy … but you’ve made a good start of it.
But then there’s the APR roadmap. The secret to success: don’t create one.
Feel better?
It’s an Agile vs Waterfall kind of thing. It’s also a project-orientation vs operations-orientation kind of thing.
Imaging you’ve just wrapped up your APR/holistic design project, complete with a well-defined and designed remediation roadmap.
Now what?
The answer, more often than not, is nothing. It’s nothing because of a business construct you might have heard of, namely, the budget.
Long before your APR roadmap came along, the company’s queue of proposed projects already had enough in it to completely consume three to five years worth of the budget and staff effort needed to clear it.
If your company is like most, there isn’t a dime left in the pot to execute your roadmap.
Which leaves you with three choices:
Freeze: Put a bunch of projects already in the queue on hold for a few of years to clear space for the APR roadmap.
Refocus: Redefine the APR roadmap so it’s purpose is business optimization by way of removing whatever barriers the current application portfolio imposes on effective business functioning.
Agility: Recognize that an APR roadmap is, at its core, a Waterfall approach to planning change, replete with the usual line-up of Waterfall fallacies. but in particular the fallacy that a two- or three-year change plan is predicated on the assumption that business planners can accurately forecast now what the business will need three or more years from now.
Freeze isn’t going to happen. The already-approved projects in the queue were approved because they promise to deliver clear, identifiable business value, and will deliver it to executives who have quite a lot more clout than the CIO.
Refocus should have been in the APR charter all along: Identifying where application limitations drive process limitations means APR isn’t an engineering sales pitch. It’s a revenue enhancement, cost reduction, and improved risk management sales pitch.
That leaves Agility. The way that works is to view the application sub-portfolios and sub-sub-portfolios the way you view Agile epics, and the individual applications and their dispositions the way you view Agile user stories.
Bob’s last word: If you’re going to go through the time and effort of assessing your applications portfolio your analysis had better include how each application contributes to the health and effectiveness (or the ill-health and ineffectiveness) of the business processes, practices, and functions it supports.
Combine that perspective with Agile planning and your problem won’t be a roadmap you’ll never get approved.
It will be a backlog you can’t clear fast enough.
Bob’s sales pitch: Want more insights into how to apply Agile thinking to more than application development? You need chapter 3 – “Fixing Agile” – of There’s No Such Thing as an IT Project.
After more than 25 years as an IT project manager, this week’s post explains why I retired last week. I spent my career understanding the ever-changing needs of the business and coordinating IT resources to ensure that systems helped the organization meet those needs.With no budget and no resources available to achieve any of our APR plans, along with business-unit leadership who can’t be bothered to understand why strong IT infrastructure is mandatory to the success of the entire operation, I couldn’t beat my head against the wall any longer. I truly loved my job up until about 10 years ago, but there is no amount of “agile planning” that can make up for the short-sighted, narrow-focused, and ill-informed decisions that today’s business leaders choose to make. Apparently today’s MBA programs and leadership training programs fail to teach them why a functional understanding of information technology is important to their success.
Just think how interesting it is for these same business leaders to make sense of “digital.”