Business Transformation Requires Transformational Leaders

Building and enterprise architecture are two aspects of the same concern: How do we see the bigger picture? How do we oversee and integrate a wide range of diverse components into a single, unified whole?

In this article, I will explain how to get business engagement and “buy-in” to remove technology debt using existing IT processes such as the quarterly/annual ­budgeting process, design reviews, and functional walkthroughs. To obtain funding and business sponsorship for TD remediation projects, it is important to get non-IT executives to understand and support the TD remediation challenges. Understanding how technology debt is created is essential to preventing, containing, and retiring the debt.

Twenty years ago in May, the American Academy of Political and Social Science published a special issue of its periodical The Annals that focused on the challenges in risk assessment and risk management, especially within government. The premise of that highly influential issue was that assessing risk needed a new perspective; one that went beyond the methodical quantification of risk prevalent at the time to one that encompassed “the complex psychological, social,

With Goal #1, we've found an approach that helps us deal with specific challenges within the company. It's not perfect, and it certainly comes with a price. Therefore, we will continue to develop the format even further. 

Making decisions without important information can result in poor choices. That is especially true with respect to technical debt. Using a technical debt framework to inform our decision making is a powerful technique to help us quickly and confidently make better judgments. I’ve worked with numerous organizations that have benefited from understanding their technical debt this way, and in this article, John Heintz shares stories about three different clients and how they were able to make good decisions for their businesses based on the data found during technical debt assessments.

Buy-in has been the mantra for consultants for as long as I can remember. Besides “walk the talk” and “be the change,” “getting buy-in” has been the most overused and misguided principle ever to haunt the halls of organizational development. If I sound jaded, I am. I’m tired of the blame game. I’m tired of fixes that are more simple than possible.

Technology backlash is as old as technological innovation. It is inevitable that people will grouse about new technologies and adopt them with varying degrees of acceptance. Yet, with one caveat, the cool stuff will take hold and prevail on the basis of its functionality and actual worth to people. The caveat is that this will happen only if these products do not give people some absurd reason to do a double-take and say, "What? You didn't tell me this amazing product" -- and here, take your pick -- "uses triangulation to share my location with perverts," "shares my aimless meandering around department store aisles with marketers," "leaves my television camera running," or "records my child babbling away to a beloved toy."

Agile as a concept and as a "method" is invaluable. But have you ever wondered how Agile itself was developed? Did the signatories to the Agile Manifesto use an "Agile approach" to arrive at the manifesto? The science of methods has this age-old conundrum: which method was used to develop a method? And how was that method validated? I share my thoughts with you in this Advisor.