The Contrast Is Stunning

I think people know by now that I get to meet lots of customers and partners in the course of my work.  Actually, I really don't consider it "work", it's really a lot of fun.

And they even pay me :-)

Sometimes, though, you get this great juxtaposition: you get to see how different IT organizations approach the same fundamental challenge in entirely different ways.

And the contrast can be stunning ...

What Do We Do About End User Computing And Productivity?

That was the fundamental question for two large, successful companies in the financial services industry.  Both are well-run businesses, both with a significant knowledge worker population that's increasing in importance. 

Both have the pain of aging desktop infrastructure that wasn't only holding the organization back, but was the quintessential "burning platform" in that something had to be done sooner than later.  Both had experimented a bit with desktop virtualization, and wanted to use more of it going forward.

The First Meeting

This meeting was clearly being led by the technologists. 

They wanted to know about things like storage efficiency, and how cheaply the VDI server farm could be built.  Seems there was some sort of mythical ROI number out there that they had to beat, otherwise they thought that the project wouldn't fly.

So we got into the usual "virtual desktop sessions per unit of physical infrastructure" discussion: how many sessions could you safely cram on a server blade, how and where could you compress and deduplicate physical storage, what kinds of data could be squeezed and what the impact was, how that would affect cost-per-user, and so on.

Now, truth be told, EMC's experience and capabilities with regard are unmatched -- no one is better.  We've done a lot of that sort of stuff, and we've usually gotten very good results.

But I left the meeting shaking my head.  I thought the project was largely doomed, simply because it had started off on the wrong foot.

The reasons why became clear as I went to my second meeting.

The Second Meeting

The people in the room were very different in the second meeting.  Yes, there were senior IT people in the room, but there were also non-IT stakeholders.

The problem statement was very different: how do we create a better capability for our business, and solve a bunch of growing problems at the same time?

They had done a good job of understanding how different parts of the organization used desktop computing, productivity and collaboration -- and how that was likely to change in the future.  Increased value creation for knowledge workers was at the very top of the list for them, shortly followed by cost containment and risk mitigation.

The EMC discussion was not led by technologists -- it was led by EMC Consulting.  This team is doing an increasing number of engagements like this, and I end up seriously enjoying every session I'm in with this team.

Frankly, we didn't talk much about technology for the two hours we were in the room -- we talked about outcomes, frameworks and processes.  If you were a technology infrastructure professional, you'd think you were in the wrong meeting.

The central questions revolved around organizational change management -- how do you engage different parts of the broader organization to be willing to adopt new ways of doing things in an effort to increase business value?

We covered a lot of great ground over two hours:

* how to get key stakeholder to embrace and endorse the new environment

* how to help the current desktop team free up enough cycles to become key contributors in the overall project

* how to engage users on how to best exploit the new capabilities they'd have

* how to comfortably integrate both internal and external end user services

* how to successfully engage the risk mitigation portions (legal, security, compliance) of the organization

There was more, but you get the idea.  And I'm sure at some point in the process, we'll get into the nitty-gritty of the supporting infrastructure, and how best to build and operate that.

It was an outcome-based discussion, not an ingredient-based discussion

We Vendors Are Largely To Blame

I have been as guilty as the next guy.

Customer wants to do a project.  Find a technology-related potential problem that you can solve.  Make the project all about that problem, and no other.  Lather, rinse, repeat.

If you're a storage vendor, and it's desktop virtualization, then it's got to be All About Storage Efficiency, doesn't it?   Or maybe we should emphasize the special coating we've put on our power cords to ensure long life?

Well, we're not doing our customers any favors by encouraging this sort of thinking.  We, as vendors, ought to be thinking about how to enable positive customer outcomes, rather than how we jam our stuff into the project.

Say what you want about consultants in general, or EMC Consulting in particular -- the contrast between the two meetings was striking.

Anyone want to guess which project I think is going to be more successful?

Comments

[scott owens]

You probably just saw a snapshot of why the company you met with is less than successful or could be more successful. Senior management is NOT sharing direction so very frequently the technical implementers are using the only business knowledge they know - via its technical aspects.
I bet "The Contrast is Stunning" within the company as well.

I am a senior engineer for a large company (5000+) employees. We are expanding a division with various new applications, new networks, new staff. I read about it in the local newspaper first. I hope they know how many blinky lights they need before they tell us what we are supposed to build.

After 20 years of working in the public and private sector I am sad to report most employers have an inability to share direction or corporate needs from the top to the bottom.
It's not that we can only see problems in 1Gb/sec or multimode vs singlemode, its that that is the only view you present us; we have no idea of what your strategic direction or needs are so we think within the limited box we know. Must be fast and reliable, why we don't know.
We're not competitors - let us in on the secret ok ?

[Chuck Hollis]

Well said -- thanks for sharing!

-- Chuck

[David R]

Rare is the technologist who also gets the value that their firm delivers to the market. It is not their fault, but they get so wound up in the crisis of the day that they never get much above the tribulations in the IT department. It is our job in the vendor/partner/consulting community to deliver ideas to these folks that are grounded in business value and leverage the technical skills the traditional IT folks have. If you try it, you will be surprised how eager "techies" can be to participate in a business proposition based on new technology versus the "business as usual" discussion about who passes traffic faster.

[Neil Ward-Dutton]

Chuck, a great post and although this isn't a topic I'm deeply familiar with I do see similar patterns every day in my own fields - business process management (BPM), SOA and software development. Many technologists - and vendors, you're right - frame "success" as a great technical implementation. However value only comes when that "success" is actually accepted and embraced by the organisation. Unless someone is thinking about the change management issues and sharing ideas about how to manage those risks, all the technical "success" in the world doesn't matter one bit.
It's an issue that's as old as the hills, and I wonder when (if ever) it'll be dealt with as a matter of course...