Skip to main content

Posts

Showing posts with the label Process

Filling the Process and Framework Skills Gap

By Donna Knapp For many organizations, the COVID-19 pandemic exposed one of two ends of a spectrum: poorly defined processes, or overly-rigorous processes. At either end of the spectrum, these organizations likely struggled to adapt as the pandemic impacted our lives. For those with poorly defined processes, things were probably pretty chaotic. For those with overly-rigorous processes, things were most certainly taking way too long. Even organizations with well-defined processes felt, and continue to feel, pressure to speed up the flow of work, minimize toil, and automate processes where possible. To do this, they must develop a culture of continuous improvement and learning. Continuous improvement is an ongoing effort to improve all aspects of an organization; its people, processes, tools, products, services, and experiences… all of which are tightly integrated. Whether improvements are large or small, what matters most is that they are constant. The highest performing organizations a

ITIL® 4 and the Evolving Role of Roles

By Donna Knapp In the context of work, a role is typically defined as a set of responsibilities, activities and authorities granted to a person or team. While a role can, at times, represent a full-time job, this is not always the case. In the course of our work, many of us play different roles (i.e., we wear different hats). For example, we may play different roles within our teams (e.g., team lead or team member), or within practices (or processes) (e.g., practice owner, process owner, or practice/process practitioner), or in the context of a framework or methodology (e.g., customer, user, or sponsor; or product owner, scrum master, or scrum team member). Roles are important because they provide greater flexibility than job descriptions, which are often bound to formalized performance plans and perhaps even to contracts. This flexibility is important because organizations are increasingly adopting operating models that are more evolutionary and less structured than most companies h

Optimizing Value Streams and Processes

Value streams are getting a lot of attention these days for a couple of reasons. One is that value streams allow us to identify opportunities to minimize waste or bottlenecks across organizations, processes and functional silos, and to improve the flow of value. Organizations adopting DevOps , for example, are using value stream mapping as a way to improve the flow of activities during the software development lifecycle, and to improve cross-functional collaboration. Another reason is that value streams direct our attention to what customers value. For example, organizations can use value stream mapping to streamline new product development activities, improve time-based measures such as lead time and time to market, and identify ways to improve product quality. They can also use it to streamline the activities involved in integrating a new employee into the company and its culture. What these both have in common is that the focus is on optimizing the value-adding activities; with the

Constructs of a “Service Relationship” – ITIL 4

Generally, when we think of “relationships,” we immediately think of the people aspect. In ITSM, we are referring to the relationships between third-party vendors, suppliers, customers, and many other stakeholders necessary to deliver the optimum service. It is mandatory to manage those relationships at the appropriate level. One way to understand the “organization and people” involved in those relationships is to understand the constructs of a “Service Relationship.” ITIL provides us this model. Starting from the bottom of the diagram and moving up, let's discuss the critical elements of a Service Relationship: Resources – All resources including people, process, and technology. In ITIL terms, that includes resources from all Four Dimensions: People and Organizations Information and Technology Partners and Suppliers Value Strea

Up YOUR Game – Become a Certified Process Design Engineer!

I find that there are many people that do not understand WHAT a Certified Process Design Engineer (CPDE) really is (be sure to scroll down on the page and then download the free whitepaper for surprising details). The CPDE role is likely much broader and deeper than you might think! Time and Money?! Yes, but not at the expense of quality and stability!  The role of a Certified Process Design Engineer is a critical skill set for all IT service  providers. There are many frameworks and standards that  define practices and methods for achieving success; ITIL 4 , Agile , Lean , DevOps , COBIT, ISO, and Site Reliability Engineering (SRE) are only a few. My point is that while each describes processes and controls (what to do), they don’t provide clear, step-by-step methods and techniques for designing, reengineering and improving processes (how to do it).  A Certified Process Design Engineer equips managers and staff at all levels to lead the organization to do t

ITIL 4 Guiding Principles – Keep It Simple

Keeping it Simple is one step towards creating a world where people get up in the morning and are inspired to go to work and love to do the work that they do. The more complex something is, the more there are ways for it to go wrong. We as an industry of service providers must become educated and stop the insanity! Getting the education and the certification is a wonderful first step but once qualified we must adapt those learnings to make it simple and “Keep IT Simple”  “Keep it Simple”, one of the seven ITIL 4 Guiding Principles is a topic we have written about many times over the years.  It is anything but simple. We must acknowledge that IT services are comprised of many complex systems and if there is a way to make them even more complex IT Professionals in general seem to have that idea down to an ART.  So; How did we get that way. Business requirements are dynamic and are consistently evolving even as you read this line. Over a period of years and in ma

Who Moved My Process?

There are some misconceptions about ITIL ® 4 and its use of the term ‘practice’ vs. ‘process’ as a component of its recently introduced service value system. One misconception is that processes aren’t important anymore. Another is that organizations think they must completely redesign their tools in order to accommodate this change. Neither is true. Let’s begin by taking a look at how ITIL 4 defines these terms. Process: a set of interrelated or interacting activities that transform inputs into outputs [to accomplish an objective]. Processes define the sequence of actions and their dependencies. Practice: a set of organizational resources designed for performing work or accomplishing an objective. Practices include resources based on the four dimensions of service management which include: organizations and people, information and technology, partners and suppliers, and value streams and – wait for it – processes.   Both processes and practices focus on achievin

It’s Still All About “The Process”

Organizations adopting DevOps cultures and practices are able to deliver high-quality software faster. This means the business can deliver value to customers faster. You sometimes hear that DevOps and ITSM aren’t compatible.  In a recent ITSM for DevOps workshop an attendee asked whether process is still relevant for digital transformation initiatives in today’s environment.  The answer is emphatically Yes.   Now more than ever before the attention to process is critical.  Whether your company is striving to achieve traction for a cultural shift, for a digital transformation, to create a DevOps pipeline or any other improvement initiative, Process will always be a critical success factor.   Remember we are talking about just enough process. We cannot have over engineered bureaucratic processes. For our purpose here, we will focus high level on some of the process design considerations and mistakes to avoid.   To learn more about what is just enough and how to design or redesign your

CPDE - Process Design Considerations

S o who should consider becoming a Certified Process Design Engineer (CPDE)?  Well anyone can consider it.  Is your organization engaged in some type of certification, working to reach some optimized level of maturity, trying to improve the processes you already have or create a process to meet some new customer requirement? All of these scenarios would employ the skills of a CPDE. To start with, no matter which framework or standard you are utilizing processes must be: Defined Documented Managed via performance metrics Continually improved  Undertaking this effort is not as simple as it may appear and having a staff member with the necessary skills and capabilities (a CPDE) ensures that clear and measurable improvement targets, along with a process design approach, can and will be carried out.   You first must understand the factors that are triggering a process improvement initiative.  These are just a few factors, but understanding why an initiative is needed is an ex

Is ITIL Still Relevant?

With the onset of practices such as DevOps, Continuous Delivery, Rugged Code, and Value stream mapping, is ITIL / ITSM Best Practice still relevant? The short and emphatic answer is YES! Let’s look at how ITSM Best Practices are relevant and enable some of the initiatives that are in the foreground of Service Management for many contemporary IT organizations today. DevOps – DevOps is a cultural and professional movement that focuses on communication and collaboration to ensure a balance between responsiveness to dynamic business requirements and stability.   Therefore, things like Lean and Value Stream Mapping, practices like Continuous Delivery and Continuous Deployment, all become a subset or a building block to a successful DevOps initiative.  DevOps is frequently an organic approach toward automating workflow and getting products to market more efficiently. Ok, if we can accept that then the next question is … What are you going to automate?    ITSM Best Practice

Process Maturity

So unlike the Billy Joel lyric “Love you just the way you are”, we can never be satisfied with our processes being just the way they are.  As the organizations that we are engaged by continually change and mature to meet customers dynamic requirements, our processes must be continually assessed, measured and matured to ensure that they stay relevant and deliver value long into the future.  This takes real time, effort and resources.  Organizations cannot possibly move from being informal or ad-hoc to having a fully integrated ITSM program in a short period of time.  Just being able to gather the correct components (people, process, technology and information) can be a lengthy process and, of course, there is the decision of which processes do I begin with. The saying “Rome was not built in a day” really applies in this situation.  We must begin from the perspective that each level of maturity forms the foundation for the next level of maturity. Trying to jump over levels will almo

The Agile Process Owner

Let’s face it, IT service management (ITSM) processes get a bad rap. Sometimes deservedly so. Bureaucratic and overly risk-adverse processes can be a real constraint in the IT value stream; particularly in organizations that are adopting agile, lean and DevOps practices. To keep pace, today’s IT organizations must be built on ITSM policies and processes that facilitate speed and change. So who ensures that ITSM processes are designed with ‘just enough’ control to meet an organization’s needs? Here’s where the role of Certified Agile Process Owner comes into play. A Certified Agile Process Owner (CAPO) SM adapts agile and Scrum values and practices to ITSM processes and process design and improvement activities. Much like a Scrum Product Owner, a Certified Agile Process Owner manages stakeholder requirements and strives to translate those requirements into process activities and features that deliver value. What’s different is that CAPOs and Process Improvement Teams use Sprints

Improvement / Transformation As a Result of Disruptive Processes

I was recently asked about companies that have made improvements and/or had significant transformation as a result of disruptive processes.  The one that I am familiar with is Netflix and their philosophy of injecting failure into the production environment to ensure systems are fault-tolerant and how they continually test their ability to survive “once in a blue moon” failures. Introducing Chaos Engineering  -  Netfl ix Simian Army http://techblog.netflix.com/2014/09/introducing-chaos-engineering.html I did some additional Google searches:  “Disruptive improvements” & “Improving your IT services in a disruptive way”.  I think the following sites and resources provide more insight: Disruptive Business growth steps – Dow Corning https://www.dowcorning.com/content/publishedlit/solarticles/simple_steps.pdf IPhone success: Disruptive innovation and continuous improvement http://businesstheory.com/apple-teach-product-development/   Disruptive technolog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Change Management People

“Those Change Management people make my life so difficult sometimes!” I heard this from one of my students the other day. In this person’s organization they have made a common error. They have confused the process of Change Management with the Service Desk, Technical, Operations and Application Management functions. In other words the people who use the Change Management (and other processes) have become the same as the process itself. This is an often misconstrued and misinterpreted idea. We must remember that ITIL makes a distinction between Functions (groups of people who use processes to complete similar types of work) and Processes (sets of activities used to complete various types of work). I like to remind my learners that Functions use Processes (or people do activities). Functions are not Processes and Processes are not Functions. There may be groups of people or work teams who use a process as their main tool. As an example, the Release Implementation Team could use Re

What IS a Process?

Ross Wise here again…While I was working on some process improvements the other day it occurred to me that it could be very easy for people to get confused over the different elements that make up a process. So I thought I would jot a few down for everyone to help clear things up… First we have the process itself. This is a collection of specific high level steps that can happen in either a linear or parallel fashion to achieve specific objectives or outputs. It consists of a number of elements: Procedures : detailed instructions for the completion of a given process step Flowchart : a diagram showing the order and connection of process steps and decisions Inputs : the raw materials you use to create the process output Outputs : the end product or service resulting from doing the process steps and procedures Triggers : events that initiate the process Roles : the assigned responsibilities given to individuals using or executing the process Resourc