The CIO Transformation Fieldbook Model
Gemini Prompt
As the new CIO for a struggling and troubled technology organization, what improvement model or methodology should I use to understand the key organizational deficiencies and execute a plan to improve and modernize the organization?
Gemini Response
To move a "troubled" organization from chaos to a modernized, high-performing state, the most comprehensive and battle-tested methodology is the IT Capability Maturity Framework (IT-CMF).
While COBIT or ITIL are great for specific controls, IT-CMF is designed specifically for CIOs to manage the "Business of IT." It treats IT as a value-creating entity rather than just a cost center.
1. The Diagnostic: IT-CMF (IT Capability Maturity Framework)
Developed by the Innovation Value Institute (IVI), this framework maps 35 Critical Capabilities (CCs) across four macro-processes. In a struggling org, you don't look at all 35; you focus on the "Emergency Room" categories:
Managing the IT Budget: Is money leaking into "zombie" projects?
IT Governance: Who actually makes decisions? (In troubled orgs, it’s usually "whoever screams loudest").
Capacity Planning: Is the team burned out because they are over-committed?
Solutions Delivery: Why are projects always late?
2. The Execution: The "Three Ways" of DevOps
Modernization isn't just buying new servers; it’s changing how work flows. Use the Three Ways (from The Phoenix Project methodology) to restructure your execution:
The First Way (Flow): Understand the "Value Stream." Visualize work using Kanban boards. Identify bottlenecks. If testing takes 3 weeks and coding takes 3 days, your deficiency isn't the developers—it's the QA process.
The Second Way (Feedback): Shorten the feedback loops. In a troubled org, problems are often hidden for months. Create a culture where "bad news travels fast."
The Third Way (Continuous Learning): Allocate 20% of all cycles to paying down technical debt. If you don't, the "interest" on that debt (maintenance and outages) will eventually consume 100% of your budget.
3. The Modernization Strategy: Wardley Mapping
To modernize, you must stop "reinventing the wheel." Use Wardley Mapping to categorize your technology stack based on its evolution:
Commoditize the Mundane: If you are managing your own email servers or basic data centers, stop. Move these to Cloud/SaaS (Commodity).
Focus on the Differentiator: Shift your best engineers away from maintenance and toward "Genesis" or "Custom" projects that actually help the company win in its specific market.
4. The Cultural Bridge: The ADKAR Model
Modernization fails because of people, not technology. Use the ADKAR model for Change Management to transition your staff:
Awareness: Do they know why the org is struggling?
Desire: Do they want to change? (Address "What's in it for me?").
Knowledge: Do they know how to use the new modern tools?
Ability: Can they implement it in their daily work?
Reinforcement: How do you keep the old, bad habits from creeping back?
Discussion
Gemini offers some great tips and resources that are consistent with prevailing models and approaches. IT-CMF is a great way to comprehensively understand and diagnose the technology organization, ensure that all areas of the organization are being looked at, and target specific areas for improvement based on maturity level. It offers an approach to analyze each IT function and make sure that nothing is missed. However the scope of the assessment across 35 capabilities implies a significant and lengthy effort and as a new CIO, you won’t have the time. It is helpful that four emergency room categories are offered (Budget, Governance, Capacity, and Delivery) as these are often key pain points that should absolutely be included as priorities in the improvement cycle. DevOps (or DevSecOps) and Wardley Mapping are useful techniques and practices that will be part of the modernization (if they are not already in use). ADKAR is a great way to manage change as personnel transition from the As-Is to the To-Be. The models offer interesting approaches but they don’t help determine what needs to be done and how to get it done (how to accomplish and get results). They are both too tactical and too conceptual at the same time. There needs to be an over-arching improvement methodology to identify, align, and execute to achieve results.
The reason for methodology and method is to bring order to the chaos. It’s like needing some jam at the grocery store, you go and there are hundreds of choices. How do you even make a selection? You feel paralyzed and start creating decision criteria on attributes like flavor, ingredients, labeling, quantity and cost. Maybe you have used a prior brand that tasted good, so you are more likely to select a product from that brand. As you consider continuous improvement methodologies, there are probably hundreds out there to choose from, but they all do pretty much the same thing. There is a study phase to figure out the situation, a planning phase to figure out what to do next, an execution stage to take action on the plan, and a measurement phase to assess results. What matters is that you have a method and most importantly, that you use the method. My method to create a process to transform a troubled project or underperforming organization into a high-performing one is called ADBEM (Analyze, Determine, Build, Execute, Measure). Many improvement methods lack the Build component. The Build phase is incredibly important because if we can’t build the people, process, and technology capabilities to do the work, then the improvement efforts will fail. At a high level, you need to:
Analyze the current state and define a future state
Determine and plan the improvement opportunities
Build necessary capacity and capability
Execute improvement efforts to address the deficiencies and exploit the opportunities
Measure and report results
Then do it all over again…a lot.
All improvement methods are derivatives of the scientific method. From Google Gemini, the scientific method is a systematic, iterative process used by scientists to explore observations and answer questions. Rather than a rigid set of steps, it is a flexible framework designed to minimize bias and ensure that conclusions are supported by evidence. I suspect that many of us remember the scientific method from our middle school science projects. The Core Steps of the Scientific Method are:
Observation: It begins with noticing a phenomenon or a problem that needs solving. (e.g., "The plants in the shade are smaller than those in the sun.")
Question: Define a specific, measurable question based on the observation. (e.g., "Does the amount of sunlight affect plant height?")
Hypothesis: Formulate a testable explanation or prediction. This is often written as an "If... then..." statement.
Experimentation: Design and conduct a controlled test to gather data. This involves identifying variables:
Independent Variable: The factor you change (e.g., sunlight).
Dependent Variable: The factor you measure (e.g., height).
Control Group: The group that remains under standard conditions for comparison.
Data Analysis: Collect the results and use statistics or logic to see if there is a significant pattern.
Conclusion: Determine if the data supports or refutes the hypothesis. If the hypothesis is refuted, scientists often develop a new one and start the process again.
Communication: Share the findings with the scientific community for peer review and replication.
When we apply the scientific method to an organization, we tailor the steps. My tailored process is called ADBEM. When this happens throughout the team or organization, then the environment is created to produce meaningful results at scale. The executive team will apply this process to their mission areas. The middle managers and project managers will apply this process at a smaller scale to their teams.
A key addition that I don’t typically see in other continuous improvement models is the addition of the “Build” phase. Organizations are not non-performing by choice. Staff want to do a good job and please their customers. Something is missing that is holding them back. Additional capability and capacity building of processes, technology, and people are needed to address unmet needs. Sometimes we need to make hard decisions to cancel initiatives to allow us to focus on the highest value opportunities. People are stuck in their own self-defined worlds and lack the ability to break out and chart a different path to a better future. I recently watched a documentary about orchards and saw how the staff culled new growth to focus the tree on producing the largest and highest value fruit. We need to cull excessive technology initiatives to deliver the highest value technology products and solutions.
The reality is that lots of tools and models will be used to transform a large technology organization. The IT-CMF may be used as part of the current and future state definition. DevOps and Wardley Mapping may become a subset of the improvement opportunities identified and selected for implementation. ADKAR will be a necessary part of the execution of the improvement efforts as people are affected by the changes introduced. Other methods and models like ITIL, CMMI, Agile, and NCSF may be used as well. As we will describe in later chapters, we will explain how to interlock the various concepts, models, and efforts to scale at the enterprise.
This cycle of ADBEM (Analyze, Determine, Build, Execute, Measure) repeats throughout this website in various domains (people, process, technology, financial) and in various contexts. It seems simple because it is simple (just five phases) however, like common sense, applying it can be far from simple and common. For example, many technology organizations struggle with goals, measurement and reporting results. Technology work can be messy and sometimes unpredictable. It is not uncommon to start a project or effort without knowing the details of how it will be accomplishments or even have clarity on the end state. Sometimes the requirements are vague and we are concerned that if we set goals and measure, then we will be held accountable for something beyond our control and we will fail. Though that seems logical, the result of not having goals is that it is then impossible to achieve the goals. Delivery is occuring in a vacuum and in many cases, the results will go unnoticed and unrecognized. Unstated goals can’t be achieved.
This website is targeted at improving underperforming technology organizations. The ADBEM cycle is a great general purpose continuous improvement cycle and it works well at the team and even project level. However, when transforming a more complex organization such as a multi-million (or multi-billion) dollar program, a national practice, or a large technology organization then greater guidance is needed. The ADBEM cycle has been scaled up to address the greater complexity and messiness of transforming a larger organization. Each chapter explains a phase of the methodology and the methodology as a whole is designed to be completed within a year (or annual budget cycle). At scale, the methodology phases are the following:
Identify The Problem
Secure The Right Leadership
Assess The Situation
Stop The Bleeding
SMART Strategy, Goals, and Objectives
Organize To Achieve
People Modernization
Process Modernization
Technology Modernization
Financial Modernization
Managing The Brand
The scaled technology organization methodology (TOM) is notionally designed for a one year cycle which aligns with a standard annual budgetary cycle. Depending on the organizational scale, cycle, and complexity, it can be expanded or compressed. However, I advise that the timeline be kept under a year to demonstrate results more quickly and build confidence internal and external to the organization.
The two models shown (ABDEM and TOM) represent a way of looking at the challenging of technology organizational transformation and breaking that effort into more manageable components and ordering the work over time. There are many other resources that should also be looked at. Gartner offers a 30-60-90 day faststart. Info Tech Research Group offers organizational templates and accelerators. It matters less about what methodology or model you select. It matters most that you have a methodology or model.