Hey everyone, welcome to tonight's webinar all about lessons identified and lessons learned. Kind of a double, right? Uh, sometimes it's both a part of our, uh, build with Us webinar series, but it's also it's kind of a standalone. It's a bit of a special. Right? Oh, that's very true. I mean, lessons learned, lessons identified can be useful for most organizations. And I also want to spend a few minutes talking about it before we jump into Build with us, because it's actually not not that complicated to support it in monday.com. Let's start with, for instance, there are a bunch of misconceptions about lessons identified and lessons learned. The lessons learned process is not incident reporting. Incident reporting could be feeding lessons identified. Like we have a lot of incidents happening in this plant around this section. Hmhm maybe something's wrong. This is, uh, something to examine. So and it's quite common that you see, um, consultancy firms that try to build like lessons learned into, like the project execution as just an evaluation thing. And that's so it's really not incident reporting. No after action review. No, that's not lessons identified. That's not lessons learned. That's just an after action review where we say what did we do? Do good, what could we improve. And based on that result, we might push something to the lessons, identify the lessons learned process. But just having that conversation in the after action review don't make the mistake of calling it lessons -learned. -Yeah, I think it's quite common that -people try to equate them. -Oh, yeah. I mean, uh, it's it's one of those, uh, it started in the armed forces, and it's a cool term. So obviously, like all other military stuff, consultancy firms, they, they take them, they try to use the cool military words and they don't really understand it, and then they become something else. Where do you think the Swot analysis came from? Yeah, I know and I also know what happened to some of the leadership educations when they turn civilian. Incident reporting is super important. And by and by doing an analysis on your incident reports, you can see commonalities that require you to start some kind of lessons learned process. The after action review might result in some bullets that are very important. Like we did something wrong during this procedure. Uh, I can tell you my daughter came through a C-section as soon as the baby was out. They had sewn her, uh, sewn up the wife. They starred in an after action review inside of the the surgery room in front of us. It's like, what did we do? Good. What could have been improved? Is there something that we need to learn? And everything was fine because it was all condensed to that team and how they work together. They had no feedback that needed the whole hospital to get involved in reviewing the processes or routines or documentation. Right? So again, after action review, super useful. Use it, do it. But it's not lessons learned. And if you search. I did a search on lessons learned before this and I don't. I saw so many project lessons learned documentations about how you do lessons learned in quotation mark for all the different phases of your project and and basically it was just a project evaluation with a really cool name. But the problem is that. Those those terminologies are being wrongly used and it is quite hurtful for the process because it's a super important process. So let's say okay, what is lessons learned in. So we have lessons identified. And we have identified an issue, problem or a weakness. We need to apply an analysis. And then we have a lessons learned process which say we have understood the issue, problem or weakness. We have changed our trading processes and supporting documentation in order to drive the desired change to eliminate the issue, problem and weakness that we had identified. And Fredrik you who are less army person? Yeah. Is there any other words we -should say this in? -No, they are quite clear spoken because it's it's much more, um, that that's the kind of scope of it. It's not just at the end of the project saying, hey, this is what happened. It it's a bit more tinkering. So let's take a tangible example. Right. Uh. We are a web shop, we're selling dropship products, and for some reason, we have an abnormally high percentage more of aftermarket support tickets for one particular product. About the colors not matching the website. Right. That is something that we have identified, that we have more complaints about this particular product only for this color. What's the deal? So that's the lesson identified. That's all we have identified an issue. The issue then needs to be addressed. So we do analysis as part of that analysis we say okay quick action. Let's put a disclaimer on the website saying like colors may change or may appear differently live than on the screen or something like that. But when we start looking into this, we realize that nobody has in the office, in our own company has actually looked at the product that we are dropshipping. So this is now a lessons learned that every new product should always be physically tested, visually inspected by the company before putting it on the web page. Right. That's one of the important lessons learned. This is where we have changed our standard operating procedures. We don't just go and source a cool item on the web. We order it, we look at it, we take our own pictures, upload our own pictures, and also make sure to match them as much as possible. But never again putting an item on the web page that we haven't visually verified. It might sound like a stupid example, but I'll tell you 80% of most like product selling websites that do dropshipping have never seen the stuff they're selling. Would you say that lessons identified, lessons learned is best done without a single case? So actually. So we see that this is like a repeat offense. Whereas like I mean a product review that yeah, that's for that specific project. We know what happened in that specific project, but we don't know the repeatability of it. -Or what would you say to that. -Well, you do have a point. If we're talking like normal business, you probably want to see like trends and start acting on trends. But if we talk about this from a generic perspective, the Army being the biggest driver of the lessons learned, lessons identified process. This actually became quite popular during the the conflict in Afghanistan, where the opposing forces started using IEDs. With the first few IEDs, this became a lessons identified. The opposing force is behaving in a way that we are not used to. We don't know what to do. So a big like organizations started looking into this cultural studies, technical, uh, forensics, and it ended up with changing the whole pre-deployment training process, creating SOPs about how you approach intersections and and also about road selection and so on. So in that case, it's also in some cases you don't want to wait right for you. Sometimes you really want to start this process early, but I think you're starting to see the difference that it's not like any feedback that becomes the lessons identified to go into lessons learned process, it actually needs to be a feedback that we can act -upon. -So basically all lessons identified should eventually become a lesson learned. But that's that's the aim at least, I mean. Yeah, yeah. Well, I mean, there's there's no such thing as 100% accuracy, unfortunately. But, uh. But I mean, you have like, if that's their lesson identified, I don't know what lessons learned will derive from that. But if the lessons identified is that when we get this kind of project, we always seem to be delayed in this phase and we don't have, uh, higher than, uh, six in a CSat for these kind of projects. That's an interesting thing to start the lessons identified project process around, right? Yeah. So I mean, feedback is good, feedback is always nice, but feedback is supposed to be your data. And by analysis, doing analysis on the data, that's when you find your identified lessons. So a project review a project evaluation I mean you should definitely do it as part of project closure, but doesn't mean that we need to start a big lessons identified project process. -No, it could be a one off. -Mhm. Exactly. So is there anything we need to say about this. Is there any questions in the chat so far. So ask us for credentials. Uh because we're still like we're not only talking monday.com here. So people might wonder why. Why is this guy here sitting and telling us that so many people are wrong? Uh, I am from the army leg of the lessons learned part. I don't see, uh, lessons learned as a as an evaluation. Uh, after action process. It's quite a big process. It takes actually a dedicated organization, most organizations that does lessons learned, they have a special task force for, for each identified lessons to make sure that it gets the attention it needs cross-functional to make sure that the whole organization is represented in what kind of lessons we need to draw from this issue, problem or weakness. -Basically, you've been working with it. -Yeah, I have done several, uh, lessons learned processes live for both where lives are at stake and where. Not lives are at stake processes. Confident in saying listen up guys. All right. So with that said let's let's really now hammer through that. You don't need a super expensive consultant to help you with setting this up in monday.com. This is a rather simple process to support from a technical perspective. The hard thing here is, is the mental thing like the management thing, what actions do we do? How do we actually learn from this? And that unfortunately, monday.com will -not help you with that part. -And on that part, you're on your own. Right? New board. So let's call this lesson. There we go. -It seems to be correct. -Huh? Wow. Cool. So really, we we don't want to discriminate. We want to make it as easy as possible to actually submit something into the lessons identified process. The more like toll gates, levers and stuff we put in place, the less likely we we are at encouraging our personnel to come forth with stuff that they feel we should work on. Right? So we really want to keep that simple. The aim here is to allow a submission for form, right? So we are going to set up a board where we see every single submission as a potential lessons identified. So we're going to have a name for the item. Of course we are going to need a status. We are going to need a we kind of need like a longer description. And I'm thinking that maybe we should just allow them to do that as an update. The first update. Yeah, but yeah. No, let's do it as a long text for now, because it makes for a really nice item card. We do need a status. In this case, we're basically saying that everything that comes in is a new, uh, new. We have some kind of review. And then, uh. Start lessons learned. Let's keep it that bad for now. We want some kind of dropdown and ask for boxes. So what we're saying is, is this in, uh, sales and right now. So I'm starting to make an error here because I'm thinking, like, I want to know what process this relates to so I can start categorizing it. Right. But I will never think in the same way as, as, as the rest of the employees. So if I put like sales, marketing, website support, I mean, that might not be what they want to call it. So let's actually be smart here and insert a text column or process. So we can start gathering data at least, and then we can use that as, as a, as a grouping. And possibly later on when we see what's being submitted, we can create turn that into a dropdown column. Mm. -Cool. -My brain just went. Oh, yeah. I would have gone straight for -the time. -Yeah, and I did what? Well, I mean, that's this is why it's so important to think about. Like, what kind of behavior do you want to drive with your boards as well? I mean, the optimal column type is still the drop down, but I'm pretty confident that I wouldn't be able to get all the single potential labels that someone else might want to put there, right? -Yeah, you. -Might end up with a ton -of various. -Yeah, exactly. And let's do a lead column. Who's going to be lead for -this process. Right. -So all of your salespeople -this is another type of lead. -Mhm. Is there a better English word for it I don't like owner I don't want to call it project leader because there's not project leading. No lead man to lead. Lead. Fine. Everyone here, we know what we mean. -Right? Okay. -Awesome. And you may call it what you want. Fine thing about monday.com Mhm. So let's, uh, let's create our form because we don't need anymore to create the form. Right. Please use this form to submit your potential lessons. Identify them and then we can obviously we can put like links to like helping, um, material and stuff like that. Um. I mean, everybody's looking at me as typing process. Work or other variation lol. You say that? Probably problem or weakness? A lot of students write. Please describe the issue. Problem slash weakness in as much detail as possible. And if this was this is the big difference between lessons identified and incident reporting. If you do incident reporting you also need to collect like what's the date and the time and the geographical location. But you also normally ask about what do you think could have alleviated this issue. But you don't need to ask about that in the lessons identified process, because that's what the process is meant to answer. And we're hiding the status. You. Submission. Blah blah blah. Perfect. The form looks awesome. Testing the form. Post-sales. Customer keeps. There we go. Submit. And we now have our nice little item to start working on. I think it's good to to look at this from an actual case. So we're building this this actual form here. So the first thing we want to do is we're going to say okay this is in review. And right now we don't have anything that's happening right now. Uh, we're reviewing. We're looking at it. Let's make sure we have a nice item card to, uh, look at while we do this review. It's. Let's do status and lead. Let's move that one down here and let's give it a big, nice space to be read at. Now we have our status, our lead. We can see your description down here quite nicely. That's all we need for now right. Yeah. So here's the thing. In the next step, we can either have this as an as a pure intake. And once we say we want to start the lessons learned, we move the item to another board where we have the whole lessons learned. Normally you don't have that many submissions. So I would say that warranted. So I would actually say let's just add a group. That will be active analysis. Right. So when we say start lessons learned we want it to move down to active analysis. Let's make that automation straight away. I would like them to group active analysis. Create automation. Yeah. And now we really want them to assign a lead. So we are going to add with. Yeah. So you're adding a lead and then we need to start working with some sub items because that's where the magic happens. Right. In in in our lessons identified. The whole process is here. Uh, this is where, where stuff's going to happen. Quick actions. The thing is, Zacharias is not super -happy. -I was hoping you couldn't hear him, -but. No, he. -Oh, no. That's fine. Hope. -Hope? It's nothing too serious. -No, I think he's having a -bad day. That's about it. -Mm hmm. Gotcha. So really, like, now we are basically treating this as a project. So we are giving, like what? Uh, uh, initial analysis. Briefing. But sending actions. So this would more or less be, in my opinion, that for minimum, uh, sub items that we want on each item. Right. Quick actions like what do we need to do straight away. Then we do an initial analysis. We need a brief. And then we need to present our actions. And then we will continue. But all everything after this will be bespoke, right? I'm doing what I'm always doing. I'm taking a photo here on of, of my items so I can go into the automation, and I could actually add it to the same trigger. I don't need to make this into two ones, but if I go in here, I can no longer add anything to this automation. There is actually a trick to this. If you go in and you say duplicate the automation. Now I have the full control. So now we can say plus. Rate. Sub item. Plus And that will be our first four first. If. Action. Like that. Perfect. Then we have. Initial analysis. We think. And. -Action. -I think that should be -findings. -Yeah, exactly. Great automation. And then we just delete the old one. So that's that's a good. And uh, if we then want to add some sub items later on, you just duplicate this one. You add what you need and then you delete it. The old -one. -So that's actually a rather good tip. Otherwise you can end up with what I've seen in accounts with like 3 or 4 very similar automations, adding different sub items by the same figure. Uh, and now we're adding a new item, and we're just testing the automation to make sure that everything works as hopefully intended. There we go. It moved. And now 1234. Awesome. Refresh. Because I pressed it too quickly. And obviously we want to mirror all of this up to the main item. Mirror board, so let's link it to the sub items. Let's get the status. And let's duplicate. And the date span. There we go. -Action. Service. -Timeline. So I will obviously be the owner of, uh, working all of these. Let's say that I have, uh, completed them today. So now I do, of course, need to add like, what's the next steps? So this will be update as SOP to reflect. And then I'm using the actual checkbox feature here to make sure that I get a good little, uh, check checklist. Always. Never publish an item on the store without first. Ordering it to that office for visual and. Inspection and we need to say, uh, don't over saturate images. Try to focus on portraying real colors. Not cool filters. Uh, and then we have some -other lessons learned, I guess. -And order at least two products to see if -there's a color variance. -But let's add that. So the the lessons learned process. Again this is not a repository to create like the knowledge base of every changes we need the lessons learned process. When you're done with the lessons learned for for an issue, a problem or a weakness, you are killing this because the documentation, the result of what you're doing should be reflected somewhere else. If the knowledge only sits in the lessons learned process, you haven't done a lessons learned. You're still on lessons -identified. -Yeah. So true. Yeah, you actually need to -take those actions as well, right? -Yeah. So that's why I'm saying, like you don't need to create like a deep repository of knowledge bases and stuff like that. That's that's something else. Lessons to Learn is about. Gustav. And in this case, Fredrik. Going in and make sure that we change our standard operating procedures to reflect this. That that's what we need to do. And once it's done, we need to. Validated. Right? Yep. And we can also say like, you know what the the process was not done well enough. So we need to restart it. Yeah. And we I want to be quite cocky with everybody here because I keep saying that this is not a repository for dumb lessons learned. So when you change validated that's it. The lessons learned is done. You have updated all the other stuff. So we're actually going to be doing quite an aggressive thing. When status changes to validated. Archive item. Obviously this is quite bold, but it's to push the correct behavior again. If I let them sit in a group in the bottom of this board, I will have people referencing items here for, oh, can you can you tell me what the latest is on how we should do new product, uh, acquisition? Like, yeah, I'll tag you in the lessons learned. No, -that's not how it works. -You go to the procedural handbook, which is now updated. Exactly. So we validate it's gone. So with that said, you might have that operational handbook within monday.com as a knowledge base. Yeah, but those should probably not be the same thing. That should be updated from the learn. It shouldn't be the lessons learned. Yeah. That's so true. I mean, we need to reflect the lessons in training, personnel instruction, standard operating procedures, uh, agreement templates. I mean, it could be any kind of actions that need. And we need to update the agreement. We need to update the terms of service to reflect this thing. I mean, when you're done with the lessons learned, there's nothing else left for the item. It's just a record. So if you want to keep a record of what have we done? How much work, how much time have we spent on this that that's really awesome. That's something totally different. About. I want to go as far and say, let's not have that this -time because. -Yeah. Because I want to drive the behavior. Yeah. And you can actually do the best of both because you can archive the item and create a new item in another board, just like a -data point. -You're absolutely right. You're absolutely right. And then obviously if you want to have like other columns to support you saying like it's not enough with lead, I want to be able to see who are the subject matter experts that we need to bring into this process. That's totally fine. Like everything, we are trying to show you the basics here, which gives you freedom to -add on top of it. -Yeah, exactly. Don't copy paste, guys, but think, what do I need to support my process? But here you have the basics and the basic setup of how how to operate it. But then do you feel. Do I need a file column. Yeah they do. Oh well I had a fighting column. -Yeah. -I did consider it, but I figured that I wanted to still keep it very simple. Yeah, but it was part of my decision process not to have it here. Uh, is there any questions? I know that it might not be a very monday.com heavy one in this case. I think this is a good way of showcasing also how you can have something created in monday.com You then create additional work items and then once you're done, it goes into the archive. Done. And you have been a lot wiser thanks to the -process. -Yeah, not everything is for keeping everywhere, right? -Yeah. -Or in this case, this is kept everywhere. Not just graphically here. Yeah, exactly. Uh, Fredrik, I'm not seeing the chat is. Yeah. And if you want to, like, discuss your lessons learned processes and anything like that, I'd be. I'd be happy to oblige. Obviously, if you want to discuss risk management, incident management as well, that's something we we love doing as well. And we are going to have risk management right for the next -build with us. -Yeah. Which is going to be on the 7th of September. But with that said guys. Peace and love.