I hope you're all feeling refreshed after the time change this weekend—though it certainly feels like we've zipped through multiple time zones, doesn't it? But let's bookmark the daylight savings discussion for another time.
Reflecting on last week's conversations, I tackled the ever-present challenge of securing buy-in for new or modified processes. It's a topic that's always resonated with me, especially since it harks back to a pivotal read from a few years ago, "Agile for Everybody." Back then, "Agile" was just starting to buzz around the corridors of the organization I was part of, sparking curiosity and a bit of a scramble for more information. As someone who's always keen to learn, I plunged into understanding Agile, eager to see how it could refine my role as a collaborator and contributor.
Agile, originally a software development approach, captivated me with its core principles, which are outlined in the Agile Manifesto:
- Prioritizing individuals and interactions over processes and tools
- Valuing working software over comprehensive documentation
- Placing customer collaboration above contract negotiation
- Embracing responding to change over following a plan
As risk managers, we might find these principles slightly jarring at first glance. We're champions of documentation, and the idea of not following a plan seems almost counterintuitive. But there's an invaluable perspective here for us. The principle that resonates the most with me is the emphasis on starting with our customers—in our case, our internal stakeholders. We're essentially offering a service when we support risk informed decisions making, and we do have internal clients.
So, how does this relate to generating buy-in for a new process? We often default to presenting a polished, final processes, forgetting that we're usually not the sole users of these processes. Agile teaches us to involve end users from the start, gathering their input throughout the development cycle. It was a "duh" moment for me too, but it makes perfect sense. By prototyping and iterating based on user feedback, we're more likely to develop a process that not only meets the users' needs but is also welcomed rather than met with resistance.
Let's take these insights and see how we can apply them to our work in risk management. It's about blending our expertise with Agile's user-centric approach to create processes that truly serve our internal "customers."
Comments