Stop me if you\u2019ve heard this:\nYou have a breach of the terms of your service level agreement (SLA) or a bad incident in your IT organization that results in lost productive time or embarrassment to your organization. Or there is consistent, negative feedback regarding the service desk and the activities they do in support of the user community. Or a change goes through to the production environment that breaks something else downstream. Most likely, there will be a \u201cpost-mortem\u201d meeting to determine what happened, and at some point in that meeting someone will say, \u201cWell, we should revise to ensure that doesn\u2019t happen again.\u201d\nWhat happens next is that you either ask someone in your organization to review all of those processes or you hire an external consultant to do that for you, most likely through a process assessment. This is great, but I\u2019m here to challenge you with a different point of view.\nAsk yourself this question: In the past 10 years, how many times has that incident occurred, and how often have change management processes, for example, changed? Not many. You can probably recite the steps of both processes with your eyes closed. The reference is sitting right there in your bookshelf, in the form of many of the best practice frameworks and standards that exist today. I think, though, that some organizations spend too much time focusing on the mechanics of process improvement the wrong way.\nYou can get away with writing a process document on one page (really!) if you start looking at your service management system in a holistic, systematic way (think about the \u201cwork holistically\u201d principle of ITIL practitioners). I would like to offer you some ideas as to how you can think differently in terms of your processes, and how to improve them.\nLet\u2019s start with scope. I discussed scope in a previous post, but this is something worth revisiting. If you define a good, concise and sufficiently narrow scope of services, your processes can be adapted to support and react to situations specific to the scope. Let\u2019s say you\u2019re an internal service provider for a supermarket and you\u2019ve determined that your vital business functions (VBF) revolve around ensuring that merchandise gets efficiently to the stores and that cashiers are able to sell and process transactions. (We could include more, but indulge me on this one. Yes?). What would an incident look like for these? An inoperative point-of-sale system could be one. The inability of a store to scan and register incoming inventory could be another. I could go on, but having a narrow scope of service helps you in identifying potential issues that can affect your VBFs, along with everything else that this provides (a well-defined, tight configuration management database, well-established service level agreements \u2014 or perhaps expectations?).\nThere will always be unexpected issues (that cashier who spilled coffee on his terminal, for one). But thinking about these types of issues at a very high level (as part of your user profile and patterns of business activity analysis) can be used as an input for service design to think around some of those things and develop countermeasures in design that can help the organization avoid some of these issues. It is my opinion that by \u201csweating\u201c the design of a service \u2014 that is, by constantly reviewing the design specifications of a service \u2014 you can avoid many issues in operations, and that includes incidents.\nSo what does this have to do with writing processes in one page? Well, I think that the vast majority of process theory exists already. ITIL has 26 processes and functions, for example. CoBIT 5 has 37. (And very interestingly, it has more for processes related to planning and organizing \u2014 13 \u2014 than it does for delivery and support \u2014 6. I don\u2019t know. Food for thought.) There are a handful of clauses in the ISO\/IEC 20000 standard, and I could go on and on.\nThe point is, this is one area that you can go very lean and first strive to focus on defining a process that converts an input (e.g., a broken service) into an output (e.g., a restored service) in a very succinct, high-level way and then refocus your organization\u2019s improvement efforts in all of the other aspects that affect the execution of the process. The way I would do it is to start thinking this way: \u201cIn this organization, our incident management process looks like , adapted and inspired by \u201d and do more of the heavy detailed definition of what the process will do as design and transition thinking.\nLet me give you a practical example. The sample incident prioritization matrix (note the judicious use of bold for the word "sample") is defined in the incident management chapter of ITIL\u2019s Service Operations. Everyone knows this and I\u2019ve been in organizations that have lifted (copy\/pasted, literally) the exact same wording and matrix from the book into their (very lengthy) incident management process documents. (And this includes tool vendors. You know who you are.) What does that do in actual operations? Very little, as service desk resources struggle often to prioritize based on what they hear from customers or what they see from monitoring tools, if they have them. And this is something that should be dead simple: A downed point-of-sale system in a store is tied to a VBF, and that\u2019s not good. The VP of HR can\u2019t print in HQ, and that\u2019s not good, either, but the expectation has to be set that VBFs are more important. (More on VIPs in another post. Promise.)\nSo how can we spin this around? During design and transition, and with the inclusion of your operations folks at all times, you can do a couple of things. You can establish all of the alerting mechanisms that operations will need through event management, establish what Priority 1, 2 or 3 incidents look like based on the service, and you can create knowledge, scripts, procedures and so on before operations has to struggle with actually supporting the service. Why do service desk agents have to ask customers \u201cHow many people are affected?\u201d By design, you should know! Most of the time anyway, and it shouldn\u2019t be the responsibility of either the user or the service desk agent to figure it out for you.\nAs for the unknowns? That\u2019s what continual service improvement is for. There are some situations that you can never prepare for. That\u2019s a given. But I\u2019ll bet you that many of those have a root cause that you have not discovered yet.\nSo for those process documents, how about defining at a high level what they look like for your enterprise? Instead of spending time developing long and boring documents that no one will ever read \u2014 in essence rewriting bits and pieces of ITIL itself \u2014 why not adapt that to what they look like for your organization at a very high level and then develop the necessary knowledge based around the organization\u2019s VBFs, its supporting services and other details?\nScope and design are your best friends when designing processes for your organization. Use the frameworks wisely, as reference points. Adopt and adapt to your organizational situation, and always be mindful about doing continual improvement.