 All right, so super keen to start on time. So welcome everyone. Akil from Salsa Digital has our next project management talk. Go for it, Akil. Thank you. Excellent. So welcome this afternoon. I hope everyone's having a good day at Dupal South. This ain't Hobart here, so let's press out. So we've got a session here about process maps. So not all maps lead to treasure, but a good process map can lead to a successful project. This is going to be a fairly light session in terms of the process mapping component of it. I want to talk more about my experience in the project I'm currently doing. I'll cover lightly what a process map is and how it could be used in different situations. I've got a bit of a demonstration here to do in audience participation with Lego. And so we'll get through as much as we can as quickly as we can. So my name is Akil Bandari. I'm a digital project manager or engagement manager for Salsa Digital. I've had experience in business analysts, user research, and I'm an agile project product owner, and also a scrum master. I've worked for about seven and a half years in government with Canberra, in Canberra with the Department of Communications and Arts. And I've worked in ICC, so this is great. Someone's calling me. Declined. It's on silent, but anyway. And I've worked with Drupal for about five years, and I've been working with Lego projects since I was five years old. You might see a bit of a Lego theme coming through. So quick overview on session today. So we're going to quickly cover what a process map is, when and why to use and build a process map, and then I'll do an actual example of the work and project I'm working on, and some key lessons and takeaways from the project. So just a few questions quickly before we get into everything. So how many people here have done process mapping, have used process maps before? Excellent, so a few people. Another question, how many people walked into this room, found their seat, and having their eyes closed? Yes, it's rhetorical, hopefully no one saw that. But when you walked into the room, you would have seen the room, you would have thought about where you're going to see it, and then you kind of work out where you're going to go. And then you get to that point and maybe the person looks a bit scary next to me and might move my seat over here and sit over there. So part of that is that you've got a process, you've got a goal, you've got to find a place that you can sit down comfortably and also upset this, turns on by itself. Then you need to find somewhere to actually sit down and just leave that, and then sit down and find somewhere to listen to the session. So you kind of work out in your head. There's a process you need to do. The goal was to sit down and find it comfortably. Things changed, you came into the room, you saw what was in the room, where the seats were. It was not quite comfortable. There was a light in my eye. So you kind of actually had to juggle a few different processes and change things around. So basically that's process mapping. So you'll have a process or a project objective goals to actually achieve. I'm going to make this a lot bigger. Give me two seconds. And basically the process mapping is done and used to help you break down sometimes complex process or a task in key activities. Who's going to be doing them and how and why to achieve those? Kind of like Lego instructions. And it should be, in my opinion, a living document. As you're going through your project activity task, what are you doing? You may find things that need to be improved. They need to be realigned with what you thought from the beginning to the end. So when and why to build a process map? So process map might be useful when you have a new team. If you're working in projects, especially with digital projects, how many people here have actually had worked with their internal team on a project? It's fairly straightforward. How many people have worked with vendors externally that you may not have worked with before? Everything changes. The dynamics change. Unknowns increase. And so if you had something that could get everyone on the same track of the vision and a process that you could all work towards, that would be potentially useful. Another situation is something that's unfamiliar. So a new process, a new project, something that hasn't been done before or is unfamiliar to many team people or individuals within the team or the functions, whether that's your devs and your finance haven't done this or they've done this and someone else hasn't done it. And also complex tasks that may need independent or dependent other processes to be in place. And especially if there's something that's long term, things that change over long term, the landscape changes, your teams change, everything kind of changes. So you kind of have to have something to go back on what we were working on, what we were trying to do from the beginning. An example would be like migrating 25 websites. Could be complex, which I'll get to. And as I mentioned, long projects with transitions between different teams. You may have different stakeholders involved at various parts or phrases of the project. So the key is to basically have something that everyone can understand where they're going towards a vision and then you can bring everyone along. And that can be ranging from your individual team members to stakeholders. So executive who are often left out of the project initiation part where we're actually making plans and scoping things. You know, the executive and other stakeholders may not get involved in that. They may know at the very end they want an output, but how are you actually going to get there? Sometimes bringing them onto the journey itself is going to be quite useful down the track where they're asking questions. So some of the process mapping methods can be just to write down your key tasks and objectives. And it could be as simple as post-it notes. I've used that in the very beginning of this process that I'm going to show you. Other people can use mind maps. Anyone familiar here with mind maps has seen that. There are different variations. I'll show you a few of those. You can use other tools, online tools and applications. There's a thing called Miro. If anyone's used that, Sketch, prototyping tools, Lucid charts. I happen to use Lucid charts for the one I'm going to show you. So there's a simple version of post-it notes. You can kind of see this is just an example, but they've got different concepts, ideas, and this could be used quite early on to sort out some of the processes that you think you need to get done. I'm going to show you a mind map. There's a couple here. This was kind of a linear decision-based outcome, so you're going to have these steps to get to this particular output, and you can have variations of those. This is more of a classical mind map. You've got ideas, everyone doodles. This is a bit more of a Lucid chart style map, which I've also used the program for Lucid charts. So now a practical example. I need to race through to get this Lego stuff done. So, Lego, I need four volunteers. Don't be shy. Wow, look at that. No one wants to come on stage. Yes, okay. One. Yes. I need three more. Yes, of course, come on. Two more. Wow, everyone is showing. Okay. Yep. Quickly, come on. Another character in here. I don't know if anyone can see these figures, but we've got the resistance. I'm not going to stand up, and we've got the Imperium. Okay, so you are really... It's not going to work. Okay. So, you've got a task. Your task is to build two Lego planes. I don't know if you guys can see. You might have to turn around a bit. You've got to make two Lego planes each. Each team. So, you've got two teams. So, there, sorry. Okay, so... It looks like it is, right? Okay, so, you've got two teams of two. Okay. And your task will be to build two Lego planes each. Okay, you're going to have basically one person is going to be a project manager slash Scrum Master. One person is going to build. Right? You've got a 15-second planning sprint to work out what you're going to do, and then you have one 30-second sprint to complete the task. There is requirements. Fairly high level. You just have to have four wings, and you must be able to see the pilot. You have two pilots at the front. Good question. So, each plane. Yep, has to have four wings. Okay. Okay, I'm about to do the timer for 15 seconds. You're actually getting more than 15 seconds. Okay, let's go. Oh, my God, that timer. One, five. Okay, go. 15-second sprint. You've got to do a planning sprint. So, you can't touch the pieces. Another 10 seconds. Okay, time's up. It's going to put 30 seconds on here. Okay, ready? And 30 seconds go. Kind of the idea there is you have limited resources. You'll have different decisions. You've got people who have not worked before together. I'll give you guys a clue. The four wings is two normal wings and two rear wings. Two normal wings and two rear wings. And there, yes. Sure. You can both work on them. Yeah, yeah, definitely. I'll give you a few more seconds. So, maybe not play Lego as much. It's going to get five, four, three, two, one. How'd we go? So, I don't know if anyone can see. Quickly show. So, thank you very much. You can sit down. Thank you. I'll explain a little bit. So, the idea there was I actually gave one team a little bit of help. They had a bit of a process and I gave them some clues. The idea being the process actually helped them speed up what they were trying to do. Although they still had four wings, there was no requirement. They didn't say what the wings had to look like. The idea was that they still, actually, yeah, that's a wing. So, that's four wings and there's four wings. But having a process might be able to help them with bottlenecks if they're not enough pieces to be to get the right information. So, well done to the teams there and the Lego. Okay, now. So, now the example. So, the last few months, I've been working on a GovCMS migration project. It's a brief. So, the project needed to have 25 websites installed into default GovCMS SaaS. We had five months approximately, so the velocity was about four weeks per site. The sites varied from having just a few pages to the larger one having 20,000 pages being DFAT corporate. We had a project team. It was a mixed team of department of Flanet staff and then several other vendors who have made up the whole team as it is, including Salsa. So, we had some key challenges. The project was specifically something that had never been done before by any of the teams or that we know of anyone else in government, which in itself was quite challenging. We had mixed teams that had not worked together before, so we didn't understand how everyone was going to work. And we were also using a new tool that was called Merlin that was going to be used as a basis to migrate everything over. The process. We reviewed the current BAU processes that were in place that the GovCMS team used with the other projects. We also found some several critical steps that needed to be taken into account and also put into the project processes themselves. And part of the project was also to have the agency change management in place as well, so that once the marked projects were actually handed over to the agencies, they were actually able to use that as a BAU outside the project once the five months was up. This is basically what I came up with. So, it took me a few weeks to do this. And I started with that line. I don't know if I can show the line on here. So basically, I started with that middle line there with the dots. So this was the critical path that we had. We definitely had a discovery alpha or beta stage, ready to go live and then done. That was what we started with. Then I had to backtrack with the process to onboard the teams. And then as we got this line, the project team understood kind of where we were going. The next phase as I did is the bottom section here represents what the team has to do and what we have to get done behind the scenes. The top section is actually what we have to get done with the customers. So this kind of comes with the change management. We actually had a check-in point just there with the green tick. As the team of the agency is getting onboarded, they need to actually follow this line. And we have to go through each of these steps at these critical points along the process of the project and through the journey. Part of that was to bring the customer onboard but also to get them ready for when they get into BAU. So the steps there include having to get information about what does GovCMIS look like, what do you need to do? Make sure that your key members are actually on a training course before you go live so that when you do go live, you're actually able to use the system. And then on the other side, we had what I mapped across was through these phases here, our forum beta, we had this is matching out to GERA tickets. And each of these stages, we had to finish each of these actual key steps in order to move sequentially down and move through the actual process to make it go live. So I was able to kind of build that out. That was used in the first couple of weeks to get everyone on board and get an alignment of who needs to do what. The front-enders can see that. Themas can see they need to be kind of involved here. We had UAT and clients coming in on site. They had to have everything ready here. We had a migration team in the Alpha stage doing migration work. And so everyone kind of had an idea of these are the key things we have to get done. And then everything else is a little bit more loose and changed as we went along as my computer or not. Yes, so the process here did change as we went along about three months in. People were obviously much more comfortable and familiar. We did change a few things here. I haven't quite updated this to the very last or newest version. But this was very useful in order to get everyone on board and get the project done. That was learned. When we were talking through that process with the team itself, we did find that there were things that didn't quite work or weren't going to work. We were able to find some bottlenecks. There were some key people that needed to do certain things. If they were away, that process would not have finished. So we had to work out some mitigation. And we had to work out some alternate ways to get things done or at least have them prepared at an early stage to make sure the process worked. For one project, that's kind of pretty easy. But when you've got 25 projects with 25 government agencies all needing to go live at certain times, there's that obviously factor that you need to book them in. You need to work around the times of the agency. So we needed to know quite well ahead of time and predict the future almost in terms of what we think we were going to get done at what point and also to be able to book them all in. So the team then realized and picked up. And what I mean by team is the technical team but also the GovCMS team that these people are going to be away. There's an event like Drupal South. There's full sites going live today, but there are obviously some people back at the office. So there are some things that you need to be identified within the team. So the team talked about the process from refine that and we then input that into the final process map I showed you. One of the key things is we have to work out what Dunn actually meant. Now for the project, for the GovCMS project was that the site was actually made live. But we adjusted that to it can go into beta live. So it was unofficial but in beta live and that was actually what we can count as actually done for the project. There are other definitions within the process as well so that the theme is new at Dunn was, so the migration team. But that was quite important to actually understand what it was actually, what we're trying to achieve to get done there. As I mentioned, we can actually refine the process and make sure that that document can get updated especially if you have a longer term project. You may have new teams that come on. They may not be aware of the changes that you've made as part of the process. So it's very useful to be able to update that process and have something that's more current. Key takeaways is to get an agreement from the whole project team about the vision. If not everyone is on board, you may find that things may not get done in time or to the quality expectation that everyone else has as well. And that may be coming back to getting feedback from the team themselves. So it's good that they may not agree but you need to find out why. There may be a technical reason why they don't agree with it. And that's good then you can actually improve the process. One of the other key things is from the process that I used there, that mapping, we would put that up on the wall in the project room that we had. If we had any executive, we'd be basically pointing them to that map to say this is the stage we're at. This is what we're going to get done next and this is where we're actually going to be in two weeks or three weeks time. It was easy to convey to them visually what we're doing and how we're going to get that done. I find with the executive, they need to know only certain bits of information that don't want to go through an entire document. If there's something simple that they know about that's going to help smooth out the process especially towards the end. One of the other things that we did is we had two systems or two boards. In this case, we had JIRA boards. We had a technical dev board which is quite normal for a splinter or scrum where you have all the technical stories. Then we had a high level JIRA board just to track each of those websites or 25 websites and those alpha beta stages and just seeing where they are. Then if we needed to see the individual items for development, we just went into the other board. But that high level board was used every day. We'd have executive, we'd have the stakeholder standups and everything and everyone can kind of see what's happening, what time and what stage they're actually up to and then we can actually have clients come in to do UAT because we know they're in the next step. So that visual representation of the JIRA board probably should have put that up there. That is everything for today. That is just my learnings and experience from this particular project but if you have any questions, feel free to ask. I think the time should be pretty close. Thank you so much. Thank you. So we just needed five minutes to set up for the next talk. If you're hanging around, great. If not, see you later. While you're still here, you can see the pledge. I'm going to pack them on my Lego.