Project recap
For this project, our team developed an AI strategy proposal for Erasmus MC, one of the largest university medical centres in the Netherlands. The core problem we tackled was in nurse rostering. When a nurse calls in sick, the scheduler has to find a replacement quickly, and the way that replacement is currently chosen tends to pile up undesirable shifts on the same nurses over time. Our proposal introduced a hospital-owned strain rule that ranks the feasible repair options by their cumulative impact on each nurse, supported by a GenAI layer that summarises the facts and drafts a monthly review, while the planner always makes the final call.
Early stages
When we started out with the project I was, just like everyone else, heavily involved in the brainstorming phase. During this first phase I quickly realised that finding an actual business problem is way harder than I initially thought. It took way longer than expected and there were loads of discussions. I was not used to uncovering a problem from scratch, since during my bachelor’s I always had a problem handed to me, instead of actually trying to uncover one myself. That really opened my eyes to how difficult this actually can be in practice. I also realised that it is really hard to not force AI onto a problem and to make sure that AI is genuinely providing value rather than just being added for the sake of it. I did use AI as a brainstorming tool during this phase to get us moving in the right direction. But something I learnt during the lessons is that general LLMs are accessible to everyone, which means other groups would probably get the same results if they used them the same way. That is why I decided to not make it too specific from the LLM, but only use it for rough ideas and brainstorm further from there ourselves.
Contribution (early phase)
When we finally got around to meeting for the first time after our feedback, after loads of discussion, I was the one that proposed a division of work that we could follow. Someone else suggested one as well, but the team eventually decided they liked mine more, so that is the one we went with. I also tried to put in a lot of effort throughout the project to see who could work when and to plan around that. In general I was very active in our WhatsApp group chat, since I like to be structured and I could consider myself a bit of a control freak when it comes to these things. I frequently asked how everyone was doing on their parts and when the next meeting would happen. If a random idea about the project popped into my head, I put it into the group chat even if it seemed useless at the time.
Contribution (Component 2: Business Model)
For the actual project components I worked on component 2, the business model, and component 7, governance and failure. When working on the business model I really learnt how important this business side is to everything. Before I always thought that business models were kind of generic and vague. But having a structured plan where everything aligns is extremely important for the actual success of the proposal, since I and the others realised throughout the project that if something does not align with something else, the whole case becomes invalid. So I discovered that this business model component really lays the foundation where the whole project rests upon, together with the problem and opportunity part of course. One of the most important things I learnt was to really differentiate value creation, value delivery and value capture. At first during the lectures it was still not really clear to me how these three parts are different from each other, but when I worked on the project this distinction became so much clearer. I also had to really dig deep into all the different models that we learnt about, since I really did not want to force a model on the project if it was not needed. Something that also caught me off-guard was that I had to do quite a bit of co-operation with other team members to make sure things aligned, especially with the person that worked on the ecosystem analysis. I made sure to communicate well and also bring these discussions into the group chat so everyone was aware.
Contribution (Component 7: Governance and failure)
Then for component 7 about governance and failure, I honestly learnt a lot of things that I had never really thought about before. Before this course I think I would have described governance as making sure a system follows the rules, and that was basically it. But going deeper into it really changed that view. I learnt about things like data minimisation, least privilege access, and what it actually means to have meaningful human oversight rather than just a human that clicks approve without really checking anything. These were concepts I had heard of vaguely but never really understood in context. Working them out for an actual case made them feel very concrete. I also learnt about the AI Act and what it means for a system to be classified as high-risk, which was something I had zero knowledge of coming into this course. The fact that a design decision, like keeping GenAI out of the selection step, can directly influence whether a system falls under that classification is something that stood out for me. Before figuring this out, I just assumed we have a traditional AI program, but it makes sense that we are not, since the AI is not there to actually select anything and the human remains in the loop. I also never really thought about legal and regulatory positioning as something that actively shapes how you build a system, but now I see that it is a real part of the design process. In general this part of the project changed the way I think about AI. I now see that building something technically is actually the easier part (especially now with AI as well), and that governance, accountability and privacy are where it gets genuinely complex and where things can go wrong in ways that are hard to see coming. To me it seems like the AI industry moves more towards to overall management of the application and everything around it, rather than the actual technical buildup of a program. This is also something I noticed in the other course (Designing Business Applications).
Contribution (Slide deck and pitch)
The last thing I want to mention is my involvement in the slide deck and the pitch presentation. For both of these I was heavily involved in the discussions about how we were going to organise everything. We had different versions of the slide deck that we shared in the group chat and I, along with others, always gave feedback on these. I clearly explained what I did and did not like, and sometimes I had to be a bit more critical and harsh than I am normally used to, since that does not come naturally to me. But it went better than in the past, which I see as a positive development in myself. Then for the pitch itself I proposed multiple options as to how we could divide and structure it, and I also made the final division of who would present which slides. In general everyone participated really well and did their own parts, so in that sense my role was more about the overall organisation and making sure we presented as one coherent team rather than six separate people.
