 Gyda afternoon everyone. I hope you're all having a fantastic first day at Drupalcon-Lill. I'm Alice, and typically I a senior delivery manager for a Drupal Agency called X produz adres, but today I'm going to be your Project First Day trainer. Firstly, hands up if you've ever worked on a project that didn't go quite to plan and maybe went over budget, maybe you didn't meet the deadline. Nobody. I see almost everyone's hands were up there and you're all in fantastic company greedy for the PMI, the Project Management Institute found that 70% of projects failed. Even the most successful project managers or agencies or developers amongst us will likely have been on a project that didn't meet its promised timeline, budget or scope. But the good news is that project failure isn't inevitable and there are things that we can do to avoid it. So, in today's session, I am going to be, if I can work the slide, there we go. Talking through, apologies, just lost my cursor, through, I'm going to stock up your proverbial first aid kits with some practical tips and strategies to spot the symptoms, there we go, of a project in crisis, giving it the best shot at survival, some tips for making sure your project recovery plan is realistic, and then finally, some strategies to keep your project out of the emergency room for good. Okay, firstly, let's stock up on some preventative medicine because some more good news, projects don't generally descend into chaos overnight. Instead, there will be often be tell-tale signs that something isn't quite right. And the earlier you can spot these signs or symptoms, the better. Early detection will not only provide you with the maximum opportunities for recovery, but it's also going to prevent even bigger setbacks, significantly improving your project's chances of success. But how can we spot these tell-tale signs? So, over the next few slides, I'm going to talk through three fantastic diagnostic tools, metrics, milestones, and honesty, and how each of these can help you spot the symptoms of an unhealthy project as early as possible, ensuring it stays track. Many of you might have a smart watch. You might be wearing it today. I'm definitely wearing mine because I think I'm going to be getting a lot more steps this week at Rupercon than I normally do sat at my desk, thanks to all of these lovely stairs. Tracking a handful of simple things such as how many steps I take or how many times I stand in a day really helps me stick with my fitness and health goals. And the same can definitely be applied to projects too. When it comes to metrics, there are a few things to bear in mind. Firstly, simplicity is king. Avoid at all costs by too much data and tracking things just for the sake of it. This can actually obscure problems and be unnecessary overhead to manage. Instead, I'd recommend sticking just a few critical indicators that are easy to track and easy to understand. Consistency is also very important as it will allow you to spot trends and therefore potential problems. I found that setting a regular time to check my projects metrics works really well. For example, every Monday. Metrics are pretty useless if they're kept in a report that no one's read. I'm sure we've all been guilty of this at one point another. So make sure you're encouraging the team to engage with those metrics by including them in things like retrospectives and planning meetings and share them visually as this will help improve understanding. Also, don't forget to make sure the team and stakeholders not only know that your velocity is 7, but also what does that number actually mean for your project so action can be taken. Here's a little snap of me on a previous project. As you can see, my project journey was marked by a series of checkpoints on milestones and these milestones aren't just there for decoration. They actually make great indicators of project health. For example, imagine you were going to break down a website redevelopment project into smaller milestones. One of your early milestones could be client approval of designs and if this design milestone isn't met when you expect it to be then straight away really early on in the project, you have a clear signal that something isn't quite right and action is likely required. To get the most out of your milestones, I'd recommend focusing only on the ones that directly impact your overall project goal. This is going to make tracking your milestones and spotting any slippages much much easier. Again, visibility is really key here. So make sure you're adding your milestones to your roadmap and updating it and sharing it with the team regularly. This is going to boost accountability and responsiveness. When it comes to projects, challenges are definitely a given, so it's really crucial to be able to discuss them openly. So when you encounter an issue, resist the urge to stick your head in the sand like these guys and make sure you're having that conversation early on when you hit the road bump rather than staying in the lead up to launch. The earlier in the project you can get your issues out of the open, the more you're going to be boosting team confidence and creating a space of psychological safety where hurdles can be discussed honestly and tackled effectively. One way you could do this is to add a section to your next retrospective where people have the chance to raise any concerns that they might have about the next sprint or the project as a whole. I recently actually had a really lovely client who was super excited about raising their first bug and I loved that. That's the exact kind of attitude that we should be looking to cultivate in software development because bugs are an integral part of development process. I'd actually be really concerned if I saw no bugs raised at all. I don't think that would be realistic. So I think it's time we reframe how we perceive bugs being raised and issues being raised and actually see them as a positive sign and celebrate their successful resolution. Embracing challenges is not only going to lead to better project outcomes, but it also forces a culture of continuous improvement and innovation. Hopefully using some of the tools that we've just discussed will have caused any issues before they sparred out of control, but in reality your project might already be in critical condition. And if that's the case, then don't worry because you're really not treading uncharted territory here and there are loads of great online resources on how to put together a crisis recovery plan. Over the next few slides, I'm going to talk a bit more about some practical tips for crafting a realistic and achievable plan. A realistic plan is absolutely critical for re-securing team and stakeholder trust, which is likely going to have taken a bit of a hit in a crisis, curbing any further complications and maximising your chances of successful and permanent recovery. In particular, we're going to talk a little bit about the importance of accepting and acknowledging the issue, some key things to bear in mind when it comes to resetting your approach, and some tips as well for fueling buy-in and enthusiasm for that plan. Before any pros can be made in resuscitating your project, it's absolutely crucial to recognise and acknowledge that that actually is a problem. While this step sounds obvious, it can actually be one of the most challenging as understandably it can be pretty daunting and uncomfortable to live with the bad news. But until the true nature, extent and implications of the problems are acknowledged, it's going to be very, very hard to get the necessary resources, support and level of urgency required to effectively resolve that issue. And it's not only important to acknowledge the problem, but it's also key to do this swiftly as possible, because delaying the news is only going to make the situation much worse and a road trust even further. So when you're informing the stakeholders, be honest about the extent and implications of the crisis, the actions you're going to take to resolve it, and also what support you need from them. The key here is to make sure you're involving the right people, i.e. the people have the keys for the emergency equipment, the additional resources or the power to move launch dates. It's really crucial that you're honest about what happened, but avoid playing the blame game. Instead, focusing on the issue at hand is really key, and make sure you're taking time to listen to everyone's concerns and questions. This is going to help foster a shared sense of responsibility, which will ultimately increase everyone's willingness to help the recovery. You're going to need everyone's hands on deck in this instance. Once you've acknowledged and communicated the crisis to the team, it's time to administer some CPR, some critical project recovery. The next step involves assessing and stabilizing the situation, and then collectively defining your immediate care plan. It's really worth considering at this stage, whether you need to temporary downstool tools or at least apply some partial anaesthetic to some work streams so that the team can focus in on the recovery planning. If the team continues to deliver work while also trying to take stock, it's essentially a bit like trying to change a car's tyre while the car is still moving, and this could result in re-work and increased costs. It sounds counterintuitive, but it's really worth considering. To stabilise your ailing project further, it's also worth considering whether you should temporary free scope. This will allow for a more predictable and focused period, and it's going to give the team the space it needs to address current concerns without distraction and with new complexities. You can also use this break to re-evaluate the remaining deliverables, so make sure you avoid falling into that sunk cost fallacy by parking anything that's not absolutely essential to the project's goal. To keep the team and the recovery focused, I'd also recommend defining a clear recovery goal. And then, focus on addressing the most pressing issues first, i.e. the issues that will have the biggest impact on the project and the recovery goal. Unfortunately, when it comes to recovery, there is no plan B. This is it, so avoid committing to a new project schedule until you can create one that's achievable. Nothing is going to A and A stakeholders more than being told, oh, just be one more month, and then to be told, oh, just one more month and then again, oh, one more month please. So also make sure that you're over-communicating throughout the recovery phase, so establish regular and clear communication channels and control the flow of communication to stay ahead of any concerns. A warning sign for me would be if people are chasing you for updates, it's likely your communication isn't effective. And just as important as providing updates is ensuring that any old information is removed too, such as outdated plans to avoid any confusion. A successful recovery ultimately hinges on your team's commitment. Dupal projects are, of course, software-based, but ultimately they are driven by us, they're driven by people, and without those people's trust and buy-in, it's going to be very difficult to move things in the right direction. Chances are your team's trust and morale is going to be a bit low, and if this is your situation, there are some potential antidotes to this. Firstly, prioritising honest and timely communication. Poor communication can be a bit of a silent killer, pun intended, so share your discoveries with the team while also highlighting what's working well to help build confidence. Involved them in every aspect of the recovery that you can. This will not only rebuild trust and commitment, but you're going to get better recovery plans overall because you're going to be drawing in everyone's expertise, and they will feel more ownership of that plan. Another way to encourage commitment is a generous dose of high morale. Be sure to recognise and celebrate achievements, both the big ones and the small ones. This is going to help boost motivation and enthusiasm. Taking the time to say thank you, both publicly and privately, and acknowledging people's contributions and hard work in patients can go a really long way. Once a project has successfully navigated its crisis and is back on track, it's essential to implement some strategies to maintain stability and to keep your project out of the emergency room for good. Some things that I found a key to preventing crisis relapses are firstly, carrying out an in-depth root cause analysis of the crisis. Secondly, ensuring that you're not repeating any past behaviour, and finally, monitoring your project very closely. A crisis can actually be a fantastic learning and growth opportunity. So once your project is in a more stable condition, I found that conducting a thorough analysis to better understand the root cause is key for long-term recovery. Make sure you're documenting those lessons learned to prevent similar situations in the future and use this deeper dive as an opportunity to validate your recovery plan and corrective actions in the longer term. It's absolutely essential to avoid going back to what you were doing before the crisis. Repeating the same behaviour and expecting different results is as good old Einstein says here, insanity. So think about using some tools you might already be using such as retrospectives as an opportunity to stay accountable and to evaluate whether you've actually changed your approach and behaviour. And finally, just like a doctor would keep a closer eye on a poorly patient, keep a very close eye on your project post-crisis. So firstly, increase the frequency of your monitoring and reporting activity and don't forget to factor in the human element too by paying close attention to team dynamics and metrics, not just focusing in on the numerical side of things. I'd also recommend considering tracking progress using inch stones. Inch stones are essentially goals on a smaller basis, a daily or weekly basis. This level of admin is probably a bit excessive if you're working on a smooth running project, but I found for a trouble one it can make a huge difference. So if you only take one thing away from today, I hope it's at least that you can rest assured that if you've ever had a project go off the rails, you're really not alone. And it's not all doom and gloom. There are some tangible things that we can pack into our emergency kits to prevent, turn the tide and even thrive in the face of project failure. So yeah, thank you all so much for listening. Please do feel free to share any feedback about this talk or the conference via the Apple QR code and to help out our lovely open source community by checking out the contribution opportunities and workshops. Thank you again.