Welcome to episode 3 of the What’s Your Baseline podcast.

The topic of this episode is how to implement your architecture tool(s). We are talking about: 

  • What do people look for when buying an architecture tool?
  • What is the end perspective on the architecture tool implementation?
  • The importance of personas and the value proposition for them – outside-in perspective
  • Four big steps of implementing an architecture tool – inside-out perspective
    • Strategy: strategy definition, releases, measure success
    • Technology: tool selection, tech setup, technical governance (data model, meta model, configuration, conventions), other systems and integration
    • Governance: processes, organizations, org change management
    • Import of existing content
  • Three legs that need to be balanced: content – governance – adoption

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

Ep. 3 – Implementing Your Architecture Tool – What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Additional Information

Enterprise Architecture Implementation - Step 5

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

  • CP1 (Welcome)
  • Wurly (Interlude 1)
  • Airplane Seatbelt (Interlude 2)
  • South Wing (Outro)

Transcript

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

Roland: Hey J-M, how are you doing on this wonderful day today?

J-M: Hey Roland, I’m doing alright, I’m making it through. Isn’t that what they say?

Roland: I hope you do and I hope you are also excited about what we’re going to talk about today.

J-M: Oh heck yeah, both of us came honestly to process management and enterprise architecture, partially through the lens of large scale implementations. And as you might imagine, organizations really, really want to transform the way they operate and to do that, particularly for very large organizations, they want to bring in large scale tool sets or platforms upon which they can automate and support their business. And these are things that are household names, the Oracles, the SAPs, the JD Edwards of the world and implement those.

Well, there’s often a conversation that needs to be had about enterprise architecture and business process management to help make those come to life and to sustain them as they get rolled out. And as they disseminate across all the people who are going to be using them in their day-to-day lives.

So that’s our topic today, and I’m quite excited to talk with you. You’ve done a lot of these, Roland, and tell me a little bit just before we get started on the actual topic itself, you’ve done a ton of these different things. What are your top three things you’ve learned from all those implementations that we’re going to talk about today.

Roland: I think the first thing is people look at buying a tool because they need a better paper and pencil. And they go and they say: “yeah, it’s just another drawing tool. You know, so why should we have this? Why should we look at a very expensive tool when Visio just does the trick and we virtually get it for free on our computers?” So that is the thing, maybe not the most important thing, but that’s the trigger that I typically see in implementations. Unfortunately I have to say, and I’ve been on a couple of those implementations where they bought our software and they  said “yeah, this is cool. We bought a new tool. It’s like Visio on steroids.”

J-M: I’ve heard that before.

Roland: Right, and you’re just looking at it and  you say “Oh, wow, we’ll see how that goes”. The second, and that might be the biggest one, is they buy it just as another drawing tool. Which means they don’t think about how we want to use it. They don’t think about the context of the implementation. They just say ”yeah, I just need something where I can scribble something on and it’s good”, right?

I think the better way to do this is to take a step back – and we will talk about this in this episode – take a step back and have a look at in which context do I want to use this? What do I ask my users to produce; which artifacts? And then go in and say “OK as part of phase X in my agile or waterfall-ish process, where are you supposed to create these artifacts so that we have a design of the solution that we want to put in the tool.” The benefit of those pricey tools is obviously the better ones, and we will talk about that in a separate episode, about what you should look for when you select your architectural tools. You can earn so much more with it. You can do analysis outside of the scope of your project. It’s reusable, you can use it for knowledge management and all those other things.

J-M: I think to dovetail to that I see is a lot of organizations try to look at when we implement on a large scale, what we’re doing is producing deliverables. And that’s a very narrow perspective to take. I think it’s kind of problematic because when you start with the end in mind being an “end” – the completion of an effort and not an ongoing process, then you’re thinking about “how can I wash my hands of something”. How can I implement something so that it’s done and that the people can be done with this kind of work and we can move on to other things? But the question is, what are you moving on to? What? Operating the business? No, no, this is a continuous process of understanding, analyzing, maintaining an ecosystem of process and architecture, of governing that ecosystem and ultimately of continuous decision making. Because this is supposed to be a platform upon which you can build.

Roland: Agreed, agreed, but on the other hand, a lot of people have a focus on just getting over with the implementation right. The traditional IT thing. Oh you business selected something. I dd buy it. I implemented it. Good luck! That’s a little bit too short of a thought. The better projects that I’ve seen and that I’ve worked on who really reaped the benefits of it, where those who saw the implementation of the tool not as a single project in time and at some point you’re done.But they had a wider scope, so they were looking not only for the current need. I need a tool to do XYZ synchronized with SAP or due process mining or whatever. But it said, hey, how does it fit into the bigger context of my enterprise? How do I want to use this? Is it to rationalize my applications that by definition is obviously not a single project, but obviously has an impact on the overall enterprise. Or is it with the idea to implement a process improvement methodology in the organization? And how do you use this. So when looking at it, the more successful implementations that I’ve seen had an enterprise wide focus, even though it might have just rolled out within a single organization, but they thought wider. That would be my first recommendation.

The second recommendation to look at is, well, who’s going to use your tool, because the requirements that you have are obviously different for somebody who should maintain an application portfolio or who should create business processes. Or who should design organizations, or who should be just the consumer, right, the viewer of these things. Or who is a risk person who needs to approve it and puts his SOX checkbox on it to say “Yep I approve this “, or, or … the second recommendation that I would have is to look at the personas.

J-M: Yeah, Roland, I have actually had a chance to talk about personas and in a couple of different dimensions. I feel like when we take a look at personas we want to understand the day in the life of what. What are they actually doing and also what do they need? What are the demand profiles? What kind of information do they tend to process? What kind of skills do they have? And I think that dovetails nicely into thinking about almost internal customer journey management, because if you’re looking at implementing a platform at a large scale you’re going to have a variety of different customers whose daily processes the way in which they work are going to interact with the platform on are going to work, hand in hand or in cross purposes with its functionality, its scope and its context, and that’s really important. So I think setting out your personas, defining them well, and ultimately being able to address the different challenges and needs of those personas dynamically as you go along is really important. And being reflective, say hey, am I doing it for y’all? If not, well how can I make it better? Those are important parts, particularly during a multi phase or multi stage multi year even implementation of enterprise management systems.

Roland: And just to chime in on that. I think another factor that you haven’t mentioned is how do the users feel? In accomplishing that task in using the tool. There is and I don’t want to go too far astray. There is a nice book, it’s called “value proposition design” written by a gentleman named Osterwalder, who you might have heard of. He invented the business model canvas concept and that book talks about the different value props for things that you might want to offer. Do your customers need to do a job? Yes, of course they do, right? Do they have a little bit more to give than just the bare minimum on this. Yes. Do you have something in your product (which is your implementation in this case) that enlightens them, that gives them joy? And I highly recommend it. We’re going to put a link to that book in the show notes, of course, but I highly recommend to have a look at that concept because that helps a lot to create your personas, which I definitely recommend. To create literary fire up your PowerPoint. Put the fixtures picture in the corner and then describe it. “Oh, this is J-M. He’s a consultant in his mid 30s who has to go to his job every day as so and so. What does he have to do to be successful to accomplish his job? How does he feel about this?”

You know, where are the roadblocks that he sees that you have to overcome? Because when you think about that value proposition design, yeah, it’s great to know what somebody needs to do and what would be the little extra on top of it and how they feel about this. And enlightens them. The flip side is how do you define your product in a way that it is more than just the tool that brings that enlightenment? That makes the users feel happy.

J-M:  It feels almost like Marie Kondoing your daily job. 

Roland: Yeah, taking up your laptop and saying how does that laptop make me feel today? 

J-M: Does it spark joy? Does does this this piece of the process spark joy for me? But no, that’s not. I mean, we talked a lot about the intangible benefits of doing the right thing,

But one of the things you think about your people, if they’re constantly forced with using systems and using processes / engaging in processes that they find unsatisfactory and not in the sense that you know. Not everyone likes their job, and I understand that you know you’re getting paid because this is what you would necessarily choose to do, but if it is adding a layer of frustration. Information is unavailable, if processes are breaking, and they’re having to wait on information, on people, on systems they’re going to leave, and you’re going to end up having a lot of costs and risk associated with constant turnover. People trying to do a job which is ultimately something you could have improved by seeing the context in the persona early on and being able to support that with the right processes and systems in place.

Roland: Agreed, but also take a step back when we think about implementations. What is typically the first thing that you do is you write some requirements. Right? You say “oh, the tool should do this. You know, brew coffee. Serve coffee, drink coffee.” Do you know what my hobbies are anyways?

J-M: Oh yeah, I see. You brought them all the way back into this. So I see Roland starts with the processes by which he can get on his motorcycle. Or he can drink a nice cup of coffee.

Roland: Or both, but unfortunately at the same time. But anyway, we’re going astray.

J-M: We are. We’re going to get into the practice and the value of really taking a structured approach to these large scale implementations. Before we do that, I wanted to ask all the folks in the audience and to think about this for a little moment. 

We’re going to take a brief break and I want you to think about what you have been implementing. What are the large scale implementations of software or processes that you’ve been part of as a participant or in charge of as a manager? And how do you see yourself as a persona? The folks around you as a persona or how have you in the past defined personas and what challenges and opportunities have come from that? We’re going to leave you for a moment and when we come back, hopefully you’ll have an answer and we’ll have an answer.

BREAK

Roland: Welcome back, I hope you took the time to jot down some notes about personas and before we move on to the next big topic, I’ll still like to spend a couple of minutes, J-M, talking about personas because I think it’s it’s pretty important to get a certain perspective right. So J-M, if you could take it from here.

J-M: Yeah, I mean I took some time in our little break to think about this and I’ve been in the situation of having to define personas before. But really what it comes down to is an outside in perspective. That’s what we want to take. We want to put ourselves in the mind space of the people who are actually doing the processes, the viewers, the editors, reviewers, the approvers, the managers of data and library, and all those sorts of things that might be part of our ecosystem. And that outside in perspective helps us to try and better. Understand what they need, when they need it, how they’re going to operate, how they’re going to interact with this platform, and we’re trying to roll things out. We can better configure requirements we can better anticipate their training needs, their documentation needs, and ultimately we can help make better decisions so that they don’t have to, and that’s going to give you a more clean, a more efficient, and ultimately a more operable way of doing things in large scale implementation. 

So that’s what I see is as a persona as a way to create personas and why personas are important, but talk about the other side of things. How do we actually get to this? So this is the practice of implementing a large scale project of around a transformation tool like this. I know you have a structured approach, you love to follow. Tell me about the phases and what do they comprise. How do we put them together?

Roland: happy to do so. It is basically an inside out perspective. Now that I will talk about, but it’s basically a four big phase approach. And the four phases are strategy, technology, governance and then importing whatever existing content you have as a dedicated phase. 

But let’s talk a little bit about the first phase, which typically actually is not the first phase people do, but it’s the first phase that people like to forget, which is the strategy phase. In the strategy Phase I think there’s there’s two major work packages that you have to think about, and the first one is actually the hardest. Bring down to paper your strategy. What is your intent? Why you’re implementing this tool? What’s the vision that you have? What are the objectives that you want to accomplish with it? 

Think about the customer journeys that we just spoke about with your personas. Think about how do you measure your success. Right, so all these things, including what you bring to the table, you know which services do you have to stand up and to bring it back to the last episode –  which capabilities do you have to stand up with in your new project to make this thing happen? And I highly, highly recommend to bring this to a virtual piece of paper. Ideally, if you already have chosen a tool in the tool of your choice so that everybody can look at it and you can discuss it, it can agree on.

J-M: So we’re laying out vision, the services, objectives, journeys, kepis, and that’s what I’m hearing.

Roland: Yeah exactly.

J-M: And it’s on a virtual canvas that you can collaborate on.

Roland: Exactly that, the second thing in that strategy phase that he should think about is how does your program fit into the landscape of all the other programs that are going on. You’re not an island, and I’ve seen, unfortunately, the projects that failed. Having that insular perspective.

So think about what do you need from other programs? What do you need from other systems that they might maintain, and what their release schedule is, but also think about what you bring to the table for them. To avoid rework and redundancies,

The follow up of this is obviously than to have a look at their schedules and their releases, which then has an impact on your release plan. And by the way, if you haven’t thought about this, I highly recommend to think about implementing your program in releases, and it doesn’t actually matter so much if you have a time based release plan, like every three months, six months. I have a new release and we adjust the scope and the features and all that stuff accordingly. Or if you have a feature driven release plan. The important thing is that you have a release plan and that you can communicate those releases to your users so that they know what to expect.

J-M: And it’s almost sounds like you’re doing like project portfolio management for your project portfolio management platforms and architecture platforms.

Roland: Or or to say it. In other words, I think it’s more around product management., 

J-M: ’cause what is a product you’re creating right?

Roland: Yeah, exactly because you bring something into the world and. Obviously you need to say OK, this is what you can do first. This is what you can do next, and so on and so forth. And if you’re transparent with that, your users and your stakeholders will obviously give you a lot of feedback.

So that’s the second thing as part of the strategy phase that you should think about. Once you’ve done this, and obviously you’ll socialize this with your stakeholders and their objectives and their agendas and their needs and what not. The second step is looking at how you measure your success.

Remember that in the first work packages that yeah, look at you objectives and your KPIs. This is basically bringing this into life. So look at means of measuring and communicating your success. That could be dashboards that could be regular reports that you need to hopefully automatically pull from your tool and bring to status meetings and so on, but the main idea behind this is to create transparency

To say yeah, not only This Is Us, This is why we’re here. This is what we’re doing, but also to be able to communicate this and say Yep, that’s our plan going forward.

J-M: And this is something you might be able to already crib from your value proposition or the business case by which you justified the implementation of the platform right? Or the different projects that you’re going to interact with. I mean, the value statements you previously claimed or you made, are going to translate to the thresholds and KPIs that you see on these dashboards and the executives you pitched are the ones who are likely going to be checking back on the goal achievement, right?

Roland: Yeah, having said that, you will see and you will be surprised how your objectives change, because once you’re part of the big team of all the other programs that are out there and they realize that you are for real, then they will come out with their demands.

So be prepared that your objectives might change and this is not a one and done exercise that you have. So keep all that stuff that you captured. Vision, services, objectives, KPIs and so on. Keep that as a living document and be prepared to switch course. Be agile with a lowercase A, Be agile and repair to change things and obviously than in the second work package of the strategy phase adjust your measuring, adjust your dashboards, adjust your reports as needed.

J-M: And as you said before, if you’re planning for releases, you know when you plan to do an iterative role at a functionality, it means that as things change, you can correct course rather than thinking of the one Big Bang approach where everybody’s got to get their little concern and complaint, and their special special like allowances in this one big release iterative releases seems like it’s a way of keeping things going as more people get on board.

Roland: Agreed, so the second phase or the second big step is the whole approach is actually what I typically see as the first step.

Unfortunately, in the ones where the projects that are not as well executed. It’s oh, some nerds want to have a new toy, so they buy a piece of software and now they’re thinking about, OK, what do I have to do? You know, and all these things so? The technology, even though it’s important and we will cover a full episode about what to think about when choosing your right tool. The platform that you use. The technology is a means to accomplish something which by now you obviously have covered in your strategy. But in this phase here the technology fails. You basically looking at four different aspects. The first one is the tool selection, right? If you don’t have one. So what do you have to look for? And like? I just said a minute ago we will have more details on that in the next episode. The second step in here is to get your text setup correct, right? So for example, do you have a local rollout, right? Everybody has a tool on their machines. Do you have a central rollout? Or if you have a central rollout, well, how do people log in? Is it the LDAP connection? Do they have their own user board and password?

How do you set up an email server so that you can send out notifications and so on and so forth? So all that technical thing that some people thrive in and most people despise. But you want to have that set up correctly.

J-M: Yeah, and I suppose I suspect if you get your requirements documents out there earlier, you have your strategy connected to it more clearly than your IT partners who will be end up end up being responsible are better informed and better ready to do what you need to get the technology actually working the way that you want. You don’t ever want to to run into technology issues when you’re trying to implement a strategy.

Roland: Agreed, but it’s just like I said in the last episode, you know, for a business user, getting requirements right is a hard thing. So it’s not that easy. Which brings us to the next point, which is looking at what I’d like to call the technical governance of your tool. So let me take a step back. A good process tool, or a good architecture tool will have something like a method being built in.

The method basically describes what you can capture in your tool. Is it applications? Is it technology? Is it processes? It rolls, risks, whatever? You need to understand in a first step what these things are. So what’s your objective is to create, say, an enterprise process repository or to rationalize your application landscape. Well, the first thing is to understand what are the things that you have to think about. What is a process? What is an application? What is a risk? So what, I highly recommend to do here, and I’ve written an article about this whole thing on whatsyourbaseline.com, is to create a data model.

And once you’ve defined these things well, then the next step is to say how do these things relate to each other, or to say it in a little bit more architect way? What’s the meta model? And basically, in a nutshell, the meta model – if you think about a matrix, you have different levels of abstractions, right? Think about a process hierarchy, the level one is obviously the 10 processes high level one processes that an organization does. And then you decompose those processes on multiple levels so that the lowest level you’re on – that who-does-what-when-where level. And define those levels. 

And then the second step is look at the different views that you have to create. We spoke about TOGAF the other day, so think about for example, what is in your strategy view, products, strategies, objectives, these type of things.

What is in your business architecture, processes, roles, risks, these type of things and so on. So what you do now is you map out a matrix where view and and level intersect. And in the meta model you basically go and say on each intersection I do have an artifact.

Like when we think about processes you have maybe 3 levels of value chains or value chain diagrams that you have to map out and then on the 4th level the who does what, when, where you go and have a BPMN diagram.

But you also do then is obviously in your meta model, which I highly recommend to do in. the tool is to then : OK, what’s in that level one process model? Oh, I have value chain objects, the chevrons, that’s great. Are they connected or do they stand by themselves? Do you allow users to drill down, or do you intend to do something else? Do you want to build a hierarchy? So all those things when you go through your meta model, you have a really large diagram, but it helps a lot to communicate.

J-M: There’s another aspect I want to talk about here as well, because meta model is really important in both a hierarchical fashion and the relationships with which they have. Also, of course, attribution to provide additional details on all of those things, but there’s another component to this. We talk about a lot, which is conventions which we’re going to get into it in subsequent episode.

But those conventions help establish the common visualizations, essentially your canonical language that you were talking with pictures to each other using, and remember that, as much as a metamodel is important, being able to harmonize the way in which people see things is going to make it so there’s the ones they have lower barrier to entry, particularly for those personas like viewers or reviewers or governance. People just make it so that it’s easier for them to add a glance, understand what they’re seeing on the page without having to be a detailed sort of consumer of the specialized knowledge that’s restricted to the tool set. If it looks like an objective object, it should be something that they understand. It looks like a person object. Something that they understand, and using the organizations predispositions or existing methodologies and visualizations as a starting point is great. Sure, maybe you  want to evolve them, but making it feel familiar makes it easier to access.

Roland: Agreed, agreed. Even though there’s a step in between. So, just to recap, I would start with the data model. I would then create the meta model and within the meta model you obviously then would, and that’s the third step in between, you would use that to configure your tool to say “OK. What are the model types that I need? What are the object types? What are the connection types in all these things?” And obviously also what’s the layout that typically is captured in something like a template. And then the 4th step is what you just said. You need to write it down. You need to have a Bible where people can go to and say hey if I don’t know what to do, what is expected from me? How does good look like? What is the artifact that I shall create? 

The last step in the technology face is identifying where to get data from. What are the other systems of record? Because one thing that I would avoid doing is trying to duplicate information that other programs already create. So if you have, say, a GRC implementation, you know the Metric Streams and Archers of the world. I think it does not make sense to recreate a separate risk catalog or controls catalog in your architecture tool. The better way of doing this is to create an interface to those other tools, who are the system of record, and then just ingest them and a good architecture to as we will talk about in the next episode will allow you to create those interfaces that you then automatically can run – maybe once a week or daily depending on how you define your governance – and that brings that stuff in.

J-M: So I would like to say that we don’t ever want to necessarily be the source of truth for everything, but we want to be the connective tissue that helps to bring together the sources of truth. And by providing that context in relationship, we’re able to emerge out insights, decisions, and visibility for all of our stakeholders. Once again going back to that persona thing, we want everyone to see what they need to see, where it’s convenient for them to bring it together.

Roland: Yeah, I typically like to call this the hub. Because the stakeholders you viewers right, they typically don’t go into those specialized tools. They don’t go into your CMDB to look up what the attributes of that application XYZ is.

J-M: Can you imagine? They don’t want to do that!

Roland: So, but what I notice is that business people respond very well on diagrams. They respond very well by drilling down into hierarchies or navigating left and right horizontally. So what your tool your architecture tool will become is the hub of that information, and I think this is a role where you want to be.

But to come back to creating those interfaces. The typical way how you do this is you create scripts and you have some form of exchange format and you do some kind of batch processing. And that can be relatively complex if you think about and I had that in one project where we had like 50,000 risks that needed to be imported and then a week later that script needed to compare where what has changed? So Archer just spit out the current state and then the logic in the script was to say, Yep, we have a risk and it has these ten attributes and now you go in and say has that attribute changed? Yes, no. If yes, change it? If no, move on. or was it deleted? The question is do you want to delete it in your architecture database? Most likely not. So you need to flag it so that a user can look at it and say, Yep, I agree, you know we have those ten occurrences of this object, but it should go.

So these type of things. So build those interfaces and also think about building dashboards for your technical folks right? To see if you have those batches you want to know because it can take awhile. You want to know at which step in that import process are you? You want to be alerted if the import just failed and that’s all of the things when we talk in the next step about automation about governance to do this. 

But to recap, in the technology phase you typically see four things. You select your tool, you get your tech setup. You define your technical governance and you identify and create interfaces to other systems so that you can become the hub of that information.

J-M: And all these things would normally be contained within a technical implementation plan like a project methodology that would include these steps as all their stakeholders and all their associated systems and things like that. Would you agree and see that in the organizations you’ve worked with?

Roland: In the goods projects, yes. In in most projects, no. Because most people go and they say yeah, I want to have a tool. Then they go window shopping, like I said the other episode, and they choose one and then they’re asking the professional services guy “bring it in but then go away.” I’ve worked in projects that did not do things like the strategy phase and of course, as to be expected a year or two down the road, it fell on their feet. So yeah, this is why I said before I think about the enterprise perspective. Even though you might just implement it for a little group.

J-M: Welcome to What’s Your Baseline. The podcast where we tell you maybe you’ve been doing it just a little bit wrong, but let’s make it. Let’s make it work a little bit better the next time. And you talk a lot about governance. I’ve heard you say that word a lot and it’s I feel like it’s a really important part of a sustained and sustainable ecosystem. Talk to me about governance in this context.

Roland: Yeah, so governance. Even though it has a bad reputation when you think about enterprise architects who live in their ivory tower and then they pick the ARB, became the committee of NO, instead of being the committee of KNOW

J-M: Yeah, yeah. That’s a good phrase. I like that.

Roland: I’ve seen that with clients who just fired their enterprise architects because they just were sitting there and said: “No. We set up the rules.” And they actually did good work, but they were not able to communicate it. Governance is important, but it’s not the most important point, but it’s a big block in your implementation.

So we spoke about strategy. We spoke about technology. The next step that I’d like to talk about is the governance. And within the governance you basically think about the people and what they’re supposed to do.

So the first work package in this section would be to define the process is what do you expect the different personas to do and J-M gave a couple of examples of personas But it’s what I like to do is to create a big value chain diagram and just put the chevrons on that virtual piece of paper and say what do I have? Oh yeah, there’s a Chevron that says create model. There’s a Chevron that says approved model. There’s a Chevron that says import from existing sources. There’s a Chevron that says or maybe multiple that describe how those interfaces work. So the idea is to get that high level picture. Align this to your personas, right? If one of your persona is the designer, where what we ask them to do? If one of your personas is somebody like a release manager? What is that role to do? 

J-M: And this is still the inside out perspective. Now like this is now us saying what do we need rather than what do you see. We will eventually get back to what they see. But right now, we need to from a governance perspective, we need to lay the ground rules.

Roland: It is, and this is where the homework that you did while thinking about your personas comes back in because what you do is you transfer those personas into roles, right that you have job descriptions for and whatnot and your persona will help you to define that job, that position in a certain way that it is enlightening for people, that they have fun doing their work and that they feel valued as you’ve mapped out in your outside in process. 

So first thing that I typically do is create that high level value chain and then the second step is I go in and create BPMN models underneath. Plain old vanilla, you know? What are their roles in swimlanes? What are applications that are used and define the steps, and this is where obviously your tools capabilities come in, and once you’ve mapped it out you will see maybe your tool doesn’t do certain things and you might have a gap. So you might have missed something in your selection tool selection process, so you do those and within that you will then see the different people and how the overall process is fit. 

Then in your SDLC in your scaled agile process and whatnot. So my recommendation here is to bring in all the other groups that you intervene with or you touch base with and then have them say how you interact.

J-M: Swimlane models, in general tend to show this particularly well, because the thing that I’m most concerned about at this moment besides some of the technology components, is handoffs, because I need to be able to train my people and show them where they need to communicate information to others. I mean I feel like it’s very easy to think about like a subprocess of I do step ABCDE, and then I’m done, but the hard things, and where I think a lot of these analysis part of it fails, is when I do ABC. And you do CDE and then I do F. Then you do G and those handoffs.

That’s where things get dropped in production. So if we think about that early, and particularly diagramming and BPMN or another swim lane format is really good for showing where that happens, highlighting it to you to include in training material or in technical configurations and things like that. That will help to reduce the burden of that.

Roland: So as you might have expected, I have a slightly different twist at it, but we’re going to talk about it in the episode when we talk about notations, but I wholeheartedly agree with what you just said about you need to agree on the handovers. You need to agree and understand what is the end to end process that that you go through. But once you’ve done your processes, the next step is that he would go and define your organizational governance, and that is now you have your swim lanes. Now you know the roles where you would have to have a deeper look on those. One might think about what are the permissions that a role must have to do their job.  The other thing is when you look at your processes. Now that you’ve recorded them, you might want to think about how do I embed those roles? When you when you think about a process architect or business architect where that’s mostly not the guy who runs your center of excellence. Or your ARB.

So think about in which organizational context you put in your roles, in which, quote u,nquote org units, you need to define like an architectural review board or a Coe? Or if you go into an organizational model, like the Spotify model – with what are you guilds, for example.

And then the next step is once you’ve defined it and you socialize it with your stakeholders. Well, then you obviously need to set them up and when you set up those organizations, my recommendation is have a super light hand touch on it so to come back to. For example, the ARB, the Committee of know. Most organizations that I’ve seen it, they brought in ARBs and they were just basically in the gateway to get approval to move on to the next phase in your project. And they said, well, what you showed us doesn’t adhere to the technical standards that we’ve defined and whatnot. So go back to the drawing board, or they plainly killed the project. That’s not helpful. The better implementations of this are a very light touch, and I did this with one customer where we defined four different levels and we said, OK, we bring in ARB in the first phase. It’s just a communication platform. Let’s meet on a regular basis. Let’s bring in the projects that implement something and let them educate us on what they’re doing. And then the next step would be to say, OK, we hear what you do. How can we help you? You know, give some guidance, give some reference architectures, give some architectural runway, how the SAFe guys would call it and make their life easier. And then maybe at a later point in time, yeah, you might want to bring in some decision powers to that board.

J-M: Yeah, because you want to socialize it slowly, right? You don’t want to get them. You want to come down hard with the requirements that they have to follow. They’re going to find a way around this time and date is never going to get organizational acceptance.

Roland: Yeah, you want them to see yourself as as the helpers. The ARB in this example is there to make their life easier. It’s not to put another burden on their project.

But why you’re doing that? Obviously you have to think about things like who’s going to be in these groups, right? How often do you meet? What’s the the stuff that people should bring when they present their projects? For example, in an ARB, do you go and force them to do what you’ve defined in your technical governance on day one? “You know, you must bring your application landscape and you must bring your data model and we expect this format blah blah blah.” At the beginning you might not. So you might want to stay even in those requirements on a very high level. And even though I’m not a big fan, you might say put it on a slide and talk us through. 

And then at a later point in time when the maturity grows then you would go and say now we move on, show me in the tool, show me the dependencies between your technology to your applications to your data to your processes. But it takes time and it takes trust because otherwise people will just try to avoid you.

J-M: Implementing a tool set, implementing a technology, implementing a capability at an organization isn’t just a technical exercise It’s not just a response machine: I have a need. I do a thing. I have a need. I do a thing. Not only is there strategy, not only is there technical enablement, there’s also governance and control. And that is a consultative approach. There is consulting strategy that goes into this and that could be internal resources taking up the realm or the reins of this kind of thing. Or it could be working with external partners as high as folks have done this before to help ensure that you have all these pieces in place, so that when you do go live, you’ve thought of all the things you need to think about your technically enabled, and you’ve got the organization in place to support ongoing.

Roland: Yeah, and it’s always a good idea to bring somebody in who’s been there before. For sure that helps. Yeah, but I, I agree, I agree. And when we will talk about the tool selection or in a future episode, we might want to talk about maturity. I typically bring in the concept of Venn diagram that has three circles.

The first one is – without going too far away here – the first one is the content. What do you want to do with your tool? The second one is the governance. How do you run the show and the third one which most people like to forget i’s the people side, the adoption. You know. How do I make that happen? And this is obviously when we talk about the organizational governance. Is obviously a big issue.

J-M: Yeah I it’s funny. I worked at a major utilities company and what we did was we interface daily with the change management team and they played a huge role in the success. Not only were they an external consulting body that was helping to socialize what was going on, they were also gathering feedback and be in playing sort of the intermediary between these different organizational units affected by these changes and as a result of that there was a lot more open communication and that open communication led to the governance and standards being implemented and actually accepted by our partners so it wasn’t ever having to force down anyone’s throat. It became part of in standardized as part of the way of life. The working way of working sort of right off the bat and change management. Great to interface with.

Roland: Yeah, interesting that you say external. I hope it was not an external consultancy who did this. I hope it was external to the project.

J-M: External to the project. Internal people, but external to the project. You want a little bit of distance, but you also want to keep it in the house.

Roland: But you basically hide at the last step in the governance part, right? You need to think about or change management. Think about what other training needs which now is super easy. You know the roles you have, the individual steps that somebody’s role needs to do because you map them out in the process is, you know the systems that your roles do. You know the specific functionalities that they do – should run a semantic check or export this. You already have that information covered, so now taking that information and do a flip side of it and say what’s my curriculum is a relatively easy exercise. And then once you have this, you would obviously bring in with your change people the decision to say hey, how do we teach people this? How do we enable them? Is it just classroom training? Is it online? Which support things? Do you have to set up like forums or open hours and whatnot?

J-M: And there are some platforms out there. I know for instance SAP Enable Now that are already ready to ingest process design content. So the things you’re doing in those earlier work packages phases and turn them into sort of ready to pre package and send out training material and that kind of approach is what you’re looking for across what you’re doing, not just at the tool level, but you’re looking for that across the whole practice level. Because that’s what you’re doing, you’re really implementing a new practice. Any tool is a catalyst for that.

Roland: Yeah, agreed, agreed and the other side of that coin is you obviously need to talk about communication. So when I said that the strategy is your first place, guess what you want to have an org change management person at the table to help defining the strategy and bring that personal aspect in because it doesn’t matter how many wallpaper, how much wallpaper with processes you put on your wall, or how many black boxes do you put in your basement that run your tool. If the person sitting in front of the computer doesn’t want to do it, they won’t. And that is the big challenge that you have to overcome. And this is why you want to have an org change management pro with a seat at the table.

J-M: I feel like organizational change management folks all have like a small amount of invested money in post-It notes because I’ve seen so many war rooms literally covered them like wallpaper. That’s a good starting point, but you mentioned earlier a digital canvas.

And digital canvas to bring these elements together. I mean that’s invaluable, because now you’re able to communicate across geographies across lines of business asynchronously with a perfect retention of information. And you know, that’s one piece of the content puzzle. I know we’ve got a bunch of stuff set up to make tomorrow work. What do we do by today?

Because, you know, we’re trying to implement a new way of doing things, but. The company’s been running for all these years. What do you do about that, Roland?

Roland: Yeah, you’re absolutely right. And that is the 4th point or the fourth major work package in your implementation. After strategy, after technology, after governance, it’s basically bring in the existing content that exists out there. That obviously exists in various formats in various states of currency and it is a challenge. So the first thing that I would do is I would sit together with your stakeholders, with the owners, with the org unit leads that you interface with and would create a content overview.

It’s a big table of content, or a big library to say. Yep, we have those 5,000 processes that need to come in and that overview should include the formats that should include the owners or context people. It should include topics. You know how to structure it going on and so on and so forth.

J-M: Yeah, but I don’t want to spoil the surprise ’cause we got a whole episode dedicated to this topic rolling, but I do the one thing I do want to say is that acknowledging other people’s existing work, the effort that’s gone into the ongoing maintenance of your organization. That’s really important..

Remember that these are all people who have invested careers they’ve invested years in trying to make this place work. So we want to acknowledge what they’ve done so far and then give them a new path forward, something that makes them makes their job, that they spending all this time on a little easier and a little bit more transportable and ultimately a higher impact to the organization and so. Say hey, we love what you got, but let’s move on together and make something new. 

Well, I want to ask a question to the audience now as we take a quick break and talk about the implementations that they’ve been part of. You know, think about when last time you were part of a platform implementation or any sort of new process implementation. What was the process you followed? Did you go through all of those four areas? We talked about the strategy, technology, governance and existing content import and harmonization? Or did you miss one? Or did you add something that we hadn’t thought of? We will take a quick break for you to think through? Sort of review in your mind what you’ve been doing, and we’ll be back with a conclusion and the end of the episode.

J-M: Alright, so I was thinking back during the break about one of the implementations that I was part of and I remember being called in and there was nothing. No strategy and no organization around it. They just said I want to make this work. Bought a tool with a credit card and what do you know. The technical setup was a mess because I never thought about the requirements and ultimately nobody ended up wanting to use it because they didn’t identify personas and they had no organization structure to make it happen. And I remember sitting there in helping to figure out how do we come back from here. And the answer was, we need to start again because we never really started. But I think we can avoid that. 

And I think listening, folks, in listening to this podcast and getting some of these lessons will set you up for success, not figuring out 3/4 of the way through that you’ve already failed role and tell me about something where you really succeeded on this on this front.

Roland: I wish I could tell you that happy case story to say yes, they just follow Roland’s advice and they did everything correctly. Unfortunately, that’s never the case on this, so just be prepared to be agile, lowercase a, to be agile in adjust things. 

What this episode should have helped you is to have a mental structure that you go through, right? So when you think about what we spoke about, it’s the outside in perspective for your personas. Versus then flipping it and have an inside out perspective. What do we have to do to build up the capability when implementing the tool and then thinking about that this should be implemented like an enterprise tool and not just the simple small group drawing tool that you want and then follow the process, right? The four phases that we spoke about: strategy, governance, technology and the import of existing content. And then overall, have an open perspective when doing your release plan, when defining your future releases so that you can get all new requirements that other groups might have, that they haven’t even thought about before interacting with you, can be brought in.

J-M: Yeah, I’m hearing the idea of listening a lot to people listening, getting feedback involving folks. And that leads us to the conclusion of today’s episode. To thank all of you for listening to us. We love what we do and we love helping organizations and people get better at doing what they do. And so thank you for being part of the What’s Your Baseline experience. 

Now, you can reach out to us and help us listen to you via email or through voice message on platforms like Anchor or through whatever your feedback mechanism of choice is. Please leave us ratings on your podcaster of choice. And of course you can leave reviews if you have a particular feeling about what we’ve been doing and you’ll see the show notes and lots. More details and articles by some of the best in the world at whatsyourbaseline.com and of course the short notes for this episode on wtsyourbaseline.com/episode3.

Thanks so much for tuning in today. This has been the What’s Your baseline podcast. I’m J-M Erlendson.

Roland: And I’m Roland Woldt.

J-M: And we’ll see you in the next one.