Service Management Leadership - Define What Good Looks Like

Foreign My name is Jeffrey Tefertiller and I want to have a short encouragement for you leaders. Many times we as leaders do not define what is good. This project's going live. Are we expecting good results? What does good look like? How is it defined? Who defines it? And so as leaders we need to take a step back, take a deep breath and understand these topics from our stakeholders perspective. Ask them when this goes live, what does good look like to you and then we can support it appropriately. When I think about projects and initiatives, whether Agile, waterfall, scrum, safe, whatever it is, we wait till right before go live and then try to define what good is, don't you think that should be way earlier? Way, way earlier when we're doing requirements, say what does good look like? Is it secure, is it compliant, does it, what benefits are expected? And I think about, I'm often reminded, and you all may be as well, the old Moscow requirements model or scheme where if you think of the city in Russia, Moscow, and we just use the consonants msc, W and we think about this for our requirements, what must we have and what results must we get? So requirements and outcome, what should we have as a requirement? What should we have as an outcome? Define these. Third, what could we have as a requirement? And third, what could we have as an outcome? And then the W is one that most people get wrong. So let me say it very cleanly. We need to define what will not be included and define for the stakeholders what will not be an outcome. If we do not define these for our stakeholders, that means that they will define them for themselves and we will have mismatched expectations. So define the requirements and at that same time define the desired outcomes. Don't wait till you get close and it's already built and then you're trying to shoehorn something in define it early. Also you should define, think about this from an improvement model. You should define what improvements do you want, not just what's in the backlog, what improvements do we need? And when I think of measurements, and this is something that's popped up to me recently, just as I've seen it, many organizations are measuring things that are easy and then there's some in something that is very tangible. MTTR reduction, tangible. Change, success rate, tangible. But if I ask you to define efficiencies gained, that's a little more difficult, right? It's like asking me if I've eaten healthily this last week and if you know me, the answer is usually nope, I haven't. But we, we lose sight of those things because our inputs are fuzzy. They're fuzzy numbers. And so I want to encourage you to be thinking of when we're defining these outcomes, they have to be measurable. They can't be fuzzy metrics. They have to be measurable in a way that our stakeholders can see that we're being transparent. The problem with fuzzy numbers, fuzzy things, estimates based upon estimates based upon estimates, is they get fuzzy. And by fuzzy, I mean squishy. I know that helps, right? But in a way where you're looking at it, you tilt your head and you're like, do I really believe this is true? And sometimes yes, sometimes no. So we need to find ways to measure things very transparently and through numbers. Hopefully this resonates with you and your organization. My name is Jeffrey Tefertiller. I thank you for joining us. I ask that you, like, share, subscribe. Wherever you are consuming this episode, let me know how I can be of help to you or your organization. Have an awesome day. Bye.