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

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

The Seeds of Transformation

Introduction

“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.” – John F Kennedy, May 25, 1961

When JFK made his famous pronouncement in 1961, the United States was losing in the space race. The Soviet Union was visibly ahead, to the point that the government shuffled the deck, bringing together various agencies to form NASA, and set a target far out ahead of where anyone was focused at the time: landing on the Moon. The context is important as the U.S. was not operating from a position of strength and JFK didn’t shoot for parity or to remain in a defensive posture. Instead, he leaned in and set an audacious goal that redefined the playing field entirely.

I spoke at a town hall fairly recently about “The Saturn V Story”, a documentary that covers the space race and journey leading to the Apollo 11 moon landing on July 20, 1969. The scale and complexity of what accomplished in a relatively short timeframe was truly incredible and feels like a good way to introduce a Transformation discussion. The Apollo program engaged 375,000 people at its peak, required extremely thoughtful planning and coordination (including the Mercury and Gemini programs that preceded it), and presented a significant number of engineering challenges that needed to be overcome to achieve its ultimate goal. It’s an inspiring story, as any successful transformation effort should be.

The challenge is that true transformation is exceptionally difficult and many of these efforts fail or fall short of their stated objectives. The remainder of this article will highlight some key dimensions that I believe are critical in increasing the probability of success.

Transformation is a requirement of remaining competitive in a global digital economy. The disruptions (e.g., cloud computing, robotics, orchestration, artificial intelligence, cyber security exposure, quantum computing) have and will continue to occur, and success will be measured, in part, based on an organization’s ability to continuously transform, leveraging advanced capabilities to its’ maximum strategic benefit.

Successful Transformation

Culture versus Outcome

Before diving into the dimensions themselves, I want to emphasize the difference I see between changing culture and the kind of transformation I’m referencing in this article. Culture is an important aspect to affecting change, as I will discuss in the context of the dimensions themselves, but a change in culture that doesn’t lead to a corresponding change in results is relatively meaningless.

To that end, I would argue that it is important to think about “change management” as a way to transition between the current and desired ways of working in a future state environment, but with specific, defined outcomes attached to the goal.

It is insufficient, as an example, to express “we want to establish a more highly collaborative workplace that fosters innovation” without also being able to answer the questions: “To what end?” or “In the interest of accomplishing what?” Arguably, it is the desired outcome that sets the stage for the nature of the culture that will be required, both to get to the stated goal as well as to operate effectively once those goals are achieved. In my experience, this balance isn’t given enough thought when change efforts are initiated, and it’s important to make sure culture and desired outcomes are both clear and aligned with each other.

For more on the fundamental aspects of a healthy environment, please see my article on The Criticality of Culture.

What it Takes

Successful transformation efforts require focus on many levels and in various dimensions to manage what ultimately translates to risk.

The set that come to mind as most critical are having:

An audacious goal
- Transformation is, in itself, a fundamental (not incremental) change in what an organization is able to accomplish
- To the extent that substantial change is difficult, the value associated with the goal needs to outweigh the difficulties (and costs) that will be required to transition from where you are to where you need to be
- If the goal also isn’t compelling enough, likely there won’t be the requisite level of individual and collective investment required to overcome the adversity that is typically part of these efforts. This is not just about having a business case. It’s a reason for people to care… and that level of investment matters where transformation is the goal

Courageous, committed leadership
- Change is, by its’ nature, difficult and disruptive. There will be friction and resistance that comes from altering the status quo
- The requirements of leadership in these efforts tend to be very high, because of the adversity and risk that can be involved, and a degree of fearlessness and willingness to ride through the difficulties is important
- Where this level of leadership isn’t present, it will become easy to focus on obstacles versus solutions and to avoid taking risks that lead to suboptimized results or overall failure of the effort. If it was easy to transform, everyone would be doing it all the time
- It is worth noting that, in the case of the Apollo missions, JFK wasn’t there to see the program through, yet it survived both his passing and significant events like the Apollo fire without compromising the goal itself
- A question to consider in this regard: Is the goal so compelling that, if the vision holder / sponsor were to leave, the effort would still move forward? There are many large-scale efforts I’ve seen over the years where a change in leadership affects the commitment to a strategy. There may be valid reasons for this to be the case, but arguably both a worthy goal and strong leadership are necessary components in transformation overall

An aligned and supportive culture
- There is a significant aspect of accomplishing a transformational agenda that places a burden on culture
- On this point, the going-in position matters in the interest of mapping out the execution approach, because anything about the environment that isn’t conducive to facilitating and enabling collaboration and change will ultimately create friction that needs to be addressed and (hopefully) overcome
- To the extent that the organization works in silos or that there is significant and potentially unhealthy internal competition within and across leaders, the implications of those conflicts need to be understood and mitigated early on (to the degree possible) so as to avoid what could lead to adverse impacts on the effort overall
- As a leader said to me very early in my career, “There is room enough in success for everybody.” Defining success at an individual and collective level may be a worthwhile activity to consider depending on the nature of where an organization is when starting to pursue change
- On this final point, I have been in the situation more than once professionally where a team worked to actively undermine transformation objectives because those efforts had an adverse impact to their broader role in an organization. This speaks, in part, to the importance of engaged, courageous leadership to bring teams into alignment, but where that leadership isn’t present, it definitely makes things more difficult. Said differently, the more established the status quo is, the harder it may resist change

A thoughtful approach
- “Rome was not built in a day” is probably the best way to summarize this point
- Depending on the level of complexity and degree of change involved, the more thought and attention that needs to be paid to planning out the approach itself
- The Apollo program is a great example of this, because there were countless interim stages in the development of the Saturn V rocket, creating a safe environment for manned space flight, procedures for rendezvous and docking of the spacecraft, etc.
- In a technology delivery environment, these can be program increments in a scaled Agile environment, selective “pilots” or “proof-of-concept” efforts, or interim deliveries in a more component-based (and service-driven) architecture. The overall point being that it’s important to map out the evolution of current to future state, allowing for testing and staging of interim goals that help reduce risk on the ultimate objectives
- In a different example, when establishing an architecture capability in a large, complex organization, we established an operating model to define roles and responsibilities, but then operationalized the model in layers to help facilitate change with defined outcomes spread across multiple years. This was done purposefully and deliberately in the interest of making the changes sustainable and to gradually shift delivery culture to be more strategically-aligned, disciplined, and less siloed in the process

Agility and adaptiveness
- The more advanced and innovative the transformation effort is, the more likely it will be that there is a higher degree of unknown (and knowledge risk) associated with the effort
- To that end, it is highly probable that the approach to execution will evolve over time as knowledge gaps are uncovered and limitations and constraints need to be addressed and overcome
- There are countless examples of this in the Apollo program, one of the early ones being the abandonment of the “Nova” rocket design, which involved a massive vehicle that ultimately was eliminated in deference to the multi-stage rocket and lunar lander / command module approach. In this case, the means for arriving at and landing on the moon was completely different than it was at the program’s inception, but the outcome was ultimately the same
- I spend some time discussing these “points of inflection” in my article On Project Health and Transparency, but the important concept is not to be too prescriptive when planning a transformation effort, because execution will definitely evolve

Patience and discipline
- My underlying assumption is that the level of change involved in transformation is significant and, as such, it will take time to accomplish
- The balance to be struck is ultimately in managing interim deliveries in relation to the overall goals of the effort. This is where patience and discipline matter, because it is always tempting to take short cuts in the interest of “speed to market” while compromising fundamental design elements that are important to overall quality and program-level objectives (something I address in Fast and Cheap, Isn’t Good)
- This isn’t to say that tradeoffs can’t or shouldn’t be made, because they often are, but rather that these be conscious choices, done through a governance process, and with a full understanding of the implications of the decisions on the ultimate transformation objectives

A relentless focus on delivery
- The final dimension is somewhat obvious, but is important to mention, because I’ve encountered transformative efforts in the past that spent so much energy either on structural or theoretical aspects to their “program design” that they actually failed to deliver anything
- In the case of the Apollo program, part of what makes the story so compelling is the number of times the team needed to innovate to overcome issues that arose, particularly to various design and engineering challenges
- Again, this is why courageous, committed leadership is so important to transformation. The work is difficult and messy and it’s not for the faint of heart. Resilience and persistence are required to accomplish great things.

Wrapping Up

Hopefully this article has provided some areas to consider in either mapping out or evaluating the health of a transformational effort. As I covered in my article On Delivering at Speed, there are always opportunities to improve, even when you deliver a complex or high-risk effort. The point is to be disciplined and thoughtful in how you approach these efforts, so the bumps that inevitably occur are more manageable and the impact they have are minimized overall.

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

-CJG 12/29/2024

Thoughts on Portfolio Management

Overview

Setting the stage

Having had multiple recent discussions related to portfolio management, I thought I’d share some thoughts relative to disciplined operations, in terms of the aforementioned subject and on the associated toolsets as well. This is a substantial topic, but I’ll try to hit the main points and address more detailed questions as and when they arise.

In getting started, given all the buzz around GenAI, I asked ChatGPT “What are the most important dimensions of portfolio management in technology?” What was interesting was that the response aligned with most discussions I’ve had over time, which is to say that it provided a process-oriented perspective on strategic alignment, financial management, and so on (a dozen dimensions overall), with a wonderfully summarized description of each (and it was both helpful and informative). The curious part was that it missed the two things I believe are most important: courageous leadership and culture.

The remainder of this article will focus more on the process dimensions (I’m not going to frame it the same as ChatGPT for simplicity), but I wanted to start with a fundamental point: these things have to be about partnership and value first and process second. If the focus becomes the process, there is generally something wrong in the partnership or the process is likely too cumbersome in how it is designed (or both).

Portfolio Management

Partnership

Portfolio management needs to start with a fundamental partnership and shared investment between business and technology leaders on the intended outcome. Fortunately, or unfortunately, where the process tends to get the most focus (and part of why I’ve heard it so much in the last couple years) is in a difficult market/economy where spend management is the focus, and the intention is largely related to optimizing costs. Broadly speaking, when times are good and businesses grow, the processes for prioritization and governance can become less rigorous in a speed-to-market mindset, the demand for IT services increases, and a significant amount of inefficiency, delivery and quality issues can arise as a result. The reality is that discipline should always be a part of the process because it’s in the best interest of creating value (long- and short-term) for an organization. That isn’t to suggest artificial constraints, unnecessary gates in a process, or anything to hinder speed-to-market. Rather, the goal of portfolio management should be to have a framework in place to manage demand through delivery in a way that facilitates predictable, timely, and quality delivery and a healthy, secure, robust, and modern underlying technology footprint that creates significant business value and competitive advantage over time. That overall objective is just as relevant during a demand surge as it is when spending is constrained.

This is where courageous leadership becomes the other critical overall dimension. It’s never possible to do everything and do it well. The key is to maintain the right mix of work, creating the right outcomes, at a sustainable pace, with quality. Where technology leaders become order takers is where a significant amount of risk can be introduced that actually hurts a business over time. The primary results being that taking on too much without thoughtful planning can result in critical resources being spread too thin, missed delivery commitments, poor quality, and substantial technical debt, all of which eventually undermine the originally intended goal of being “responsive”. This is why partnership and mutual investment in the intended outcomes matters. Not everything has to be “perfect” (and the concept itself doesn’t really exist in technology anyway), but the point is to make conscious choices on where to spend precious company resources to optimize the overall value created.

End-to-End Transparency

Shifting focus from the direction to the execution, portfolio management needs to start with visibility in three areas:

Demand management – the work being requested
Delivery monitoring – the work being executed
Value realization – the impact of what was delivered

In demand management, the focus should ideally be on both internal and external factors (e.g., business priorities, customer needs, competitive and industry trends), a thoughtful understanding of the short- and long-term value of the various opportunities, the requirements (internal and external) necessary to make them happen, and the desired timeframe for those results to be achieved. From a process standpoint, notice of involvement and request for estimate (RFE) processes tend to be important (depending on the scale and structure of an organization), along with ongoing resource allocation and forecast information to evaluate these opportunities as they arise.

Delivery monitoring is important, given the dependencies that can and do exist within and across efforts in a portfolio, the associated resource needs, and the expectations they place on customers, partners, or internal stakeholders once delivered. As and when things change, there should be awareness as to the impact of those changes on upcoming demand as well as other efforts within a managed portfolio.

Value realization is a generally underserved, but relatively important part of portfolio management, especially in spending constrained situations. This level of discipline (at an overall level) is important for two primary reasons: first, to understand the efficacy of estimation and planning processes in the interest of future prioritization and planning and, second, to ensure investments were made effectively in the right priorities. Where there is no “retrospective”, a lot of learnings may be being lost in the interest of continuous improvement and operational efficiency and effectiveness over time (ultimately having an adverse impact on business value created).

Maintaining a Balanced Portfolio

Two concepts that I believe are important to consider in how work is ultimately allocated/prioritized within an IT portfolio:

Portfolio allocation – the mix of work that is being executed on an ongoing basis
Prioritization – how work is ultimately selected and the process for doing so

A good mental model for portfolio allocation is a jigsaw puzzle. Some pieces fit together, others don’t, and whatever pieces are selected, you ultimately are striving to have an overall picture that matches what you originally saw “on the box”. While you also can operate in multiple areas of a puzzle at the same time, you also generally can’t focus in on all of them concurrently and expect to be efficient on the whole.

What I believe a “good” portfolio should include is four key areas (with an optional fifth):

Innovation – testing and experimenting in areas where you may achieve significant competitive advantage or differentiation
Business Projects – developing solutions that create or enable new or enhanced business capabilities
Modernization – using an “urban renewal” mindset to continue to maintain, simplify, rationalize, and advance your infrastructure to avoid significant end of life, technical debt, or other adverse impacts from an aging or diverse technology footprint
Security – continuing to leverage tools and technologies that manage the ever increasing exposure associated with cyber security threats (internal and external)
Compliance (where appropriate) – investing in efforts to ensure appropriate conformance and controls in regulatory environments / industries

I would argue that, regardless of the level of overall funding, these categories should always be part of an IT portfolio. There can obviously be projects or programs that provide forward momentum in more than one category above, but where there isn’t some level of investment in the “non-business project” areas, likely there will be a significant correction needed at some point of time that could be very disruptive from a business standpoint. It is probably also worth noting that I am not calling out a “technology projects” category above on purpose. From my perspective, if a project doesn’t drive one of the other categories, I’d question what value it creates. There is no value in technology for technology’s sake.

From a prioritization standpoint, I’ve seen both ends of the spectrum over the course of time: environments where there is no prioritization in place and everything with a positive business case (and even some without) are sent into execution to ones where there is an elaborate “scoring” methodology, with weights and factors and metrics organized into highly elaborate calculations that create a false sense of “rigor” in the efficacy of the process. My point of view overall is that, with the above portfolio allocation model in place, ensuring some balance in each of the critical categories of spend, a prioritization process should include some level of metrics, with an emphasis on short- and long-term business/financial impact as well as a conscious integration of the resource commitments required to execute the effort by comparison with other alternatives. As important as any process, however, is the discussions that should be happening from a business standpoint to ensure the engagement, partnership, and overall business value being delivered through the portfolio (the picture on the box) in the decisions made.

Release Management

Part of arriving at the right set of work to do also comes down to release management. A good analogy for release management is the game Tetris. In Tetris, you have various shaped blocks dropping continually into a grid, with the goal of rotating and aligning them to fit as cleanly with what is already on the radar as possible. There are and always will be gaps and the fit will never be perfect, but you can certainly approach Tetris in a way that is efficient and well-aligned or in a way that is very wasteful of the overall real estate with which you have to work.

This is great mental model for how project planning should occur. If you do a good job, resources are effectively utilized, outcomes are predictable, there is little waste, and things run fairly smoothly. If you don’t think about the process and continually inject new work into a portfolio without thoughtful planning as to dependencies and ongoing commitments, there can and likely will be significant waste, inefficiency, collateral impact, and issues in execution.

Release management comes down to two fundamental components:

Release strategy – the approach to how you organize and deliver major and minor changes to various stakeholder groups over time
Release calendar – an ongoing view of what will be delivered at various times, along with any critical “T-minus” dates and/or delivery milestones that can be part of a progress monitoring or gating process used in conjunction with delivery governance processes

From a release strategy standpoint, it is tempting in a world of product teams, DevSecOps, and CI/CD pipelines to assume everything comes down to individual product plans and their associated release schedules. The two primary issues here are the time and effort it generally takes to deploy new technology and the associated change management impact to the end users who are expected to adopt those changes as and when they occur. The more fragmented the planning process, the more business risk there is that ultimately end users or customers will be either under or overserved at any given point in time, where a thoughtful release strategy can help create predictable, manageable, and sustainable levels of change over time across a diverse set of stakeholders being served.

The release calendar, aside from being an overall summary of what will be delivered when and to whom, also should ideally provide transparency into other critical milestones in the major delivery efforts so that, in the event something moves off plan (which is a very normal occurrence in technology and medium to larger portfolios), the relationship to other ongoing efforts can be evaluated from a governance standpoint to determine whether any rebalancing or slotting of work is required.

Change Management

While I won’t spend a significant amount of time on this point, change management is often an area where I’ve seen the process managed very well and relatively poorly. The easy part is generally managing change relative to a specific project or program and that governance often exists in my experience. The issue that can arise is when the leadership overseeing a specific project is only taking into account the implications of change on that effort alone, and not the potential ripple effect of a schedule, scope, or financial adjustment on the rest of the portfolio, future demand, or on end users in the event that releases are being adjusted.

On Tooling

Pivoting from processes to tools, at an overall level, I’m generally not a fan of over-engineering the infrastructure associated with portfolio management. It is very easy for such an infrastructure to take a life of its own, become a significant administrative burden that creates little value (beyond transparency), or contain outdated and inaccurate information to the degree that the process involves too much data without underlying ownership and usage of the data obtained.

The goal is the outcome, not the tools.

To the extent that a process is being established, I’d generally want to focus on transparency (demand through delivery) and a healthy ongoing discussion of priorities in the interest of making informed decisions. Beyond that, I’ve seen a lot of reporting that doesn’t generally result in any level of actions being taken, which I consider to be very ineffective from a leadership and operational standpoint.

Again, if the process is meant to highlight a relationship problem, such as a dashboard being created requiring a large number of employees to capture timesheets to be rolled up, marked to various projects, all to have a management discussion to say “we’re over allocated and burning out our teams”, my question would be why all of that data and effort was required to “prove” something, whether there is actual trust and partnership, whether there are other underlying delivery performance issues, and so on. The process and tools are there to enable effective execution and the creation of business value, not drain effort and energy that could better be applied in delivery with administrivia.

Wrapping Up

Overall, having spent a number of years seeing well developed and executed processes as well as less robust versions of the same, effective portfolio management comes down to value creation. When the focus becomes about the process, the dashboard, the report, the metrics, something is amiss in my experience. It should about informing engaged leadership, fostering partnership, enabling decisions, and creating value. That is not to say that average utilization of critical resources (as an example) isn’t a good thing to monitor and keep in mind, but it’s what you do with that information that matters.

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

-CJG 07/29/2024