Alex Jauch is a Director of Product Management for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.
In part three, he’ll answer the question: “How do I ensure I am making the right IT investments?”
There is a huge potential for IT organizations to fundamentally transform their businesses through the use of cloud business models and architectures. While we see examples of business transformation almost every day, it is rare to see IT organizations leading this change. As we have discussed, I have my theories about this. As I have stated previously, I feel that this is fundamentally an organizational change management problem. IT organizations who attempt to retain traditional organizational structures and processes struggle to implement successful transformations. One aspect of this problem is sometimes referred to as the “bottom line” dilemma. If an IT organization is considered a cost center, it is very difficult for that organization to create the amount of change required to add value. If you are not adding value, you are a cost center by definition. It’s a quandary.
Let’s start with the concept of value. If you want to create value in any organization, you must introduce change. Change is by definition a value precursor. Not all change creates value, but all value creation requires change. Think about something simple like jewelry. If I give you a lump of gold, does that lump have value? Yep. Did I add any value by giving you the lump? Nope. What if I changed the lump into a ring? Ah, I have introduced physical change to the gold. This may have value to you, unless the ring is really ugly. Then you’d probably rather just have the gold. See where this is headed?
You would think that IT organizations are temples to change. You would think that change is in their lifeblood. They thrive on change. Nope. It turns out that this is not true. People are people. Each one has its own level of acceptance for change. Organizations that pride themselves on technical excellence usually resist change.
Why?
Because if you do something, again and again, you get really good at it, you become an expert. Doing something new means the risk of making mistakes and finding out that you are not perfect and do not know everything. There is also an implication that if the new way is better, you must have failed when you started doing it the old way. When I was first starting out at Microsoft Services, a very senior guy in the group asked me a question that I could not answer: “How do you know what you don’t know?” Needless to say, I was pretty put off by this question. It seemed pointless. By definition, you cannot know what you DON’T know; only what you DO KNOW.
Over the years, I came to understand the question and the very important lesson behind it. Being able to say “I don’t know” is a huge skillset in the technology business. When I say “I KNOW” that means I’m sure. If I’m not sure I say “I DON’T KNOW.” My mentor’s question is about understanding and respecting your own limits. For example, when interviewing technical people, my intent is to always ask more and more specific technical questions until the answer is “I DON’T KNOW.” In my opinion, the limit of their knowledge and the ability to understand that they have just crossed that line is hugely important. It’s fascinating how many people will simply keep answering questions and fudging the answers in an attempt to impress.
This is an artifact of what I call the “expert syndrome.” These people are experts. They enjoy being experts. Knowing everything and being able to answer every question is part of their internal mythology. If you are suffering from expert syndrome, you will resist change. This is because any new way of doing things means you are instantly degraded from “expert” to “learner.” This causes you to resist change. Not super healthy for the organization.
This is also a proof point for the customer-centric IT organization. If the business really needs a service that IT cannot provide internally, why wouldn’t they help the business acquire this function from the cloud? This would be the customer-centric thing to do. However, this is not what traditional IT organizations do. Instead, there are policies created to prevent this type of activity. Standards are created. Architectural boards of review are convened. This allows IT to retain control but is not the customer-centric approach. If your job is to protect the business from itself, then this is what you need to do. It depends on your worldview. However, the purpose of this blog is not to debate corporate policy. I bring up these issues to help you understand how incredibly difficult it can be to change the culture of a large organization.
So, if change is good (sometimes) how do we evaluate “good” change and compare that to “bad” change? One way that I really like is to use a technique called “benefits management” developed by Dr. Peter Weil at MIT Sloan. I used to teach a two-day class on this topic, but the short version is that in order to have “benefit”, an IT activity must have underlying business metrics and those metrics must have a business owner. For example, back in the old days, it was common to claim that PCs “increased worker productivity.” OK, great. How do I measure that? Either I produce x more widgets or I reduce expenses (which in IT usually means reducing headcount). That’s it. You cannot say that task x takes 10 fewer seconds and is performed 10,000 times a day, therefore, you have saved 100,000 seconds a day. Saving 100,000 seconds is entirely theoretical until it is expressed into an actual benefit like reducing labor costs or increasing production. This is why IT organizations so rarely have this discussion. It’s hard.
This is especially true when discussing traditional IT benefits like saving time. This implies that the organization reduces headcount which nobody wants to talk about. If you have the luxury of a quickly growing company, this benefit can be expressed in terms of avoided new headcount, but not everyone has the benefit of a large, growing business that’s constantly hiring. No, it’s much more fun to talk about creating top-line revenue: increasing production, exploring new markets, increasing customer satisfaction. Those are always great IT projects.
How do we use this principle to help us align our IT spending? One way is to think about the “benefits” that you think the platform or system will bring to the organization. Things like “increased agility” or “reduced downtime” or “reduced IT labor costs.” Make a list. Hopefully, it’s a super long list. Then you need to categorize these into top-line items (increased agility) and bottom-line items (reduced IT costs). For each item, you need to identify exactly which business owner (or their representative) will benefit within the organization (VP of Sales, COO, VP of Product Development) and figure out exactly how much this will help their organization and what metrics you can apply. Once you have your proposed metrics, you need to go to the business owner of that activity and get them to agree to your metric. For example, the VP of Sales may not be super happy that you’re asking them to commit to an additional $1M of quota because you want to deploy a new sales productivity application. See how this gets complicated? You cannot claim a benefit unless those you claim to benefit agree. That may not always happen. As I said, you’re hoping for a super long list. This lack of visibility and support for IT business improvement is at the heart of failed projects. IT says that things are better but the business either disagrees or simply doesn’t care. Neither of these scenarios is good.
In many cases, this technique will radically change IT’s implementation priorities. The organizations that want IT services come up in priority. Those who are unhappy or uncaring drop down. Remember what I said about running a business? You need to provide a service that your customer wants. Your customers will tell you if you are doing the right thing or not. It is a similar exercise when you use benefits management to ensure that IT is actually creating value for the organization. This is true even if you choose not to do chargeback and no money ever changes hands.
If you know which IT activities are actively producing benefits for your organization, you know where to focus your attention. Those activities which do not directly produce benefits may be areas where you can economize or outsource. Beware, rice bowls will be broken. This is not a fun or painless process and most IT organizations simply give up. However, this type of introspection is vital if you wish to transform your organization for the cloud era.
No comments:
Post a Comment