Automation in Sweco: Scaling the Adoption of Dynamo

JOSTEIN BERGER OLSEN: Hi, and welcome to all of you. So scaling automation, that's today's topic. In order to hold anything up, you know, a building, a bridge, a company, you need pillars, something to rely on.

And in my company, there's four. Four pillars. Four pillars of, well, operational excellence, if you wish. And once I could talk to great lengths about all of them, or I want to highlight one of them here today for you, because it is so [AUDIO OUT] and to all the things I'm going to talk about.

And the one I'm referring to is this one. Decentral. One of the pillars of my company is to be decentral. It is the key to our existence, even. The reason, stripped down to its essence, is because then we're close to our customers. That's essentially how we make money, and thus continue to drive, and drive the world forward.

Another pillar that I will mention is the internal efficiency one. We want to be efficient at what we do. So really, those two pillars combined, of course, with the others as well, but those two, in particular, sets the stage for today's topic. How the heck do we scale automation in a decentralized organization?

So what organization are [AUDIO OUT] you say? And it's this one, Sweco. And [AUDIO OUT] that we are Europe's leading architecture and engineering company. And if you're interested in this kind of stuff, I can mention that we are well above 17,000 employees right now.

We earn money. That's good. And now, to my horror, I see that the bottom right figure might be mistaken, actually. We do, in fact, have more than 70 plus projects. What it means to tell is that we have projects in more than 70 markets. It's quite a difference. Well, anyways.

Basically, we're all over northern parts of Europe. The one speaking to you right now, from the abyss of recorded online conferencing, works at that company, and that someone is me, Jostein Berger Olsen call me Justin if the Norwegian pronunciation is a bit hard on your tongue.

But I've been in the industry for 13 years in AI capacity. I work with infrastructure stuff, big plans, skate parks and Revit. Yeah, usually I'm describing myself as a potato. Not particularly good on my own, but goes OK with a lot of stuff. Or jack of all trades. Sorry for that one.

And by that, I also participated in some of our strategic initiatives on digitalization over the last year or so. So don't write me off entirely rhetorically for not having executive manager in my title there. Basically, I've been around for a while, and I think I have some insights on many levels In my organization, and hopefully some of that can be of use to you watching this, wherever you see it, and what time you're watching this.

So that was my decentral organization and myself. So I was thinking to myself, given this subject, Automation in Sweco, Scaling the Adoption of Dynamo, what could I possibly say about this in half an hour or so that would actually give people something without boring them half to death?

And the two things I ended up with were these. We're going to go a little high. We're going to go a little low. First, we're going to have a look at some, well, basically strategic tips and tricks. I don't want to share too much of course, given that our competitors are going to watch this probably, but I'll try to give some advice on the strategic level about scaling automation, again, in a decentralized organization like mine.

And then what I'm going to spend also some time on is to dive down again in one of the tactical implementations that we've done over the last year or so together with Autodesk. So hopefully, there will be something for everyone here. We'll see.

All right. So first up, some tips and tricks. Some tips and tricks when it comes to strategy, the subject matter, scaling and automation. The first tip I want to come with is to have a proper mandate. It's barely even a tip. It's so cliche.

But I cannot stress this enough, how important it is to have a proper mandate, an actual mandate for implementing automation, or really any kind of digital initiatives at scale. And this is especially true in decentral organizations like Sweco, where a lot of power sits out in the different business areas.

So if you want to succeed on heightening automation, and other digital initiatives in your organizations, you will have to have this designated mandate. And if this is treated, by experience, likely by the C-level executives, I promise you it will fail.

You need clear mandates, allocated resources, and paint a clear picture for everyone how things are going to be governed. And this sounds really easy, but it is extremely hard to implement. And the thing is that without it, you will lose a lot less-- you will have a lot less forward momentum on this.

So that's one of the first things to really get in order when dealing with scaling automation, is to establish this mandate, and go for that mandate, and really clarify that before pretty much doing anything else. And this is something [AUDIO OUT] had a group-wide initiative for how probably mandates digital initiatives like this one across all the business areas.

The second tip I want to give is don't underestimate the power of communities, or don't underestimate communities. Or rather, horizontal alignment, if you want to use that kind of management talk, if you wish. So in a decentral organization like ours, there is always at least three forces or vectors, if you wish, working on any given employee or team or business area, et cetera. Represented here by the black dot, you can see in the right-hand picture there.

The first force or vector pulling on people, you know, that's always pulling on people's attention, that's the vertical vector. The management up ahead of you. The responsibility is that you or the team have to the chain of command. Economy reporting, control oriented stuff, all of that. Yeah, I need you [INAUDIBLE] now, you know that drill probably.

The second force or vector pulling on people in the organization, which I think is the biggest one in, at least in a AC consultancy, that's the external vector. Our obligations to external clients, our projects, et cetera. And the last one is where we can really get value out of being a big company, a big organization. And that's a horizontal alignment to our organization, to other business areas, to other teams, to other colleagues, and so on.

Now, usually what happens is that that external vector you see right here drags us away from doing any internal work cross-border or cross-BA, right? Because it basically hurts our billable time. And here, if you spend some centralized hard earned overhead money building communities that focuses that internal vector, that blue one, as you can see, it will improve business.

Even if you flip it, the costs of not knowing is so immense. Like if we take design technology, and just as a small part of this, like who can I ask about Dynamo in my company of 17,000 employees? Where can I find template files? Who can I ask when stuff really hits the fan, to put it nicely.

So this internal vector, with some central fertilizing, it's really going to make a change, in my mind. And one quick example of that is the bridge project that we did here in Norway called [INAUDIBLE] Bridge, by my fantastic colleagues.

It started almost out of the blue. So some colleagues of mine got some resources to get together across the border and be nerdy, even, you know, doing visual programming. And that was funded by the organization, a little fertilizing there. And later this start event spurred on a community of like-minded people. And then that team later ended up with designing this bridge, using all of that shared knowledge.

And the project won multiple awards for being innovative. A lot of responses, a lot of PR online, and other places as well for the project, and for all the stakeholders. So this was a win-win for everyone, right? And this happens just because someone in charge spend a little fertilizing money on it early on, on building a community.

And who knows, imagine if they got to know from their line managers or the organization there instead? Maybe it would have happened the same way, but most probably not, right? So don't underestimate communities and that inward vector in companies. It's a really important part of building good organizations, in my mind.

So the next step is a little bit different. It's more a way for categorizing different initiatives and how to govern them, in a way. Both for scaling automation, but also other digital initiatives, if you wish. And it is a four-part approach.

So in this case, let us take design automation as a case here now, since most of you are familiar with that ecosystem already. So I'm not going to talk about automation initiatives on travel expense, management systems, or stuff like that right now. But more automation within that design ecosystem, if that makes sense. Hopefully it does.

So starting at the bottom there, with the foundation. In order to scale automation, it is essential that you have a good foundation. We cannot build all our tools as engineers and architects from scratch. We need a vetted and solid portfolio of software platforms that can serve as a basis for both our revenue, but also for spurring other automation initiatives.

And this means having licensing agreements in place with all of this. You need your Office packages, Office 365, and stuff like that. Other back Office systems, maybe. Even having templates in place for all of you. Yeah, et cetera.

And this is traditionally an IT responsibility, right? So once you have that in place, you can sort of build on top of that, where maybe the first level, which is basically tactical automation workflows. And given our context, that can be Dynamo. That can be Grasshopper, Python, Power Automate, stuff like that.

Automation workflows, that sits right in our projects. So for instance, using Dynamo to automate sheet creation in Revit, right? The point is it is tactical. It's highly bespoke and customized to the projects. We could build a big system for dealing with Dynamo scripts, and so on.

But in our experience, the real value, where a central organization can get the most in return investment is by focusing on building communities, provide a toolbox for those communities, and also do metrics of that community to sort of measure the buzz in the community, and also report maybe back KPIs to the mandating body, in this case. I'll show you an example of this later.

There reason for this is that maintaining a centralized approach to maintaining all of these scripts, and making sure it's quality checked, it's very resource intensive. I'm not saying it's wrong. But on this level, things will always shift around. So if an automation initiative is recognized to be on this level, we should focus on developing thriving community that freely shares with each other, making sure they have the resources to do so.

And of course, you know, again backed in a real solid mandate, to make sure that we always know what kind of tools we should prioritize, what should we focus on, and so on, across all the different business areas.

The second level box or developed software initiatives. Well, one example in this particular context could be adding some Revit, you know, more proper automation tools maybe. And on this level, it is also important with communities and stuff like on level 1, but we also need this additional layer of professionalism when it comes to developing software.

We need testing. We need proper debugging tools. We need to have repositories, deployment strategies, all of that. The reason is is that this level scales beyond level 1, and will probably be used by more people. So also from a risk mitigation perspective, it's also necessary to, as much as possible, avoid personal dependencies.

Meaning that Frank, who sits in the technical services team in Norway, and built this amazing rock validation tool in C sharp from scratch, he should have a proper governance model in place so that his code his traceable, the code is centralized, and [? repoed ?] and quality assurance.

So that if Frank [AUDIO OUT] we still have the code base available and possible to maintain for others. And we don't lose knowledge that easy as we have done in the past. So that, essentially, initiatives on this level require you as a company to really commit. And to me, that's really a strategic decision.

Do you, as a non-software company, want to deal with this kind of work? If yes, have the guts to build a proper dev environment. Otherwise, buy this from somewhere else. And just my two cents, I think if you don't do this as a AC company in 10 years time, I think you will find the world a really hard place to be, to be honest.

And Additionally, it will make you more prepped for actually buying software from third parties in the future as well, because you have the necessary procurement competency. So, you know, yeah.

The third level [AUDIO OUT] briefly touch. But basically, it is initiatives that is on the forefront of innovation, and that will guide us into the future. We can represent new business models and new opportunities. Proves great marketing material, to be honest.

But again, even more risk, as well. So represented here in this picture by my colleague's work on a REST API system called Scala, something like high par for those of you who know what that is. But basically, a REST API system for connecting our highly siloed engineering approaches together. So that's the level three initiatives, and I think that's as much as I'll say about that subject.

So in short, what the mandating body, together with the C levels, should focus on is how do we choose to spend resources between all of these on digital initiatives. What kind of profile do we want? What kind of profile do we need? And again, this system may also be applied to other parts of the business, like well, I don't know, HR, for instance, maybe have a level 1 initiative to develop some awesome Excel tools for them, for [INAUDIBLE] That will help you out immensely.

And maybe even our software, stuff that we developed ourselves on level 2, where we've internally developed the travel expense system that I talked about, that I wouldn't say anything about, but I did. But that's like a level 2 initiatives. It's more proper software, if you wish. And so on.

So that was sort of the high flying stuff. Let's dive right into some tactical approaches, and so many of it. To kind of a tactical story on level 1. So basically, what happened was that we identified a wish in our organization to take a leap when it comes to Dynamo. We wanted to push that forward.

And Dynamo is very much a level 1 automation tool. So we were a bit short staffed internally to do it ourselves. So we made good use of the major account deal that we have with Autodesk, and got hold of Autodesk consulting.

More specifically, this wonderful human being up in the right corner here now, Raquel Bascones Recio, shoot me if the pronunciation is wrong, Raquel, but she was very helpful. She did training for us. She developed an extensive report, I would say, on governance models, template files, processes, and a lot of other stuff as well. I can't possibly get through all of this.

But Autodesk. I mean, Autodesk really did help us a lot. And we managed to get allocated some internal resources as well. Really tried to scale up the adoption of Dynamo in Sweco.

So what we focused on was exactly the same as I showed you previously. So on this level, level 1, we wanted to go for a community building with training, and sort of a platform for doing this community building on. We needed metrics in place to assess both the community itself, but also measure KPIs and so on, to follow up the mandate on this.

And lastly, we also built a toolbox on top of the platform to help our decentralized company build a community around this, around Dynamo, which is one of the-- well, one of the most important automation tools, given our portfolio of softwares.

So first off, we did some training sessions in some of our countries, because they wanted to upskill themselves. Again, building communities. And Autodesk with Raquel spearheading did that for us. It went really well, despite the pandemic. I think everyone was quite happy with how it turned out.

And this is a great example on we used Autodesk consulting right, and where it makes someone use that capability, because we can keep our best Dynamo people and production, and we can also, while doing that, we can also educate newcomers. So that was a brilliant use of the agreement we have in Autodesk.

The next thing we did was to basically build a platform to make it as easy as possible to build that community that we speak about. So what we landed on was Teams in combination with SharePoint. This was, of course, one of many options.

But, you know, we landed on this partly because it's there. Everyone has immediate access to it. There's no third-party vendor or platform involved, et cetera. And also, because we have that level 2 competence for building new capabilities on top of this system, so yeah.

But you know, it covers a lot of ground for a community forum to ask now, we can look up documents on the [AUDIO OUT] So that provides a great platform for us.

Moving on to metrics. And also, I guess, on the more technical side. We used some internal components over in Finland. Again, level 2 capabilities. But we used them to build us a view extension in Dynamo, combined with, as you can see right here now, Power BI integration in Teams, SharePoint, that lets us track usage across all countries.

It should be noted, though, that the one you see on the screen here now is from the beta version. So just FYI. But essentially, it lets us keep track of the community, see where the competence is on the subject matter, et cetera, et cetera.

And I think without this, we wouldn't have any real possibilities to introduce KPIs on a later date, if we wanted to. Or if we want to, or decide to in the future. So this, essentially, makes everything more tangible across a decentral company.

And over to [AUDIO OUT] we credit some stuff as well, building on top of the platform like this template, as you can see, based on Autodesk's proposal. And the one thing that we can mention here is that you can see the text fields down here in the documentation side of things. We created, essentially, tags with these angular brackets, so that upon uploading this to SharePoint, we could convert all of this into metadata for simplifying, you know, automating all of this. So cool thing in my mind. Yeah.

And while it's not on the top of the priority list, we also built a central repository with scripts, so people can check that repo first if they are in dire need of something. So you can search for scripts. You can upload new ones or edit, and so on.

We also built a SharePoint UI on this. It's simple. But it really works. And it's great for having a place to look up, whilst this was not, again, not our top priority, because these things tends to be highly bespoke and adapted to the different projects, but at least we can see who's working with roads, and we can call them. So that's, again building that inward vector so to build these bonds together across [? BAs. ?] That's important.

We also built this request service, where you can actually request a script, and some of the super users will get this and describe if it's possible to do, or give some tender-ish hours on this. So yeah. So that was also included.

So closing in here now. But for future development on this level, we want to have a look, or we wish to include some of the things that we've already done for other level 1 tools. As you can see right here, that's right on Grasshopper.

Things like having a centrally upgraded packet manager, maybe, in order to make sure that we always have the latest and most up to date packages available to everyone, so they don't have to do that themselves. And maybe even develop our own packages, like we've done in Grasshopper. We've done that to some extent, but not across business areas and across countries. So maybe in the future.

All right. So with that, our time is unfortunately pretty much up. I tried to convey some ups and downs, I guess. I'd like to say thanks for watching this. It's really much appreciated. Kind of a prompt exit here, but half an hour is half an hour. I hope you found some of the stuff I've been talking about interesting. And as I've said countless times the last year or so, I sincerely hope to catch you live sometime in the not too distant future. So thanks for watching.