Having touched on the importance of quality in accelerating value in my latest article Creating Value Through Strategy, I wanted to dive a little deeper into the topic of “speed versus quality”.
For those who may be unfamiliar, there is a general concept in project delivery that the three primary dimensions against which you operate are good (the level of effort you put into ensuring a product is well architected and meets functional and non-functional requirements at the time of delivery), fast (how quickly or often you produce results), and cheap (your ability to deliver the product/solution at a reasonable cost).
The general assumption is that the realities of delivery lead you to having to prioritize two of the three (e.g., you can deliver a really good product fast, but it won’t be cheap; or you can deliver a really good product at a low cost, but it will take a lot of time [therefore not be “fast”]). What this translates to, in my experience, has nearly always been that speed and cost are prioritized highest, with quality being the item compromised.
Where this becomes an issue is in the nature of the tradeoff that was made and the longer-term implications of those decisions. Quality matters. My assertion is that, where quality is compromised, “cheap” is only true in the short-term and definitely not the case overall.
The remainder of this article will explore several dimensions to consider when making these decisions. This isn’t to say that there aren’t cases where there is a “good enough” level of quality to deliver a meaningful or value-added product or service. My experience, however, has historically been that the concepts like “we didn’t have the time” or “we want to launch and learn” are often used as a substitute for discipline in delivery and ultimately undermine business value creation.
Putting Things in Perspective
Dimensions That Matter
I included the diagram above to put how I think of product delivery into perspective. In the prioritization of good, fast, and cheap, what often occurs is that too much focus and energy goes into the time spent getting a new capability or solution to market, but not enough on what happens once it is there and the implications of that. The remainder of this section will explore aspects of that worth considering in the overall context of product/solution development.
Some areas to consider in how a product is designed and delivered:
Architecture
Is the design of the solution modular and component- or service-based? This is important to the degree that capabilities may emerge over time that surpass what was originally delivered and, in a best-of-breed environment, you would ideally like to be able to replace part of a solution without having to fundamentally rearchitect or materially refactor the overall solution
Does the solution conform to enterprise standards and guidelines? I’ve seen multiple situations where concurrent, large-scale efforts were designed and developed without consideration for their interoperability and adherence to “enterprise” standards. By comparison, developing on a “program-“ or “project-level”, or in working with a monolithic technology/solution (e.g., with a relatively closed ERP system), creates technology silos that lead to a massive amount of technical debt as it is almost never the case that there is leadership appetite for refactoring or rewriting core aspects of those solutions over time
Is the solution cloud-native and does it support containerization to enable deployment of workloads across public and private clouds as well as the edge? In the highly complex computing environments of today, especially in industries like Manufacturing, the ability to operate and distribute solutions to optimize availability, performance, and security (at a minimum) is critical. Where these dimensions aren’t taken into account, there would likely be almost an immediate need for modernization to offset the risk of technology obsolescence at some point in the next year or two
Security
Does the product or service leverage enterprise technologies and security standards? Managing vulnerabilities and migrating towards “zero trust” is a critical aspect of today’s technology environment, especially to the degree that workloads are deployed on the public cloud. Where CI/CD pipelines are developed as part of a standard cloud platform strategy with integrated security tooling, the enterprise level ability to manage, monitor, and mitigate security risk will be significant improved
Integration
Does the product or service leverage enterprise technologies and integration standards? Interoperability with other internal and external systems, as well as your ability to introduce and leverage new capabilities and rationalize redundant solutions over time is fundamentally dependent on the manner in which applications are architected, designed, and integrated with the rest of a technology footprint. Having worked in environments with well-defined standards and strictly enforced governance versus ones where neither were in place, the level of associated complexity and costs in the ultimate operating environments was materially different
Data Standards
Does the product or service align to overall master data requirements for the organization? Master data management can be a significant challenge from a data governance standpoint, which is why giving this consideration up front in a product development lifecycle is extremely important. Where it isn’t considered in design, the end result could be master data that doesn’t map or align to other hierarchies in place, complicating integration and analytics intended to work across solutions and the “cleanup” required of data stewards (to the degree that they are in place) could be expensive and difficult post-deployment
Are advanced analytics aspirations taken into account in the design process itself? This is an area becoming increasingly important given AI-enabled (“intelligent”) applications as discussed in my article on The Intelligent Enterprise. Designing with data standards in mind and an eye towards how it will be used to enable and drive analytics, likely in concert with data in other adjacent or downstream systems is a step that can save considerable effort and cost downstream when properly addressed early in the product development cycle
“Good Enough”/Responsive Architecture
All the above points noted, I believe architecture needs to be appropriate to the nature of the solution being delivered. Having worked in environments where architecture standards were very “ivory tower”/theoretical in nature and made delivery extremely complex and costly versus ones where architecture was ignored and the delivery environment was essentially run with an “ask for forgiveness” or cowboy/superhero mentality, the ideal state in my mind should be somewhere in between, where architecture is appropriate to the delivery circumstances, but also mindful of longer-term implications of the solution being delivered so as to minimize technical debt and further interoperability in a connected enterprise ecosystem environment.
Thinking Total Cost of Ownership
What makes product/software development challenging is the level of unknowns that exist. At any given time, when estimating a new endeavor, you have the known, the known unknown, and the complete unknown (because what you’re doing is outside your team’s collective experience). The first two components can be incorporated into an estimation model that can be used for planning and the third component can be covered through some form of “contingency” load that is added to an estimate to account for those blind spots to a degree.
Where things get complicated is, once execution begins, the desire to meet delivery commitments (and the associated pressure thereof) can influence decisions being made on an ongoing basis. This is complicated by the normal number of surprises that occur during any delivery effort of reasonable scale and complexity (things don’t work as expected, decisions or deliverables are delayed, requirements become increasingly clear over time, etc.). The question is whether a project has both disciplined, courageous leadership in place and the appropriate level of governance to make sure that, as decisions need to made in the interest of arbitrating quality, cost, time, and scope, that they are done with total cost of ownership in mind.
As an example, there was a point in the past where I encountered a large implementation program ($100MM+ in scale) with a timeline of over a year to deploy an initial release. During the project, the team announced that all the pivotal architecture decisions needed to be made within a one-week window of time, suggesting that the “dates wouldn’t be met” if that wasn’t done. That logic was then used at a later point to decide that standards shouldn’t be followed for other key aspects of the implementation in the interest of “meeting delivery commitments”. What was unfortunate in this situation was that, not only were good architecture and standards not implemented, the project encountered technical challenges (likely due to one or two of those root causes, among other things) that caused it to be delivered over a year late regardless. The resulting solution was more difficult to maintain, integrate, scale, or leverage for future business needs. In retrospect, was any “speed” obtained through that decision making process and the lack of quality in the solution? Certainly not, and this situation unfortunately isn’t unique to larger scale implementations in my experience. In these cases, the ongoing run rate of the program itself can become an excuse to make tactical decisions that ultimately create a very costly and complex solution to manage and maintain in the production environment, none of which anyone typically wants to remediate or rewrite post-deployment.
So, given the above example, the argument could be made that the decisions were a result of inexperience or pure unknowns that existed when the work was estimated and planned to begin with, which is a fair point. Two questions come to mind in terms of addressing this situation:
Are ongoing changes being reviewed through a change control process in relation to project cost, scope, and deadline, or are the longer-term implications in terms of technical debt and operating cost of ownership also considered? Compromise is a reality of software delivery and there isn’t a “perfect world” situation pretty much ever in my experience. That being said, these choices should be conscious ones, made with full transparency and in a thoughtful manner, which is often not the case, especially when the pressures surrounding a project are high to begin with.
Are the “learnings” obtained on an ongoing basis factored into the estimation and planning process so as to mitigate future needs to compromise quality when issues arise? Having been part of and worked closely with large programs over many years, there isn’t a roadmap that ever plays out in practice how it is drawn up on paper at the outset. That being said, every time the roadmap is revised, as pivot points in the implementation are reached and plans adjusted, are learnings being incorporated such that mistakes or sacrifices to quality aren’t being repeated over and over again. This is a tangible thing that can be monitored and governed over time. In the case of Agile-driven efforts, it would be as simple as looking for patterns in the retrospectives (post-sprint) to see whether the process is improving or repeating the same mistakes (a very correctible situation with disciplined delivery leadership)
Speed on the Micro- Versus Macro-Scale
I touched on this somewhat in the previous point, but the point to call out here is that tactical decisions made in the interest of compromising quality for the “upcoming release” can and often do create technical issues that will ultimately make downstream delivery more difficult (i.e., slower and more costly).
As an example, there was a situation in the past where a team integrated technology from multiple vendors that provided the same underlying capability (i.e., the sourcing strategy didn’t have a “preferred provider”, so multiple buys were done over time using different partners, sometimes in parallel). In each case, the desire from the team was to deliver solutions as rapidly as possible in the interest of “meeting customer demand” and they were recognized and rewarded for doing so at speed. The problem with this situation was that the team perceived standards as an impediment to the delivery process and, therefore, either didn’t leverage any or did so on a transactional or project-level basis. Where this became problematic was where there became a need to:
Replace a given vendor – other partners couldn’t be leveraged because they weren’t integrated in a common way
Integrate across partners – the technology stack was different and defined unique to each use case
Run analytics across solutions – data standards weren’t in place so that underlying data structures were in a common format
The point of sharing the example is that, at a micro-level, the team’s approach seems fast, cheap, and appropriate. The accumulation of the technical debt, however, is substantial when you scale and operate under that mindset for an extended period of time, and it does both limit your ability to leverage those investments, migrate to new solutions, introduce new capabilities quickly and effectively, and integrate across individual point solutions where needed. Some form of balance should be in place to optimize the value created and cost of ownership over time. Without it, the technical debt will undermine the business value in time.
Consulting Versus Corporate Environments
Having worked in both corporate and consulting environments, it’s interesting to me that there can be a different perspective on quality depending on where you sit (and the level of governance in place) in relation to the overall delivery.
Generally speaking, it’s somewhat common on the corporate side of the equation to believe that consultants lack the knowledge of your systems and business to deliver solutions you could yourself “if you had the time”. By contrast, on the consulting side, ideally, you believe that clients are thinking of you as a “hired gun” when it comes to implementations, because you’re bringing in necessary skills and capacity to deliver on something they may not have the experience or bench strength to deliver on their own.
So, with both sides thinking they know more than the other and believing they are capable of doing a quality job (no one does a poor job on purpose), why is quality so often left unattended on larger scale efforts?
On this point:
The delivery pressures and unknowns I mentioned above apply regardless of who is executing a project.
A successful delivery in many cases requires a blend of internal and external resources (to the extent they are being leveraged) so there is a balance of internal knowledge and outside expertise to deliver the best possible solution from an objective standpoint.
Finally, you can’t deliver to standards of excellence that aren’t set. I’ve seen and worked in environments (both as a “client” and as a consultant) where there were very exacting standards and expectations of quality and ones where quality wasn’t governed at the level it should be
I didn’t want to belabor this aspect of delivery, but it is interesting how the perspective and influence over quality decisions can be different depending on one’s role in the delivery process (client, consultant, or otherwise).
Wrapping Up
Bringing things back to the overall level, the point of writing this article was to provide some food for thought on the good, fast, cheap concept and the reality that, in larger and more complex delivery situations, the cost of speed isn’t always evaluated effectively. There is no “perfect world”, for certain, but having discipline, thinking through some of the dimensions above, and making sure the tradeoffs made are thoughtful and transparent in nature could help improve value/cost delivered over time.
I hope the ideas were worth considering. Thanks for spending the time to read them. Feedback is welcome as always.
One of the things that I’ve come to appreciate over the course of time is the value of what I call “actionable strategy”. By this, I mean a blend of the conceptual and practical,a framework that can be used to set direction and organize execution without being too prescriptive, while still providing a vision and mental model for leadership and teams to understand and align on the things that matter.
Without a strategy, you can have an organization largely focused on execution, but that tends to create significant operating or technical debt and complexity over time, ultimately having an adverse impact on competitive advantage, slowing delivery, and driving significant operating cost. Similarly, a conceptual strategy that doesn’t provide enough structure to organize and facilitate execution tends to create little impact over time as teams don’t know how to apply it in a practical sense, or it can add significant overhead and cost in the administration required to map its strategic objectives to the actual work being done across the organization (given they aren’t aligned up front or at all). The root causes of these situations can vary, but the important point is to recognize the criticality of an actionable business-aligned technology strategy and its role in guiding execution (and thereby the value technology can create for an organization).
In reality, there are so many internal and external factors that can influence priorities in an organization over time, that one’s ability to provide continuity of direction with clear conceptual outcomes (while not being too hung up on specific “tasks”) can be important in both creating the conditions for transformation and sustainable change without having to “reset” that direction very often. This is the essence of why framework-centric thinking is so important in my mind. Sustainable change takes time, because it’s a mindset, a culture, and way of operating. If a strategy is well-conceived and directionally correct, the activities and priorities within that model may change, but the ability to continue to advance the organization’s goals and create value should still exist. Said differently: Strategies are difficult to establish and operationalize. The less you have to do a larger-scale reset of them, the better. It’s also far easier to adjust priorities and activities than higher-level strategies, given the time it takes (particularly in larger organizations) to establish awareness of a vision and strategy. This is especially true if the new direction represents a departure from what has been in place for some time.
To be clear, while there is a relationship between this topic and what I covered in my article on Excellence By Design, the focus there is more on the operation and execution of IT within an organization, not so much the vision and direction of what you’d ideally like to accomplish overall.
The rest of this article will focus on the various dimensions that I believe compromise a good strategy, how I think about them, and ways that they could create measurable impact. There is nothing particularly “IT-specific” about these categories (i.e., this is conceptually akin to ‘better, faster, cheaper’) and I would argue they could apply equally well to other areas of a business, but differ in how they translate on an operating level.
In relation to the Measures outlined in each of the sections below, a few notes for awareness:
I listed several potential areas to consider and explore in each section, along with some questions that come to mind with each.
The goal wasn’t to be exhaustive or suggest that I’d recommend tracking any or all of them on an “IT Scorecard”, rather to provide some food for thought
My general point of view is that it’s better to track as little as possible from an “IT reporting” standpoint,unless there is intention to leverage those metrics to drive action and decisions. My experience with IT metrics historically is that they are overreported and underleveraged (and therefore not a good use of company time and resources). I touch on some of these concepts in the article On Project Health and Transparency
Innovate
What It Is and Why It Matters
Stealing from my article on Excellence By Design: “Relentless innovation is the notion that anything we are doing today may be irrelevant tomorrow, and therefore we should continuously improve and reinvent our capabilities to ones that create the most long-term value.”
Technology is evolving at a rate faster than most organizations’ ability to adopt or integrate those capabilities effectively. As a result, a company’s ability to leverage these advances becomes increasingly challenging over time, especially to the degree that the underlying environment isn’t architected in a manner to facilitate their integration and adoption.
The upshot of this is that the benefits to be achieved could be marginalized as any attempts to capitalize on these innovations will likely become point solutions or one-off efforts that don’t scale or create a different form of technical debt over time. This is very evident in areas like analytics where capabilities like GenAI and other artificial intelligence-oriented solutions are only as effective as the underlying architecture of the environment into which they are integrated. Are wins possible that could be material from a business standpoint? Absolutely yes. Will it be easy to scale them if you don’t invest in foundational things to enable that? Very likely not.
The positive side of this is that technology is in a much different place than it was ten or twenty years ago, where it can significantly improve or enhance a company’s capabilities or competitive position. Even in the most arcane of circumstances, there likely is an opportunity for technology to fuel change and growth in a digital business environment, whether that is internal to the operations of a company, or through its interactions with customers, suppliers, or partners (or some combination thereof).
Key Dimensions to Consider
Thinking about this area, a number of dimensions came to mind:
Promoting Courageous Leadership
This begins by acknowledging that leadership is critical to setting the stage for innovation over time
There are countless examples of organizations that were market leaders who ultimately lost their competitive advantage due to complacency or an inability to see or respond to changing market conditions effectively
Fueling Competitive Advantage
This is about understanding how technology helps create competitive advantage for a company and focusing in on those areas rather than trying to do everything in an unstructured or broad-based way, which would likely diffuse focus, spread critical resources, and marginalize realized benefits over time
Investing in Disciplined Experimentation
This is about having a well-defined process to enable testing out new business and technology capabilities in a way that is purposeful and that creates longer-term benefits
The process aspect of this important as it is relatively easy to spin up a lot of “innovation and improvement” efforts without taking the time to understand and evaluate the value and implications of those activities in advance. The problem of this being that you can either end up wasting money where the return on investment isn’t significant or that you can develop concepts that can’t easily be scaled to production-level solutions, which will limit their value in practice
Enabling Rapid Technology Adoption
This dimension is about understanding the role of architecture, standards, and governance in integrating and adopting new technical capabilities over time
As an example, an organization with an established component (or micro-service) architecture and integration strategy should be able to test and adopt new technologies much faster than one without them. That isn’t to suggest it can’t be done, but rather that the cost and time to execute those objectives will increase as delivery becomes more of a brute force situation than one enabled by a well-architected environment
Establishing a Culture of Sustainability
Following onto the prior point, as new solutions are considered, tested, and adopted, product lifecycle considerations should come into play.
Specifically, as part of the introduction of something new, is it possible to replace or retire something that currently exists?
At some point, when new technologies and solutions are introduced in a relatively ungoverned manner, it will only be a matter of time before the cost and complexity of the technology footprint will choke an organization’s ability to continue to both leverage those investments and to introduce new capabilities rapidly.
Measuring Impact
Several ways to think about impact:
Competitive Advantage
What is a company’s absolute position relative to its competition in markets where they compete and on metrics relative to those markets?
Market Differentiation
Is innovation fueling new capabilities not offered by competitors?
Is the capability gap widening or narrowing over time?
I separated these first two points, though they are arguably flavors of the same thing, to emphasize the importance of looking at both capabilities and outcomes from a competitive standpoint. One can be doing very well from a competitive standpoint relative to a given market, but have competitors developing or extending their capabilities faster, in which case, there could be risk of the overall competitive position changing in time
Reduced Time to Adopt New Solutions
What is the average length of time between a major technology advancement (e.g., cloud computing, artificial intelligence) becoming available and an organization’s ability to perform meaningful experiments and/or deploy it in a production setting?
What is the ratio of investment on infrastructure in relation to new technologies meant to leverage it over time?
Reduced Technical Debt
What percentage of experiments turn into production solutions?
How easy is to scale those production solutions (vertically or horizontally) across an enterprise?
Are new innovations enabling the elimination of other legacy solutions? Are they additive and complementary or redundant at some level?
Accelerate
What It Is and Why It Matters
“Take as much as time as you need, let’s make sure we do it right, no matter what.” This is a declaration that I don’t think I’ve ever heard in nearly thirty-two years in technology. Speed matters, “first mover advantage”, or any other label one could place upon the desire to produce value at a pace that is at or beyond an organization’s ability to integrate and assimilate all the changes.
That being said, the means to speed is not just a rush to iterative methodology. The number of times I’ve heard or seen “Agile Transformation” (normally followed by months of training people on concepts like “Scrum meetings”, “Sprints”, and “User Stories”) posed as a silver bullet to providing disproportionate delivery results goes beyond my ability to count and it’s unfortunate. Similarly, I’ve heard glorified versions of perpetual hackathons championed, where the delivery process involves cobbling together solutions in a “launch and learn” mindset that ultimately are poorly architected, can’t scale, aren’t repeatable, create massive amounts of technical debt, and never are remediated in production. These are cases where things done in the interest of “speed” actually destroy value over time.
That being said, moving from monolithic to iterative (or product-centric) approaches and DevSecOps is generally a good thing to do. Does this remedy issues in a business/IT relationship, solve for a lack of architecture, standards and governance, address an overall lack of portfolio-level prioritization, or a host of other issues that also affect operating performance and value creation over time? Absolutely not.
The dimensions discussed in this section are meant to highlight a few areas beyond methodology that I believe contribute to delivering value at speed, and ones that are often overlooked in the interest of a “quick fix” (which changing methodology generally isn’t).
Key Dimensions to Consider
Dimensions that are top of mind in relation to this area:
Optimizing Portfolio Investments
Accelerating delivery begins by first taking a look at the overall portfolio makeup and ensuring the level of ongoing delivery is appropriate to the capabilities of the organization. This includes utilization of critical knowledge resources (e.g., planning on a named resource versus an FTE-basis), leverage of an overall release strategy, alignment of variable capacity to the right efforts, etc.
Said differently, when an organization tries to do too much, it tends to do a lot of things ineffectively, even under the best of circumstances. This does not help enhance speed to value at the overall level
Promoting Reuse, Standards, and Governance
This dimension is about recognizing the value that frameworks, standards and governance (along with architecture strategy) play in accelerating delivery over time, because they become assets and artifacts that can be leveraged on projects to reduce risk as well as effort
Where these things don’t exist, there almost certainly will be an increase in project effort (and duration) and technical debt that ultimately will slow progress on developing and integrating new solutions into the landscape
Facilitating Continuous Improvement
This dimension is about establishing an environment where learning from mistakes is encouraged and leveraged proactively on an ongoing basis to improve the efficacy of estimation, planning, execution, and deployment of solutions
It’s worth noting that this is as much an issue of culture as of process, because teams need to know that it is safe, expected, and appreciated to share learnings on delivery efforts if there is to be sustainable improvement over time
Promoting Speed to Value
This is about understanding the delivery process, exploring iterative approaches, ensuring scope is managed and prioritized to maximize impact, and so on
I’ve written separately that methodology only provides a process, not necessarily a solution to underlying cultural or delivery issues that may exist. As such, it is part of what should be examined and understood in the interest of breaking down monolithic approaches and delivering value at a reasonable pace and frequency, but it is definitely not a silver bullet. They don’t, nor will they ever exist.
Establishing a Culture of Quality
In the proverbial “Good, Fast, or Cheap” triangle, the general assumption is that you can only choose two of the three as priorities and accept that the third will be compromised. Given that most organizations want results to be delivered quickly and don’t have unlimited financial resources, the implication is that quality will be the dimension that suffers.
The irony of this premise is that, where quality is compromised repeatedly on projects, the general outcome is that technical debt will be increased, maintenance effort along with it, and future delivery efforts will be hampered as a consequence of those choices
As a result, in any environment where speed is important, quality needs to be a significant focus so ongoing delivery can be focused as much as possible on developing new capabilities and not fixing things that were not delivered properly to begin with
Measuring Impact
Several ways to think about impact:
Reduced Time to Market
What is the average time from approval to delivery?
What is the percentage of user stories/use cases delivered per sprint (in an iterative model)? What level of spillover/deferral is occurring on an ongoing basis (this can be an indicator of estimation, planning, or execution-related issues)?
Are retrospectives part of the delivery process and valuable in terms of their learnings?
Increase in Leverage of Standards
Is there an architecture review process in place? Are standards documented, accessible, and in use? Are findings from reviews being implemented as an outcome of the governance process?
What percentage of projects are establishing or leveraging reusable common components, services/APIs, etc.?
Increased Quality
Are defect injection rates trending in a positive direction?
What level of severity 1/2 issues are uncovered post-production in relation to those discovered in testing pre-deployment (efficacy of testing)?
Are criteria in place and leveraged for production deployment (whether leveraging CI/CD processes or otherwise)?
Is production support effort for critical solutions decreasing over time (non-maintenance related)?
Lower Average Project Cost
Is the average labor cost/effort per delivery reducing on an ongoing basis?
Optimize
What It Is and Why It Matters
Along with the pursuit of speed, it is equally important to pursue “simplicity” in today’s complex technology environment. With so many layers now being present, from hosted to cloud-based solutions, package and custom software, internal and externally integrated SaaS and PaaS solutions, digital equipment and devices, cyber security requirements, analytics solutions, and monitoring tools… complexity is everywhere. In large organizations, the complexity tends to be magnified for many reasons, which can create additional complexities in and across the technology footprint and organizations required to design, deliver, and support integrated solutions at scale.
My experience with optimization historically is that it tends to be too reactive of a process, and generally falls by the wayside when business conditions are favorable. The problem with this is the bloat and inefficiency that tends to be bred in a growth environment, that ultimately reduces the value created by IT with increasing levels of spend. That is why a purposeful approach that is part of a larger portfolio allocation strategy is important. Things like workforce and sourcing strategy, modernization, ongoing rationalization and simplification, standardization and continuous improvement are important to offset what otherwise could lead to a massive “correction” the minute conditions change. I would argue that, similar to performance improvement in software development, an organization should never be so cost inefficient that a massive correction is even possible. For that to be the case, something extremely disruptive should have occurred, otherwise the discipline in delivery and operations likely wasn’t where it needed to be leading up to that adjustment.
I’ve highlighted a few dimensions that are top of mind in regard to ongoing optimization, but have written an entire article on optimizing value over cost that is a more thorough exploration of this topic if this is of interest (Optimizing the Value of IT).
Key Dimensions to Consider
Dimensions that are top of mind in relation to this area:
Reducing Complexity
There is some very simple math related to complexity in an IT environment, which is that increasing complexity drives a (sometimes disproportionate) increase in cost and time to deliver solutions, especially where there is a lack of architecture standards and governance
In areas like Integration and Analytics, this is particularly important, given they are both foundational and enable a significant amount of business capabilities when done well
It is also important to clarify that reducing complexity doesn’t necessarily equate to reducing assets (applications, data solutions, technologies, devices, integration endpoints, etc.), because it could be the case that the number of desired capabilities in an organization requires an increasing number of solutions over time. That being said, with the right integration architecture and associated standards, as an example, the ability to integrate and rationalize solutions will be significantly easier and faster than without them (which is complexity of a different kind)
Optimizing Ongoing Costs
I recently wrote an article on Optimizing the Value of IT, so I won’t cover all that material again here
The overall point is that there are many levers available to increase value while managing or reducing technology costs in an enterprise
That being said, aggregate IT spend can and may increase over time, and be entirely appropriate depending on the circumstances, as long as the value delivered increases proportionately (or in excess of that amount)
Continually Modernizing
The mental model that I’ve had for support for a number of years is to liken it to city planning and urban renewal. Modernizing a footprint is never a one-time event, it needs to be a continuous process
Where this tends to break down in many organizations is the “Keep the Lights On” concept, which suggests that maintenance spend should be minimized on an ongoing basis to allow the maximum amount of funding for discretionary efforts that advance new capabilities
The problem with this logic is that it can tend to lead to neglect of core infrastructure and solutions that then become obsolete, unsupportable, pose security risks, and that approach end of life with only very expensive and disruptive paths to upgrade or modernize them
It would be far easier to carve out a portion of the annual spend allocation for a thoughtful and continuous modernization where these become ongoing efforts, are less disruptive, and longer-term costs are managed more effectively at lower overall risk
Establishing and Maintaining a Workforce Strategy
I have an article in my backlog for this blog around workforce and sourcing strategy, having spent time developing both in the past, so I won’t elaborate too much on this right now other than to say it’s an important component in an organizational strategy for multiple reasons, the largest being that it enables you to flex delivery capability (up and down) to match demand while maintaining quality and a reasonable cost structure
Proactively Managing Performance
Unpopular though it is, my experience in many of the organizations in which I’ve worked over the years has been that performance management is handled on a reactive basis
Particularly when an organization is in a period of growth, notwithstanding extreme situations, the tendency can be to add people and neglect the performance management process with an “all hands, on deck” mentality that ultimately has a negative impact on quality, productivity, morale, and other measures that matter
This isn’t an argument for formula-driven processes, as I’ve worked in organizations that have forced performance curves against an employee population, and sometimes to significant, detrimental effect. My primary argument is that I’d rather have an environment with 2% involuntary annual attrition (conceptually), than one where it isn’t managed at all, market conditions change, and suddenly there is a push for a 10% reduction every three years, where competent “average” talent is caught in the crossfire. These over-corrections cause significant disruption, have material impact on employee loyalty, productivity, and morale, and generally (in my opinion) are the result of neglecting performance management on an ongoing basis
Measuring Impact
Several ways to think about impact:
Increased Value/Cost Ratio
Is the value delivered for IT-related effort increasing in relation to cost (whether the latter is increasing, decreasing, or remaining flat)?
Reduced Overall Assets
Have the number of duplicated/functionally equivalent/redundant assets (applications, technologies, data solutions, devices, etc.) reduced over time?
Lower Complexity
Is the percentage of effort on the average delivery project spent on addressing issues related to a lack of standards, unique technologies, redundant systems, etc. reducing over time?
Lower Technical Debt
What percentage of overall IT spend is committed to addressing quality, technology, end-of-life, or non-conformant solutions (to standards) in production on an ongoing basis?
Inspire
What It Is and Why It Matters
Having written my last article on culture, I’m not going to dive deeply into the topic, but I believe the subject of employee engagement and retention (“People are our greatest asset…”) is often spoken about, but not proportionately acted on in deliberate ways. It is far different, as an example, to tell employees their learning and development is important, but then either not provide the means for them to receive training and education or put “delivery” needs above that growth on an ongoing basis. It’s expedient on a short-term level, but the cost to an organization in loyalty, morale, and ultimately productivity (and results) is significant.
Inspiration matters. I fundamentally believe you achieve excellence as an organization by enrolling everyone possible in creating a differentiated and special workplace. Having worked in environments where there was a contagious enthusiasm in what we were doing and also in ones I’d consider relatively toxic and unhealthy, there’s no doubt on the impact it has on the investment people make in doing their best work.
Following onto this, I believe there is also a distinction to be drawn in engaging the “average” employees across the organization versus targeting the “top performers”. I have written about this previously, but top performers, while important to recognize and leverage effectively, don’t generally struggle with motivation (it’s part of what makes them top performers to begin with). The problem is that placing a disproportionate amount of management focus on this subset of the employee population can have a significant adverse impact, because the majority of an organization is not “top performers” and that’s completely fine. If the engagement, output, and productivity of the average employee is elevated even marginally, the net impact to organizational results should be fairly significant in most environments.
The dimensions below represent a few ways that I think about employee engagement and creating an inspired workplace.
Key Dimensions to Consider
Dimensions that are top of mind in relation to this area:
Becoming an Employer of Choice
Reputation matters. Very simple, but relevant point
This becomes real in how employees are treated on a cultural and day-to-day level, compensated, and managed even in the situation where they exit the company (willingly or otherwise)
Having worked for and with organizations that have had a “reputation” that is unflattering in certain ways, the thing I’ve come to be aware of over time is how important that quality is, not only when you work for a company, but the perception of it that then becomes attached to you afterwards
Two very simple questions to employees that could serve as a litmus test in this regard:
If you were looking for a job today, knowing what you know now, would you come work here again?
How likely would you be to recommend this as a place to work to a friend?
Promoting a Healthy Culture
Following onto the previous point, I recently wrote about The Criticality of Culture, so I won’t delve into the mechanics of this beyond the fact that dedicated, talented employees are critical to every organization, of any size, and the way in which they are treated and the environment in which they work is crucial to optimizing the experience for them and the results that will be obtained for the organization as a whole
Investing in Employee Development
Having worked in organizations where there was both an explicit, dedicated commitment to ongoing education and development and others where there was “never time” to invest in or “delivery commitments” that interfered with people’s learning and growth, the consequent impact on productivity and organizational performance has always been fairly obvious and very negative from my perspective
A healthy culture should create space for people to learn and grow their skills, particularly in technology, where the landscape is constantly changing and there is a substantial risk of skills becoming atrophied if not reinforced and evolved as things change.
This isn’t an argument for random training, of course, as there should be applicability for the skills into which an organization invests on behalf of its employees, but it should be an ongoing priority as much as any delivery effort so you maintain your ability to integrate new technology capabilities as and when they become available over time
Facilitating Collaboration
This and the next dimension are both discussed in the above article on culture, but the overall point is that creating a productive workplace goes beyond the individual employee to encouraging collaboration and seeking the kind of results discussed in my article on The Power of N
The secondary benefit from a collaborative environment is the sense of “connectedness” it creates across teams when it’s present, which would certainly help productivity and creativity/solutioning when part of a healthy, positive culture
Creating an Environment of Transparency
Understanding there are always certain things that require confidentiality or limited distribution (or both), the level of transparency in an environment helps create connection between the individual and the organization as well as helping to foster and engender trust
Reinforcing the criticality of communication in creating an inspiring workplace is extremely obvious, but having seen situations where the opposite is in place, it’s worth noting regardless
Measuring Impact
Several ways to think about impact:
Improved Productivity
Is more output being produced on a per FTE basis over time?
Are technologies like Copilot being leveraged effectively where appropriate?
Improved Average Utilization
Are utilization statistics reflecting healthy levels (i.e., not significantly over or under allocated) on an ongoing basis (assuming plan/actuals are reasonably reflected)?
Improved Employee Satisfaction
Are employee surveys trending in a positive direction in terms of job satisfaction?
Lower Voluntary Attrition
Are metrics declining in relation to voluntary attrition?
Perform
What It Is and Why It Matters
Very simply said: all the aspirations to innovate, grow, and develop capabilities don’t mean a lot if your production environment doesn’t support business and customer needs exceptionally well on a day-to-day basis.
As a former account executive and engagement manager in consulting at various organizations, any account strategy for me always began with one statement: “Deliver with quality”. If you don’t block and tackle well in your execution, the best vision and set of strategic goals will quickly be set aside until you do. This is fundamentally about managing infrastructure, availability, performance of critical solutions, and security. In all cases, it can be easy to operate in a reactive capacity and be very complacent about it, rather than looking for ways to improve, simplify, and drive greater stability, security, and performance over time.
As an example, I experienced a situation where an organization spent tens of millions of dollars annually on production support, planning for things that essentially hadn’t broken yet, but had no explicit plan or spend targeted at addressing the root cause of the issues themselves. Thankfully, we were able to reverse that situation, plan for some proactive efforts that ultimately took millions out of that spend by simply executing a couple projects. In that case, the issue was the mindset, assuming that we had to operate in a reactive rather than proactive way, while the effort and dollars being consumed could have been better applied developing new business capabilities rather than continuing to band-aid issues we’d never addressed.
Another situation that is fairly prevalent today is the role of FinOps in managing cloud costs. Without governance, the convenience of spinning up cloud assets and services can add considerable complexity, cost, and security exposure, all under the promise of shifting from a CapEx to OpEx environment. The reality is that the maturity and discipline required to manage it effectively requires focus so it doesn’t become problematic over time.
There are many ways to think about managing and optimizing production, but the dimensions that come to mind as worthy of some attention are expressed below.
Key Dimensions to Consider
Dimensions that are top of mind in relation to this area:
Providing Reliability of Critical Solutions
Having worked with a client where the health of critical production solutions was in a state where that became the top IT priority, this can’t be overlooked as a critical priority in any strategy
It’s great to advance capabilities through ongoing delivery work, but if you can’t operate and support critical business needs on a daily level, it doesn’t matter
Effectively Managing Vulnerabilities
With the increase in complexity in managing technology environments today, internal and external to an organization, cyber exposure is growing at a rate faster than anyone can manage it fully
To that end, having a comprehensive security strategy, from managing external to internal threats, ransomware, etc. (from the “outside-in”) is critical to ensuring ongoing operations with minimal risk
Evolving Towards a “Zero Trust” Environment
Similar to the previous point, while the definition of “zero trust” continues to evolve, managing a conceptual “least privilege” environment (from the “inside-out”) that protects critical assets, applications, and data is an imperative in today’s complex operating environment
Improving Integrated Solution Performance
Again, with the increasing complexity and distribution of solutions in a connected enterprise (including third party suppliers, partners, and customers), the end user experience of these solutions is an important consideration that will only increase in importance
While there are various solutions for application performance monitoring (APM) on the market today, the need for integrated monitoring, analytics, and optimization tools will likely increase over time to help govern and manage critical solutions where performance characteristics matter
Developing a Culture Surrounding Security
Finally, in relation to managing an effective (physical and cyber) security posture, while a deliberate strategy for managing vulnerability and zero trust are the methods by which risk is managed and mitigated, equally there is a mindset that needs to be established and integrated into an organization for risk to be effectively managed
This dimension is meant to recognize the need to provide adequate training, review key delivery processes (along with associated roles and responsibilities), and evaluate tools and safeguards to create an environment conducive to managing security overall
Measuring Impact
Several ways to think about impact:
Increased Availability
Is the reliability of critical production solutions improving over time and within SLAs?
Lower Cybersecurity Exposure
Is a thoughtful plan for managing cyber security in place, being executed, monitored, and managed on a continuous basis?
Do disaster recovery and business continuity plans exist and are they being tested?
Improved Systems Performance
Are end user SLAs met for critical solutions on an ongoing basis?
Lower Unplanned Outages
Are unplanned outages or events declining over time?
Wrapping Up
Overall, the goal of this article was to share some concepts surrounding where I see the value of strategy for IT in enabling a business at an overall level. I didn’t delve into what the makeup of the underlying technology landscape is or should be (things I discuss in articles like The Intelligent Enterprise and Perspective on Impact Driven Analytics), because the point is to think about how to create momentum at an overall level in areas that matter… innovation, speed, value/cost, productivity, and performance/reliability.
Feedback is certainly welcome… I hope this was worth the time to read it.
When looking towards the Delivering at Speed dimension of Excellence by Design, it’s worthwhile to understand roles and responsibilities and, more importantly, the criticality of effective communication and collaboration in delivery. To that end, I wanted to provide a quick commentary on the value and risk of RACI as an enabler in the process.
Many who have worked with me know that I’m not a fan of the RACI tool. In this article, I’ll cover what I consider good and not so good about it. Hopefully the concepts will be helpful.
At the end of the day, what makes teams effective is a collective investment in success. That takes courage and a willingness to do whatever it takes to deliver, particularly if a project is complex or high risk. Where individuals and teams don’t lean into that discomfort, things can easily become imbalanced, inefficient, and ineffective… and the opportunity for excellence is lost. The ultimate reality is that technology delivery is messy and complex, it involves dealing with adversity and is not for the faint of heart, which is why courageous leadership is the first and most critical dimension to driving excellence in an organization.
A Quick Refresher
For those who may be unfamiliar, the RACI tool is used to help clarify roles and responsibilities across a set of constituents against a defined set of activities, deliverables, or whatever is relevant to the conversation.
The process is generally to have a facilitator populate a grid in two dimensions, with stakeholders or teams as a set of rows and the activities or deliverables across an entire project lifecycle (as an example) as the columns. Once the teams and work are clarified, the team then typically goes a column at a time, noting which teams have which responsibilities using the RACI notation to indicate who is:
R – Responsible (DOER – primarily responsible for performing the activity)
A – Accountable (LEADER – ultimately accountable for the execution)
C – Consulted (ADVISOR – asked to provide input, in a supporting role)
I – Informed (LISTENER – notified of the status or outcome, but not involved)
A conceptual example of a completed RACI chart could look something like this:
Generally, there should only be one “Accountable” party per activity, though there can be more than one individual or team “Responsible” for performing the work. In many cases, “R” and “A” go together, though there can be situations where someone is playing a general contractor-type role who is Accountable, but someone else is actually playing a subcontracting-type role who is Responsible for performing the work. In one of my previous employers, we occasionally collapsed the “R” and “A” categories into a single “Owner” (O) role, which indicated the individual or team who was both responsible and accountable and simplified the facilitation of the exercise.
What’s Good about RACI
In my experience, the value of a RACI discussion is in the conversation, not the tool.
The conversation is helpful in two primary respects:
Clarifying the scope and breadth of activities/ deliverables/ responsibilities that are associated with whatever the cross-functional team is trying to accomplish
Having an understanding of the anticipated interactions of that cross-functional team against those activities
On the latter point, the exercise can be particularly helpful for a newly formed team or on a new type of effort where the combination of activities is emerging and the interactions across the team against those activities isn’t clearly understood.
The discussion itself gives the team a chance to engage, interact, experience the various communication and leadership styles and, in the process, talk about the work they need to perform.
Where Things Go Awry
…So what’s the problem?
Well, the problem is sometimes in the mindset of the participants as they enter the discussion and how the tool is ultimately used in practice.
Things to watch for in a RACI discussion:
Asserting Control / Promoting Exclusion
There are times when participants use the tool and process as a way to establish their authority to make decisions (as the “Accountable” party) in a way that excludes others
In these cases, the RACI tool can become a hammer that enables dysfunction and empowers poor leadership
Showing a Lack of Accountability
There are times when the tone of discussion shifts towards an “us” and “them” conversation and the concept of “team” is subjugated to who is accountable if something goes wrong.
In this situation, the tool becomes a hammer to assign blame and undermine partnership
Encouraging a Lack of Collaboration
Finally, the stronger the contrast between “RA” and “C” comes across, there is risk of an underlying level of dysfunction that goes beyond activities and deliverables
While the tool and process are meant to help foster healthy discussion on primary accountability and roles, an extreme version of its use can feel like there is a lot of “throwing things over the wall”… and that is normally something you can hear in the discussion itself
Summing this up, while RACI can be a useful tool, it can also be a mechanism to stratify dysfunction in an organization, enable poor leadership, assign blame, and do more harm than good.
Breaking Down the Model
In thinking about the above, the question arises: “Ok, so what do you do about it?”
In a previous employer where we conducted a lot of client workshops, we would start with a predefined set of ground rules and allow the clients to add to the list as they saw fit. Depending on the group assembled, there were times when that flexibility actually would go astray and the rules became a long, laundry list of “what not to dos”.
If the discussion started to feel unhealthy, we would suggest that we reset the list back to two things:
Do what makes sense
Do the right thing
In practice, almost any situation that would arise in a workshop setting could be addressed with those two principles and they are simple and broad enough that they cover what you need to facilitate a session on about any topic.
Going back to RACI, when the discussions go astray, the same type of principles may be helpful to set the tone for collaboration as part of the effort.
Summing It Up
Stepping back from the tools and process, the critical point to remember is the importance of communication and collaboration in a cross-functional team.
In my experience, when people are effective collaborators and the underlying relationships are sound, there isn’t a need for RACI discussions. People work past boundaries, sometimes swap responsibilities where the capabilities of individuals are roughly equivalent, and the team is focused less on “who owns what” and doing what they need to do to meet the conditions of success. There is a mindset of mutual support and partnership… and the efficiency of the execution will be much higher by extension.
Most of the time, when I hear someone request or suggest a RACI discussion, I assume there is an underlying issue or source of dysfunction. It doesn’t mean the conversations can’t be useful in helping to surface and address those concerns and challenges, but it is important to understand they are not a cure all if the outcome is just a snapshot of something that wasn’t working effectively in the first place.
Hopefully the concepts were helpful. As always, feedback is welcome and appreciated.
As I began this journey and subsequently to assemble topics about which to write, I noticed that there were both an overwhelming set of ideas coming (a good problem to have) and a very unclear relationship in the concepts that were running quite rapidly through my mind (not a good thing).
Upon further reflection, it occurred to me that the ideas all centered around the various dimensions of leading a technology organization at different levels of specificity. To that end, I thought I should set the stage a bit, in the interest of making things more cohesive in what I may write from here.
On the Pursuit of Excellence
At an overall level, what better place to start than a simple premise: Excellence is a choice.
Shooting for excellence is a commitment that requires a lot on a practical level, starting with courageous leadership, because it is a perpetually moving target, requires adaptability, tenacity, and a willingness to accept change as a way of life. Excellence isn’t accidental, it is a matter of organizational will and the passion to pursue aspirations beyond what, at times, may feel “realistic” or “practical”. It requires a belief in what is possible and is defined along multiple dimensions, which we’ll explore briefly here, namely:
Relentless Innovation
Operating with Agility
Framework-Driven Design -and-
Delivering at Speed
Relentless Innovation
Starting with vision, some questions to consider in the context of an overall strategy:
Is it clear and understood across the organization, along with its intended outcome (e.g., what success looks like)?
Is it one that connects to individuals in the organization, their roles and ongoing contributions, or are those disconnected concepts (i.e., is it something that individuals take to heart)?
Can it evolve as circumstances change while maintaining a degree of fundamental integrity (e.g., will it stand the test of time or need to be continually redefined)?
Is it actionable? Can tangible steps be taken to drive progress towards its ultimate goals?
Is it “deliberate”/intended/proactive or was it defined in a reactive context (e.g., in response to a competitor’s actions)?
Are day-to-day decisions made with the strategy in mind?
Overall, the point is to have a thoughtful, proactive strategy, that is actionable, connected to ongoing decisions, and embraced by the broader organization.
Where this becomes more interesting is in how we think of strategy in relation to change, which is where the next concept comes into play. Relentless innovation is the notion that anything we are doing today may be irrelevant tomorrow, and therefore we should continuously improve and reinvent our capabilities to ones that create the most long-term value. This is much easier said than done, because it requires a lot of organizational humility and a willingness to tear down existing structures and rebuild new ones in their place. That forces a degree of risk tolerance, because there is safety in the established practices and solutions of today, especially if they’ve created value. On the other hand, success can be very detrimental insofar as complacency can become part of the organizational mindset and change slows down to an environment that is essentially an iteration of the present.
Operating with Agility
Looking at IT Operations, a number of questions come to mind that may be the subject of future articles:
Is there a mindset of being cost-efficient (driving the highest value/cost ratio)?
Is there a culture of continuous improvement and innovation in place?
Is there a strategy for incorporating and optimizing the relationship of project and product teams (to the extent that a full product orientation isn’t feasible)?
Is there a sourcing strategy in place that is deliberate, governed, optimized (whether insourced, outsourced, or some combination thereof)?
Are portfolio management processes effective and aligned to business strategy?
Is there a highly transparent, but extremely lightweight operating infrastructure in place to facilitate engagement and value creation?
To what degree is talent rotation and development part of the culture? Are people stuck in the same organization or silo for long periods of time, or are high potential leaders moved between teams to facilitate a higher degree of knowledge sharing, development, and improvement?
Having worked in IT Ops, the largest issue I’ve seen in a number of companies is an overly significant focus on process and infrastructure by comparison with transparency and enablement. This is a tricky balance to strike, but arguably, I’d much rather have a less “mature” operating environment (IT for IT) that produces directionally correct information and drives engagement than a heavy, cumbersome process that becomes a distraction from producing business outcomes. A simple litmus test on the latter type of environment being in place is whether, in discussion, teams talk about the process and tools versus the outcomes, decisions, and impact.
Framework-Driven Design
Shifting focus to technology, I believe the opportunity is to think differently about the overall solution architecture of future ecosystems. Much has been written and discussed relative to modern or cloud native applications, data-centric design, DevSecOps, domain-driven design, and so on.
What fundamentally bothers me about solution design approaches is that, when focusing on one dimension (e.g., data centricity), other dimensions of the more holistic view of modern application design is left out, and then it becomes a challenge to delivery teams to integrate one or more of these concepts in practice without a way to synthesize them into one cohesive approach. This is where framework-centric design can be an interesting approach to consider.
In my definition, framework-centric design is focused on architecting a connected ecosystem and operating environment intended to promote resiliency, interoperability, and application-agnostic integration such that individual solution components can be upgraded or replaced over time at a rapid pace without disrupting the capability of the ecosystem as a whole.
I will explore this topic further in a future article, but the base premise is to design an overall solution that performs complex tasks given multiple components integrated in standardized ways, leveraging modern, cloud native technologies, with integrated data that feeds embedded analytics capabilities as part of the operation of the ecosystem.
The framework itself, therefore, becomes a platform and the individual components are treated as replaceable parts that enable a best-of-breed mentality as new capabilities emerge that become advantageous to integrate with the framework over time.
Delivering at Speed
From a delivery standpoint, as tempting as it is to write about iterative development (or Agile in particular) as a cure all, the reality is that more organizations suffer from a lack of discipline than a lack of methodology.
The unfortunate myth that needs to be explored and unwound is that executing with discipline means value will be delayed when, in fact, the exact opposite is true. It is a generalization, but the faster a build team moves (to the extent that process or rigor is abandoned), the immediate impact is usually a level of technical debt that will create drag, either in the initial or subsequent delivery efforts.
Quality doesn’t happen by accident. It is something that needs to be planned and built into a work product from the kickoff of a delivery effort, regardless of the methodology or operating model employed.
I will likely write more on this topic given the number of opportunities that exist, but it’s sufficient to say that you can’t achieve excellence when you don’t execute as flawlessly as possible… and discipline is needed to accomplish that.
Wrapping Up
Overall, the goal was to provide a quick summary of the various dimensions that I believe are important to consider in leading an organization. No doubt, there may be questions or omissions (intentional or unintended) as this was a first blush at how I think about it.
What about people and culture? Well… that’s part of operating effectively… as an example.
Hopefully this was a good starting point and provided some food for thought. Feedback, questions, and reactions are always welcome.
Having spent a number of years in project and program management (as well as IT Operations), one of my favorite subjects is transparency.
For the purposes of this article, I’m focusing on “traditional” project and program delivery (irrespective of methodology), not product-based operating environments, though many concepts would apply to both.
Context
An inevitable truth of managing programs (especially large ones) is: Things will change. I think of these changes as “points of inflection”, namely times when some level of pivot is needed either within a single project or across multiple work efforts in a coordinated fashion to get things realigned, stable, and back to operating in a healthy way… typically with a revised delivery schedule.
What makes a programs successful at these points of inflection is three things:
Having good transparency – Knowing where you are at the present time in relation to your ultimate goal, so that you can evaluate the remedy (or remedies) needed to adjust course
Making the right “turn” – Adjusting the scope, approach, plan, work efforts, risk profile, etc. so that you address the issues identified in a way that increases operating stability, plan integrity, and quality of the ultimate solution and/or deliverables
Turning quickly – Making the appropriate adjustments as quickly as possible after the issues are identified to rectify the situation. This can’t be emphasized enough, given a significant amount of disruption, cost, and other negative impacts tend to come as a result of organizational inaction related to materialized risks. As has been said in consulting many times, “bad news doesn’t get better with time”… and the sooner critical issues or risks are addressed, the better.
So looking at the above, the critical dependency is transparency because, without an understanding of where you are, there’s no way to evaluate whether the changes you make will ultimately help or hurt your delivery effort.
The Challenge
This is where the problem starts: Wanting transparency is different than needing lots of metrics, and the latter is where a significant percentage of projects and IT operations efforts waste time, energy, and cost that ultimately undermine delivery and/or operational excellence. The goal of transparency is to enable governance and risk management. Reporting in of itself is administrative in nature and adds marginal value (unless it is of a regulatory nature, of course).
What tends to happen is that, rather than approach transparency in a top-down fashion, with a focus on enabling engagement and action, leaders take a bottom-up approach, assuming that the more data they have, the more they can ultimately understand and control. This is a critical mistake that happens on projects all the time… reporting so much information that the fundamentals are lost amidst the noise.
One root cause of the above situation is that there are a good number of leaders who see status as organizational comfort food, as if having excessive documentation will provide “proof of ongoing work” for customers or to create a level of air cover in the event that things ultimately go wrong. On the latter point, having led high risk and complexity delivery efforts, particularly in consulting… the minute anything goes wrong, if you’re a project or program manager, you can pretty much assume you’ll be taking the blame regardless of whether the issue or risk has been documented on a status report… and that’s the job, and it’s ok… because no one said these jobs are easy.
This is either what makes project and program management work difficult or very rewarding, depending on how you choose to see it. Your best work tends to be happening when nothing goes wrong, in which case people may well ask what you do all day. In the converse scenario, when things are not going well, you may find yourself in the situation where people ask what you’ve been doing, and you won’t want the answer to involve having spent hours writing or updating reports. Our goal in delivery is producing value (i.e., business outcomes), not status.
Some Examples
Three different situations (each from a different organization) come to mind where “reporting” got in the way of actual transparency:
First, I was asked to cover a delivery project from an oversight standpoint while the director responsible for the work was out on vacation. The project manager, a trained PMP, had a well-organized and documented project, with an abundance of metrics. A source of particular pride was the earned value (EVM) calculation, which indicated that the team was 90+% complete on the project. Upon reviewing the artifacts, we realized that the effort related to producing deliverables was not included in the plan, and therefore, the EVM calculation didn’t include the full project scope and it was actually massively BEHIND where it was supposed to be (something in the 70+% range). In practice, the project manager had spent so much time managing metrics that they forgot to make sure the scope of the project was represented in the plan, effectively compromising what they had been reporting for weeks. The good news is that, having recognized the gap, we made the necessary corrections, pulled in some additional help, and got things back on track. Overall, however, the lesson learned was that metrics are only as good as the understanding they provide for the underlying effort itself.
In another situation, I inherited a client engagement where one of the divisional CIOs had the team producing a forty-page status report covering all delivery efforts in the portfolio on a weekly basis. It was well understood that the client wasn’t reading the report, but rather requested it to force the team to evaluate their project health on a continuing basis. The implication being that writing status helps project managers focus on their project, which is actually the opposite of what happens in practice. The more time project managers spend in administrivia, the less time they tend to spend on activities that add value, such as communicating with customers, engaging with their delivery team(s), identifying and managing risks, reviewing the plan for gaps and issues, and so on. It took some convincing, but this was an activity that we ultimately eliminated that not only reduced administrative effort, but also allowed us to cut a full-time position that had been staffed solely to report on that portfolio of work.
Finally, I was asked to take a short-term assignment to help a divisional CIO organize his PMO, particularly the reporting being done across a relatively large and diverse portfolio of work. Similar to previous situation, he showed me a stack of printed status roughly four inches thick that he was receiving weekly across his delivery leaders, ultimately which we replaced with a four-page dashboard organized across financial health, strategic programs, ongoing discretionary projects, and production support. Rather than produce information on a project-by-project basis, we requested standard information from each delivery team at a summarized level that helped highlight areas where intervention was actually required and eliminated a significant amount of the administration related to written status. In practice, the minute the yellow or red light goes on, someone likely needs to have a conversation anyway, so writing a lot of documentation doesn’t tend to help anyone. The end result was less paperwork and a lot of relieved project managers.
Focusing on What Matters
Coming back to transparency, some fundamental concepts that I believe are important:
If you can’t understand the overall situation, the details don’t matter
Qualitative information can be just as good as quantitative data, given the quality of detailed project metrics is often suspect and imperfect anyway
Any metric that is reported should be actionable, otherwise it is likely noise and a distraction
Once things get into the ‘yellow’ or ‘red’ there is a discussion coming, so there is little value in writing a lot of language in a status report that ultimately will be discussed anyway
It’s completely fine (and often helpful) to track detailed items within a project, but report on summary characteristics from a governance standpoint
In line with the above, these are the primary seven ‘indicators’ (all in R/Y/G) that I consider important to track across projects in a program or portfolio of work, along with their conceptual definitions:
Overall Health – Indication of the Delivery Quality overall, given the following six dimensions
Scope – Requirements are clear and understood
Budget – Financially in line with expectations
Staffing – Team is skilled and staffed to deliver the work
Schedule – Work is being executed in line with expectations
Quality – Work product is in line with or exceeding expectations
Risk – Concerns areas are understood and being mitigated effectively
Where the indicators are defined as:
Green – On Track
Yellow – Needs Attention (50%+ chance of an issue)
Red – Requires Action (Issue exists, discussion or intervention needed)
This isn’t to say that things like next major milestone, %complete, %test cases planned/ executed/ passed, etc. are not useful to report, but they generally fall at a lower level of criticality once the above indicators are addressed. My general preference is to have details only where there is additional insight needed (for example, Schedule is “yellow”, in which case progress metrics specific to the current activities may provide useful information).
Conclusion
While a lot has been written about these topics, the goal of this article was simply to share a few concepts about transparency, the role it plays in effective governance and risk management, and the often questionable value of reporting in itself.
There are many best practices related to transparency and reporting, but the main takeaways:
If you don’t have effective transparency, you are highly exposed to the experience of the people leading an effort, and your ability to govern and manage risk and change will be limited
If you don’t know how you will use information (down to the individual metrics) being reported on a delivery effort (or operational dashboard), don’t collect them. It’s likely a waste of time
The more you measure and report, the less you’ll likely notice the critical things that matter
The more time you force delivery leaders to spend on reporting, the less likely they are to be focused on their actual delivery responsibilities
The goal of transparency is to drive engagement and action (and value), not administration
I hope the information was useful… as always, feedback and comments welcome.
Organized Chaos 