TLDR: There is a lot of “good practice” within the overall model but the most significant challenge and question for most customers is WHEN should each component be implemented? Followed by HOW? …given the ongoing talent shortage within the overall ServiceNow ecosystem.

Good Practice
First off, should this operating model be treated as Best Practice? Not yet. But from ServiceNow’s perspective, it may very well be considered their best practice. The prescribed Operating Model is far from being void of debate — especially in relation to the HOW — as well as the lack of widespread, real-world application. The infamous Frederick Taylor would also be pleased because from many angles this could be perceived as an attempt to define “the one best way” to manage the Now Platform but hopefully, we all recognize that we need a new lens when it comes to defining the Future of Work and Working in New Ways. I don’t necessarily believe that this perception is what ServiceNow wants you to take away from the Operating Model, but some will undoubtedly view it as another governance-related control mechanism that actually negatively impacts their innovation program. In other words, there is such a thing as “going too far” when it comes to controlling the WHY, WHAT, WHEN, WHERE, and HOW related to the Future of Work.

Could one adopt the Operating Model and follow the guidance from the various ServiceNow forums…but still fail to realize the organization’s desired level of value from the Now Platform?

Absolutely. But the Operating Model is a good foundation and starting point. My previous comments elude to a much bigger problem where best practice is all too often thrown around in our everyday language without much hesitation or understanding of context. Those that do it, assume adoption will pretty much guarantee success in achieving a given outcome. One should be asking themselves and others, can this given standard, methodology, or framework become part of OUR best practice? …and then let the “yeah, but will it work here?” debate play out from a good practice perspective. By the way, the subtle change in ITIL 4, where the authors transitioned away from processes to practices, supports the larger trend of how organizations need to be thinking about when they attempt to change their IT Operating Model. The ServiceNow Operating Model and Common Service Data Model (CSDM) should just be pieces within the larger IT Operating Model, which then needs to be integrated with the Business Operating Model(s) to create a Digital Operating Model (DOM) — a prerequisite for participating in the overall Digital Economy. This aligns with why ServiceNow goes to extraordinary lengths to describe and market its value proposition can help companies deliver their unique transformation aspirations.

Certainly, some of the underlying governance components and process-related methods could be considered best practice IF certain criteria are met but as a whole, a model has more in common with a framework and as such, is more difficult to reach the “yeah, this makes total sense because no one could possibly dispute the existing cause and effect relationship within the underlying guidance”. For example, is the prescribed Center of Excellence (CoE) really the best and only option for accomplishing the goals and objectives?

Governance Components
Executive Steering Board — It never hurts to get as many executives involved as possible as one attempts to extract maximum value from the Now Platform, especially for business use cases; however, the further one gets in their journey from just doing IT Workflows (ITSM, ITOM, ITAM, etc), the more executives need to know about the Now Platform. In other words, the learning curve is highly correlated to one’s overall ServiceNow spend.

Pro Tip: Something that won’t be observable in the Operating Model but is a key element to “getting this right”, is that Ideas and Demands should NOT be disconnected or hidden from the Executive Steering Board — at least not those that hold funding authority. More on this is in the Product Team section.

Demand Board — Governance in this area is all about leadership, particularly the Program Manager and Demand Manager roles within the Business Engagement and Delivery team as well as the Platform Owner and Value Management Lead, working collectively to ensure that the best ideas and most important work is being approved. In other words, “Are we doing the right things?” The concept of a Demand is rooted in the recently renamed Strategic Portfolio Management (SPM) application and as such, is used for capturing, centralizing, and assessing strategic and operational demands, particularly those that rise to the level — based on difficulty, cost, alignment, time, etc. — of needing to be reviewed and approved. Technical Governance Board — What’s not to love about a solution review? Well, I guess it depends on the context and scope of the solution.

The model shows three specific ones:
– Review requests for customization
– Enforce technical standards
– Track technical debt

I am on board with those three contexts largely because of how often customization on the Now Platform leads to technical debt, issues doing upgrades, inability to scale, and lack of sustainability of the overall capability. The grey area is the Enforce technical standards, largely because there are some really outdated standards (minimum requirements) still being used today. Unfortunately in many cases, no one really knows WHY and collectively, they can negatively impact any notion of a new way of working emerging for the Platform Architecture and Support team as well as each of the Product Teams that are closer to the constant and rapid change being experienced throughout the ServiceNow ecosystem. This is where the Executive Steering Board and certain elements of the CoE can be seen as being “out of touch” with reality when it comes to the criticality of the platform vision and value realization needing to be aligned with talent acquisition strategies and the value that ServiceNow partners must be able to deliver. Unfortunately, the partners continue to employ a worn-out business model — more on that in future blog posts.

Center of Excellence and Innovation (CoEI)
I have to be as transparent as possible on this element. I don’t believe the [and] between the two elements is the best approach, nor do they belong in the same sentence, especially in the context of governance. A Center of Excellence has many definitions but I immediately think of an entity that creates guiding principles, best practices, guidance, and/or standards for a given domain. It coincides with one’s desire for Operational Excellence. The interesting part of the image above is the 3rd bullet, where “good” is specifically called out. I don’t believe the authors intended to play into the “good practice” perspective that I shared earlier but it does elude to the notion that a LOT of IT Service Management (ITSM) — especially the traditional Change Management process — is under the microscope when it comes to Agile DevOps. For the most part, I think the merits of a CoE are valid if it is structured and positioned correctly…but not in the context of innovation, complexity, and Product Management — really anything that deals with or contains non-linear activities and patterns.

More often than not, I believe the times when a CoE is incorrectly structured or positioned, the source is an “old school” manager clinging to an illusion of control. After all, the only constant is change, often in the form of complex and entangled challenges. For example, we shouldn’t expect a CoE to produce something outside of what the Cynefin Framework would associate with an Ordered System. A system that has linear causality with a high degree of certainty and knowledge in the form of best practice and rigid constraints or good practice with a specific boundary of expertise or knowledge. Some of you may even have an Innovation Center of Excellence in your organization today. If it is doing anything other than defining, communicating, and supporting, say the Open Innovation process throughout the enterprise, then I’d like to hear from you on how successful it is or how success is defined. Additionally, the word Excellence thrives on a lack of variability, which is almost the exact opposite of the concept of innovation and more specifically the modern Product Management process — something that ServiceNow fully supports within the latest version of their Common Service Data Model.

Unfortunately, true innovation often needs chaos as an accelerant, let alone thrive throughout an entire corporate culture. One simply isn’t going to be successful applying best or good practices when dealing with complexity. Those that do have occasional success often then incorrectly associate correlation with causation. In other words, luck had more to do with their occasional success and frustration is on the doorstep. Again, this presents some major challenges for those that continue to hold on to every ounce of control they can, call it controlled chaos — if there ever was such a thing.

Without a doubt, the Now Platform can be part of the environment that needs to be created as part of enabling creators — even Citizen Developers — to do their best work. An environment that can’t be forced or coerced into existence. This also includes how one leverages all of the innovation that ServiceNow delivers within each major release. In fact, the entire ServiceNow approach is analogous to a treadmill, which begins the moment you make your initial purchase. This consumption treadmill isn’t necessarily a bad thing but of course, that too is highly dependent on one’s ability to extract value, largely based on the perceptions of those holding funding authority for the overall ServiceNow journey. The real opportunity comes in the form of building custom applications on the Now Platform, specifically those that provide or support a competitive advantage in the marketplace. In other words, anyone can buy the innovation that ServiceNow is delivering in their various products. Essentially, the greatest insight that I get from the Operating Model is how it should enable creators to be, well…creative, but there is a lot of unobservable work associated with making it a success. Leaders need to be held accountable for creating the environment that was previously mentioned, dramatically increasing one’s probability of success so that true innovation emerges and delivers tangible results. This is really the foundation of how modern leadership is shifting away from the worn-out command and control management style from past Industrial Revolutions. Doing so gives creators an opportunity to navigate the complexity that is so often associated with building an innovative product that customers or users actually want or need.

In place of a Center of Excellence, I would like to echo the sentiment that Jonathan Smart outlines in his book, Sooner Safer Happier, around what he calls a Ways of Working (WoW) Center for Enablement (C4E). There are a couple of definitions for C4E but the one that Mulesoft subscribes to aligns more closely with our underlying context. A C4E is a group that drives the IT operating model shift. It’s in charge of enabling business divisions — including but not exclusively IT — to build and drive the consumption of assets successfully, thereby enabling speed and agility. They promote consumption and collaboration and help drive self-reliance while improving results through feedback and metrics. Overall, the primary goals of the C4E are to run the API platform — in the case of ServiceNow, a Platform of Platforms — and enable teams on how to best use it while developing reusable APIs to accelerate innovation and deliver change more efficiently. The context and scope of a ServiceNow-focused C4E could be Enterprise Service Management (ESM).

Product Teams
The analysis wouldn’t be complete without covering the Product Team and Citizen Developer layer, which are also referred to as Product Streams. Honestly, this is where the real value is delivered from the Now Platform. The ServiceNow.com website is also structured by Workflows: IT, Employee, Customer, and Creator, which then align to each subsequent ServiceNow Product, like ITSM, HR Service Delivery, Customer Service Management, etc. To be in alignment with the Operating Model, a Product Team for each major Product being consumed needs to be formed, largely in an effort to decrease the cognitive load required to achieve the desired (higher) maturity for the underlying Product. For example, many ServiceNow Developers have a deep skill set and experience level with the IT Service Management (ITSM) application, largely because that’s where almost every ServiceNow customer begins their journey. The cognitive load can ramp up very quickly if the IT Operations Management (ITOM) and IT Asset Management (ITAM) applications are also being added to the Now Platform. Then the Security Operations (SecOps) application, rinse, repeat for Employee, Customer, and Creator Workflows Products. An additional trend to increase the probability of success throughout the ESM approach is to hire personnel with years of domain-specific experience and then teach them ServiceNow — largely because there is no quick solution for the lack of experience. There are two critical elements that must be addressed within the Product Team model. Organizing the ServiceNow team members into an appropriate Product Team is only a local optimization of the larger ServiceNow Team. In my opinion, the missing element is end-to-end value streams containing ALL of the resources/assets to deliver the desired portfolio of products and services. For example, the ServiceNow IT Operations Management (ITOM) Product aligns well with Infrastructure Operations, including Cloud Operations. Forming the ServiceNow ITOM Product Team is just the first step; the larger challenge comes in extending the Product Team concept to form an autonomous, high-performing, collaborative, and cross-functional team — capable of co-creating value through empowerment. The powerful aspect of this is what happens — often to the surprise of everyone — when you bring the collective knowledge and experience together on a single team, rather than continuing to “throw work over the wall”. The end-to-end value stream approach then has not only the Now Platform at their disposal but the tacit knowledge from a given domain, making the delivery of value everyone’s job.

The end-to-end value streams then need to have connective tissue back into the Executive Steering Board and CoE or C4E as a way to ensure that the co-creation of value is achieving desired objectives but also made visible to those defining the strategic intent and possessing funding authority. Project management methodologies also matter, like Waterfall vs Agile, within the overall Operating Model but also in the context of whether you are funding a Product Team, aka a Product with no established end date until it is strategically removed from the portfolio or a traditional Project. The difference is rooted in what Mik Kersten talks about in his book, Project to Product.

The Product Team model then becomes the critical intersection related to the flow of Ideas and what becomes a Demand, which can be combined into the larger flow of value concept. Unfortunately, it is still possible that leaders with funding authority still hold on to the legacy definition of value, which is all about lowering the cost of something. According to Mik Kersten’s Flow Framework, Business Results does include Value and Cost separately, along with Quality and Happiness. The Key Results of the Product Model within the Flow Framework includes a Flow Distribution mechanism that includes Features, Defects, Risks, and Debts — which are collectively what then become the “knobs” that leaders within the context of the Demand Board can use to ensure Product Teams are working on the most important work. Getting this level of detail related to the flow of value through the CoE or C4E, most importantly the funding component, is paramount to one’s long-term success in ESM. Don’t settle for local optimizations of the ServiceNow Team.

Pro Tip: A Product Team member should not have to submit a Demand for another member of the same Product Team to do something in regard to a Feature, Defect, Risk, or Debt. If something is needed from another Product Team, sure…put it in the form of a Demand and ensure that it is routed for approval by the appropriate group within the CoE or C4E. Also, create a “funnel” of Ideas for the Executive Steering Board to consider for approval — including the funding — prior to transitioning them to a Demand and thus into the development queue of a Product Team.

Final Thoughts
Overall, I can appreciate the reasoning and justification for the prescriptive ServiceNow (Platform) Operating Model, much the same way I feel about the CSDM. From top to bottom, there is a lot of potential but the HOW is so critically important and I don’t think the creators of the Operating Model would disagree; they are simply balancing high-level guidance with providing a detailed tactical approach, like end-to-end value streams, that may need additional expertise in order to achieve. The outcome of the adoption of an Operating Model, like what ServiceNow is prescribing, should certainly be a much better methodology for managing the Now Platform, certainly eliminating new customers from ever having to do a very disruptive “back to box” re-implementation. I look forward to seeing how the Operating Model evolves, much in the same way the CSDM has, and gets adopted by customers.

If you found this post insightful and are curious about the idea behind The Value Network LLC, please Join the community as well as follow us on X and connect with me personally on LinkedIn. Always happy to collaborate on Working in New Ways strategic ideas.