“It’s like déjà-vu all over again” Yogi Berra famously once said, and yes, it is. We’ve been here before. The promise of a new technology the will create so many efficiencies – too many to count. It will make everyone’s life so much ‘easier’ and allow the organization to make unprecedented gains. Continue reading
A long time ago, or at least what seems like a long time ago, in the U.S., Manufacturing was King. For companies whose primary product was manufactured, manufacturing, along with finance, dominated discussions. There was little concern for quality, cost, or customer service. The customers would get what they got (and like it), and any additional costs incurred would simply be passed along in the price of the product. Life was good! Continue reading
Over the past several months, I have written several posts about the issues facing IT Business Alignment, a need to create a dependence between IT and the Business, and an emphasis on taking a process centric approach to the issue.
I decided to consolidate that into a white paper, which is now available.
It’s not sponsored by a large software or hardware company, but does present an approach offered by my company (New Age Technologies) to help an organization move toward IT Business Alignment by focusing on a process to be improved, then understanding how it’s infrastructure and technology can help that process.
Please feel free to leave any comments about the paper at this post, or you can email me at the address on the paper.
I hope you enjoy!
Effective communication is critically important in any relationship, be it with your significant other, or your business partners. This is ever so important in the IT Business relationship. After all, if we want to improve alignment, we need to make sure we understand each other. Despite all the efforts, the issues continue to present themselves. A couple of examples from the past few weeks:
In a meeting with IT & operations leaders, a business unit VP was discussing how they needed to better understand the ‘workflow’ and be able to improve it. He asked IT to help. Since the organization had Microsoft SharePoint deployed, the IT team went back and looked at the ‘Workflow’ engine in SharePoint. Unfortunately, the ‘workflow’ he was talking about was the process the people were using to complete their tasks. Same word, different meanings.
A hospital scheduling organization allowed physician offices to fax orders into the system. The orders were converted to PDF files using “Fax-o-matic” (name changed). Indexers then labeled the orders into the email system, and linked it to the order in the scheduling system (I know, a mess, but no $$$ to change). Hospital leadership would constantly hear of issues with the “Fax-o-matic” system. When they approached IT, IT would say it was working fine. To IT, “Fax-o-matic” was the creation of the PDF file from the fax. To Hospital leadership, “Fax-o-matic” was the entire process from faxing the order to linking it to the scheduling system, as well as finding it as necessary.
Much time and effort could have been saved (as well as some nasty meetings in the case of the second example) if both parties had taken the time to understand exactly what the other was saying, what it meant to them, and explaining what they were going to do. If the IT group had said what it was going to look at when the meeting ended, the VP would have realized they were not on the same page.
When communicating, it is not only important that you understand what the other person is saying, but that you are sure they understand what you are saying.
Let me know your thoughts!
What’s wrong with your approach to IT Business Alignment is your approach to IT Business Alignment. For over 30 years, organizations have been wrestling with the IT Business Alignment issue, and according to the annual Society of Information Management survey it remains a top issue today.
Why is this so difficult to get our arms around? I’ve written previously about how defining IT Business Alignment has been an ongoing issue, and how our organizational structures make it very challenging (here). We have spent so much time struggling to figure out the right approach that perhaps we have lost our way.
Part of this struggle is due to the definition itself. ITIL v3 defines Business/IT Alignment as:
An approach to the delivery of IT Services that tries to align the Activities of the IT Service provider with the needs of the Business.
The problem with this definition is it defines Business/IT Alignment as an approach. Other definitions call it an “ongoing process” (Wikipedia). While there may be a process to achieve it, Business/IT Alignment is not an approach or process, it is an outcome.
It is the outcome of many different approaches and processes which will vary by organization and will involve varying levels of technology. Defining it as an outcome:
IT Business Alignment is the delivery of IT Services that does align the IT activities to the needs of the business.
Now looking at it as an outcome, how do you know when you’ve achieved it? Well, it’s just like in the movie Goldfinger, when James Bond is asked, “What do you know about gold 007?” His response was, “I know it when I see it.” IT Business Alignment is like this in many ways because there is no “one size fits all” solution; each organization is unique, and alignment will look different in each. This is what makes it so challenging. An attempt by Company B to replicate the alignment results at Company A will likely be disappointing, because Company B is different than Company A.
However, to achieve this outcome, there must be some fundamental pieces in place in order to drive the approaches to meet the outcome of IT Business Alignment. Fundamentally, IT and Business must be dependent on each other for success, and this dependence must be mutually recognized and acted upon.
Creating this dependence starts with creating a relationship and establishing common metrics. Many will say this already exists in their organization. Before you do, ask if the actions back it up? Remember, not only does the dependence need to be recognized, but it must be acted upon.
One way to act is to take the initiative to engage with the business in helping improve their operation. This is where taking a process based focus to the operation can provide real benefit. Using techniques like Business Process Management, or the one we’ve developed like the IT2x FrameworkSM, can help IT and Business create the necessary dependence and become aligned.
Once aligned, continue to move IT and the business closer. Whether you call this Synchronization, Convergence, or Fusion, doesn’t matter. What does matter is the continuous process of moving toward these goals.
Change your approach to IT Business Alignment. Stop treating it as an approach, and start looking at it as an outcome. Then act toward achieving this outcome, by creating a dependence on each other through relationships, common metrics, and a process centric approach to improving operations.
Let me know your thoughts!
I’ve been doing a lot of research over the past few months on the classic IT Business Alignment issue, and am putting the final touches on a white paper that will offer a definition of IT Business Alignment and present a framework for how an organization can start toward the goal of achieving better alignment. Until then, I want to briefly talk about what IT Business Alignment isn’t.
While reading CIO magazine the other day (yes, the actual print edition), I came across one of those sponsored ads that looks like an article – “An IT Focus on Process”. The ad-article immediately caught my attention due to my focus on process and process improvement. As I read, I’m thinking there’s some pretty good stuff here – a focus on structure processes, need for organizational alignment – then it came. The hook, the savior, the thing you need to achieve IT Business Alignment: Software. Yep, buy our software because it does all these great things that will allow you to achieve IT Business Alignment.
Whether or not the software actually does these things I don’t know. It may be the greatest software ever written. But IT Business Alignment isn’t software. If buying software is all we need to do to achieve IT Business alignment, why is it still a problem after 30+ years?
Companies are constantly pushing for the one thing that will enable an organization to achieve alignment – maybe that is why the issue has, in some circles, become stale. People go off, buy the software, install it, and then wonder why they aren’t magically aligned. They focus on the technology, maybe glance at the process, are blind to the people and wonder why things don’t go as planned. How about a new approach: Focus on the process while engaging and involving the people to prepare for the technology.
Why not give it a shot?
Let me know your thoughts!
Last time, in exploring Lean & IT, I posed the question, “Are you going to ‘do’ Lean, or are you going to ‘BE’ Lean?” In other words, are you simply going to use the tools of Lean, or are you going to embrace the true belief in continuous improvement and make it a part of your organization’s culture? The latter is much harder and takes much longer to achieve.
Over the past week, thinking about the relationship between Lean and Agile, I posed a question on Twitter: Is Agile software development Lean, or is Lean part of Agile software development? To expand on this, Gerry Kirk (@gerrykirk) created a poll. As of February 1, the top three responses were:
1) Lean complements Agile (42%)
2) Agile is part of Lean (21%)
3) I don’t really care, I use Lean as part of my Agile work (17%)
Looking at the responses, #3 can be grouped with #1, so that nearly 60% of respondents feel Agile and Lean complement each other. This goes to the point of viewing Lean as a collection of tools, and not a mindset or organizational culture. It is also important information for an IT organization that may already be using Agile, and wishes to move into Lean. Understanding how your organization views or understands Lean before embracing it will allow you to develop a strategy for truly beginning the Lean journey.
As IT organizations begin to embrace Lean Thinking, and it’s associated methods and tools, they need to remember it is a total organizational journey, and not just doing some Value Stream Maps or A3s. It does not start and stop with the IT department. Yes, the tools are important, and you can’t get there without using the tools, but it is an organizational journey, not a quick trip to the supermarket.
By the way, I was in the 21% that feels Agile is a part of Lean.