Visualizing Experience

“Are we set up for success?”

This is a question that I’ve heard asked many times, particularly when there is a strategic initiative or transformation effort being kicked off. Normally, the answer is an enthusiastic “Yes”, because most programs start with a lot of optimism (which is a good thing), but not always a full understanding of risk. The question is… How do you know whether you have the necessary capabilities to deliver?

In any type of organization, there is a blend of skills and experience, whether that is across a leadership team or within an individual team itself. Given that reality and the ongoing nature of organizations to evolve, realign, and reorganize, it is not uncommon to leverage some form of evaluation (such as a Kolbe assessment) to understand the natural strengths, communication, or leadership styles of various individuals to help facilitate understanding and improve collaboration.

But what about knowledge and experience? This part I haven’t seen done as often partially because, if not done well, it can lead to a cumbersome and manually intensive process that doesn’t create value.

The focus of this article is to suggest a means to understand and evaluate the breadth of knowledge and skills across a team. To the extent we can visualize collective capability, it can be a useful tool to inform various things from a management standpoint, which are outlined in the second section below.

Necessary caveats: The example used is not meant to be prescriptive or exhaustive and this activity doesn’t need to be focused on IT alone. The goal in the illustration used here was to provide enough specificity to help the reader visualize the concept at a practical level, but the data is entirely made up and not meant to be taken as a representation of an actual set of people.

On the Approach

Thinking through the Dimensions

The diagram above breaks out 27 dimensions from a knowledge and skills standpoint, ranging from business understanding to operations and execution. The dimensions chosen for the purposes of this exercise don’t particularly matter, but I wanted to select a set that covered many of the aspects of an IT organization as a whole.

From an approach standpoint, the goal would be to identify what is being evaluated, select the right set of dimensions, define them, then determine “what good looks like” in terms of having a baseline for benchmarking (e.g., 10 means X, 8 means Y, 6 means Z, etc.). With the criteria established, one should then explain the activity to the group being evaluated, prepare a simple survey, and gather the data. The activity is meant to be rapid and directionally accurate, not to supplant individual performance evaluations, career development, or succession plans that should exist at a more detailed level. Ideally the dimensions should also align to the competency model for an organization, but the goal of this activity is directional, so that step isn’t critical if it requires too much effort.

Once data has been collected, individual results can be plotted in a spider graph like the one below to provide a perspective on where there are overlaps and gaps across a team.

Ways of Applying the Concept

With the individual inputs from a team having been provided, it’s possible to think about the data in two different respects: how it reflects individual capabilities, gaps, and overlaps as well as what it shows as the collective experience of the team as a whole (the green dotted outline above).

The data now being assembled, there are a number of ways to potentially leverage the information outlined below.

Talent Development: The strengths and gaps in any individual view can be used to inform individual development plans or identify education needs for the team as a whole. It can also be used to sanity check individual roles and accountability against the actual experience of individuals on the team. This isn’t to suggest rotations and “learn on the job” situations aren’t a good thing, but rather to raise awareness of those situations so that they can be managed proactively with the individual or the team as a whole. To the extent that a gap with one person is a strength in another, there could be cross-training opportunities that surface through the process.

Coordination and Collaboration: With overlaps and gaps visible across a team, there can be areas identified where individual team members see opportunities to consult with others who have a similar skillset, and also perhaps a different background that could surface different ways to approach and solve problems. In larger organizations, it can often be difficult to know “who to invite” to a conversation, where the default becomes inviting everyone (or making everyone ‘mandatory’ versus ‘optional’), which ultimately can lead to less productive or over-attended conversations that lack focus.

Leaders and Teams: In the representative data above, I deliberately highlighted areas where team members were not as experienced as the person leading the team, but the converse situation as well. In my experience, it is almost never the case that the leader is the most experienced in everything within the scope of what a team has to do. If that was the case, it could suggest that the potential of that team could be limited to that leader’s individual capabilities and vision, because others lack the experience to help inform direction. In the event that team members have more experience than their leader, there can also be opportunities for individuals to step up and provide direction, assuming the team leader creates space and a supportive environment for that occur. Again, the point of the activity is to identify and determine what, if anything, to do with these disparities where they exist.

Sourcing Strategy: Where significant gaps exist (e.g., there is no one with substantial AI experience in the example data above), these could be areas where finding a preferred partner with a depth of experience in the topic could be beneficial while internal talent is acquired or developed (to the extent it is deemed strategic to the organization).

Business Partnership: The visibility could serve as input to a partnership discussion to align expectations for where business leaders expect support and capability from their technology counterparts versus areas where they are comfortable taking the lead or providing direction. This isn’t always a very deliberate conversation in my experience, and sometimes that can lead to missed expectations in complex delivery situations.

Risk Management: One of the most important things to recognize about a visualization like this is not just what it shows about a teams’ capability, it’s also what isn’t there.

Using Donald Rumsfeld’s now famous concept:

There is known – something for which we have facts and experience
There is known unknown – something we know is needed, but which is not yet clear
And the pure unknown – something outside our experience, and therefore a blind spot

The last category is where we should also focus in an activity like this, because the less experience that exists individually and collectively in a leadership team, there will be a substantial increase in risk because there is a lack of awareness of all the “known unknowns” that can have a material impact on delivering solutions and operating IT. To the extent that a team is relatively inexperienced, no matter how motivated they may be, there is an increased probability that something will be compromised, whether that is cost, quality, schedule, morale, or something else. To that end, this tool can be an important mechanism to identify and manage risk.

Wrapping Up

Having recently written a fairly thorough set of articles on the future of enterprise technology, I wanted to back up and look at something a little less complex, but also with a focus on improving transparency and informing leadership discussions on risk, development, and coordination.

Whether through a mechanism like this or some other avenue, I believe there is value in understanding the breadth of capabilities that exist within a team and across a leadership group as a means for promoting excellence overall.

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 08/24/2025

The Intelligent Enterprise 2.0 – IT Organizational Implications

“Go West, Young Man”

I remember a situation where an organization decided to aggressively offshore work to reduce costs. The direction to IT leaders was no different than that of the Gold Rush above. Leaders were given a mandate, a partner with whom to work, and a massive amount of contracting ensued. The result? A significant number of very small staff augmentation agreements (e.g., 1-3 FTEs), a reduction in fixed, but a disproportionate increase in variable operating expenses, and a governance and administrative nightmare. How did it happen? Well, there was leadership support, a vision, and a desired benefit, but no commonly understood approach, plan, or governance. The organization then spent a considerable amount of time transitioning all of the agreements in place to something more deliberate, establishing governance, and optimizing what quickly became a very expensive endeavor.

The requirements of transformation are no different today than they ever have been. You need a vision, but also the conditions to promote success, and that includes an enabling culture, a clear approach, and governance to keep things on track and make adjustments where needed.

This is the final post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”. The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

Overall Approach

Writing about IT operating models can be very complex for various reasons, and mostly because there are many ways to structure IT work based on the size and complexity of an organization, and there is nothing wrong with that in principle. A small- to medium-size IT organization, as an example, likely has little separation of concerns and hierarchy, people playing multiple roles, a manageable project portfolio, and minimal coordination required in delivery. Standardization is not as complex and requires considerably less “design” than a multi-national or large-scale organization, where standardization and reuse needs to be weighed against the cost of coordination and management involved as the footprint scales. There can also be other considerations, such as one I experienced where simplification of a global technology footprint was driven off of operating similarities across countries rather than geographic or regional considerations.

What tends to be common across ways of structuring and organizing is the various IT functions that exist (e.g., portfolio management, enterprise architecture, app development, data & analytics, infrastructure, IT operations), just at different scales and levels of complexity. These can be capability-based, organized by business partner, with some centralized capabilities and some federated, etc. but the same essential functions likely are in place, at varying levels of maturity and scale based on the needs of the overall organization. In multi-national or multi-entity organizations/conglomerates, these functions likely will be replicated across multiple IT organizations with some or no shared capability existing at the parent/holding company or global level.

To that end, I am going to explore how I think about integrating the future state concepts described in the earlier articles of this series in terms of an approach and conceptual framework that, hopefully, can be applied to a broad range of IT organizations, regardless of their actual structure.

The critical challenge with moving from our current environment to one where AI, apps, and data are synthesized and integrated is doing it in a way that follows a consistent approach and architecture while not centralizing so much that we either constrain progress or limit innovation that can be obtained by spreading the work across a broader percentage of an organization (business teams included). This is consistent with the templatized approach discussed in the prior article on Transition, but there can be many ways that that effort is planned and executed based on the scale and complexity of the organization undertaking the transformation itself.

Key Considerations

Define the Opportunities, Establish the Framework, Define the Standards

Before being concerned with how to organize and execute, we first need to have a mental model for how teams will engage with an AI-enabled technology environment in the future. Minimally, I believe that will manifest itself in four ways:

Those who define and govern the overall framework
Those who leverage AI-enabled capabilities to do their work
Those who help create the future environment
Those who facilitate transition to the future state operating model

I will explore the individual roles in the next section, but an important first step is defining the level of standardization and reuse that is desirable from an enterprise architecture standpoint. That question becomes considerably more complex in organizations with multiple entities, particularly when there are significant differences in the markets they serve, products/services they provide, etc. That doesn’t mean, however, that reuse and optimization opportunities don’t exist, but rather that they need to be more thoughtfully defined and developed so as not to slow any individual organization down in their ability to innovate and promote competitive advantage. There may be opportunities to look for common capabilities that make more sense to develop centrally and reuse that can actually accelerate speed-to-market if built in a thoughtful manner.

Regardless of whether capabilities in a larger organization are designed and developed in a highly distributed manner, having a common approach to the overall architecture and standards (as discussed in the Framework article in this series) could be a way to facilitate learning and optimization in the future (within and across entities), which will be covered in the third portion of this article.

Clarify the Roles and Expectations, Educate Everyone

The table below is not meant to be exhaustive, but rather to act as a starting point to consider how different individuals and teams will engage with the future enterprise technology environment and highlight the opportunity to clarify those various roles and expectations in the interest of promoting efficiency and excellence.

While I’m not going to elaborate on the individual data points in the diagram itself, a few points to note in relation to the table.

There is a key assumption that AI-related tools will be vetted, approved, and governed across an enterprise (in the above case, by the Enterprise Architecture function). This is to promote consistency and effectiveness, manage risk, and consider issues related to privacy, IP-protection, compliance, security, and other critical concerns that otherwise would be difficult to manage without some formal oversight.

It is assumed that “low hanging fruit” tools like Copilot, LLMs, and other AI tools will be used to improve productivity and look for efficiency gains while implementing a broader, modern and integrated future state technology footprint with integrated agents, insights, and experts. The latter of these things has touchpoints across an organization, which is why having a defined framework, standards, and governance are so important in creating the most cost-effective and rapid path to transforming the environment to one that create disproportionate value and competitive advantage.

Finally, there are adjustments to be made in various operating aspects of running IT, which is to reinforce the idea that AI should not be a separate “thing” or a “silver bullet”, it needs to become an integrated part of the way an organization leverages and delivers technology capabilities. To the extent it is treated as something different or special and separated from the ongoing portfolio of work and operational monitoring and management processes, it will eventually fail to integrate well, increase costs, and underdeliver on value contributions that are widely being chased after today. Everyone across the organization should also be made aware of the above roles and expectations, along with how these new AI-related capabilities are being leveraged so they can help identify continuing opportunities to leverage and improve their adoption across the enterprise.

Govern, Coordinate, Collaborate, Optimize

With a model in place and organizational roles and responsibilities clarified, there needs to be a mechanism to collect learnings, facilitate improvements to the “templatized approach” referenced in the previous article in this series, and drive continuous improvement in how the organization functions and leverages these new capabilities.

This can be manifest in several approaches when spread across a medium to large organization, namely:

Teams can work in partnership or in parallel to try a new process or technology and develop learnings together
One team can take the lead to attempt a new approach or innovation and share learnings with other in a fast-follower based approach
Teams can try different approaches to the same type of solution (when there isn’t a clear best option), benchmark, and select the preferred approach based on the learning across efforts

The point is that, to achieve maximum efficiency, especially when there is scale, centralizing too much can hamper learning and innovation, and it is better to develop coordinated approaches that can be governed and leveraged than to have a “free for all” where the overall opportunity to innovate and capture efficiencies is compromised.

Summing Up

As I mentioned at the outset, the challenge in discussing IT implications from establishing a future enterprise environment with integrated AI is that there are so many possibilities for how companies can organize around it. That being said, I do believe a framework for the future intelligent enterprise should be defined, roles across the organization should be clarified, and transition to that future state should be governed with an eye towards promoting value creation, efficiency, and learning.

This concludes the series on my point of view related to the future of enterprise technology with AI, applications, and data and analytics integrated into one, aligned strategy. No doubt the concepts will evolve as we continue to learn and experiment with these capabilities, but I believe there is always room for strategy and a defined approach rather than an excess of ungoverned “experimentation”. History has taught us that there are no silver bullets, and that is the case with AI as well. We will obtain the maximum value from these new technologies when we are thoughtful and deliberate in how we integrate them with how we work and the assets and data we possess. Treating them as something separate and distinct will only suboptimize the value we create over time and those who want to promote excellence will be well served to map out their strategy sooner rather than later.

I hope the ideas across this series were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 08/19/2025

The Intelligent Enterprise 2.0 – Managing Transition

A compelling vision will stand the test of time, but it will also evolve to meet the needs of the day.

There are inherent challenges with developing strategy for multiple reasons:

It is difficult to balance the long- and short-term goals of an organization
It generally takes significant investments to accomplish material outcomes
The larger the change, the more difficult it can be to align people to the goals
The time it takes to mobilize and execute can undermine the effort
The discipline needed to execute at scale requires a level of experience not always available
Seeking “perfection” can be counterproductive by comparison with aiming for “good enough”

The factors above, and other too numerous to list, should serve as reminders that excellence, speed, and agility require planning and discipline, they don’t happen by accident. The focus of this article will be to break down a few aspects of transitioning to an integrated future state in the interest of increasing the probability of both achieving predictable outcomes, but also in getting there quickly and in a cost-effective way, with quality. That’s a fairly tall order, but if we don’t shoot for excellence, we are eventually choosing obsolescence.

This is the sixth post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”. The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

Key Considerations

Create the Template for Delivery

My assumption is that we care about three things in transitioning to a future, integrated environment:

Rapid, predictable delivery of capabilities over time (speed-to-market, competitive advantage)
Optimized costs (minimal waste, value disproportionate to expense)
Seamless integration of new capabilities as they emerge (ease of use and optimized value)

What these three things imply is the need for a consistent, repeatable approach and a standard architecture towards which we migrate capabilities over time. Articles 2-5 of this series explore various dimensions of that conceptual architecture from an enterprise standpoint, the purpose here will be to focus in on approach.

As was discussed in the article on the overall framework, the key is to start the design of the future environment around the various consumers of technology, the capabilities being provided to them, now and in the future, and prioritizing the relative value of those capabilities over time. That should be done on an internal and external level, so that individual roadmaps can be developed by domain to eventually surface and provide those capabilities as part of a portfolio management process. In the course of identifying those capabilities, some key questions will be whether those capabilities are available today, involve some level of AI services, whether those can/should be provided through a third-party or internally, and whether the data ultimately exists to enable them. This is where a significant inflection point should occur: the delivery of those capabilities should follow a consistent approach and pattern, so it can be repeated, leveraged, and made more efficient over time.

For instance, if an internally-developed AI-enabled capability is needed, the way that the data is exposed, processed, the AI service (or data product) exposed, and integrated/consumed by a package or custom application should be exactly the same from a design standpoint, regardless of what the specific capability is. That isn’t to say that the work needs to be done by only one team, as will be explored in the final article on IT organizational implications, but rather that we ideally want to determine the best “known path” to delivery, execute that repeatedly, and evolve it as required over time.

Taking this approach should provide a consistent end-user experience of services as they are brought online over time, a relatively streamlined delivery process as you are essentially mass-producing capabilities over time, and a relatively cost-optimized environment as you are eliminating the bloat and waste of operating multiple delivery silos that will eventually impede speed-to-market at scale and lead to technical debt.

From an architecture standpoint, without wanting to go too deep into the mechanics here, to the extent that the current state and future state enterprise architecture models are different, it would be worth evaluating things like virtualization of data as well as adapters/facades in the integration layer as a way to translate between the current and future models so there is logical consistency in the solution architecture even where the underlying physical implementations are varied. Our goal in enterprise architecture should always be to facilitate rapid execution, but promote standards, simplification, and reduce complexity and technical debt wherever possible over time.

Govern Standards and Quality

With a templatized delivery model and target architecture in place, the next key aspect to transition is to both govern the delivery of new capabilities to identify opportunities to develop and evolve standards, as well as to evolve the “template” itself, whether that involves adding automation to the delivery, building reusable frameworks or components that can be leveraged, or other assets that can help reduce friction and ease future efforts.

Once new capabilities are coming online, the other key aspect is to review them for quality and performance, to also look for ways to evolve the approach, adjust the architecture, and continue to refine the understanding of how these integrated capabilities can best be delivered and leveraged on an end-to-end basis.

Again, the overall premise of this entire series of articles is to chart a path towards an integrated enterprise environment for applications, data, and AI in the future. To be repeatable, we need to be consistent in how we plan, execute, govern, and evolve in the delivery of capabilities over time.

Certainly, there will be learnings that come from delivery, especially early in the adoption and integration of these capabilities. The way that we establish and enable the governance and evolution stemming from what we learn is critical in making delivery more predictable and ensuring more useful capabilities and insights over time.

Evolve in a Thoughtful Manner

With our learnings firmly in hand, the mental model I believe would be worth considering is more of a scaled Agile-type approach, where we have “increment-level”/monthly scheduled retrospectives to review the learnings across multiple sprints/iterations (ideally across multiple product/domains) and to identify opportunities to adjust estimation metrics, design patterns, develop core/reusable services, and anything else that essentially would improve efficiency, cost, quality, or predictability.

Whether these occur monthly at the outset and eventually space out to a quarterly process as the environment and standards are better defined could depend on a number of factors, but the point is not to make it too reactive to any individual implementation and to try and look across a set of deliveries to look for consistent issues, patterns, and opportunities that will have a disproportionate impact on the environment as a whole.

The other key aspect to remember in relation to evolution is that the capabilities of AI in particular are evolving very rapidly at this point, which is also a reason for thinking about the overall architecture, separation of concerns, and standards for how you integrate in a very deliberate way. A new version of a tool or technology shouldn’t require us to have to rewrite a significant portion of our footprint, it ideally should be a matter of upgrading the previous version and having the new capabilities available everywhere that service is consumed or in swapping out one technology for another, but everything on the other side of an API remaining nearly unchanged to the extent possible. This is understood as a fairly “perfect world” description of what likely would happen in practice, depending on the nature of the underlying change, but the point is that, without allowing for these changes up front in the design, the level of disruption they cause will likely be amplified and slow overall progress.

Summing Up

Change is a constant in technology. It’s a part of life given that things continue to evolve and improve, and that’s a good thing to the extent that it provides us with the ability to solve more complex problems, create more value, and respond more effectively to business needs as they evolve over time. The challenge we face is in being disciplined enough to think through the approach so that we can become effective, fast, and repeatable. Delivering individual projects isn’t the goal, it’s delivering capabilities rapidly and repeatably, at scale, with quality. That’s an exercise in disciplined delivery.

Having now covered the technology and delivery-oriented aspects of the future state concept, the remaining article will focus on how to think about the organizational implications on IT.

Up Next: IT Organizational Implications

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 08/15/2025

The Intelligent Enterprise 2.0 – Deconstructing Data-Centricity

Does having more data automatically make us more productive or effective?

When I wrote the original article on “The Intelligent Enterprise”, I noted that the overall ecosystem for analytics needed to change. In many environments, data is moved from applications to secondary solutions, such as data lakes, marts, or warehouses, enriched and integrated with other data sets, to produce analytical outputs or dashboards to provide transparency into operating performance. Much of this is reactive and ‘after-the-fact’ analysis of things we want to do right or optimize the first time, as events occur. The extension of that thought process was to move those insights to the front of the process, integrate them with the work as it is performed, and create a set of “intelligent applications” that would drive efficiency and effectiveness to different levels than we’ve been able to accomplish before. Does this eliminate the need for downstream analytics, dashboards, and reporting? No, for many reasons, but the point is to think about how we can make the future data and analytics environment about establishing a model that enables insight-driven, orchestrated action.

This is the fifth post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”. The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

Design Dimensions

In line with the blueprint above, articles 2-5 highlight key dimensions of the model in the interest of clarifying various aspects of the conceptual design. I am not planning to delve into specific packages or technologies that can be used to implement these concepts as the best way to do something always evolves in technology, while design patterns tend to last. The highlighted areas and associated numbers on the diagram correspond to the dimensions described below.

Starting with the Consumer (1)

“Just give me all the data” is a request that isn’t unusual in technology. Whether that is a byproduct of the challenges associated with completing analytics projects, a lack of clear requirements, or something else, these situations cause an immediate issue in practice: what is the quality of the underlying data and what are we actually trying to do with it?

It’s tempting to start an analytics effort from the data storage and to work our way up the stack to the eventual consumer. Arguably, this is a central premise in being “data-centric.” While I agree with the importance of data governance and management (the next topic), it doesn’t mean everything is relevant or useful to an end consumer, and too much data very likely just creates management overhead, technical complexity, and information overload.

A thoughtful approach needs to start with identifying the end consumers of the data, their relative priority, information and insights needs, and then developing a strategy to deliver those capabilities over time. In a perfect world, that should leverage a common approach and delivery infrastructure so that it can be provided in iterations and elaborated to include broader data sets and capabilities across domains over time. The data set should be on par with having an integrated data model and consistent way of delivering data products and analytics services that can be consumed by intelligent applications, agents, and solutions supporting the end consumer.

As an interesting parallel, it is worth noting that ChatGPT is looking to converge their reasoning and large language models from 4x into a single approach for their 5x release so that end customers don’t need to be concerned with having selected the “right” model for their inquiry. It shouldn’t matter to the data consumer. The engine should be smart enough to leverage the right capabilities based on the nature of the request, and that is what I am suggesting in this regard.

Data Management and Governance (2)

Without the right level of business ownership, the infrastructure for data and analytics doesn’t really matter, because the value to be obtained from optimizing the technology stack will be limited by the quality of the data itself.

Starting with master data, it is critical to identify and establish data governance and management for the critical, minimum amount of data in each domain (e.g., customer in sales, chart of accounts in finance), and the relationship between those entities in terms of an enterprise data model.

Governing data quality has a cost and requires time, depending on the level of tooling and infrastructure in place, and it is important to weigh the value of the expected outcomes in relation to the complexity of the operating environment overall (people, process, and technology combined).

From Content to Causation (3)

Finally, with the level of attention given to Generative AI and LLMs, it is important to note the value to be realized when we shift our focus from content to processes and transactions in the interest of understanding causation and influencing business outcomes.

In a manufacturing context, the increasing level of interplay between digital equipment, digital sensors, robotics, applications, and digital workers, there is a significant opportunity to orchestrate, gather and analyze increasing volumes of data, and ultimately optimize production capacity, avoid unplanned events, and increase the safety and efficacy of workers on the shop floor. This requires deliberate and intentional design, with outcomes in mind.

The good news is that technologies are advancing in their ability to analyze large data sets and derive models to represent the characteristics and relationships across various actors in play and I believe we’ve only begun to scratch the surface on the potential for value creation in this regard.

Summing Up

Pulling back to the overall level, data is critical, but it’s not the endgame. Designing the future enterprise technology environment is about exposing and delivering the services that enable insightful, orchestrated action on behalf of the consumers of that technology. That environment will be a combination of applications, AI, and data and analytics, synthesized into one meaningful, seamless experience. The question is how long it will take us to make that possible. The sooner we begin the journey of designing that future state with agility, flexibility, and integration in mind, the better.

Having now elaborated the framework and each of the individual dimensions, the remaining two articles will focus on how to approach moving from the current to future state and how to think about the organizational implications on IT.

Up Next: Managing Transition

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 08/03/2025

The Intelligent Enterprise 2.0 – A Framework for the Future

Why does it take so much time to do anything strategic?

This not an uncommon question to hear in technology and, more often than not, the answer is relatively simple: because the focus in the organization is delivering projects and not establishing an environment to facilitate accelerated delivery at scale. Those are two very different things and, unfortunately, it requires more thought, partnership, and collaboration between business and technology teams than headlines like “let’s implement product teams” or “let’s do an Agile transformation” imply. Can those mechanisms be part of how you execute in a scaled environment? Absolutely, but choosing an operating approach and methodology shouldn’t precede or take priority over having a blueprint to begin with, and that’s the focus of this article.

This is the second post in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”. The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

Design Dimensions

User-Centered Design (1)

A firm conducts a research project on behalf of a fast-food chain. There is always a “coffee slick” in the drive thru, where customers stop and pour out part of their beverage. Is there something wrong with the coffee? No. Customers are worried about burning themselves. The employees are constantly overfilling the drink, assuming that they are being generous, but actually creating a safety concern by accident. Customers don’t want to spill their coffee, so that excess immediately goes to waste.

In the world of technology, the idea of putting enabling technology in the hands of “empowered” end users or delivering that one more “game changing” tool or application is tempting, but often doesn’t deliver the value that is originally expected. This can occur for a multitude of reasons, but what can often be the case is an inadequate understanding of the end user’s mental model, approach to performing their work, or a fundamental misunderstanding that more technology in the hands of a user is always a good thing (when it definitely isn’t the case).

Two learnings that came out of the dotcom era were, first, the value to be derived from investing in user-centered design, thinking through their needs and workflow, and designing experiences around that. The other common practice was assuming that a disruptive technology (the internet in this case) was cause to spin out a separate organization (the “eBusiness” teams of the time) meant to incubate and accelerate development of capabilities that embraced the new technology. These teams generally lacked a broader understanding of the “traditional” business and its associated operating requirements, and thus began the ”bricks versus clicks” issues and channel conflict that eventually led to these capabilities being folded back into the broader organization, but only after having spent time and (in many cases) a considerable amount of money experimenting without producing sustainable business value.

In the case of artificial intelligence, it’s tempting to want to stand up new organizations or repurpose existing ones to mobilize the technology or to assume everything will eventually be relegated to a natural language-based interface where a user provides a description of what they want into an agent acting at their personal virtual assistant, with system deriving the appropriate workflow and orchestrating the necessary actions to support the request. While that may be a part of our future reality, taking an approach similar to the dotcom era would be a mistake and there will lost opportunity where this is the chosen path.

To be effective in a future digital world with AI, we need to think of how we want things integrated at the outset, starting with that critical understanding of the end user and how they want to work. Technology is meant to enable and support them, not the other way around, and leading with technology versus a need is never going to be an optimal approach… a lesson we’ve been shown many times over the years, no matter how disruptive the technology advancement has been.

I will address some of the organizational implications of the model in the seventh article in this series, so the remainder of this post will be on the technology framework itself.

Designing Around Connected Ecosystems (2)

Domain-driven design is not a new concept in technology.

As I mentioned in the first article, the technology footprint of most medium- to large-scale organizations is complex and normally steeped in redundancies, varied architectures, unclear boundaries between custom and purchased software, hosted and cloud-based based environments, hard coded integrations, and standard ways of moving data within and across domains.

While package solutions offer some level of logical separation of concerns between different business capabilities, the natural tendency in the product and platform space is to move towards more vertically or horizontally integrated solutions that create customer lock in and make interoperability very challenging, particularly in the ERP space. What also tends to occur is that an organization’s data model is biased to conform to what works best for a package or platform, but not necessarily the best representation of their business or their consumers of technology (something I will address in article 5 on Data & Analytics).

In terms of custom solutions, given they are “home grown”, there is a reasonable probability that, unless they were well-architected at the outset, they very likely provide multiple capabilities, without clear separation of concerns in ways that make them difficult to integrate with other systems in “standard” ways.

While there is nothing unique about these kinds of challenges, the problem comes when new technology capabilities like AI are available and we want to either replace or integrate things in a different way. This is where the lack of enterprise-level design and a broader, component-based architecture takes its toll, because there likely will be significant remediation, refactoring, and modernization required to enable existing systems to interoperate with the new capabilities. These things take time, add risk, and ultimately cost to our ability to respond when these opportunities arise, and no one wants to put new plumbing in a house that is already built with a family living in it.

On the other hand, in an environment with defined, component-based ecosystems that uses standard integration patterns, replacing individual components becomes considerably easier and faster, with much less disruption at both a local- and an enterprise-level. In a well-defined, component-based environment, I should be able to replace my Talent Acquisition application without having to impact my Performance Management, Learning & Development, or Compensation & Benefits solutions from an HR standpoint. Similarly, I shouldn’t need to make changes to my Order Management application within my Sales ecosystem because I’m transitioning to a different CRM package. To the extent that you are using standard business objects to support integration across systems, the need to update downstream systems in other domains should be minimized as well. Said differently, if you want to be fast, be disciplined in your design.

Modular, Composable, Standardized (3)

Beyond designing towards a component-based environment, it is also important to think about capabilities independent of a given process so you have more agility in how you ultimately leverage and integrate different things over time.

Using a simple example from personal lines insurance, I want to be able to support a third-party rating solution by exposing a “GetQuote” function that takes necessary customer information and coverage-related parameters and sends back a price. From a carrier standpoint, the process may involve ordering credit and pulling a DMV report (for accidents and violations) as inputs to the process. I don’t necessarily want these capabilities to be developed internal to the larger “GetQuote”, because I may want to leverage them for any one of a number of other reasons, so that smaller grained (more atomic) transactions should also be defined as services that can be leveraged by the larger one. While this is a fairly trivial case, there are often situations where delivery efforts move at such a rapid pace that things are tightly coupled or built together that really should be discreet and separate, providing more flexibility and leverage of those individual services over time.

This also can occur in the data and analytics space, where there are normally many different tools and platforms between the storage and consumption layers and ideally you want to optimize data movement and computing resources such that only the relevant capabilities are included in a data pipeline based on specific customer needs.

The flexibility described above is predicated on a well-defined architecture that is service-based and composable, with standard integration patterns, that leverages common business objects for as many transactions as practical. That isn’t to say that there are times where the economics make sense to custom code something or to leverage point-to-point integration, rather that thinking about reuse and standardized approaches up front is a good delivery practice to avoid downstream cost and complexity, especially when the rate of new technologies being introduced is as high as it is today.

Leveraging Standard Integration (4)

Having mentioned standard integration above, my underlying assumption is that we’re heading towards a near real-time environment where streaming infrastructure and publish and subscribe models are going to be critical infrastructure to enable delivery of key insights and capabilities to consumers of technology. To the extent that we want that infrastructure to scale and work efficiently and consistently, there is a built-in incentive to be intentional about the data we transmit (whether that is standard business objects or smaller data sets coming from connected equipment and devices) as well as the ways we connect to these pipelines across application and data solutions. Adding a data publisher or consumer shouldn’t require rewriting anything per se, any more than plugging in a new appliance to a power outlet in your home should require you to either unplug something else or change the circuit board and wiring itself (except in extreme cases).

Summing Up

I began this article with the observation about delivering projects by comparison with establishing an environment for delivering repeatably at scale. In my experience, depending on the scale of an organization, there will be some level of many of the things I’ve mentioned above in place, but then a potentially large set of pain points and opportunities across the footprint where things are suboptimized.

This is not about boiling the ocean or suggesting we should start over. The point of starting with the framework itself is to raise awareness that the way we establish the overall environment has a significant ripple effect into our ability to do things we want to do downstream to leverage new capabilities and get the most out of our technology investments later on. The time spent in design is well worth the investment, so long as it doesn’t become analysis paralysis.

To that end, in summary:

Design from the end user and their needs first
Think and design with connected ecosystems in mind
Be purposeful in how you design and layer services to promote reuse and composability
Leverage standards in how you integrate solutions to enable near real-time processing

It is important to note that, while there are important considerations in terms of hosting, security, and data movement across platforms, I’m focusing largely on the organization and integration of the portfolios needed to support an organization. From a physical standpoint, the conceptual diagram isn’t meant to suggest that any or all of these components or connected ecosystems need to be managed and/or hosted internal to an organization. My overall belief is that, the more we move to a service-driven environment, the more of a producer/consumer model will emerge where corporations largely act as an integrator and orchestrator (aka “consumer”) of services provided by third-parties (the “producers”). To the extent that the architecture and standards referenced above are in place, there shouldn’t be any significant barriers to moving from a more insourced and hosted environment to a more consumption-based, outsourced, and cloud-native environment in the future.

With the overall framework in place, the next three articles will focus on the individual elements of the environment of the future, in terms of AI, applications, and data.

Up Next: Integrating Artificial Intelligence

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 07/26/2025

The Intelligent Enterprise 2.0 – The Cost of Complexity

How did we get here…?

The challenges involved in managing a technology footprint today at any medium to large organization are very high for a multitude of reasons:

Proliferation of technologies and solutions that are disconnected or integrated in inconsistent ways, making simplification or modernization efforts difficult to deliver
Mergers and acquisitions that bring new systems into the landscape that aren’t rationalized with or migrated to existing systems, creating redundancy, duplication of capabilities, and cost
“Speed-to-market” initiatives involving unique solution approaches that increase complexity and cost of ownership
A blend of in-house and purchased software solutions, hosted across various platforms (including multi-cloud), increasing complexity and cost of security, integration, performance monitoring, and data movement
Technologies advancing at a rate, especially with the introduction of artificial intelligence (AI), that organizations can’t integrate them quickly enough to do so in a consistent manner
Decentralized or federated technology organizations that operate with relative autonomy, independent of standards, frameworks, or governance, which increases complexity and cost

The result of any of the above factors can be enough cost and complexity that the focus within a technology organization can shift from innovation and value creation to struggling to keep the lights on and maintaining a reliable and secure operating environment.

This article will be the first in a series focused on where I believe technology is heading, with an eye towards a more harmonious integration and synthesis of applications, AI, and data… what I previously referred to in March of 2022 as “The Intelligent Enterprise”. The sooner we begin to operate off a unified view of how to align, integrate, and leverage these oftentimes disjointed capabilities today, the faster an organization will leapfrog others in their ability to drive sustainable productivity, profitability, and competitive advantage.

Why It Matters

Before getting into the dimensions of the future state, I wanted to first clarify how these technology challenges manifest themselves in meaningful ways, because complexity isn’t just an IT problem, it’s a business issue, and partnership is important in making thoughtful choices in how we approach future solutions.

Lost Productivity

A leadership team at a manufacturing facility meets first thing in the morning. It is the first of multiple they will have throughout the course of a day. They are setting priorities for the day collectively because the systems that support them: a combination of applications, analytics solutions, equipment diagnostics, and AI tools, are all providing different perspectives on priorities and potential issues, but in disconnected ways, and it is now on the leadership team to decide which of these should receive attention and priority in the interest of making their production targets for a day. Are they making the best choices in terms of promoting efficiency, quality, and safety? There’s no way to know.

Is this an unusual situation? Not at all. Today’s technology landscape is often a tapestry of applications with varied levels of integration and data sharing, data apps and dashboards meant to provide insights and suggestions, and now AI tools to “assist” or make certain activities more efficient for an end user.

The problem is what happens when all these pieces end up on someone’s desktop, browser, or mobile device and they are left to copy data from one solution to the other, arbitrate which of various alerts and notifications is most important, identify dependencies to help make sure they are taking the right actions in the right sequence (in a case like directed work activity), and quite often that time is lost productivity in itself, regardless of which path they take, which may amplify the impact further, given retention and/or high turnover are real issues in some jobs that reduce the experience available to navigate these challenges successfully.

Lower Profitability

The result of this lost productivity and ever-expanding technology footprint is both lost revenue (to the extent it hinders production or effective resource utilization) and higher operating cost, especially to the degree that organizations introduce the next new thing without retiring or replacing what was already in place, or integrating things effectively. Speed-to-market is a short-term concept that tends to cause longer-term cost of ownership issues (as I previously discussed in the article “Fast and Cheap Isn’t Good”), especially to the degree that there isn’t a larger blueprint in place to make sure such advancements are done in a thoughtful, deliberate manner.

To this end, how we do something can be as important as what we intend to do, and there is an argument for thinking through the operating implications when undertaking new technology efforts with a more holistic mindset than a single project tends to take in my experience.

Lost Competitive Advantage

Beyond the financial implications, all of the varied solutions, accumulated technologies and complexity, and custom or interim band aids built to connect one solution to the next eventually catches up in a form of what one organization used to refer to as “waxy buildup” that prevents you from moving quickly on anything. What seems on paper to be a simple addition or replacement becomes a lengthy process of analysis and design that is cumbersome and expensive, where the lost opportunity is speed-to-market in an increasingly competitive marketplace.

This is where the new market entrants thrive and succeed, because they don’t carry the legacy debt and complexity of entrenched market players who are either too slow to respond or too resistant to change to truly transform at a level that allows them to sustain competitive advantage. Agility gives way to a “death by a thousand paper cuts” of tactical decisions made that were appropriate and rational in the moment, but created significant amounts of technical debt that inevitably must be paid.

A Vision for the Future

So where does this leave us? Pack up the tent and go home? Of course not.

We are at a significant inflection point with AI technology that affords us the opportunity to examine where we are and to start adjusting our course to a more thoughtful and integrated future state where AI, applications, and data and analytics solutions work in concert and harmony with each other versus in a disconnected reality of confusion.

It begins with the consumers of these capabilities, supported by connected ecosystems of intelligent applications, enabled by insights, agents, and experts, that infuse intelligence into making people productive, businesses agile and competitive, and improve value derived from technology investments at a level disproportionate to what we can achieve today.

The remaining articles in this series will focus on various dimensions of what the above conceptual model means, as a framework, in terms of AI, applications, and data, and then how we approach that transition and think about it from an IT organizational perspective.

Up Next: Establishing the Framework for the future…

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 07/24/2025

Four Years In: The Patterns That Define Performance and Leadership

Having had this blog for nearly four years, I took a look at the nature of the articles written to date, and subjects included therein, wondering if there were any patterns that emerged. I found the resulting chart (above) interesting as a reflection of the relative importance I associate with certain topics overall. To that end, I thought I’d provide some perspective on what’s been written to date before moving to the next article, whatever that may be.

Leadership and Culture

The two largest focus areas were leadership and culture, which isn’t surprising given I’ve worked for many years across corporate and consulting environments and have seen the relative impact that both can have on organizational performance on the whole. Nearly two-thirds of my articles to date touch on leadership and one-half on culture, because they are fundamental to setting the stage for everything else you want to accomplish.

In the case of organizational excellence, courageous leadership has to be at the top of the list, given that difficult decisions and a level of fearlessness are required to achieve great things. By contrast, hesitancy and complacency will almost always lead to suboptimized results, because there will be apprehension about innovating, challenging the status quo, and effectively managing relationships where the ability to be a partner and advisor may require difficult conversations at times.

With leadership firmly rooted, it becomes possible to establish a culture that promotes integrity, respect, collaboration, innovation, productivity, and results. Where one or more of these dimensions is missing, it is nearly impossible to be effective without compromising performance somewhere. That isn’t to say that you can’t deliver in an unhealthy environment, you certainly can and many organizations do. It is very likely, however, that those gains will be short-lived and difficult to repeat or sustain because of the consequential impact of those issues on the people working in those conditions over time. In this case, the metrics will likely tell the tale, between delivery performance, customer feedback, solution quality, and voluntary attrition (to name a few).

Delivery and Innovation

With the above foundation in place, the next two areas of focus were delivery and innovation, which is reassuring given that I believe strongly in the concept of actionable strategy versus one that is largely theoretical in nature. Having worked in environments that leaned heavily on innovation without enough substantive delivery as well as ones that delivered consistently but didn’t innovate enough, the answer is to ensure both are occurring on a continual basis and managed in a very deliberate way.

Said differently, if you innovate without delivering, you won’t create tangible business value. If you deliver without ever innovating, at some point, you will lose competitive advantage or risk obsolescence in some form or other.

The Role of Discipline

While not called out as a topic in itself, in most cases where I discuss delivery or IT operations, I mention discipline as well, because I believe it is a critical component of pursuing excellence in anything. The odd contradiction that exists, is the notion that having discipline somehow implies bureaucracy or moving slowly, when the reality is the exact opposite.

Without defined, measurable, and repeatable processes, it is nearly impossible to drive continuous improvement and establish a more predictable operating environment over time. From a delivery standpoint, having methodology isn’t about being prescriptive to the point that you lose agility, as an example, it’s about having an understood approach that you can estimate and plan effectively. It also defines rules of engagement within and across teams so that you can partner and execute efficiently in a repeatable fashion. Having consistent processes also allows for monitoring, governing, and improving the efficiency and efficacy of how things are done over time.

The same could be said for leveraging architectural frameworks, common services, and design patterns as well. There is a cost for establishing these things, but if you amortize these investments over time, they ultimately improve speed, reduce risk, improve quality, and thereby reduce TCO and complexity of an environment once they are in place. This is because every team doesn’t invent their own way of doing things, ultimately creating complexity that needs to be maintained and supported down the road. Said differently, it would be very difficult to have reliable estimation metrics when you never do something in a consistent way and analyze variance.

Mental Models and Visualization

The articles also reflect that I prefer having a logical construct and visualizations to organize, illustrate, analyze, and evaluate complex situations, such as AI and data strategy, workforce and sourcing strategy, digital manufacturing facilities, and various other situations. Any of these topics involve many dimensions and layers of associated complexity. Having a mental model, whether it is a functional decomposition, component model, or some other framework, is helpful for both identifying the dimensions of a problem, and also surfacing dependencies and relationships in the interest of driving transformation.

Visualizations also can help facilitate alignment across broader groups of stakeholders where a level of parallel execution is required, making dependencies and relationships more evident and easier to coordinate.

Wrapping Up

Overall, the purpose of writing this article was simply to pause and reflect on what has become a fairly substantive body of work over the last several years, along with recognizing the themes that reoccur time and again because they matter when excellence is your goal. Achieving great things consistently is a byproduct of having vision, effective leadership, discipline, commitment, and a lot of tenacity.

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 07/14/2025

Why Excellence Matters

A new leader in an organization once asked to understand my role. My answer was very simple: “My role is to change mindsets.”

I’m fairly sure the expectation was something different: a laundry list of functional responsibilities, goals, in-flight activities or tasks that were top of mind, the makeup of my team, etc. All relevant aspects of a job, to be sure, but not my primary focus.

I explained that my goal was to help transform the organization, and if I couldn’t change people’s mindsets, everything else that needed to be done was going to be much more difficult. That’s how it is with change.

Complacency is the enemy. Excellence is a journey and you are never meant to reach the destination.

Having been part of and worked with organizations that enjoyed tremendous market share but then encountered adversity and lost their advantage, there were common characteristics, starting with basking in the glow of that success too long and losing the hunger and drive that made them successful in the first place.

The remainder of this article will explore the topic further in three dimensions: leadership, innovation, and transformation in the interest of providing some perspective on the things to look for when excellence is your goal.

Fall short of excellence, you can still be great. Try to be great and fail? You’re going to be average… and who wants to be part of something average? No one who wants to win.

Courageous Leadership

As with anything, excellence has to start with leadership. There is always resistance and friction associated with change. That’s healthy and good because it surfaces questions and risks and, in a perfect world, the more points of view you can leverage in setting direction, the more likely you’ll avoid blind spots or avoidable mistakes just for a lack of awareness or understanding of what you are doing.

There is a level of discipline needed to accomplish great things over time and courage is a requirement, because there will inevitably be challenges, surprises, and setbacks. How leaders respond to that adversity, through their adaptability, tenacity and resilience will ultimately have a substantial influence on what is possible overall.

Some questions to consider:

Is there enough risk tolerance to create space to try new ideas, fail, learn, and try again?
Is there discipline in your approach so that business choices are thoughtful, reasoned, intentional, measured, and driven towards clear outcomes?
Is there a healthy level of humility to understand that, no matter how much success there is right now, without continuing to evolve, there will always be a threat of obsolescence?

Relentless Innovation

In my article on Excellence by Design, I was deliberate in choosing the word “relentless” in terms of innovation, because I’ve seen so many instances over time of the next silver bullet meant to be a “game changer”, “disruptor”, etc. only to see that then be overtaken by the next big thing a year or so later.

One of the best things about working in technology is that it constantly gives us opportunities to do new things: to be more productive and effective, produce better outcomes, create more customer value, and be more competitive.

Some people see that as a threat, because it requires a willingness to continue to evolve, adapt, and learn. You can’t place too much value on a deep understanding of X technology, because tomorrow Y may come along and make that knowledge fairly obsolete. While there is an aspect of that argument that is true at an implementation level, it gives too much importance to the tools and not enough to the problems we’re ultimately trying to solve, namely creating a better customer experience, delivering a better product or service, and so on.

We need to plan like the most important thing right now won’t be the most important 6 months or even a year from now. Assume we will want to replace it, or integrate something new to work with it, improving our overall capability and creating even more value over time.

What does that do? In a disciplined environment, it should change our mindset about how we approach implementing new tools and technologies in the first place. It should also influence how much exposure we create in the dependencies we place upon those tools in the process of utilizing them.

To take what could be a fairly controversial example: I’ve written multiple articles on Artificial Intelligence (AI), how to approach it, and how I think about it in various dimensions, including where it is going. The hype surrounding these technologies is deservedly very high right now, there is a surge in investment, and a significant number of tools are and will be hitting the market. It’s also reasonable to assume a number of “agentic” solutions will pop up, meant to solve this problem and that… ok… now what happens then? Are things better, worse, or just different? What is the sum of an organization that is fully deployed with all of the latest tools? I don’t believe we have any idea and I also believe it will be terribly inefficient if we don’t ask this question right now.

As a comparison, what history has taught us is that there will be a user plugged into these future ecosystems somewhere, with some role and responsibilities, to work in concert (and ideally in harmony) with all this automation (physical and virtual) that we’ve brought to bear on everyone’s behalf. How will they make sense of it all? If we drop an agent for everything, is it any different than giving someone a bunch of new applications, all of which spit recommendations and notifications and alerts at them, saying “this is what you need to do”, but leaving them to figure out which of those disconnected pieces of advice make the most sense, which should be the priority, and try somehow not to be overwhelmed? Maybe not, because the future state might be a combination of intelligent applications (something I wrote about in The Intelligent Enterprise) and purpose-built agents that fill gaps those applications don’t cover.

Ok, so why does any of that matter? I’m not making an argument against experimenting and leveraging AI. My point is that, every time there is surge towards the next technology advancement, we seldom think about the reality that it will eventually evolve or be replaced by something else and we should take that into consideration as we integrate those new technologies to begin with. The only constant is change and that’s a good thing, but we also need to be disciplined in how we think about it on an ongoing basis.

Some questions to consider:

Is there a thoughtful and disciplined approach to innovation in place?
Is there a full lifecycle-oriented view when introducing new technologies, to consider how to integrate them so they can be replaced or to retire other existing, potentially redundant solutions once they are introduced?
Are the new technologies being vetted, reviewed, and integrated as part of a defined ecosystem with an eye towards managing technical debt over time?

Continual Transformation

In the spirit of fostering change, it is very common for a “strategy” conversation to be rooted in a vision. A vision sets the stage for what the future environment is meant to look like. It is ideally compelling enough to create a clear understanding of the desired outcome and to generate momentum in the pursuit of that goal (or set of goals)… and experience has taught me this is actually NOT the first or only thing important to consider in that first step.

Sustainable change isn’t just about having a vision, it is about having the right culture.

The process for strategy definition isn’t terribly complicated at an overall level: define a vision, understand the current state, identify the gaps, develop a roadmap to fill those gaps, execute, adapt, and govern until you’re done.

The problem is that large transformation efforts are extremely difficult to deliver. I don’t fundamentally believe that difficulty is often rooted in the lack of a clear vision or as simple as having execution issues that ultimately undermine success. I believe successful transformation isn’t a destination to begin with. Transformation should be a continual journey towards excellence.

How that excellence is manifest can be articulated through one or more “visions” that communicate concepts of the desired state, but that picture can and will evolve as capabilities available through automation, process, and organizational change occur. What’s most important is having courageous leadership and the innovation mindset mentioned above, but also a culture driven to sustain that competitive advantage and hunger for success.

Said differently: With the right culture, you can likely accomplish almost any vision, but only some visions will be achievable without the right culture.

Some questions to consider in this regard:

Is there a vision in place for where the organization is heading today?
What was the “previous” vision, what happened to it, did it succeed or fail and, if so, why?
Is the current change viewed as a “project” or a “different way of working”? (I would argue the latter is the desired state nearly in all cases)

Wrapping Up

Having shared the above thoughts, it’s difficult to communicate what is so fundamental to excellence, which is the passion it takes to succeed in the first place.

Excellence is a choice. Success is a commitment. It takes tenacity and grit to make it happen and that isn’t always easy or popular.

There is always room to be better, even in some of the most mundane things we do every day. That’s why courageous leadership is so important and where culture becomes critical in providing the foundation for longer-term success.

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 06/05/2025

Conducting Effective Workshops

Overview

Having led and participated in many workshops and facilitated sessions over time, I wanted to share some thoughts on what tends to make them effective.

Unfortunately, there can be a perception that assembling a group of people in a room with a given topic (for any length of time) can automatically produce collaboration and meaningful outcomes. This is definitely not the case.

Before getting into the key dimensions, I suppose a definition of a “workshop” is worthwhile, given there can be many manifestations of what that means in practice. From my perspective, a workshop is a set of one or more facilitated sessions of any duration with a group of participants that is intended to foster collaboration and produce a specified set of outcomes. By this definition, a workshop could be as short as a one-hour meeting and also span many days. The point is that it is facilitated, collaborative, and produces results.

By this definition, a meeting used to disseminate information is not a workshop. A “training session” could contain a workshop component, to the degree there are exercises that involve collaboration and solutioning, but in general, they would not be considered workshops because they are primarily focused on disseminating information.

Given the above definition, there are five factors that are necessary for successful workshop:

Demonstrating Agility and Flexibility
Having the Appropriate Focus
Ensuring the Right Participation
Driving Engagement
Creating Actionable Outcomes

Demonstrating Agility and Flexibility

Workshops are fluid, evolving things, where there is an ebb and flow to the discussion and to the energy of the participants. As such, beyond any procedural or technical aspect of running a workshop, it’s critically important to think about and to be aware of the group dynamics and to adjust the approach as needed.

What works:

Soliciting feedback on the agenda, objectives, and participants in advance, both to make adjustments as needed, but also to identify potential issues that could arise in the session itself
Doing pulse checks on progress and sentiment throughout to identify adjustments that may be appropriate
Asking for feedback after a session to identify opportunities for improvement in the future

What to watch out for:

The tone of discussion from participants, level of engagement, and other intangibles can tend to signal that something is off in a session
- Tactics to address: Call a break, pulse check the group for feedback
Topics or issues not on the agenda that arise multiple times and have a relationship to the overall objectives or desired outcomes of the session itself
- Tactics to address: Adjusting the agenda to include a discussion on the relevant topic or issue. Surface the issue, put in a parking lot to be addressed either during or post-session
Priorities or precedence order of topics not aligning in practice to how they are organized in the session agenda
- Tactics to address: Reorder the agenda to align the flow of discussion to the natural order of the solutioning. Insert a segment to provide a high-level end-to-end structure, then resume discussing individual topics. Even if out of sequence, that could help contextualize the conversations more effectively

Having the Appropriate Focus

Workshops are not suitable for every situation. Topics that involve significant amounts of research, rigor, investigation, cross-organizational input, or don’t require a level of collaboration, such as detailed planning, are better handled through offline mechanisms, where workshops can be used to review, solicit input, and align outcomes from a distributed process.

What works:

Scope that is relatively well-defined, minimally at a directional level, to enable brainstorming and effective solutioning
Conduct a kick off and/or provide the participants with any pre-read material required for the session up front, along with any expectations for “what to prepare” so they can contribute effectively
Choosing topics where the necessary expertise is available and can participate in the workshop

What to watch out for:

Unclear session objectives or desired outcomes
- Tactics to address: Have a discussion with the session sponsor and/or participants to obtain the necessary clarity and send out a revised agenda/objectives as needed
Topics that are too broad or too vague to be shaped or scoped by the workshop participants
- Tactics to address: Same as previous issue
An agenda that doesn’t provide a clear line of sight between the scope of the session or individual agenda items and desired outcomes
- Tactics to address: Map the agenda topics to specific outcomes or deliverables and ensure they are connected in a tangible way. Adjust as needed

Ensuring the Right Participation

Workshops aren’t solely about producing content, they are about establishing a shared understanding and ownership. To that end, having the right people in the room to both inform the discussion and own the outcomes is critical to establishing momentum post-session

What works:

Ensuring the right level of subject matter expertise to address the workshop scope and objectives
Having cross-functional representation to identify implications, offer alternate points of view, challenge ideas, and suggest other paradigms and mental models that could foster innovation
Bringing in “outside” expertise to the degree that what is being discussed is new or there is limited organizational knowledge of the subject area where external input can enhance the discussion

What to watch out for:

People jumping in and out of sessions to the point that it either becomes a distraction to other participants or there is a loss of continuity and effectiveness in the session as a whole
- Tactics to address: Manage the part-time participants deliberately to minimize disruptions. Realign sessions to try and organize their participation into consecutive blocks of time with continuous input rather than sporadic engagement or see what can be done to either solicit full participation or identify alternate contributors who can participate in a dedicated capacity.
There is a knowledge gap that makes effective discussion difficult to impossible. The lack of the right people in the discussion will tend to draw momentum out of a session
- Tactics to address: Document and validate assumptions made in the absence of the right experts being present. Investigate participation of necessary subject matter experts in key sessions focused on their areas of contribution
Limiting participants to those who are “like minded”, which may constrain the outcomes
- Tactics to address: Explore involving a more diverse group of participants to provide a means for more potential approaches and solutions

Driving Engagement

Having the right people in the room and the right focus is critical to putting the right foundation in place, but making the most of the time you have is where the value is created, and that’s all about energy and engagement.

What works:

Leveraging an experienced facilitator, who is both engaging and engaged. The person leading the workshop needs to have a contagious enthusiasm that translates to the participants
Ensuring an inclusive discussion where all members of the session have a chance to contribute and have their ideas heard and considered, even if they aren’t ultimately utilized
Managing the agenda deliberately so that the energy and focus in the discussion is what it needs to be to produce the desired outcomes

What to watch out for:

A lack of energy or lack of the right pace from the facilitator will likely reduce the effectiveness of the session
- Tactics to address: Switch up facilitators as needed to keep the energy high, pulse check the group on how they feel the workshop is going and make adjustments as needed
A lack of collaboration or participation from all attendees
- Tactics to address: Active facilitation to engage quieter voices in the room and to manage anyone who is outspoken or dominating discussion
A lack of energy “in the room” that is drawing down the pace or productivity of the session
- Tactics to address: Calling breaks as needed to give the participants a disruption, balancing the amount of active engagement of the participants in the event there is too much “presentation” going on where information is being shared and not enough discussion occurring

Creating Actionable Outcomes

One of the worst experiences you can have is a highly energized session that builds excitement, but then leads to no follow up action. Unfortunately, I’ve seen and experienced this many times over the course of my career, and it’s very frustrating, both when you lead workshops and as a participant, when you spend your time and provide insights that ultimately go to waste. Workshops are generally meant to help launch, accelerate, and build momentum through collaboration. To the extent that a team comes together and uses a session to establish direction, it is critical that the work not go to waste, not only to make the most of that effort, but also to provide reassurance that future sessions will be productive as well. If workshops become about process without outcome, they will lose efficacy very quickly and people will stop taking them seriously as a mechanism to facilitate and accelerate change.

What works:

Tracking the completion of workshop objectives throughout the process itself and making adjustments to the outcomes as required
Leaving the session with clear owners of any next steps
Establishing a checkpoint post-session to take a pulse on where things stand on the outcomes, next steps, and recommended actions

What to watch out for:

Getting to the end of a workshop and having any uncertainty in terms of whether the session objectives were met
- Tactics to address: Objectives should be reviewed throughout the workshop to ensure alignment of the participants and commitment to the desired outcomes. There shouldn’t be any surprises waiting by the end
Leaving a session not having identified owners of the next steps
- Tactics to address: In the event that no one “signs up” to own next steps or the means to perform the assignment is unclear for some reason, the facilitator can offer to review the next steps with the workshop sponsor and get back to the group with how the next steps will be taken forward
Assigning ownership of next steps without any general timeframe in which those actions were intended to be taken
- Tactics to address: Setting a checkpoint at a specified point post-session to understand progress, review conflicting priorities, clear barriers, etc.

Wrapping Up

Going back to the original reason for writing this article, I believe workshops are an invaluable tool for defining vision, designing solutions, and facilitating change. Taking steps to ensure they are effective, engaging, and create impact is what ultimately drives their value.

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 05/09/2025

Making Governance Work

In my most recent articles on Approaching Artificial Intelligence and Transformation, I highlight the importance of discipline in achieving business outcomes. To that end, governance is a critical aspect of any large-scale transformation or delivery effort because it both serves to reduce risk and inform change on an ongoing basis, both of which are an inevitable reality of these kinds of programs.

The purpose of this article is to discuss ways to approach governance overall, to avoid common concerns, and to establish core elements that will increase the probability it will be successful. Having seen and established many PMOs and governance bodies over time, I can honestly say that they are difficult to put in place for as many intangible reasons as anything mechanical, hopefully the nature of which will be addressed below.

Have the Right Mindset

Before addressing the execution “dos” and “don’ts”, success starts with understanding that governance is about successful delivery, not pure oversight. Where delivery is the priority, the focus is typically on enablement and support. By contrast, where the focus is the latter, emphasis can be placed largely on controls and intervention. The reality is that both are needed, which will be discussed more below, but starting with an intention to help delivery teams generally should translate into a positive and supportive environment, where collaboration is encouraged. If, by comparison, the role of governance is relegated to finding “gotchas” and looking for issues without providing teams will guidance or solutions, the effort likely won’t succeed. Healthy relationships and trust are critical to effective governance, because they encourage transparent and open dialogue. Without that, likely the process will break down or be ineffective somewhere along the way.

In a perfect world, delivery teams should want to participate in a governance process because it helps them do their work.

Addressing the Challenges

Suggesting that you want to initiate a governance process can be a very uncomfortable conversation. As a consultant, clients can feel like it is something being done “to” them, with a third-party reporting on their work to management. As a corporate citizen, it can feel like someone is trying to exercise a level of control over their peers in a leadership team and, consequently, limiting individual autonomy and empowerment in some way. This is why relationships and trust are critically important. Governance is a partnership and it is about increasing the probability of successful outcomes, not adding a layer of management over people who are capable of doing their jobs with the right level of support.

That being said, three things are typically said when the idea of establishing governance is introduced: that it will slow things down, hinder value creation, and add unnecessary overhead to teams that are already “too busy” or rushing to a deadline. I’ll focus on each of these in turn, along with what can be done to address the concerns in how you approach things.

It Slows Things Down

As I wrote in my article on Excellence by Design, delivering at speed matters. Lack of oversight can lead to efforts going off the rails without the timely interventions and support that cause delays and budget overruns. That being said, if the process slows everything down, you aren’t necessarily helping teams deliver either.

A fundamental question is whether your governance process is meant to be a “gate” or a “checkpoint”.

In the case of a gate, they can be very disruptive, so there should be compliance or risk-driven concerns (e.g., security or data privacy) that necessitate stopping or delaying some or all of a project until certain defined criteria or standards are met. If a process is gated, then this should be factored into estimation and planning at the outset, so expectations are set and managed accordingly, and to avoid the “we don’t have time for this” discussion that otherwise could happen. Gating criteria and project debriefs / retrospectives should also be reviewed to ensure standards and guidelines are updated to help both mitigate risk and encourage accelerated delivery, which is a difficult balance to strike. In principle, the more disciplined an environment is, the less “gating” should be needed, because teams are already following standards, doing proper quality assurance, and so on, and risk management should be easier on an average effort.

When it comes to “checkpoints”, there should be no difference in terms of the level of standards and guidelines in place, it’s about how they are handled in the course of the review discussion itself. When critical criteria are missed in a gate, there is a “pause and adjust” approach, whereas a checkpoint would note the exception and requested remedy, ideally along with a timeframe for doing so. The team is allowed to continue forward, but with an explicit assumption that they will make adjustments so the overall solution integrity is maintained in line with expectations. This is where a significant amount of technical debt and delivery issues are created. There is a level of trust involved in a checkpoint process, because the delivery team may choose not to remediate any issues, in which case the purpose and value of standards can be undermined, and a significant amount of complexity and risk is introduced as a result. If this becomes a pattern over time, it may make sense to shift towards a more gated process if things like security, privacy, or other critical issues are being created.

Again, the goal of governance is to remove barriers, provide resources where required, and to enable successful delivery, but there is a handshake involved to the degree that the process integrity needs to be managed overall. My general point of view is to trust teams to do the right thing and to leverage a checkpoint versus a gated process, but that is predicated on ensuring standards and quality are maintained. To the delivery discipline isn’t where it needs to be, a stronger process may be appropriate.

It Erodes Value

To the extent that the process is perceived to be pure overhead, it is important to clarify the overall goals of the process and, to the extent possible, to identify some metrics that can be used to signal whether it is being effective in helping to promote a healthy delivery environment.

At an overall level, the process is about reducing risk, promoting speed and enablement, and increasing the probability of successful delivery. Whether that is measured in changes in budget and schedule variance, issues remediated pre-deployment, or by a downstream measure of business value created through initiatives delivered on time, there should be a clear understanding of what the desired outcomes are and a sanity check that they are being met.

Arguably, where standards are concerned, this can be difficult to evaluate and measure, but certainly the increase in technical debt that is created in an environment that lacks standards and governance, cost of operations, and percentage of effort directed and build versus run on an overall level can be monitored and evaluated.

It Adds Overhead

I remember taking an assignment to help clean up the governance of a delivery environment many years ago where the person leading the organization was receiving a stack of updates every week that was literally three feet of documents when printed, spanning hundreds of projects. It goes without saying that all of that reporting provided nothing actionable, beyond everyone being able to say that they were “reporting out” on their delivery efforts on an ongoing basis. It was also the case that the amount of time project and program managers were focused on updating all that documentation was substantial. This is not governance. This is administration and a waste of resources. Ultimately, by changing the structure of the process, defining standards, and level of information being reported, the outcome was a five-page summary that covered critical programs, ongoing maintenance, production, and key metrics that was produced with considerably less effort and provided much better transparency into the environment.

The goal of governance is providing support, not producing reams of documentation. Ideally, there should be a critical minimum amount of information requested from teams to support a discussion on what they are doing, where they are in the delivery process, the risks or challenges they are facing, and what help (if any) they may need. To the degree that you can leverage artifacts the team is already producing so there is little to no extra effort involved in preparing for a discussion, even better. And, as another litmus test, everything included in a governance discussion should serve a purpose and be actionable. Anything else likely is a waste of time and resources.

Making Governance Effective

Having addressed some of the common concerns and issues, there are also things that should be considered that increase the probability of success.

Allow for Evolution

As I mentioned in the opening, the right mindset has a significant influence on making governance successful. Part of that is understanding it will never be perfect. I believe very strongly in launching governance discussions and allowing feedback and time to mature the process and infrastructure given real experience with what works and what everyone needs.

One of the best things that can be done is to track and monitor delivery risks and technology-related issues and use those inputs to guide and prioritize the standards and guidelines in place. Said differently, you don’t need governance to improve things you already do well, you leverage it (primarily) to help you address risks and gaps you have and to promote quality.

Having seen an environment where a team was “working on” establishing a governance process over an extended period of time versus one that was stood up inside 30 days, I’d rather have the latter process in place and allow for it to evolve than one that is never launched.

Cover the Bases

In the previous section, I mentioned leveraging a critical minimum amount of information to facilitate the process, ideally utilizing artifacts a team already has. Again, it’s not about the process, it’s about the discussion and enabling outcomes.

That being said, since trust and partnership are important, even in a fairly bare bones governance environment, there should be transparency into what the process is, when it should be applied, who should attend, expectations of all participants, and a consistent cadence with which it is conducted.

It should be possible to have ad-hoc discussions if needed, but there is something contradictory to suggesting that governance is a key component to a disciplined environment and not being able to schedule the discussions themselves consistently. Anecdotally, when we conducted project review discussions in my time at Sapient, it was commonly understood that if a team was ever “too busy” to schedule their review, they probably needed to have it as soon as possible, so the reason they were overwhelmed or too busy was clear.

Satisfy Your Stakeholders

The final dimension to consider in making governance effective is understanding and satisfying the stakeholders surrounding it, starting with the teams. Any process can and should evolve, and that evolution should be based on experience obtained executing the process itself, monitoring operating metrics on an ongoing basis, and feedback that is continually gathered to make it more effective.

That being said, if the process never surfaces challenges and risks, it likely isn’t working properly, because governance is meant to do exactly that, along with providing teams with the support they need. Satisfying stakeholders doesn’t mean painting an unrealistically positive picture, especially if there are fundamental issues in the underlying environment.

I have seen situations where teams were encouraged to share inaccurate information about the health of their work in the interest of managing perceptions and avoiding difficult conversations that were critically needed. This is why having an experienced team leading the conversations and a healthy, supportive, and trusting environment is so important. Governance is needed because things do happen in delivery. Technology work is messy and complicated and there are always risks that materialize. The goal is to see them and respond before they have consequential impact.

Wrapping Up

Hopefully I’ve managed to hit some of the primary points to consider when establishing or evaluating a governance process. There are many dimensions, but the most important ones are first, focusing on value and, second, on having the right mindset, relationships, and trust. The process is too often the focus, and without the other parts, it will fail. People are at the center of making it work, nothing else.

I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.

-CJG 03/31/2025