Learn a four-phase framework for AI for Good projects: Explore stakeholder needs, Design prototypes and data strategies, Implement and test, then Deploy and measure impact. The phases iterate rather than follow a straight line, and projects often fail, so realistic expectations matter from the start.
Welcome back. In the first week of this course, you learned a lot about how machine learning works, what kind of projects teams are working on out there in the AI for Good space, and some of the practical considerations that you need to keep in mind when taking on such projects. In the second week of the course, you'll now be walking through a framework for structuring your approach to AI for good projects. In fact, this is a framework that you could apply to any real world project where AI could be part of the solution. By the end of this week, you'll have the tools you need to dive into the case study for making air quality estimates in Bogota, Colombia. Now, first, I'll just say that there is no official or universally accepted framework for approaching AI for good projects. But the framework I'll be showing you here is based on a collection of best practices drawn from my own experience in disaster response and public health, and also from building AI driven products in industry, as well as from a number of other stakeholders who are working on this space. So I hope it can serve you in the projects that you will work on here in this course and in the future. In general, AI for Good projects, like pretty much any project, happen in a set of stages or phases. For your work in these courses, I've broken up the project lifecycle into four phases, which you can think of as first, an explore phase where you're connected with stakeholders, defining the problems that you want to work on, evaluating feasibility and determining whether AI can add value as part of a solution. Then, if your exploration of the project looks promising, you can move into the design phase where you're prototyping your solution, developing your model strategy, investigating the data further, and thinking about how you ensure data privacy, as well as how potential users will be interacting with your system. Now, it's possible that within the design phase you'll realize that some of your assumptions coming out of the explore phase aren't holding up and you'll need to go back and explore further, have more discussions with stakeholders, and maybe iterate on your problem statement. If so, adding this little arrogant backwards here from design to explore to suggest that this can be an iterative process and sometimes you might need to go back to a previous phase if you discover that you don't have what you need to complete work in the phase you're in. And to be transparent, a lot of the time you work out that you're not able to complete a project successfully at all. And this is nothing to be ashamed about. The majority of projects focused on social good that I've worked on didn't have a demonstrable impact on the communities that we were trying to help. The majority of AI projects that I've worked on or technologies aided by AI weren't really able to demonstrate a very significant improvement in that product by using AI. So if the majority of AI projects don't work and the majority of for good projects don't work, you should not be surprised that when you try to combine these two very difficult areas, the majority of ideas, no matter how well intentioned, are not going to work out. And being able to recognize that you're not likely to reach a successful outcome is actually one of the most important leadership and design skills that you can develop. For this course we are going to talk about use cases where we do think that you'll be able to have a positive impact. So in this model, once you've settled on a design, you'll move into the implement phase where you do what I'm calling productionizing your models. And this really just means taking what you've been designing in some sort of testing environment and getting it ready for deployment and integration with your user interface. And then you'll also test your system for performance and usability. Again here it's possible that through your work in the implement phase, the really some aspects of your design just aren't going to work out. You need to go back to the design phase and that's okay. So met in this other little error here going from implement back to design, because that can be a path you take as you iterate towards your final product. Once you've got implementation you're happy with, you're ready to deploy. Now of course there's a lot more to deployment in terms of technical details than just pressing the button and going live. But for the purposes of this course, I'll just draw this little rocket ship taking off here to indicate that deployment. And note that there are a whole other courses out there on the technical aspects of a successful machine learning product development, but we're not going to be talking about those details here. After your system is deployed, it's time to evaluate the impact, communicate your findings, and then decide what to do next. At this point, a number of things might have happened. Most commonly, perhaps you'll have discovered through deploying your system that there's something you would like to tweak about the implementation. So you go back to the implement phase and eventually relaunch an updated version of your product. Or it's possible that you discover something about your design ultimately didn't meet your expectations. So you decide to return to the design phase and rethink certain components of your system before implementing a new solution. Or it's possible that you decide to explore a new aspect of the problem you're initially working on, or go explore a new problem altogether. All of these could be very common outcomes, and I can say from experience that when you're working on a real project, things can seem a lot more chaotic than this relatively simple diagram might seem to indicate. But what I can also say is that you keep this framework in mind at every stage of the project. Then you'll be much more likely to arrive at successful outcome, or at the very least realize why you're getting off track and then be able to get up and get back on track as effectively as possible. I'd like to mention as a side note that if you're familiar with software development practices, this might seem like a waterfall development paradigm. But knowing where you're at in terms of evaluating your project impact could equally apply to agile development paradigms with more frequent iterations. In the next few videos, I'll walk you through an example of a project moving through all four phases of this framework so you can see how things might progress. For one particular scenario.
