ITIL or Agile? DevOps or Lean? Where to start? Where to end?
At some point in your life, you’ve probably used a butterknife to loosen a screw. While it may have worked, it certainly isn’t the most elegant or efficient solution. In fact, if you had to deal with more than one screw, you’d probably spend more time and effort to make sure you had the right tool for the job. When we consider managing our IT and Development organizations, this analogy rings true. You need to use the right tool for the job.
But therein lies the rub. If the tool we are discussing is a framework, how do you ensure the tool addresses the problem especially when you have limited resources to invest in your tools. I’d like to point out some common challenges to consider and ultimately help you select the right framework(s) for your organization.
Understand the Purpose
One of the biggest issues I’ve observed concerns a fundamental misunderstanding of the purpose and subsequent application of a framework. Agile’s Scrum methodology shines in development environments. It can even take your Project Management Office to the next level. But it might be more like a butterknife on a screw if you try convert all your meetings to standups. While this is a wild misapplication, it’s one I’ve actually encountered. To be successful, you need a solid understanding of a framework and its appropriate applications.
So how does one get a solid understanding of a framework? As with most things, there are right ways and wrong ways. While I can’t cover every aspect, I would warn against two common errors.
First, be careful to avoid the historical assumptions of someone marginally experienced in Service Management practices. That may sound a little pointed on its face. But, as a consultant and trainer that deals with Service Management practices daily, I can’t begin to count the number of times that an individual misrepresented a framework to me in a conversation based on their prior experience or assumptions.
ITIL has been described to me as “a rigid and unforgiving framework” when it is, by its own definition, a nonprescriptive and adaptable framework of best practices. Take with a grain of salt those conversations which include “when we implemented this framework at my previous company” and other similar statements. You don’t need to disregard these experiences, simply place them in their proper context.
Second, be aware of confirmation bias. For example, someone who already has knowledge and experience in a certain framework may naturally gravitate toward that framework being the right solution for your organization. The framework may very well be the right solution for your organization, but you must be aware of context. As an instructor, I’ve sent many passionate students out of a foundation-level course with a warning that they hold enough knowledge to be dangerous. Be cautious of a framework’s evangelist whose zeal exceeds their knowledge.
I’ve also heard former students regurgitate an application example shared in a classroom environment to argue for the efficacy of a framework. While these examples may be valid, it can be dangerous to present these use cases without a broader understanding of their context, challenges, successes, and failures. A whitepaper or first-hand account should carry more weight than a good story.
If you avoid these two issues, you stand a better chance at gaining an understanding of the purpose and application of a framework. Without attending training courses, one of the best ways to get a high-level understanding of a framework’s purpose is to see what the framework or intellectual property owner say about the framework. What does the Scrum Guide say about Scrum? How does AXELOS describe ITIL? How does ISACA define COBIT? When you are armed with this basic information, ask someone with the right experience who doesn’t have an obvious bias. If that’s not possible, ask someone with a bias but always be conscious of their bias.
Understand the Big Picture
Selecting a framework isn’t a decision that should be made in a vacuum. There are many organizational considerations beyond your immediate pain points. For example, if you are implementing a framework simply to improve the Service Desk, how does that framework impact upstream and downstream stakeholders?
Accounting for upstream and downstream stakeholders ensures we’re thinking in a more holistic way. But if I’m honest here, there is a tendency to become selfish and shortsighted. It’s important to force an understanding of how work gets done in the organization. Even a simple workflow mapping exercise with sticky notes and a whiteboard can help you identify and account for critical dependencies. Perhaps, involving these other stakeholder groups in your decision will further enhance your relationships and ensure a better result from your selected framework.
Realize that there may not be a single, simple solution. In fact, the best approach is often multifaceted and will likely rely on adapting multiple frameworks to your specific organizational needs.
You are Unique, Like Everyone Else
Speaking of adapting frameworks, recognize that your organization is unique. There is no other organization that shares the same culture, values, management, expertise, customers, products, services, etc. Yes, you are unique. And so is everyone else. And that’s a good thing. But despite how unique your organization truly is, you will share common challenges with other organizations. And frankly, that’s the power of a good framework. Frameworks will often address the challenges that are common across an industry. And since you are still unique, recognize that you can adapt the framework to meet your particular needs. There is no one-size-fits-all solution.
To Find Your Solution, Know Your Problem
With all of this said, there’s still the matter of knowing which framework, or frameworks, are right for my organization. But this brings us right back to a critical issue. Perhaps this is the area where we need to start. What, exactly, is the problem I am trying to solve? There may be several problems. You may have blind spots. Your metrics may be a mess. You might just want to get more efficient or more effective in a particular area. There are times when you don’t know what you don’t know. The more clearly you can define the problems you want to solve, the better equipped you’ll be to find the solution.
Once you’ve come up with your list, often from a brainstorming session with the right stakeholders, spend some time drilling down and refining that list. Be specific. Ask for clarification. What does it mean to be more efficient? Why is this a problem? What, exactly, does this mean? Then, prioritize that list. And when you are ready, please reach out to see how we can help.