Little Caesars Pizza

Operationalization: Wikipedia states “Operationalization thus defines a fuzzy concept so as to make it clearly distinguishable, measurable, and understandable by empirical observation. In a broader sense, it defines the extension of a concept— describing what is and is not an instance of that concept.”

As a corollary – it is better stated in a change management process as - if you do not know what the change is going to do, you have not evaluated it in more than x number of iterations, and it was not 100% successful, then you cannot roll it forward. Answer the following questions:

• “What could happen if it fails?” NOT “What do I do if it fails?”

• “What friction would it introduce into the business, and will the staff there have to do something which is reboot, reset, how do we notify, and overcome impact?”

• “How does this affect the Customer and their confidence in our practice?”

The “DUH” moment is “well everyone knows this.” However, not every team takes the time and planning to build & test, monitor & test, alert & test, then stop & assess, test & adjust, and test to recover from an event. This is a conscious and intent-driven act!

“The best support model and communication to your customers is when they never know there was an issue/event that affected them.”

This is just not about “recovery”. This is about “being operational” in all your practices and ensuring that in this new climate of cloud, hybrid, and multiple data centers, you strive to not have an event. The best support model and communication to your customers is when they never know there was an issue/ event that affected them.

Something we built years ago was an “11-step drop.” In short, where do we start when we get a call for an issue. What if we started with that 11-step drop and used it as a checklist for Operationalization? You can start all these sentences with “Have I thought about resiliency of” but in the beginning troubleshooting we used this as a guide.

Start each question with "DO YOU HAVE:"

1. Power

2. Network

3. Servers

4. Storage

5. Services

6. Security

7. Alerts

8. Monitors

9. Vendor integrations

10. Other dependencies

11. A list of what changed last.

As understood, this must be Top level (C-Suite) sponsored and a fully sanctioned business process like cybersecurity. Each team must plan “right to left” and build this into their day-to-day process, from business stakeholders, product owners, business analysts, developers, dev ops, systems engineers, and support teams!

Is your first question How or Why when a request is made to put technology into production?

What about making your first question being, “What does great look like.” As technologists, we always think about what new thing we want to build. What if we took the “acceptance criteria” and worked backward. This is not a mission statement; it is more a comprehensive executive summary of the expectations for your customers, stakeholders, and internal teams to “Dream to the Theme” or “Done to the thought,” a.k.a ‘D-triple T.’

Could the “why” be obvious? What is your loss per minute? People, time, customer, confidence, all those items have a monetary impact. Are you a critical provider of utilities, healthcare, or transportation? What are your users’ expectations? What are the key learnings in your segment? What mistakes have others made, and how do you prevent them? How does preparation meet possibilities meet costs? Take a moment, understand the implementation, and think “great” backwards. Operationalization, done correctly is right to left.