Hello, everyone. Thanks for joining me today at Conf 42 Platform Engineering. I hope you're having a good time so far and learning a ton. I know, myself, I'm definitely learning from all the others. Let's try to keep it going. Today I want to share with you a technique that is called pre martem that can be used to hack the future. But why should we care about that? projects fail sometimes. Maybe not yours, maybe you have been lucky in your career so far and none of the projects you've worked on failed the project. But it's quite a typical scenario. Most people have had failure in the past, and while we don't like that, it's something that do happen. In fact, 74 percent of all IT projects fail, depending on definition of failure, obviously, and they don't all end up burning in flame. Sometime it may be just some delays, sometime could be some feature missing, issues at the launch, and you have to fix them in the firefighting for a few weeks before it can come back to normal. So you can deal with failure when it happens. Obviously, much better to prevent the failure from happening in the first place, or reducing the risk of such failure as much as possible. So the technique I want to share with you, it's called a premortem. Let's get into that. What's a premortem? It's actually a risk discovery technique that you do as a group. So it's similar to a brainstorming. It's really similar to a parse more temp, actually, but we use a two step process. First, we set up a scenario, which is a hypothetical future, where the project have failed. So if your project launched, for example, on May 4th, that's how you would set it up. You would, as a group, you would say, we are now May 4th. The project was launched last week. It's a complete failure, whatever. What should we do now? How this, how did this happen? That's what you asked yourself. What did go wrong? So it's really the same as a, post mortem. You ask what went wrong and why, but you do that before the failure actually happening. That's why it's also similar to brainstorming. You want to get a lot of, ideas out. Using this framing, it's actually prove, proven to increase the ability to identify reason for future outcome. So there's been studies on that using this kind of framing. better at that than just asking what could go wrong without the framing around it. So while it's simple to do, as I've described, you already know how to do that. From my experience, there are some ways that you can get more out of this process, and there are also some things that if you do, you will pretty much get nothing out of it, or it even could cause harm. to the project or your company culture, anything. So it's important to, do some stuff correctly and some stuff to not do it at all. Let me share that with you based on my own experience. First thing is much better to have a small team doing that, a small group setting. Like much, pretty much all brainstorming technique. The bigger the group, the less people will share. also have less time for everybody. It's time consuming if you want everybody to talk. So it's much better to do that in a small group as possible. That said, you want to also have diversity of thought. So you don't want to have only like three DevOps engineer doing that exercise because they will all have most likely same perspective. You will get less idea. So again, similar to when you do. brainstorming, you want to have diversity of thought. So different people, not too many, but different people, different background, different part of the company, as long as they are relevant to the project. So you could have a project manager, you could have a salesperson, potentially, you could have a engineer, different people in engineering, depending on what you are doing in the project, try to have a variety. So you get diversity of views. That said, some don't. So don't problem solve. That's something I've seen often and again, especially with engineer. We like to solve problem. That's basically our job. Just solve problem all the time. So as soon as somebody say something, often you will have some engineer that will go in and say how we can prevent that problem. You have to stop them right now. Like you don't want to get into a situation where you spend all your time solving one problem. what you want to do at this stage is really just get as much problem as possible, as much possible risk, as much potential problem, because they may not happen. So you just want to get them out. So you keep note of the problem, but you prevent people from solving it. It's not the right time. we'll do that at the later stage in the project life cycle, but right now don't problem solve. Also, don't reject anything. Don't throw away. That's a big issue. Anytime you are brainstorming, if you start to tell people their idea is stupid, obviously they will stay quiet and stop sharing. So you don't want to do that. You want to keep everything coming in. Encourage. Just list everything. Something I've seen an example of that at elsewhere, other, place. Somebody said that cause of project failure could be that the CEO die before the project launch. So that may seem forefetched. Not sure what you can do about it as an engineer or anybody on the team really. Maybe you don't have to care about that, but in any case, don't reject that. Just list it. Thank you, we can move on. That said, instead of rejecting if it's a too wide problem that is raised, you can keep asking why. So try to get deeper into the problem to get more value out of it. For example, if somebody says that, maybe the project failed because the server crashed. you can ask more questions like, what do you mean by server crash? Was it like overloaded? Was it actually a card that had an issue? And, The server application failed, was it too many users login at first, too much account creation, like try to get more and list them out, basically, but don't, if you see that it is a problem that is vague and high level, and you could see that there could be multiple reasons why this happened. Then keep digging, ask why, so you can get as many specific problems as possible. Also, all along the journey, when you do the primordium, at the beginning and during it as well, remind people what the goal is for this exercise. So the goal is to gather ideas, not solve them, no stupid ideas, all ideas are welcome. The goal is to gather ideas. a list of potential problems in advance so we can act on them. So sometime I've seen that, people are getting pessimistic because they just keep hearing about all the way things can burn down. so remind them that the purpose of that is to list everything that could happen, doesn't mean it will happen. And hopefully thanks to this activity, they will not happen because you Raise the problem in advance so you can then build your project plan or address that anyway Later on but at least you are better tooled To solve the problem. So it's important to remind people of that all along and also at the end after everybody Brought all the point you just remind them. Thanks. Now we have all these issue. We much better suited to solve the problem and not have a project that failed So then what? You've done that, you've spent a few hours listing everything, you have a long list of words and ideas and everything. So from that, you need to adjust your plan. So the first thing is to group and clean up all the items you have on that list. So this possible that people you were talking and they mentioned, basically the same problem, different way. So you could have different way of saying the same thing. You group them together. you can try to like previous example where you keep asking why. So you may end up with a bunch of problem or potential risk that are different, but could result in the same, behavior in the end. So you may still want to group them together, make it easier to tackle and think about that. So you group and clean up item. If there are stuff, that were not clear, or you don't remember, it's fine to go back to the people that brought the idea. If you remember, you can clarify, but the goal is to have a clean list of items. Then you assess the risk of each of them. Again, if the risk is CEO could die, maybe not much you can do about it as an engineer, but also, maybe that's not the biggest problem that will come if the CEO dies. Maybe it will not be. project launch failed, the whole company might be in jeopardy, so maybe, not a big risk, for the project itself. some risks you may ignore, some risks may be ready for fetch, so you have to use your own judgment, talk with people, see, like, how likely risks are, because obviously, That's always the trade off. If you prevent all the possible risks, it will take forever to build that. So you have to be strategic about it and only address the most likely risk that you've listed. And then you share your risk mitigation plan with everybody. It's important to follow up with people that did the exercise in the first place. Of course, you can share with whoever is relevant, but, to close the loop with them, they were the one that brought all the issues. So it's good to follow up with them saying, Hey, thanks for participating in this. We now have this big list of issues. We grouped them, we've looked at them. Here is the plan to address the one that we deem to be most likely are worth fixing for that. It's possible to, say that, this one is really unlikely. We can solve later on. Things like that, but to have a plan and share it with people and how to address that, this will well actually prevent the project from failing from this scenario, but also give more confidence, everybody in the team about the chance of success. So seeing that, Oh, We had that big list of issues. And yeah, I see that this plan will address them. We will have that person work on this problem. We are taking consideration about scaling issue as we build the backend services. like all this stuff will be in the plan. So people will be much more motivated about the project. the morale will be higher. So even just that in itself is a benefit and you can prevent failure just because people are more optimistic about the outcome. And that's pretty much that. So thank you everyone for joining. My name is Laurent. I'm happy to discuss further during the conference in the networking, section. And if you want to follow up with me, stay in touch, happy to chat about this and other stuff. Thanks again and enjoy the rest of the conference.