Standardizing Engineering Software in a Global Environment

ANDREW WHITEHEAD: So good afternoon, everybody. The door's closed, so I guess that means we're going to get started. Welcome and thank you for your interest in this class. I'm surprised to see so many people. I've lived and breathed this for so long it's just normal, so, yeah, nice to see so much interest. I'm Andrew Whitehead and joining me up front is Chris-- Chris Cann.

I want to start with diversity, culture of caring, and safety. They're very important values at Jacobs and part of our Beyond Zero culture. So I'll start with a brief Beyond Zero moment focusing on safety, but also touching a little bit on caring too.

Every hotel room contains an evacuation plan, usually attached to the inside of the door. They're all very different. Some are simple and easy to follow and some are way more complex and detailed than others. Most of us travel with business, all of us staying at this-- at hotels this week, I'm guessing.

So do you know your exit route? Have you looked at the plan and were you able to understand it? Have you worked your exit routes? It's always my first activity when I check in to familiarize myself with my new surroundings. So do you know where you'll end up if you follow those routes? Many times the final emergency door is locked if-- for emergency uses only and alarmed. So although you're out of the building, you don't quite know where you are. In an emergency be prepared to help others. Many people in hotels aren't traveling on business, they're relaxed and they're not as safety aware as perhaps we are.

I'll share with you a couple of experiences. I stayed in a hotel in Glasgow some years ago and it was an unfamiliar hotel, so I followed all of the escape signs to map my route. I ended up in the kitchen, in the basement, in the center of the building. So had I followed those signs in an emergency, I think I'd have been in a mess. Through our safety observation report system within Jacobs, we were able to work with the hotel to correct the signage.

I also remember an incident in a Manchester hotel. I'd been coming down from the top floor all the way to the ground floor and it stopped on every single floor. Right at the last floor an old couple got in and somebody uttered under their breath-- I don't remember it being me-- something about them not using the stairs just for one floor. And they replied that they didn't know where the stairs were. So I made it my responsibility to show them where the stairs were and how they would get out in case of emergency.

And then another experience I had with a 3:00 AM alarm. There's an unfamiliar sound, a horrible siren, flashing lights, and everything, it's quite confusing and disorientating. So as I threw some clothes on and found my way out of my room, there's just people peering through partially open doors asking what to do. Do I leave? So, yeah, you do leave and you show them the way out because most of the people don't know. So essentially know your surroundings, know your escape plan, stay safe always, not just while you're traveling on company time.

So the JSW Project, the Jacobs Standard Workflow Project, is one of eight projects which make up a portfolio to transform the core of Jacobs. Integrated Project Control Systems, IPCS, our business management system, Jacobs Standard Workflows-- the topic of this class-- technical talent engine, global integrated delivery, workforce planning, estimating and benchmarking, and global business services. Transforming the core of Jacobs would ultimately improve project delivery, sales effectiveness, and deliver business excellence. Project delivery efficiency improved through standardized processes, increase our ability to connect globally, provide greater staff mobility and career opportunities, and it also gives Jacobs a vehicle to divine-- define and develop best practices globally.

So as we started out on this process, Jacobs was a company of around 60,000 people-- multiple lines of business spanning many global markets, very diverse organization with the ability to deliver the full package. Growth is a core value at Jacobs. We've grown steadily over the years through acquisition to increase our project delivery capability. Due diligence with each acquisition identifies best practices to be adopted by the new larger organization.

But we haven't always been the best at retiring those other practices post-integration, resulting in a duplication over time-- many different ways of doing the same thing. As the company has grown, pockets of innovative practice have popped up all over the place. These are often quite localized, specific to a market, office location, or a region-- some resulting in incredibly successful outcomes. But because they were developed in isolation and not effectively shared with the wider organization, this significantly limits our ability to leverage best practice globally.

Again, with software, similar to the above. Local preferences on software titles and versions resulted in many tools to perform the same functions and where used in isolated pockets often requiring specific, local knowledge for support-- difficult to facilitate global integrated delivery. The teams in our high value centers, for example, had to understand multiple work processes, multiple tool sets, multiple ways of working, creating quite a challenge for them to deliver consistently-- ultimately a fragmented and expensive way of doing business, hampering our ability to perform as a global organization and leverage the full potential of global integrated delivery.

This morning's keynote focused on the opportunity of better and about where the impact of automation has had-- or-- and on the impact that automation has had on delivering better. Well, we want to be better. We want to automate. But before we can achieve any of this, we need to con-- we need consistency and predictability with our processes and tools, which all needs to start with some level of standardization and that's what our JSW project needed to deliver.

As we set out on the journey, we quickly realized that this was a mammoth task. We engaged with some of our core vendors to help us validate our approach. This was new ground for us and, in all honesty, we needed the reassurance. We also recruited an external resource with enterprise architecture experience to guide our vision.

Steve Crunkhorn joined us for around 18 months and here's where we needed the reassurance-- he had no knowledge of engineering and had no experience with engineering tools. Seeing Autodesk as a strategic partner for this initiative was vital. Quite some time ago we stopped seeing Autodesk as a seller of boxes of CDs and we started to move away from that transactional client-vendor relationship and into a more strategic partnering, which always benefits both organizations. We engaged with Autodesk Consulting to work with us as we set out the roadmap for this initiative.

But even with Autodesk on board as a strategic partner, we still couldn't quite predict what our architecture would look like upon completion. The problem was clear, as was the objective, but we accepted that this was a complex issue that would require significant agility as it was developed. We recognized that the technology available to us, as we set out on this journey, would almost certainly change or evolve through the life of the project. Our own growth through acquisition would add complexity to our journey. Our core vendors' growth through acquisition would also muddy the waters, as would the constant development of their tools to fulfill the growing demands for project delivery in such a competitive landscape. As we heard this morning the era of change is changing. Excuse me.

It's fair to say that we'd had a number of previous attempts to standardize around certain software titles or versions. In fact, we'd had many small successes with such projects, but they always started and ended with the tools. It's vital that you know what it is you need to build before you start looking at the tools and materials you need to build it.

In order to know what to build, you first need to understand what you want to use your building for. It's no good starting with a pile of six by four plywood and a big hammer if your end goal is to plant seeds and nurture young seedlings, for that you're going to need a greenhouse. Plywood is not the right material. And once you've mastered the right materials, then a big hammer is not going to be no good for working with glass. We wanted to take a very different approach and start by understanding what it is we do, what we need to deliver, rather than the tools and the materials we wanted or preferred to use.

Our architecture would need some rules to bind it. Oh, sorry, too far. Our architecture, we need some rules to bind it, some core operating principles. At a very early stage we agreed that in order to fit within our architecture, each tool would need to play nice with our common data environment. Be available as part of an enterprise license agreement. Be geography neutral, available globally. Be data driven, vital for the digital world that lay ahead of us. And be best in class or approved in strategic technology, making best use of the-- our internal-- internally developed tools.

It also needs to be cloud-based, now or with a future roadmap, and still available and supported by the vendor-- i.e., not vendor obsolete-- thus, creating a portfolio of tools to deliver best value and highest quality of service to our clients. The ability to fully leverage our global expertise by standing around these core operating principles, we would be able to more effect-- we would enable more effective global integrated delivery. We move the work to the people, not the people to the work.

And by standardizing as much as possible-- around function and capability-- we would be able to start identifying the overlap or duplication. This would give us a greater insight into the real number of tools we would need to deliver at least the same capability as we had today.

As we identify the tools we need, by definition, we also identify the tools, we don't, which delivers an opportunity to reduce cost in a number of ways. Some savings from licensing a maintenance reduction. Some saving through being able to better leverage our high value centers and global business centers. Less time converting file formats and data produced using different tools. Reduction in errors as more people become fluent in fewer tools, processes, and systems. Higher quality of work produced more consistently.

But all of this wasn't going to be enough. We also needed to play by our own rules-- those operating principles we'd already identified. So things like using a proven strategic-- proven strategic technology, something that was geography neutral, something cloud-ready, something data-driven. And to achieve the correct balance between best practice and pragmatic implementation, our plan was to apply TOGAF as an industry standard to create what were essentially three components all supported by a single source of data truth. And those components being a logical business conceptual model, our BCM, an expression of the BCM as a series of process steps, essentially the Jacobs standard workflow, and an application architecture.

This actually is an incredibly simple idea. It takes us right back to core principles of decision-making, but from simplicity comes complexity. So I'll provide a little bit more insight as to how we use the TOGAF process shown on the left to guide us.

A purist TOGAF implementation assumes that assumes working through a series of eight steps and architectural archive artifacts usually in succession. These are represented by the ring of gold circles. They are held in check by a further circle that represents the driving organizational requirement.

A is about having a driving vision for the business. We didn't look to do anything new in this space, but took our motivation and inspiration from the transformation program and the integration management office working to bring Jacobs and CH2M together. B is an arc-- is the business architecture. Within this project, this really is a combination of the business conceptual model and the Jacobs Standard Workflow. The key point is that we understand the business landscape before describing the tools that enable it.

C is an expression of information systems architecture. Its articulation of how applications are structured and how they exchange information to achieve the desired functionality of the business layer. D is assumed to be more infrastructure-based technology layer that further enables C. This will be the later step in business as usual as the IT team works-- manages with our suppliers to realize a fully integrated design suite.

E, F, and G are all about the implementation. While D concerns the physical aspects of the infrastructure, there are rationalization opportunities and solutions in E and the plans to achieve those optimizations in F. Ultimately, these would exist within the tools retirement strategy.

H is about implementing governance. Governing the above would be managed through policy and procedure around tool selection within the operating guidelines and by linking our procurement approval process directly with the business conceptual model and associated Jacobs Standard Workflows. SPARX enterprise architecture is our tool of choice for the management of our data-- our single source of truth. So let's look at those artifacts.

In order to begin the process, we have to we had to have an understanding of what we were already using. Pulling information from many sources we identified more than 2,500 software titles in use by buildings and infrastructure alone. We set out to our data to this comprehensive list of software identifying the tools core functions, identifying which of our markets we used-- we use in each tool, breaking that down into disciplines-- which disciplines specifically we using the tool, adding cost and licensing information, et cetera. This became our tools master list initially assembled on a SharePoint site.

Using the master list as our initial single source of truth, we were able to start leveraging the data in a more creative way. With the tools now listed in one place, we were able to start defining and adding their functional capabilities as well as understanding their performance against our core operating principles.

So we now turn our attention from the tools themselves to create something to agnostic. The individual capabilities we'd identified were grouped into higher level capabilities and our business conceptual model started to take shape. The business conceptual model is an affinity diagram. It shows that a fairly detailed level what functions and capabilities have to exist in Jacobs to deliver all of it-- to all of its markets. This is 100% tool agnostic. The model is purely based on function and the associated capabilities, no tools or vendors mentioned whatsoever in this model. The insight it gives is a comprehensive reminder of what has to exist and Jacobs to be successful and how those individual elements need to relate to each other.

With the business conceptual model taken shape, the next challenge was to start looking at our application relationships. The application architecture is our developing statement of how the software should be organized against the TOGAF guiding principles. It is a model for-- to facilitate a greater understanding and will eventually become the wiring diagram for Jacobs or, as described this morning, maybe the nervous system.

Our next objective would be to combine the knowledge we documented in the business conceptual model and the application architecture to map out our Jacobs Standard Workflows. The Jacobs Standard Workflow introduced the relationship between time and technology. Each JSW reinforces our market strategy. Each market has its own JSW. Each JSW shows the fundamental process flow needed to deliver excellence. They provide a global standard for each market-- the one Jacobs way of working. And each would eventually describe the technology we wish to use as a standard for each of the process steps.

The amount of data we created to drive this vision is significant. So the information we make available needs to be relevant to the person who's using it. I remember back when you needed a phone number you had to turn to the yellow pages. If you asked me for a number, I could look it up and give you that number, but I could also give you the yellow pages. I've given you what you need because the number's in there somewhere. But that's no good to you, you need your data to be relevant.

So, in our case, there is no value in giving access-- general access to the business conceptual model, the application architecture, or, in fact, the master list itself. We had already been doing some work with Autodesk around visualizing what our tools do for highways. This became an obvious choice for the visual way of presenting filtered, relative data in a usable format-- a slick user interface to the JSW data.

So this isn't an IT project. It's driven by the business and supported by functional groups within IT who provide guidance. Our need to drive global standards meant, first, having to achieve global agreement. For each of our markets, we held a global workshop facilitated by Autodesk as our partner. Finding the right balance of attendee was a challenge. They needed to be close enough to the project delivery to understand it fully, but also needed to be senior enough and empowered as decision makers.

For each market we gathered representation from all regions to ensure the correct global coverage. The desired outcome of each workshop would be a common way of delivering projects globally-- focused purely on functional requirements, again, with no tools mentioned at this stage. It was actually surprisingly easy to get agreement at this level. The fundamental requirements and steps for market-specific project delivery proved quite common. With our organization we already have Centres of Excellence and Communities of Practice, so involving those groups throughout the process was vital in gaining their support and leveraging their knowledge. Throughout the process it would also be vital to reinforce the global nature of our transformation activities.

So we held a number of market-specific global workshops to collaboratively discuss and agree our standard work processes. We held a workshop on water and wastewater in Denver. For buildings in Dallas. Mumbai, we doubled up and looked at rail and highways. For Dubai, we agreed workflows for ports and maritime. Winnersh in the UK, we looked at aviation. London for rail and Kuala Lumpur for power and energy. Lots of writing stuff on walls, lots of making sticky notes, lots of moving sticky notes around, lots of updating and adding to sticky notes.

Autodesk took away all of this information and developed our workshop scribblings into concise deliverables-- importantly, that was the main deliverable being our Jacobs Standard Workflow for each of the markets. There was now, of course, something missing. It's OK to understand the enterprise and have the Jacob standard workflows defined, but without tools there would be no project delivery.

So we already had detailed information about who was currently using each tool and what function each tool performed. So it was relative-- relatively easy to start mapping those tools to workflow steps within the Jacobs Standard Workflow and it was then that we started to see the full scale of overlap and technology duplication. We needed to start defining the future state toolset, defining what we needed, and, of course, what we didn't.

So we broke the decision-making process down into three tiers. Tier one was pass or fail against the rules of our guiding principles. This didn't give as an immediate pass or fail unless vendor obsolete, in which case the tool was marked for retirement. What it did give us was a visualization of how each tool performed against those guiding principles. So we-- so where there were multiple tools performing the same function, we could now start to evaluate based on their performance and how they compared with our guiding principles.

The second tier was all around business engagement. Similar to the earlier workshops, we now started collaborative discussions on the tools. We didn't gather people in rooms and have them traveling all over the world to attend workshops. This was an exhaustive series of telephone conferences at all hours of the day and night. The idea here was to gain SME input from the communities of practice and the centers of excellence to reduce the number of tools performing the same function. This is not a process of standardizing around one tool, but an agree-- but agreeing the minimum number of tools to fulfill our capability requirements.

And the third tier, where a decision on each tool couldn't be reached using tiers one and two-- we would hold detailed functional analysis predominately undertaken by the communities of practice and the centers of excellence-- similar to step two, but with a much deeper dive.

From the outcomes of those workshop calls, we were looking for one of three options. Our preferred tools. The tools that were-- that would conform to our guiding principles were available globally as part of an enterprise license agreement, cloud-ready, et cetera, or that were mandated due to some kind of legislatory requirement-- mandated by something beyond our control or influence. These are the tools that are optimal for global integrated delivery, our go-to solution. Anything falling into this global architecture would be budgeted for and instantly approved through our procurement processes.

We always accepted that we need to allow for exceptions. These are the tools that are not required or preferred by a project team or by a client, not mandated by any kind of legislatory requirements, just preferred. So these tools would not be included in the global funding model, as such, any of these would need local approval and funding by the client or by the project requesting them as their preference. Anything that didn't fall into the preferred or the exceptions category would be marked for retirement and would go through our-- the associated change control process. So our future state looked a lot cleaner-- the removal of duplicated functionality where possible, anything much as global already budgeted for, anything marked as an exception needing some form of localized funding, and everything else removed from service.

We now have a functional Jacobs Standard Workflow for each of those markets. But at this point they are no longer tool agnostic workflow diagrams. With the output from our decision-making sessions added to all of our other data, we now have something functional, as Chris will demonstrate. I need you to just forgive me a second because we weren't able to get this fully integrated, so I just need to switch our display. Is it that one?

CHRIS CANN: Just type it under explore-- explorer. At the bottom.

ANDREW WHITEHEAD: Ah, there we go. That one?

CHRIS CANN: Yes. So what is they say? Never do a live demo. That is the reason why he invited me along, it turns out. So as Andrew said, the visualizer that you're looking at the moment, it was-- it used to be an Autodesk product-- an Autodesk in-house product. And we had the consulting team code it and put it onto one of our web servers. And initially it was just for the UK highways market to denote the tools that were approved for use there. So as part of this project we just took the work we'd already done with that and we added in these Jacobs Standard Workflows that were produced from the workshops. These are essentially hyperlinked Visio-type diagrams that we've loaded in.

You'll see the top here there is access to all of the seven markets that we looked at. And in here-- and I'll just-- you'll see there is-- that is the-- you can't it all in one screen, but it is the entire work process around UK highways in this particular instance. The colors on the box is defined whether it's discipline-specific and I'll go onto the yellow boxes in just a moment. Down the left hand side we've got project phases or-- yeah, project phases which are loosely tied to the REBA stage of work in the UK. So you've got approximately eight and we've got some sub-- yeah, we've got some sub-phases too.

Across the top you've got primary capabilities and this came out of the mapping exercises that we did within the workshops, so things like information capture at the front end, [INAUDIBLE] analysis, and so on. So this allows-- what this allows is the project staff-- be they the PMs, be they the planners, or the designers-- to come into the visualizer to find the phase of work they're at. So if we were to pick preliminary design-- and then you can see the activities or the processes in here. And when you click upon them that will show you the approved tools allowed for that particular process. So-- and they're displayed on what we call-- what are called cards. So you got all of them in here.

You click-- so there's a brief description of what the tool does in here. If you then rotate the card, you get some more information. So-- and it tells you the status of the tool. So just briefly go through these-- the technical steward is the superuser, the person you might go to get more information. Request access. If you click on that-- been even more brave now trying to do another-- there we go. It opens up our service desk and allows you to request the software to be installed on your endpoint. And then request training-- if you click on this, it will then automatically route you to the person who can provide the training for you either themselves or they'll go away and arrange it for you.

So if we go back to the main workflow, some more notes about the-- some of the symbols. Where we've got a green dot, this is where we've identified opportunities for us to do some automation activities to improve the-- to improve the speed or the quality. There are some triangles, which link out into other workflows. So, for example, structural design-- if it appears in the highways workflow, you-- it would link you through to maybe the building's workflow as well.

The yellow boxes-- this is something we have just recently added. As Andrew was saying, we want to be able to leverage our global design centers to be able to offshore work to high value centers. So if your process has got a green-- sorry, a yellow box above it, that means that it is an offshoreable activity. So if we go back to bridge and tunnel design again, it will show you that bridge design and tunnel design are available in our global design centers.

So click on the back of the bridge design and it would tell you the primary GD global design center of focus for the BIA, which is Buildings and Infrastructure of America will be India. APAC and Middle East will be India as well. And Europe will be India and Poland. And then you've got additional centers here. If you click on one of these, it will automatically start an email up to the person who's responsible for that global delivery center.

And, finally, on tools-- this is a list of every single tool that made it through-- that's made it onto one of those workflows. So by using the standard workflows and clicking on the hyperlink, it just filters that down into a more manageable list of the approved tools. Back over to you.

ANDREW WHITEHEAD: Thank you. So I have to fiddle around a little bit to get the right display. Where we going with this? My clicker's not working all of a sudden. There we go. Do you want to do it again?

CHRIS CANN: No.

ANDREW WHITEHEAD: So with our toolset now defined and documented, we needed to start looking at the process of removing any surplus. Retirements follow a rigorous change control process to ensure that an effective solution is already in place before they are removed from the architecture. Significant savings will be achieved by removing duplicated functionality and any associated license and maintenance costs. However, some of that cost will still remain due to the fact that we now have increased usage in our global preferred tools. Essentially, the function still remains and there has to be a tool to provide that capability.

So as more of our staff use fewer tools, connected and mobile, for more effective integrated delivery, we anticipate a significant reduction in cost and duplicated-- duplication and rework. The process itself cannot stop as the project ends. Continual development of the architecture will result in further rationalization and improvement to data quality and project delivery excellence. The Jacobs Standard Workflows will continue to focus on function and project delivery requirements.

As existing technologies advance and new technologies emerge, they will continually challenge the architecture. Where a tech-- where a new technology provides a new function or capability for project delivery, it will be added to the architecture. Where a new or emerging technology improves an existing functional capability, we will use the retirement change control process to reevaluate and replace or remove any of the existing technologies it can replace.

So some interesting numbers on where we've got to so far. We've got Jacobs Standard Workflows in place for seven markets. We have 4,200 functions and business capabilities detailed in a logical model. 573 process steps in market-specific standard workflows. We have 2,749 applications reviewed and detailed. 2,063 of those relate specifically to engineering tools. 1,095 tools identified for retirement, estimating a saving of $4 million per year. Tools in the architecture today-- oh, sorry-- 1,020 tools in the architecture today all interactively linked with the functions they perform. And we have 402,000 relationships in an interactive model. 2,545 data objects associated with interoperability. And we've engaged over 200 people with the-- within the process today.

So our benefits today and tomorrow. We directly enable a consistent experience for our clients and provide a platform for promotion of best practice. We directly enable project efficiency and effectiveness by simplifying decision-making around standardized process steps and tool selection-- a promotion of best practice, creating greater efficiency and helping us lead the way and stay ahead. We directly reinforce maximum use of global design centers.

This is a data-centric approach to the JS-- to the Jacobs Standard Workflows and interoperability is an enabler of an integrated design suite. Jacobs standard workflows provide a structure for continuous improvement. They indirectly enable tool costs to be allocated with greater accountability. The cost avoidance already-- the cost avoidance value of the decisions already taken is around $1 million per annum and as a result this project has essentially been self-funding. And as we said prior, the potential value to rationalize all of the other tools identified is the further $4 million per year.

The Jacobs Standard Workflows are more than a suite of workflows. They are the first output from an innovative data-centric approach to better understanding our buildings, and infrastructure, and advanced facilities business through enterprise architecture techniques. Enterprise architecture is not a benefit in itself, it is a vehicle for further building blocks of continuous improvement. As our approach matures, further strategic insight and tangible benefits will follow.

We are already using the model data to facilitate decisions in our procurement processes and we are able to use model data at project startup across seven markets. So our Jacobs Standard Workflow project already gives us the ability to deliver better right here right now. But more importantly it lays the foundations for automation, which results in the opportunity to deliver even better in the future. We already-- we've already started a number of automation proof of concept projects. You saw those identified with the circles on the-- the green circles on the Jacobs Standard Workflow. And some simple examples of those are the auto-creation of a project execution plan or project technology plan.

So if you remember back to one of the earlier slides, I mentioned that the Jacobs Standard Workflow project is one of eight transformational projects within Jacobs. One that links very closely to this project is the technical talent engine. While the JSW project focuses attention on the enterprise architecture from a process and technology standpoint, the technical talents engine focuses on the people. So I hope that somebody from Jacobs will be stood here next year reporting on the successful integration of these two transformation projects.

Any questions? Now I'm nervous.

AUDIENCE: No, it was very good. Question, a couple questions. One, what was the time frame from beginning to where you're at now? And where you're at now. And also how much [INAUDIBLE] went into what's available now technology-wise versus what you want the workflow to be for the future? Obviously, you're going to continue on improvements as the technology allows, but if you try to force [INAUDIBLE] and try to whiteboard process making versus [INAUDIBLE].

ANDREW WHITEHEAD: OK, 18 months, and yes. Next? No, yeah, we're 18 months in. So we're about ready for handing over into business as usual, now. One of the things we said in one of the early slides was that we had to make sure that we kept everybody in line and understanding this was a global initiative. But it also was a future-looking initiative.

So while we originally were only able to look at the tools currently have in the estate, we were constantly looking at what they should be replaced with. And how we could better deliver value using newer tools. So we haven't added a lot to the architecture yet, but there was always that look ahead that the current tool set wouldn't be current for long.

AUDIENCE: Very good presentation. Thank you.

ANDREW WHITEHEAD: Thank you.

AUDIENCE: I'm aware the cost components that you mentioned, does that take into account the cost efficiency that you could reach from the data center [INAUDIBLE]?

ANDREW WHITEHEAD: No, that's just looking at the savings on licensing and maintenance. So all of those improvements in efficiency, we--

AUDIENCE: Because I would imagine that $1 million is just a blip on the radar.

ANDREW WHITEHEAD: Yeah. We haven't quite worked out how we're going to calculate that bit. And I don't know if we dare, because when you commit to that as an ROI, it's a scary commitment.

AUDIENCE: Just to comment on [INAUDIBLE]

ANDREW WHITEHEAD: We get to save so much because we were in a bigger mess at the start. Oh, sorry. I'll come to you in a second.

AUDIENCE: [INAUDIBLE]

ANDREW WHITEHEAD: You might be able to answer that one better.

CHRIS CANN: Was the question, if I heard it right, is the BIM level of detail part of what we did today? Not directly. When we had the workshops, some of the more mature markets that are using BIM quite extensively, then there was some discussion around that. But it wasn't a particular line item.

So in some areas, like buildings, they advanced in-- and highways, actually. They did go into that level of detail. But it wasn't a conscious effort across all of them.

ANDREW WHITEHEAD: What we were able to do though was, in our rail markets, for example, they were much more mature with their BIM implementation in some regions, but not in others. So by connecting those regional teams together, they were able to learn from each other and improve globally.

AUDIENCE: So, within the organization, who recognized the need to canonize all of this software and essentially champion it? Was it at the bottom, or was it at the top?

ANDREW WHITEHEAD: Almost at the top.

AUDIENCE: I would think so, at least on the scope of the convincing and otherwise [INAUDIBLE]

ANDREW WHITEHEAD: Well, because it was quite a significant effort, of course it needed that executive sponsorship. And you know, we mentioned in one of the earlier slides that we tried smaller standardizations tool by tool. They were never going to be effective enough. So, yeah, it needed that executive sponsorship to drive it down.

CHRIS CANN: And it needed to be executive sponsorship from the business itself. So the group was a mixed group that delivered it of corporate functions, but previous efforts from [INAUDIBLE] or BIM base, if you like to try and promote standardized tool sets, they got us to UK Highways, which is why we had the visualizer in the first place. But we really needed pretty significant senior backing to go after all of the buildings and infrastructure market.

AUDIENCE: That's the hard part.

CHRIS CANN: Yeah.

ANDREW WHITEHEAD: And one thing we should have included in the slides, and it's only just come to me now, is this was a really small project team. Although we engaged and included 200 people in our engagement process, this was actually four people. It's a four-person project, which is probably why it's taken 18 months.

AUDIENCE: So what's the [INAUDIBLE]

CHRIS CANN: I think the answer to that, typically, is not yet. There will be a further iteration of this project. I mean, because we're at an 18-month stage. What's tangible that we can hand over? But we'll need to do that further development, I think. Because we could probably rationalize down the number of total tools, even more so, by really aggressively looking at the comparisons and new technology.

ANDREW WHITEHEAD: That's a complicated one to answer, though, because within the business conceptual model, we've also mapped inputs and outputs of all of the tools and the relationships that they need to have with each other in order to interoperate. So when we come to making a decision on which tools to use in a particular workflow step, that interoperability with the prior step and the later step really came into that decision-making process. So it wasn't just a case of picking the most popular or the favorites, the interoperability was key.

CHRIS CANN: I think we might have exhausted the questions.

ANDREW WHITEHEAD: Good questions. Thank you.

AUDIENCE: [INAUDIBLE]

ANDREW WHITEHEAD: We would, too.

AUDIENCE: [INAUDIBLE]

ANDREW WHITEHEAD: Well, within our team, we are part of a functional group in IT called Project Technology Services. And within that organization, we have a portfolio management team and a common data environments team. So we leverage some of the resources from those teams.

CHRIS CANN: As Andrew mentioned, the actual whole effort was led by someone with transformation and enterprise architecture experience. So that was where the driving vision came from to start with. And then, yeah, as Andrew said, a lot of people from our teams. And then lots of people dropping in and out as needed to give input to the processes.

ANDREW WHITEHEAD: It was quite difficult to corral his ideas, actually, because he's mad as a hatter. So he's very, very visionary, but actually trying to bring that down into something deliverable was one of the bigger challenges-- just keeping him on a short lead.

AUDIENCE: Did process matter [INAUDIBLE]

ANDREW WHITEHEAD: Am I allowed to say we're still working on that bit? So that's part of our move from project into business as usual. So we had some temporary governance in place as part of the project activities, but then as we move into a more structured governance through business as usual, yeah, we're still working out where the ownership is, and everything.

AUDIENCE: [INAUDIBLE] establish [INAUDIBLE]

CHRIS CANN: It's referred to-- I think the space holder, if you like, for that, it was the design authority. So who has the authority to approve the inclusion or removal of a tool. Yeah.

AUDIENCE: [INAUDIBLE]

ANDREW WHITEHEAD: For all of the seven markets that we listed, yes.

CHRIS CANN: I just knew the highways one worked well. I just knew the highways one worked, so that was why I focused on that.

ANDREW WHITEHEAD: This area of expertise. So you had a question?

AUDIENCE: First, thanks for your presentation. I would like to know if you have any specific areas that was responsible for all of the studies for [? efficient ?] users? And are they named within the IT area?

ANDREW WHITEHEAD: Yes, that's basically part of our functional group within IT, which is Project Technology Services. So we are the custodians of that, and manage those relationships.

CHRIS CANN: And there are communities of practice that actually define-- the process map is owned by a community of practice who actually decide what order we do things in and what activities take place. So we interface with those people. Because the actual process is a business-led, project delivery-led process. So yeah, there is communities of practice that look after those on the intellectual property level.

AUDIENCE: I have two interrelated questions. One is, to what extent [INAUDIBLE] internal resistance you had from the infrastructure side. On one side, you've got receiving the high-level executive backing which was necessary [INAUDIBLE]. But then, there's also a huge gap between that high-level sponsorship, [INAUDIBLE] employees, and [INAUDIBLE] resistance along the way. So have you encountered such resistance--

ANDREW WHITEHEAD: Yes.

AUDIENCE: [INAUDIBLE]?

ANDREW WHITEHEAD: So during the workshops, we didn't encounter any resistance. It was really quite amazing how everybody pulled together and understood the value of what we were trying to achieve. The resistance started to kick in a little bit when we started trying to remove tools. You know, people are very emotionally attached to the tool sometimes.

But with the support of the executive leadership and the governance and the communities of practice, as long as we've got a replacement tool in place for them, then the policy itself, the initiative itself, makes the decision for us. So they have to get on board, because that's just the rules, right? There was another piece to the question, wasn't there?

CHRIS CANN: Compliance, I think.

AUDIENCE: Yeah, [INAUDIBLE] compliance. [INAUDIBLE]

ANDREW WHITEHEAD: So at the moment, it's very basic. Our procurement processes go through a rigorous approval cycle. If we've got something that's approved for use in the architecture, it's a no-brainer. It just gets approved.

But one of the reasons we were in such a mess is that not everybody uses the procurement process. There were loads of onesy and twosey pieces that people buy on a credit card and put through expenses. And they install it themselves.

So we've got a couple of initiatives that are ongoing at the minute. One is going to kick in early next year around the control desktop. So we limit what the end user can do. We also have, working with our endpoint services team, we've got our whitelist and our blacklist. If anything in the blacklist appears, it just gets removed.

So we wear them down, basically. They'll install it and it gets removed, they install-- and eventually they give up.

CHRIS CANN: It's also worth noting that Jacobs has grown by acquisition. And we've done, as we acquire a company and we integrate them, quite a lot of them come with legacy tools as well. The way that these tools actually arrive in our environment varies. It could be like Andrew said, or it could be because of what that company is using, even their own bespoke in-house tools.

ANDREW WHITEHEAD: But we've already obviously got change control processes within IT itself around the removal of old revisions of tools and standardizing around stuff. So we leverage those existing policies and procedures. Now, at the moment, it's fairly crude.

And we're working with those guys to actually make the process a little bit slicker and plug it into this better. So at the moment, they're bolted on. But we hope to have them more integrated in the future.

AUDIENCE: [INAUDIBLE]

ANDREW WHITEHEAD: They just look at managing the endpoints themselves. So as long as they know what can't be on there, they'll look after it for us.

AUDIENCE: How would you manage [INAUDIBLE] workflow, process workflow [INAUDIBLE]

ANDREW WHITEHEAD: Well, that's why we said right at the outset, it wasn't going to be a case of reducing everything down to one tool per step. So for example, highways is kind of easy. In the UK, very focused around Civil 3D. In Asia-Pacific, very focused around 12D. And in the US, very focused around the Bentley tools. So around that model authoring step, within the workflow, there's a selection of tools. So you do have options, still.

You know, we found 86 different tools for structural steel analysis. Getting that down to 10 is a real benefit, right? So it wasn't a case of pulling it down and getting it to one. It's the minimum viable product to carry on with the same level of capability that we have now. But then, ultimately, improve that, longer-term.