The topic of this second “Shorts” podcast episode is “Capabilities”. We spoke about this in Episode 2 – “Why EA and BPM?”, but received some feedback that we should dig deeper into this topic. So here it is 🙂

The high-level topics of this episode are:

  • What is the difference between a capability and a process?
  • How do capabilities fit into architecture?
  • A real-life example of how capabilities can be used in a program for planning purposes
  • Business vs. IT capabilities
  • Where should capabilities be used, and how?

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Additional information

This is the “three column slide” that I referred to showing the connection between strategy, capabilities, and programs.

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

J-M: Hello and welcome to another What’s Your Baseline Shorts today. We’re gonna be talking about capabilities and I’m J-M:, I’m one of your hosts for today, process and architecture expert, been doing this for a decade and a half and I’m a big fan of helping to bring business ideas together, which is why capabilities is such an important topic to me. And my friend and co-host Roland, talk to you about, talk to us about yourself.

Roland: As always brief and short. My name is Roland. I had the idea for that whole thing and obviously we’re going to talk about capabilities today in our What’s Your Baseline Short. So, JM, what is a capability? Is it me being able to time my shoelaces?

J-M: Ah, that’s a great question. So I feel like capability is an abstraction of something that you’re doing to achieve a business outcome or service that can be quantified or can be qualified and in a way that others can access it. You’re creating things your company can do internally or externally that allow your company to do business. Now, it’s not a process, though it is closely aligned to processes in some cases. But they are not exactly processes. So, I think of them as an abstraction, a layer above that allows us to now interlock it with other parts of the business and of the whole company. So, Roland, what’s your definition? 

Roland: Yeah, I would describe it slightly differently, even though I use the same words that you have. A capability is something that an organization can do. But the capability is comprised of multiple things, you know.

One is the process. The other one is the organization who does it, right? The roles. It’s the skills that you need. It’s the applications. It’s the data. It’s the location where this happens and so on and so forth. So the capability is a construct of all those different things that describe what an organization can do. It’s not what they do? It’s not included in how well you do it.

J-M: Um, which is actually something. Yeah, it’s not what one thing does at a time. Yeah, I understand. No, you could put KPIs against that , though.

Roland: That would be something like, that’s true, but that would be if you really perform it, that would be something like a business service. So typically when clients ask me and say ‘hey what’s the difference?” I typically say a little bit loosely “ well your business service is your capability with an SLA attached to it”.

 J-M: Ah, that’s fair.

Roland: I’m going to do this project for you in this amount of time for this amount of cost and whatnot.

J-M: Yeah, and I think it’s an interesting thing because a lot of people like to think of processes as capabilities like your process hierarchy and your capability hierarchy. Well, it’s really just the same thing but I think you felt I outline it. I think we want to start first and foremost break this idea right open that your process isn’t your capability. Your process delivers a capability and it’s part of the puzzle. 

Roland: Yeah, it’s part of the capability. It shows the step that you will perform to do this thing that you’re capable of doing.

J-M: But just like you might think a process has a spider web of other things, a capability One of the things is a process. So yes, exactly.

Roland: The capability describes the “what”, the process and all those other things describe the ”how”, right? if you think about it when you’re in a system implementation and you would go and say hey – and I did this in a previous life where I was the program architect for a large global three year / twenty million build implementation where in a previous firm. We wanted to invent our internal audit offering and we were just looking at okay hey this is what we need to be able to do you know plan internal audits and schedule resources and do the program management and issue tracking and all those wonderful things in one two but we looked at it and here in the US the firm had about three and a half thousand internal auditors -people who did that for a living- in the Netherlands it was, like, thirty five.

So the requirements that the guys in the Netherlands had were much lower in fidelity than what we had here in the United States. So capabilities can come in different flavors, right? Which are called capability configurations. So think about gold, silver, bronze in that case.

The goldilocks solution that we built here for the United States was obviously much more expensive and way more fancy versus the bronze version that we did for our Dutch friends, who just didn’t have those requirements. So the capability was” yes, they all could deliver internal audit projects”.

They had the capability to schedule and plan and do and whatnot. But the way you’ve done it was through different configurations, and that was obviously helpful when it came to planning the whole timeline, right? Because there might be dependencies between them. The need to build something for the gold version and you just cannot assume that it exists, for in this case, a country where we implemented the bronze version right? Something to think about.

J-M: Yeah, I love using the word fanciful in North America it had to be more fanciful. Ah, but this is something you’re touching on and this is what I really want to get the meat of this is that capability is kind of at interlock you’re seeing in a lot of different contexts as you’re building up capabilities. You know, we’re touching on different areas and we’re touching on those areas as like sort of centralized interlock that will help us understand what the requirements are passed between different spaces, so connecting business to it is a perfect example.

And Roland, I know you’ve worked a lot with IT capabilities and how they relate to business. Let’s talk about why? That’s so important. Ah oh yeah, we have a little time.

Roland: Ah, you open another can of worms. I think we need to introduce another concept here. One  is obviously business capabilities. 

I, as a business, as an organization, want to be able to do XY and Z, right? But then you break them down over multiple levels. I typically say stick to 3 or 4 because obviously the deeper you get, the wider the pyramid will be, and the more complex it becomes at some point in time.

You will hit applications and applications do have “capabilities” too ,right? And this is where the distinction now comes in business capability versus technical capability. My favorite application can take coffee orders brew coffee and serve coffee.

That’s completely independent of the whole context of “ oh, I want to be able to run a coffee shop”, right? There is the need for a machine or an application that can do those 3 things that I said  and that’s separate between business capabilities. What the organization does versus the technical capabilities that maybe an app or machine has.

J-M: Yeah, and to talk  about that specifically, I feel like I see a lot of clients tell me that how they do business or how  their business runs on applications, is driven by the application. And that is such a locked-in mindset. You’re stuck. You can never switch off that application because that’s how you do things. That’s how you do things, but it’s not that you are leveraging an application capability and that application capability could be performed by any application or any part of a number of applications. 

So when you’re looking at evolving your IT landscape. If you start with the point of how we do things as applications, then you’re only ever going to be able to make a solution choice of the applications, where, if you talk about it from capabilities, you can do anything for sure. Yeah.

Roland: Um, that is semi-correct, I would say, and basically you just pointed out how old I am because this is not dye, you know, that’s real gray. 

J-M: Ah I got gray too baby. Don’t worry.

Roland: But in all seriousness, what I’ve seen in the past is there are trends going through our industry. You know, when you think about the ERP stuff, where everybody says no, don’t do your own thing; standardize on what your application does – you know, the SAPs and the Oracles of the world. And you said “Yeah, that saves us so much money because we don’t have to think about upgrades, because we’re following the standard process”. 

And then the next wave was “oh yeah, automation, you know? Oh no, you have your custom thing. Mr. Client, and we’re happy to build this.” So what vendors sold organizations was the box of Legos to build their own stuff. Or at a different time you had that “best of breed” approach. “Oh yeah, these are ranked by the analysts as number one in this area and those are the ones that are number 1 in that area. You should bring them together.” 

So I think it’s more a question of maturity in the organization to define what we actually want. And for this capabilities are a good thing. You know, you take the step away-  you say “yep I want to open a coffee shop right?” And for this I need those 3 capabilities? Order, brew, serve.

 But I’m not tied to a certain application. I’m not tied to a certain business model,  if you will, right? I can take a step back and rationalize for myself. What I want to do, and this is where capabilities are a good construct for.

J-M: Yeah, you use the word rationalized and I think that when we look at application and in a capability and IT perspective that’s where I see a lot of people successfully using that as a marker for rationalization If I have, you know, twenty, thirty applications with the same capability as part of their listed functionality sets then I can start looking at maybe this could have been done by one  application and sure I’m going to have to make some contractual concessions and I’m going to have to cancel things or not renewing or harmonizing. Maybe I have to adapt functionality and customize to actually meet my company’s needs. But you are focusing on capability as that common identifier to show duplication and not exactly.

Roland: Yeah, there’s some migration cost that you have, yep. But you have the same with your processes. Stick with another example, right: why do I have location one doing the same thing differently than location two? That’s a valid question. I think this is one of the takeaways of this episode of What’s Your Baseline Shorts. It is where do capabilities fit into the bigger picture. So obviously they do all the things that we just discussed, but in my mind capabilities should be the main driver for developing your architectures. 

So when you think about it, the way how I visually typically visualize it, is where you have your strategy somehow modeled – your vision, your mission, your objectives, your strategies, all that type of stuff, and the KPIs that you measure your success with – but then the question comes up with “Well, how do we bring this into fruition?”. Where the answer is “by defining capabilities”. I want to be able to run a coffee shop right? It doesn’t say how I’m doing this right. So that’s the middle column here.

And then obviously the ultimate question comes “well, how do we bring this to life?” which is the third column on that slide that I typically use is why are you going to do this by implementing projects. 

So your capabilities drive the shape of your projects and your investments. And one key question that I always like to ask when somebody comes to me and says “oh, I have that wonderful idea. I want to have this and it just costs so and so much” is threefold: 

What capability do you create? What capability do you change? What capability do you retire?

And if the answer is “none”, well, then my answer is “you don’t get any money. Go home”, right? Figure out where it fits so and then your capabilities drive your project setup, your programs, your projects and whatnot down to the work package, if you will, where you then actually create something right? And that something can be measured.

J-M: Um, yeah.

Roland: And this is where it closes the loop, because those are the KPIs that you will measure that then show, “did I accomplish my strategic objectives that I’ve set out in my strategy?” So strategy drives capability drives projects and programs.

J-M: Yeah, so so bringing this all back together for this episode of what’s your baseline shorts I think we’re really hopefully giving you a sense of what the importance of capability is some people sometimes say I don’t want to get to that level of capability. It seems like it’s too much of a level of abstraction extra work. This is the interlock that will keep your work reasonable. Will give you a vision of the scope as realized by its different components and it’s important to do. And number one is “capabilities are important”.  They are what your company does and they contain a lot of the components of process, and architecture, and organization, and data – all those sorts of things, so that are capabilities. It’s not just your processes. Not just your application services. 

Roland: I think to close that out is Episode 2 if you want to hear more about this topic, I highly recommend it. It’s about 50 minutes or so. Listen to our episode 2 where we talk about EA and BPM and (full spoiler alert) – from our perspective. It’s the same thing. It’s just a different view on things because an organization has one architecture. It’s not different architectures. So capabilities help you set the structure and stay sane in that setup.

J-M: Yeah.

Roland: So listen to episode 2 “Why EA and BPM” and with that I think we’ll let you go right? My name is Roland: and we’re going to see you in the next one.

J-M: Sure well, yes, I’m J-M:, and we will see you in the next one.