We sometimes confuse the terms practice and process, but they are different. Often, practices and processes are closely related. In enterprise IT, the focus of this article, many practices build upon individual processes.
Let’s take a look.
What is a process?
The enterprise IT industry generally believes that process is the foundation, so let’s start there. Processes refer to the way you get things done: the steps to get from Point A to Point B. The process might be a straightforward few steps to achieve a certain outcome. Or, a process might have a sequence or layers of operations that encompass people, technology, strategies, and governance.
In any process, the steps are more rigid for a reason: so you can walk yourself through the steps. The intelligence of the process—how it’s getting something accomplished—is embedded not in a person but directly in the process.
In enterprise IT, you’ll often follow a process to get something done. For example, let’s take service creation and delivery. You’ll have to design the service, then build it, then deliver it. Each step, however, might not require an explicit process:
- Inventing a service. You might not need a process to invent or create a service, or the idea for a service. Your approach could be more creative—an idea struck you in the middle of the night—or Agile based, where you see the gaps in your current products. A certain number of steps don’t lead up to or guarantee innovation. (If it were that easy, we’d all do it!)
- Building a service. Once you’ve designed the service, you’ll need to build or manufacture it. This piece might depend on a process—steps that have to be performed in a certain order. Or, depending on your environment, it might not need much of a process.
- Delivering a service. It is likely that the way you deliver a service follows one or a few processes that must be done in order for the end users to receive and begin using that process. Here, processes are crucial for efficient service delivery and for increasing scale.
The end of a process
A distinguishing feature of any process is that it has an end. A process is generally considered complete when you’ve achieved the goal of the process.
What is a practice?
A practice is more holistic and overarching than any single process. A practice is the ongoing pursuit of some goal or interest—and it’s usually something that you’re looking to continuously improve or optimize. After all, we use the term best practice, not best process. A best practice is something that an industry generally agrees as the most effective way to achieve something.
In enterprise IT, practices are those activities that you’re always looking to make more effective, more efficient. These areas are further comprised of many practices—some that are required, many that are optional. Depending on your organizational strategy and structure, these areas tend to be considered practices—much bigger than processes—and they’re often directly divided into additional sub-practices:
- Service management
- IT operations
- Software/product development and deployment
- Information security
- Data analytics
- Governance
- Leadership
In any practice, the intelligence tends to sit with a person or a team: the person/team who owns the practice or has some expertise in the practice. That person can use any number of processes in their expert toolkit to ensure the practice is doing what it’s meant to do. Just the same, that person can decide which processes no longer support the overarching practice.
The phrase “practice makes perfect” sums it up completely—we’re practicing something regularly in order to get better at it. Contrast that with processes, where a process is perfect if it accomplishes the one task it meant to do.
The end of a practice
The end of practice is harder to measure. Where processes have clear beginnings and ends, practices are ongoing and overarching, comprised of any variety of processes. That’s why practices rely on metrics—to measure how our practice performs regarding:
- Quality
- Agility
- Compliance
- Agility
- Other needs
Basically, you have to measure a practice in some quantifiable way in order to know your practice is working—that you’re improving in that area.
Examples of practices
Examples of enterprise IT practices include:
- Incident management
- Problem management
- Service desk and service level management
- Software development, deployment, and management
- Change management
- Security information and event management (SIEM)
Process vs Practice: IT examples
Let’s look at some common technology areas and how they treat processes and practices.
ITIL
The leading service management framework, ITIL® was traditionally divided into a variety of practices. With the release of ITIL 4, in 2019, ITIL responded to criticism that it wasn’t modernizing or keeping pace with the digital era.
This newest version actually stopped using the term “process” in favor of “practice”, a move that many ITSM pros praise. As Kirstie Magowan explains:
“In reality…“processes” was a misnomer in ITIL v3 and earlier iterations. When we talked about the incident management process, [for instance,] we were never talking about a single process. Instead, we were talking about a group of processes and capabilities that allowed us to efficiently manage incidents. ITIL 4 has pulled all these facets together and called it a practice. To me, this makes perfect sense.”
Agile
Initially a response to traditional software development methods, the principles and values of the Agile methodology can apply to development and other areas of IT and the business more widely. The Agile methodology treats practices and processes in a similar manner:
- Processes are well-defined steps that achieve a predictable result.
- Practices are activities that might include any number of processes.
A process is a series of well-defined, repeatable steps with predictable results. Here, all the knowledge you need to perform the task at hand is embedded in the process—you don’t have to rely on your own experience or knowledge.
Agile practices, conversely, are individual activities that implement Agile principles and values. For the most part, the Agile methodology doesn’t prescribe explicit practices (unlike ITIL). Instead, it leaves the specifics to the individuals who make them work, informed by Agile principles and based on knowledge, experience, and need.
Agile sees the practice vs process as more of a continuum: well-defined processes on one end, loosely defined practices on the other.
Processes and practices: How many are enough?
If you’re struggling to get things done, you might wonder if you need more, or better, processes or practices. For most organizations, it’s a matter of degree: you’ll need some, but not too many. Processes and practices are only useful if they provide some value to your organization. Not everything needs to be a process or a practice. Some tasks, activities, and goals can just be accomplished, depending on:
- The task at hand
- The people involved
Consider the type of work you’re responsible for. What is the purpose? Is the work rigid or more open? If you manage a data center 24/7 that requires repeatable actions for a guaranteed result, you could do one of two things:
- Trust that your staff will remember all the tasks they need to accomplish.
- Roll out repeatable actions and processes that guarantee high availability.
This is where processes and practices can support success. But other areas might not need this level of detail and micromanagement. A general rule of thumb:
- Processes and practices can support highly rigid work, such as IT Operations, including infrastructure and networking.
- Processes and practices can hinder more Agile, open-ended work, such as service desk support and software/application development.
Moving towards greatness
Being married to unnecessary process and practices makes you more bureaucratic—doing a process for the sake of the process. (You’ll recognize this if you see or hear about too much micromanagement.) The effects of this are adverse:
- Little to no agility
- Minimal creativity and innovation
- Longer time to market
In Good to Great, Jim Collins discusses how the number of practices and processes you need will lie in the competence and discipline of your staff:
“Bureaucracy…compensates for incompetencies and a lack of discipline.”
The most successful processes and practices need to be explicitly spelled out for anyone that comes along and might touch a part of them. New employees in particular benefit from processes. But processes and practices have overhead. Managing each process and practice become work in itself: people to manage them, ensure they work, change them when they stop working, etc. It is likely that at least one person owns or is responsible for each process or practice.
This issue, however, will dissipate as you have the right talent in your company. The right people can get work done without relying on every single rule to do it—they understand the end goal, and they understand how a process or practice might help or hurt their accomplishing that goal. And, as you know the rules, you can see areas of waste that are no longer necessary. Take advantage of those opportunities to innovate or make something more efficient.
Practice makes perfect
At the end of the day, you’ll likely develop some processes and some practices, whether naturally or intentionally. Processes and practices themselves are neither good or bad—they are simply more or less helpful, depending on your:
- Industry
- Organizational structure and strategy
- People and talent
- Products
- Resources
Both practices and processes should enable the system, not become the system. These activities aren’t the end goal—they should only help you reach the end goal. When some new process becomes more useful, pivot to that.
Additional resources
For more on IT strategy, explore these resources:
