What It Is: Architecture provides the structure, standards, and framework for how technology strategy should be manifested and governed, including its alignment to business strategy, capabilities, and priorities. It should ideally be aligned at every level, from the enterprise to individual delivery projects
Why It Matters: Technology is a significant enabler and competitive differentiator in most organizations. Architecture provides a mental model and structure to ensure that technology delivery is aligned to overall strategies that create value. Having a lack of architecture discipline is like building a house without a blueprint… it will cost more to build, not be structurally sound, and expensive to maintain
Key Dimensions
Operating Model – How you organize around and enable the capability
Enable Innovation – How you allow for rapid experimentation and introduction of capabilities
Accelerating Outcomes – How you promote speed-to-market through structured delivery
Optimizing Value/Cost – How you manage complexity, minimize waste, and modernize
Inspiring Practitioners – How you identify skills, motivate, enable, and retain a diverse workforce
Performing in Production – How you promote ongoing reliability, performance, and security
Operating Model
Design the model to provide both enterprise oversight and integrated support with delivery
Ensure there is two-way collaboration, so delivery informs strategy and standards and vice versa
Foster a “healthy” tension between doing things “rapidly” and doing things “right”
Innovate
Identify and thoughtfully evaluate emerging technologies that can provide new capabilities that promote competitive advantage
Engage in experimentation to ensure new capabilities can be productionized and scaled
Accelerate
Develop standards, promote reuse, avoid silos, and reduce complexity to enable rapid delivery
Ensure governance processes promote engagement while not gating or limiting delivery efficacy
Optimize
Identify approaches to enable simplification and modernization to promote cost efficiency
Support benchmarking where appropriate to ensure cost and quality of service is competitive
Inspire
Inform talent strategy ensuring the right skills to support ongoing innovation and modernization
Provide growth paths to enable fair and thoughtful movement across roles in the organization
Perform
Integrate cyber security throughout delivery processes and ensure integrated monitoring for reliability and performance in production, across hosted and cloud-based environments
What It Is: Transformation is the process of reshaping a way of working in the interest of achieving a significant and measurable impact in business results
Why It Matters: When faced with changing market conditions, competitive threats, technology advancements, etc., it is critical for organizations to reinvent themselves. This typically involves changes to process, organization, and technology and doing so in a thoughtful manner is critically important
Critical Dimensions
A Compelling Vision – The desired future state should be clear enough to create emotional investment and the commitment required to overcome the inertia that naturally resists change
Clear Business Outcomes –There should be tangible goals established (along with key financial and operating metrics) to inform prioritization and guide critical decisions throughout execution
Courageous, Committed Leadership – Transformation efforts are complex and require resilience, decisiveness, persistence, and determination to work through adversity along the way
A Supportive Culture – The environment and culture within an organization will have an impact on the degree of change that is possible to achieve overall and the rate at which it can be done
A Thoughtful Approach – It is tempting in larger programs to initiate too much work, too quickly, causing significant disruption and suboptimal results (or even programs to fail overall). Given that a lot of learnings tend to occur in terms of processes, standards, and governance in initial delivery efforts, it is often the case that incubating large programs with a smaller, expert team and extending and scaling afterward is a more effective way to build momentum and reduce risk
Results-Orientation – Another problem in large transformation efforts is taking on too much, too early in terms of scope that can substantially defer any benefit realization, by comparison with a consistent, incremental delivery environment that is both predictable and repeatable over time
Adaptability and Agility – Transformation efforts are messy, involve complexity, and typically run into a host of issues throughout execution. It is critical to maintain a high level of transparency into ongoing work, have an active and engaged governance process, and to make decisions efficiently and thoughtfully as they are needed during execution. Roadmaps produced at the start of large programs rarely remain unchanged for very long, and it’s important that every inflection point is taken as an opportunity to learn, improve, and respond versus react
Patience and Discipline – Sustainable change takes time. While it’s possible to force a level of change in the short-term and achieve incremental benefits, systemic and holistic changes to the way an organization operates take time. Managing the process in a disciplined way both helps achieve overall results faster as well as mitigate risk
What It Is: Technology organizations are sometimes led through a combination of CIO and CTO roles, working towards a shared vision, each having a clear focus in the interest of promoting IT excellence
Why It Matters: Technology continues to advance at a rate, particularly with the introduction of AI, that exceeds many organizations ability to respond effectively. Having the right leadership in place to develop strategy, consider longer-term implications of decisions made in ongoing delivery, and govern execution can be key to avoiding technical debt, while promoting delivery excellence over time
Five Types of CTOs
Technology Strategist – This is the most common modern orientation, focused on enablement, simplification, optimization, and capability delivery
Mistitled CIO – This occurs when the CTO actually has all the typical CIO responsibilities and they are fulfilling that role in every way, leading IT, setting direction, etc. without the CIO title
Futurist – This occurs where the CTO plays a more directional, but not action-oriented role, focused on white/position papers, and ideation
Infrastructure Lead – This is the historical role of a CTO, focused more on hosting, networking, reliability, performance, and operations with the CIO covering applications and data
Lead Designer / Senior Developer – This generally the case in start-up/smaller scale product environments, where the CTO leads the product design and helps code the solution
High-Level Differences
CIO focuses on the “what”, obtains business alignment and identifies capabilities, along with desired technology capabilities, focuses on the customer and providing vision and direction
CTO focuses on the “how”, understands desired business capabilities, determines how to provide technical capabilities and deliver on commitments, partnering with the broader team
Both roles participate in governance, CIO provides and aligns business priorities, CTO provides and aligns technical priorities in support of the CIO
When It Makes Sense to Have a CTO in Addition to a CIO
There is sufficient time required working with business partners that additional support is needed to define and evolve the technology strategy and work actively with delivery leaders
There is considerable complexity in the technology footprint, a high degree of transformation, or substantial integration required across ongoing delivery where having the CIO focused in the weeds of execution could result in underserving the business team and executive leadership
There is a need to move multiple levers (cloud platform migration, modernization, core platform implementation, AI integration, etc.) that a level of dedicated focus and oversight is needed to work through the risks and impacts of various strategies to define the best technology solution
When the scale of the organization in people, internally, externally, including customers, suppliers, and partners exceeds one person’s ability to manage relationships effectively
Where the CIO has a business background and it is helpful to supplement their capabilities with a more technology-focused leader overall
Benefits of Having a “Healthy Tension”
There can be a natural tension created when there is a separation of roles, because a CIO generally is incented to deliver new business capabilities at speed and the CTO should be incented to do things “right” to minimize long-term cost of ownership, managing technical debt, promoting standards and governance, and improving predictability of the delivery environment
Business delivery will generally be top priority, but having a CTO can mitigate the impact of tradeoffs made during delivery, particularly in large programs, where consequences are higher
The Downside:
There is incremental cost associated with adding leadership roles, there can be confusion across the broader IT leadership if roles and responsibilities aren’t clear, and a strong CIO/CTO partnership is important to making the role effective in practice
That being said, the value to any organization with a relatively large technology footprint would likely far exceed the cost of having a CTO focused on managing complexity and optimizing cost
The Difference Between CTO and Chief Architect
The CTO is the keeper of the overall technology strategy, apps, data, infrastructure, security integration with all of the above (working with the CISO), inclusive of the delivery environment
A “Chief Architect” tends to be more narrowly focused on application and data architecture strategy, but with awareness on how to incorporate cloud and platform strategy as well
A Chief Architect could be a role reporting to the CTO, depending on the scale of the organization, focused more on defining, modernizing, or rationalizing the enterprise ecosystem of connected components, acting more like a designer than a strategist, where a CTO without this role would generally do both at the enterprise level
What It Is: Governance (in a delivery context) is the process for reviewing a portfolio of ongoing work in the interest of enabling risk management, containing avoidable cost, and increasing on-time delivery. PMOs (Project/Program Management Offices) are the mechanism through which governance is typically implemented in many organizations.Why It Matters: As the volume, risk, and complexity in a portfolio increase, there is typically a disproportionate increase in issues that come about, leading to cost overruns, missed expectations on scope or schedule (or both), and reduced productivity. PMOs, meant to be a mechanism to mitigate these issues, are often set up or executed poorly, becoming largely administrative and not value-generating capabilities, which furthers or amplifies any underlying execution issues. In an environment where organizations want to transform while managing a high level of value/cost efficiency, a disciplined and effective governance environment is critical to promoting IT excellence
Key Concepts
There are countless ways to set up an operating model in relation to PMOs and governance, but the culture and intent have to be right, or the rest of what follows will be more difficult
There is a significant difference between a “governing” and an “enabling” PMO in how people perceive the capability itself. While PMOs are meant to accomplish both ends, the priority is enabling successful, on-time, quality delivery, not establishing a “police state”
Where the focus of a PMO becomes “governance” that doesn’t drive engagement and risk management it can easily become an administrative entity that drives cost and doesn’t create value and ultimately undermines the credibility of the work as a whole
The structure of the overall operating model should align to the portfolio of work, scale of the organization, and alignment of customers to ongoing projects and programs
It can easily be the case that the execution of the governance model can adapt and change year-over-year but, if designed properly, the structure and infrastructure should be leverageable, regardless of those adjustments
The remainder of this article with introduce a concept for how to think about portfolio composition and then various dimensions to consider in creating an operating model for governance
Framing the Portfolio
In chalking out an approach to this article, I had to consider how to frame the problem in a way that could account for the different ways that IT portfolios are constructed. Certainly, the makeup of work in a small- to medium-size organization is vastly different than a global, diversified organization. It would also be different when there are a large number of “enterprise” projects versus a set of highly siloed, customer-specific efforts. To that end, I’m going to introduce a way of thinking about the types of projects that typically make up an IT project portfolio, then an example governance model, the dimensions of which will be discussed in the next section.
The above graphic provides a conceptual way to organize delivery efforts, using the rocks, pebbles, and sand in a jar metaphor that is relatively well known, and also happens to apply to organizing technology delivery.
To establish effective governance, you generally first want to examine and classify delivery projects/programs based on scale (in effort and budget), risk, timeframe, and so on. This is important so as not to apply a “one size fits all” approach to how you track and govern projects that encumbers lower complexity efforts with the same level of reporting that you would typically have on larger-scale, transformation programs.
In the model above, I went with a simple structure of four project types:
Sand – very low risk projects that can be something like a rate change in Insurance or data change in analytics
Pebbles – medium complexity work like incremental enhancements or an Agile sprint
Rocks – something material, like a package implementation, new technology introduction, product upgrade, or new business or technology capability delivery
Boulders – high complexity, multi-year transformation programs, like an ERP implementation where there are multiple material, related projects under one larger delivery umbrella
The characteristics of these projects and metrics you would ideally like to gather, along with the level of “review” needed on an ongoing basis would vary greatly, which will be explored in the next section.
In a real-world scenario, it is possible that you might want to identify additional sub-categories to the degree it helps inform architecture or delivery governance processes (e.g., security, compliance, modernization, AI-related projects), most of which would likely be specialized kinds of “Pebbles” and “Rocks” in the above model. It is very easy to become bloated quickly in terms of a governance process, so I am generally a proponent of tuning the model to the work and asking only questions relevant to the type of project being discussed.
What about Agile/SAFe and Product team-oriented environments? In my experience, it is beneficial to segment delivery efforts because, even in product-based environments, there are normally a mix of projects that are more monolithic in nature (i.e., that would align to “Rocks” and “Boulders”). Sprints within iterative projects (for a given product team) would likely align to “Pebbles” in the above model and the question would be how to align the outcome of retrospectives into the overall governance model, which will be addressed below.
So, coming back to the diagram, for the purposes of illustration, the assumption we will use is that the portfolio we’re supporting is a mix of all four project types (the “Portfolio Makeup” at right above), so that we can discuss how the governance can be layered and integrated across the different categories expressed in the model itself.
For the remainder of this article, we will assume the work in the delivery portfolio is divided equally between two business customer groups (A and B), with delivery teams supporting each as represented in the below diagram.
If your individual scenario involved a common customer, the model below could be simplified to one branch of the two represented. If there were multiple groups, it could be scaled horizontally (adding branches for each additional organization) or if there were multiple groups across various geographies, it could be scaled by replicating and sizing the entire structure by entity (e.g., work organized by country in a global organization or by operating company in a conglomerate with multiple OpCos) and then adding one additional later for enterprise or global governance.
Key Dimensions
There are many dimensions to consider in establishing an enterprise delivery governance model. The following breakdown is not intended to be exhaustive, but rather to highlight some key concepts that I believe are important to consider when designing the operating model for an IT organization.
General Design Principles
The goal is to enable decisions as close to the delivery as possible to improve efficiency and minimize the amount of “intervention” needed, unless it is a matter of securing additional resources (labor, funding, etc.) or addressing change control issues
The model should leverage a common operating infrastructure to the extent possible, to enable transparency and benchmarking across projects and portfolios. The more consistency and the more “plug and play” the infrastructure for monitoring and governance is, the faster (and more cost-effectively) projects and programs can typically be kicked off and accelerated into execution without having to define these processes independently
Metrics should move from summarized to more detailed as you move from oversight to execution, but the ability to “’drill down” should ideally be supported, so there is traceability
Business and IT PMOs versus “One” consolidated model
There is a proverbial question as to whether it is better to have “one”, integrated PMO construct, or an IT PMO separate from one that manages business dependencies (whether centralized or distributed)
From my perspective, this is a matter of scale and complexity. For smaller organizations, it may be efficient and practical to run everything through the same process, but as work scales, my inclination would be to separate concerns to keep the process from becoming too cumbersome and leverage the issue and risk management infrastructure to track and manage items relevant to the technology aspects of delivery. There should be linkage and coordination to the extent that parallel organizations exist, but I would generally operate them independently so they can focus on their scope of concerns and be as effective as possible
Portfolio Management Integration
I’m assuming that portfolio management processes would operate “upstream” of the governance process and inform which projects are being slotted, address overall resource management and utilization, and release strategy
To the extent that change control in the course of delivery affects a planned release, a reverse dependency exists from the governance process back to the portfolio management process to see if schedule changes necessitate any bumping or reprioritization because of resource contention or deployment issues
IT Operations Integration
The infrastructure used to track and monitor delivery should come via the IT Operations capability, theoretically connecting at the IT Scorecard for executive level delivery metrics to portfolio and project metrics tracked at the execution level
IT Operations should own (or minimally help establish) the standards for reporting across the entire operating model
Participation
IT Operations should facilitate centralized governance processes as represented in the “Unit-level” and “Enterprise” governance processes in the diagram above. Program-level governance for “Boulders” would likely be best run by the delivery leadership accountable for those efforts
Participation should include whoever is needed to engage and resolve 80% (anecdotally) of the issues and risks that could be raised, but be limited to only people who need to be there
Governance processes should never be a “visibility” or “me too” exercise, they are a risk management and issue resolution activity, meant to drive engagement and support for delivery. Notes and decisions can and should be distributed to a broader audience as appropriate so additional stakeholders are informed
In the context of a RACI model (Responsible, Accountable, Consulted, Informed), meetings should include only “R” and “A” parties, who can reach out to extended stakeholders as needed (“C”), but very rarely anyone who would be defined as an “I” only
It is very easy to either overload a meeting to the point it becomes ineffective or not include the right participants to the extent it doesn’t accomplish anything, so this is a critical consideration for making a governance model effective
Session Scope and Scheduling
I’ve already addressed participation, but scheduling should consider the pace and criticality of interventions. Said differently, a frequent, recurring process may make sense when there is a significant volume of work, but something more episodic if there are a limited number of major milestones over the course of time where it makes sense to review progress and check in at specific points in time
Where an ongoing process is intended, “Boulders” and “Rocks” should have a standing spot on the agenda given the criticality and risk profiles of those efforts likely would be high. For “Pebbles”, some form of rotational involvement might make sense, such as including two of the four projects in the example above in every other meeting, or prioritizing any projects that are showing a Yellow or Red overall project health. In the case of the “Sand”, those projects likely are so low risk that, beyond reporting some very basic operating metrics, they should only be included in a governance process when there is an issue that requires intervention or a schedule change that involves potential downstream impacts
Governance Processes
I mentioned this in concert with the example portfolio structure above, but it is important to consider tailoring the governance approach to the type of work so as not to create a cumbersome or bureaucratic environment for delivery teams where they focus on reporting and not managing and delivering their work
Compliance and security projects, as an example, are different than AI, modernization, or other types of efforts and should be reviewed with that in mind. To the extent a team is asked to provide a set of information as input to a governance process that doesn’t align cleanly to what they are doing, it becomes a distraction that creates no value. That being said, there should be some core indicators and metrics that are collected regardless of the project type and reviewed consistently (as will be discussed in the next dimension)
The process should be designed and managed by IT Operations so it can be leveraged across an organization. While individual nuances can be applied that are specific to a particular delivery organization, it is important to have consistency to enable enterprise-level benchmarking and avoid the potential biases that can come from teams defining their own standards that could limit transparency and hinder effective risk management
Delivery Health and Metrics
I’ve written separately on Health and Transparency, but minimally every project should maintain a Red, Yellow, Green on Overall Health, and a second-level indicator on Schedule, Scope, Cost, Quality, and Resourcing that a project/program manager could supply very easily on an ongoing basis. That data should be collected at a defined interval to enable monitoring and inform governance processes on an ongoing basis, regardless of other quantitative metrics gather
Metrics on financials, resourcing, quality, issues, risks, and schedule can vary, but to the extent they can be drawn automatically from defined system(s) of record (e.g., MS Project, financial systems, a time tracking system with defined project coding, defect or incident management tools), the level of manual intervention required to enable governance should ideally be limited to data teams should be utilizing on an ongoing basis
In the event that there are multiple systems in place to track ongoing work, the IT Operations team should work with the delivery stakeholders to identify any enterprise-levels standards required to normalize them for reporting and governance purposes. To give a specific example, I encountered a situation once where there were five different defect management systems in place across a highly diversified IT organization. In that case, the team developed a standard definition of how defects would be tracked and reported and the individual systems of record were mapped to that definition so that reporting was consistent across the organization
Change Control
Change is a critical area to monitor in any governance process because of the potential impact it has to resource consumption (labor, financials), customer delivery commitments, and schedule conflicts with other initiatives
Ideally a governance process should have the right information available to understand the implications of change as and when it is being reviewed as well as the right stakeholders present to make decisions with that information having been provided
To the extent that schedule, financial, or resource considerations change, information would need to be sent back to the IT Portfolio Management process to remedy any potential issues or disruptions that have been caused through decisions made. This is consistently missed in my experience in large delivery portfolios
Issue and Risk Management
Leveraging a common issue and risk management infrastructure both promotes a consistent way to track and report on these things across delivery efforts, but also creates a repository of “learnings” that could be reviewed and harvested in the interest of evaluating the efficacy of different approaches taken for similar issues/risks and promoting delivery health over time
Dependency/Integrated Plan Management
There are two dimensions to consider when it comes to dependencies. First is whether they exist within a project/program or are a dependency from that effort to others in the portfolio or downstream of it. Second is whether the dependency is during the course of effort or connected to the delivery/deployment of the project
In my experience, teams are very good at covering project- or program-driven dependencies, but there can be major gaps in looking across delivery efforts to account for risks caused when things change. To that end, some level of dependency-related matrix should exist to identify and track dependencies across delivery efforts separate from a release calendar that focuses solely on deployment and “T-minus” milestones as projects near deployment
Once these dependencies are being tracked, changes that surface through the governance process can be escalated back to the IT Portfolio Management process and other delivery teams to understand and coordinate any adjustments required
This can include situations where there are sequential dependencies, as an example, where a schedule overrun requires additional resource commitment from a critical resource needed to kick off or participate in another delivery effort. Without a means to identify these dependencies, the downstream effort may be delayed or not have time to explore alternate resourcing options without having a ripple effect to that downstream delivery. This is part of the argument for leveraging named resource planning (versus exclusively FTE-/role-based) for critical resources when slotting during the portfolio management process
Partner/Vendor Management
The IT Operations function should ideally help ensure that partners leverage internal reporting mechanisms or minimally conform to reporting standards and plug into existing governance processes where appropriate to do so
In the case of “Rocks” and “Boulders” that are largely partner-driven they likely will have a standalone governance process that leverages whatever process the partner has in place, but the goal should be to integrate and leverage whatever enterprise tools and standards are in place so that work can be benchmarked across delivery partners and also to compare the service delivery to internally-led efforts as well
It is very tempting to treat sourced work differently than projects delivered internal to IT, but who delivers a project should be secondary to whether the project is delivered on time, with quality and meets its objectives. The standards of excellence should apply regardless of who does the work
Learnings and Best Practices
Part of the potential benefit for having a shared infrastructure for executing governance discussions by comparison with distributing the work is that it enables you to see patterns in delivery, consistent bottlenecks, risks, and delays, and to leverage those learnings over time to improve delivery quality and predictability
Part of the governance process itself can also include having teams provide a post-mortem on their delivery efforts upon completion (successful or otherwise) so that other teams that participate in the governance process and the broader governance team can leverage those insights as appropriate
Change Management
While change management isn’t an explicit focus of a PMO/governance model, the dependency management surrounding deployment and learnings coming from various deployments should be coordinated with larger change management efforts and inform them on an ongoing basis in the interest of promoting more effective integration of new capabilities
Some Notes on Product Teams/Agile/SAFe Integration
It is tempting to treat product teams as isolated, independent, and discrete pieces of delivery. The issue with moving fully to that concept is that it becomes easy to lose transparency and benchmarking across delivery efforts that surface opportunities to more effectively manage risks and issues outside a given product/delivery team
To that end, part of the design process for the overall governance model should look at how to leverage and/or integrate the tooling for Agile projects with other enterprise project tracking tools as needed, along with integrating learnings from retrospectives with overall delivery improvement processes
Wrapping Up
Overall, there are many considerations that go into establishing an operating model for PMOs and delivery governance at end enterprise level. The most important takeaway is to be deliberate and intentional about what you put in place, keep it light, do everything you can to leverage data that is already available, and keep the balance between the project and the portfolio in mind at all times.The more project-centric you become, the more likely you will end up siloed and inefficient overall, and that will translate into missed dates, increased costs, and wasted utilization.
What It Is: IT Operations provides “IT for IT”, the infrastructure to track, monitor, and manage operating performance across various dimensions, depending on the scale and complexity of the organization
Why It Matters: The more an IT organization scales in headcount and complexity, the more important it becomes to have a way to benchmark performance and enable operational excellence
Key Concepts
IT Ops is a support organization meant to promote effectiveness, not create bureaucracy
Ops should be centralized regardless of the IT operating model (functional, product-based, etc.)
For large-scale organizations, a federated IT Ops model is preferable for overall org effectiveness
Key Dimensions
Transparency
Without visibility, it is nearly impossible to promote excellence and operational improvement
Focus should be on critical, minimum metrics that enable governance and benchmarking
Metrics can span from a leadership IT scorecard to portfolio and delivery metrics
Governance, Compliance, and Risk Management
IT Ops doesn’t need to provide PMO services, but it should ensure they exist and are effective
Compliance capabilities can be everything from regulatory and SOX to cyber security and audit
Portfolio Management
IT Ops may not provide the services, but should ensure that transparency and governance exist
Capabilities can span demand generation and prioritization to monitoring and value realization
Workforce and Sourcing Strategy
IT Ops should monitor internal/external performance, utilization, and workforce composition
Financial Management
IT Ops should help benchmark value/cost across IT at a service level and identify improvements
Continuous Improvement
IT Ops should identify and track operational excellence opportunities on an ongoing basis
Part of ongoing improvement should be reviewing and ensuring efficacy of IT services overall
What It Is: IT Portfolio Management is the process whereby technology investments are prioritized, managed, and governed (from demand management through delivery) on an ongoing basis, in the interest of enabling business strategy, maximizing return, minimizing risk, and providing security and compliance.
Why It Matters: Organizations don’t have unlimited capacity in terms of people, funding, ability to adopt new solutions, etc. and ensuring investments is essential to maximizing value in relation to spend
Overall Concepts
Portfolio management is about leadership and business partnership first, and process second
Portfolio reviews should produce schedule changes, delivery engagement, or risk management
Understanding total cost of ownership and effective resource management are critical input
Performing named resource planning versus role-based is important for critical roles
Transparency and Governance
Provide visibility into demand, scope, value, complexity, critical resource needs
Monitor ongoing delivery to proactively address risk and maintain and adjust release calendar
Evaluate and report on value realization, adjust metrics on new demand to improve efficacy
Portfolio Allocation
Typically includes: Innovation, Business Projects, Modernization, Security, Compliance, Operate
Prioritization model balance local versus global efforts, short- and long-term value
Release Management
Have a structured release approach with deployment windows to reduce risk and ease adoption
Frontload the first half of the year to avoid excess resource availability issues near the holidays
Separate major and minor releases, maintenance, and experiments into defined release slots
Change Management
Manage a global view of deployments to avoid schedule conflicts and manage end user change
Maintain an end-user view of technology and consider integration to avoid being project-centric
Tools
Portfolio management tools should enable and support the process, never become the focus
Gather only critical data that is actionable, or it is administrative overhead and likely wasteful
What It Is: An overall IT Strategy sets direction for an organization, providing a framework for the services IT provides, along with key dimensions and objectives, with flexibility to evolve over time
Why It Matters: With the ever-increasing demand for innovation in a competitive, but cost-conscious environment, a thoughtful strategy accelerates results, reduces cost and risk, and enables sustainability
Key Concepts
Technology strategy always needs to be rooted in a business-enabling approach
It is tempting to over-index on one dimension (e.g., cost management) and sacrifice capability
Excellence in IT is rooted in having business aligned objectives, with a disciplined approach
This model is organized around five key dimensions, which should be defined and prioritized
A simple IT scorecard could be created using how business partners evaluate each dimension
This article focuses on delivering IT objectives, IT Excellence focuses on “how to operate” in IT
Key Dimensions
Innovate – Promote Competitive Advantage
Map to business goals, establish a disciplined innovation process aligned to architecture strategy
What It Is: Excellence is core to creating sustainable value through technology in any organization
Why It Matters: Technology advances so rapidly that most organizations can’t keep up. The balance of agility and discipline, speed and quality are essential to optimizing the value of IT at the right cost
Key Dimensions
Courageous Leadership
Excellence requires tenacity, agility, flexibility, risk appetite, humility, and discipline
Given leadership sets the tone and direction for everything else, this is critical to get right
Need to be an advocate, champion, and business partner, knowing when to say “no” if needed
Transformative Culture
Remaining competitive in a continually evolving world requires a culture that enables change
Culture is expressed in what people see as much or more than anything they hear in speeches
Core values need to be consistently demonstrated from leaders to individual contributors
Relentless Innovation
Consider what happens in the technology strategy if core solutions are obsolete in 18-24 months
Make disciplined innovation part of the ongoing portfolio strategy to maintain competitive edge
Plan for “urban” renewal so there is minimal need for large scale, disruptive modernization
Operating with Agility
Establish strong business partnerships to respond to changes in portfolio composition/priorities
Create a minimally invasive, highly transparent operating infrastructure to drive efficiencies
Leverage workforce and sourcing strategy to provide the right capabilities at the right cost
Framework-Centric Design
Leverage enterprise architecture to establish a connected enterprise of intelligent ecosystems
Develop standards to enable ongoing integration of best-of-breed technology capabilities
Integrate artificial intelligence in thoughtful ways that scale and provide sustainable value
Delivering at Speed
Create a disciplined and repeatable environment for delivering solutions that can scale
Design with architecture, quality, and security in mind, not as an afterthought
Understand that total cost of ownership is as important as speed-to-market most of the time
What It Is: Manufacturing continues to move rapidly down a continuum from the highly manual to the digital, from disconnected, asynchronous activities to integrated, orchestrated actions, across an ever-expanding and diverse set of components
Why It Matters: Defining a holistic strategy that enables agility and flexibility, that provides structure without limiting innovation, can be a highly complex activity, but one that is well worth the investment given the right strategy can unlock value in multiple ways (production capacity, productivity, improved quality and safety, etc.), particularly in situations where there is a diverse footprint in place
Key Concepts
Design with a framework in mind, that is intended to connect, monitor, track, orchestrate, and optimize performance within and across digital facilities
Establish data ownership, data management, and data governance to enable long-term value
Think of individual facilities as having varied configurations of logically common components
Manage individual components so that they can be relatively commoditized and replaced easily
Understand that the goal is to optimize the overall system, harmonizing workers and equipment
Design the framework to enable adding individual components rapidly, with minimal disruption
Leverage the framework to create an environment that can simulate changes pre-deployment
Define strategies to insulate legacy equipment so that it integrates the same as modern assets
Work with OEMs to facilitate transition between bolt-on analytics to intelligent equipment
Integrate AR where it provides incremental value without adding complexity / distraction
Reduce complexity with AI, enabling operators to be more productive, effective, and safe
Integrate learning and development content dynamically based on operator experience
Approach
Provide required internal/external connectivity, infrastructure, and monitoring across locations
Identify connected components across facilities by function (equipment, devices, sensors, etc.)
Define relevant personas and capabilities to enable digital workers (shop floor to facility leaders)
Architect the environment to treat individual components as actors in a connected ecosystem
Identify integration standards and relevant characteristics per component to enable analytics
Design facility data solutions to allow for structured and unstructured data aligned to the cloud
Establish an infrastructure for orchestration that can coordinate activity across connected actors
Gather, analyze, and optimize processes given performance data and operating characteristics
Analyze observations centrally to leverage insights and opportunities across similar facilities
Extend the boundaries of orchestration incorporate customers, suppliers, and partners
What It Is: Workforce and Sourcing Strategy is the long-term approach that an organization uses to provide the necessary skills, internal and external, to enable capabilities to deliver on business commitments and support the current and future technology footprint
Why It Matters: Having a deliberate and thoughtful strategy not only creates an agile and responsive workforce to meet ongoing and variable business demand, but also does so at the right cost. Where a defined strategy is not in place and being governed, there is very likely cost optimization opportunity
Key Concepts
Business and technology needs fluctuate. A strategy helps mitigate the cost impact of change
Leverage a competency model internally and externally to benchmark roles, capacity, and costs
Generally speaking, it’s better to align variable capacity to areas of variable demand
Benchmark internal cost of service against best-in-class providers, make adjustments as needed
Understand that not everything needs differentiated service, keep the lights on is valid in cases
Invest in areas where technology creates competitive advantage and IP, outsource elsewhere
Actively manage and govern talent development and performance to optimize productivity
Never assume HC = FTE. Used named resources for capacity planning of critical roles vs FTEs
Source where technology is emerging and immature to facilitate experiments and early learning
It is a reasonable strategy to engage partners in simplification efforts through mutual incentives
Never assume shifting sourcing to captives for arbitrage benefits is a 1:1 FTE exchange, it isn’t
Be mindful in how you manage overall tenure. Motivated inexperience introduces risk and cost
Leverage role-based capacity agreements to shift contract labor costs to a defined model
Scrutinize contracting heavily to avoid inflated cost. Convert or hire longer-term needs
Establish consistent contract language that aligns to service delivery roles and expectations
Define primary and secondary partners for individual sourcing needs, manage them consistently
Negotiate aggressively but fairly, “partnerships” produce more value than a “vendor” mentality
Benchmark and leverage consistent performance metrics across internal and external partners
Apply vendor management and governance processes to captives the same as external partners
Approach
Understand Current State – Benchmarking capacity by role across sources of staff, including cost
Determine What You Need – Evaluate business and industry trends, do the same for technology
Define Sourcing Approach – Identify critical skills to retain and source, and where to get them
Refine Talent Strategy – Clarify gaps between current and future IT staffing, skills and capacity
Develop Transition Plan – Plan change to talent pool and make explicit sourcing decisions
Organized Chaos 