Let's take a look at guiding principle number 3: progress iteratively with feedback. It's kind of like ITIL took a little bit of guidance from the software development life cycle or agile. It's like do a little bit of work, gets some feedback, some sign-off, do more work, get additional feedback and sign off, and continue on in this type of waterfall or agile process. This is where we talk about feedback loops and gathering responses in a fast way so that we can make our adjustments and continue on. We never want to find out that something is not going to be successful in their solutions after the fact. Using this principle includes breaking down tasks into smaller, manageable parts, allowing subject matter experts to have an overview of the task, approve, or provide comments or make changes so that we can respond quickly and adjust and move on to the next iteration. Using this guiding principle allows for IT technicians to make improvements and to gather feedback while they're actually developing a solution. We all know we want to make fixes as fast as possible, and not all improvements can be done simultaneously. Breakdown your improvement areas into smaller sections and allow for revisions. These are called feedback loops. It's part of a continual evaluation process and it will allow us to respond to issues faster. If there is an issue and we need to make a fix of some type, we can get feedback quicker and even respond to failures faster, so output from one iteration is used as input into the next. Use something we call minimal viable product, where a version of the final product is kind of looked at in a Beta mode or pilot or prototype. Then it can be validated, and then we can move on to building a bigger solution. We want to give ourselves time to re-evaluate,you know look at the smallest area for feedback, and then move on to the next area. This is very beneficial in trying to catch issues early on. Guiding principle number 4: collaborate and promote visibility. This is where you share the status of your development or your work with other subject matter experts to allow for transparency, to allow for buy-in. If there's any understanding of the solution that stakeholder has and they would like to provide some suggestions or some recommendations, this is their opportunity to do so. We may not get a consensus, but what we can get is an opportunity for others to take a look at what we're doing. We don't want to work in silos or in a vacuum. Using this principle is to provide updates, regular updates to the appropriate stakeholders even if it's bad news, even if it's about something that is not going to roll off successfully. We want to figure out alternatives and alternate solutions. This creates trust. We want to break down those silos across teams and share as much information as early on as possible. Collaboration and promoting visibility is really about sharing information, and maybe not getting a consensus, but being very open on what you're working on. You can work with critical team members and stakeholders to get their assessment. You can work with customers, developers, and suppliers, and you can work with stakeholders at different levels within the organization as well. If they have an understanding, even if they don't have buy-in, at least, you can identify what their issues are. You want to be inclusive and you would like to get cooperation from as many people as you can as possible. But this allows everyone to take a look at the solution for bottlenecks, to eliminate waste so that everyone can understand what the project goals are and what is going to be the output. This promotes trust and identifies a sense of urgency and priority when you share information and you share data with other team members. Guiding principle number 5: think and work holistically. This is pretty common sense. It's exactly what it says. Look at the whole organization even when you're implementing and moving on, updating parts in different sections or different tasks within the organization, please take a step back, look at the big picture, and does it add any value to the organization as a whole? This stops working in isolation. Using this principle is how we consider. When we get ready to automate, you have to look at the entire organization, the coordination that's going to be needed when you roll out the solution. We need to look at this in a holistic view because changing one aspect of an organization could definitely affect another. We know that service management entails everything that we do to try to roll out IT services and products in an integrated way. There are a lot of dependencies and relationships between components within the organization. That's why we want to recognize how complex our solution is going to be. Look at any patterns that may hinder the business from looking at your IT solution. Is it user-friendly? Does it provide valuable outcomes to the whole and not just certain parts of the organization? It's not just valuable for certain customers or certain departments, but for the whole. We want to look at integrating our solutions. Think about collaborating in the visibility, in the coordination. We want to look at our interactions so that if we do decide to automate, we can remove any of those complexities early on, so that if the automation is going to be an improvement in the organization, it improves everyone together, not just certain parts.
