Many IT organizations are being put in yet-another-pickle in meeting the challenges of the newest crop of knowledge workers.
Although the technology is relatively straightforward, organizing and executing around it seems to be the sticking point.
And, although I've collected some glowing stories of IT organizations who've met the challenge, I meet far more that are in the trying-to-figure-it-all-out phase.
Why Is This Important?
I would argue persuasively that many of our organizations are now made up of far more knowledge workers than transactional workers.
I'm sure there are very precise definitions of these terms somewhere, but -- as a working proxy -- I'd describe a "knowledge worker" as someone who primarily thinks, interacts, communicates, creates and organizes for a living -- and a "transactional worker" as one who primarily deals with predictable and routine workflows and processes.
In a previous post, Daniel commented on one of my earlier statements: "IT managers will find themselves at ground zero for what I believe is the most significant transformation in our economy ever—from an economy of transactions to knowledge and information."
OK, maybe I was being a bit dramatic for effect, but the point is valid. Lots of ways to look at it, but one (simplified) analogy is to consider what the first wave of internet did for our economy: the cost of a transaction was dramatically reduced, and the cost of information was dramatically reduced.
Now, in the web 2.0 world, we can find people with similar interests as ours far more easily. We can more easily share and leverage the knowledge and experiences of others. More value is being created by expertise, perspective, relationships, influence, connections, etc. -- than by the things themselves.
Maybe some pragmatic examples?
Let's say I sell someone something on the internet.
Now consider the "2.0" context: the information about who you are, what you're interested in, what you've bought before, what you might buy in the future, how you intend to use the product, your opinions on this product and similar ones, your ability to influence others in this regard, your ideas on how to make the product better -- all infinitely more valuable than the mere act of selling the thing itself.
Just ask Amazon.
Or, let's say someone logs a customer service call. The short-term goal is to clear the call, right? And there's a certain by-the-numbers way to measure that.
But -- is this call part of a pattern of calls, either around this product, or from this customer? Is the customer still dissatisfied with us, even though we ostensibly fixed the problem? Did we design the product correctly? Did we document it correctly? Is it being used in a way we didn't envision? Is there an opportunity to redefine what customers really need?
I'd argue that all that contextual information and knowledge is perhaps far more valuable that a cost-optimized customer support transaction.
At least, that's how EMC looks at customer service ...
Sorry, I digress ...
One could make the argument that -- in many organizations -- more business value is being created by knowledge workers than transactional workers. And --- although I can't prove it -- I believe we'll see this become even more pronounced in the future.
And -- if IT is all about creating value for the business -- more and more focus will need to be put on making knowledge workers more productive. And, for many IT organizations, that's a structurally hard thing to do.
Understanding The (New) Knowledge Worker
First, the knowledge worker deals in information -- all types and from many sources. Whether it's from the internal data warehouse, or the latest excerpt from the web -- they tend to be information junkies.
Second, the knowledge worker tends to organize things in a variety of ways: projects, topics, threads, keywords, etc. They take all of this information and digest it in ways that are useful for them. And no two seem to be the same in this regard.
Third, the knowledge worker communicates and collaborates using an extremely broad array of tools and mechanisms: synchronous, asynchronous, one-to-one, one-to-many, many-to-many, voice, text, video, etc.
At this level, the recipe for knowledge worker success seems to be pretty easy: expose them to as much information as possible, give them multiple tools to organize that information, and invest in a variety of mechanisms to help them communicate and collaborate -- the more the merrier!
So why is this turning out to be so difficult to do?
No Business Unit Or Process Owner To Engage
So many IT projects have a clear customer in mind -- a business unit, or a process owner -- that can provide the context and the rationale for a given undertaking.
If you want to improve Order-To-Cash, it's pretty clear who you'd work with. Or create a slick new customer portal. Or something similar.
But the problem with knowledge workers is that they're pretty much everywhere in the company. No one business unit or process owner speaks for them or their needs.
And without a clear customer, it's hard.
Justifying Productivity Gains Is Squishy Stuff
If the rationale of a given knowledge-worker initiative is to make them more productive, you're going to have a devil of a time building the business case.
I ran into this when I was launching our internal social media proficiency effort. I knew the productivity gains were going to be there, but I lacked the tools and methodologies to make a convincing case. I couldn't even find a consultant to do it for me.
Imagine you had to justify email in your environment (assuming you didn't have it already!). At once you'd be frustrated that (a) it's so blindingly obvious, and (b) there are no good tools or frameworks to explain exactly where the productivity gains would come, or how big they'd be.
Process and Workflow Mindset
So much of business analysis and the resultant applications are all about business processes and workflows. To listen to some people talk, you'd think that's what IT is all about.
Well, knowledge workers tend to work in very nonlinear, intuitive ways. If you've ever seen an email thread ricochet and morph into something different than what it started with, you'll know what I'm referring to.
Part of what these people do is structured, but a lot of it is unstructured.
And, since it's unstructured activity (albeit directed), it's hard for people and organizations that think in terms of linear, structured activity to fully comprehend what knowledge workers do -- even though these same IT people may be knowledge workers themselves!
Finite Project Vs. Sustained Engagement
Most IT organizations think in terms of projects that have a beginning and an end -- budget, schedule, resources, outcome -- and, when you're done, you move onto something else.
Supporting knowledge workers is a more iterative process. You put something in front of people. They use it. They then have new questions and new ideas. You put something else in front of them. Lather, rinse, repeat ad infinitum.
This favors a model of multiple, small tactical investments coupled with a program management function. You end up trying lots of stuff, but only invest heavily in the things that demonstrate real value.
But the idea of a new program office, an unclear charter, a correspondingly vague set of activities, coupled with an uncertain budget spend is an anathema to many IT organizations.
But, as I talk to the few IT organizations that are proficient at this -- that's sort of what they're doing to a certain degree.
"Put up an email server" is a finite, bounded project (relatively speaking). "Help people to communicate more effectively" is not.
Hard To Charge Back For Resources Used
And then there's the question of funding. I don't know about you, but I don't get charged separately for sending an email, making a phone call, using a conference room to have a meeting, surfing the web, etc. I guess there's a "corporate allocation" somewhere that covers all those knowledge-worker support services.
It's almost impossible and self-defeating to charge back for accessing the corporate intranet portal, or using enterprise search, or a wiki platform.
And, because there's only so much funding for "corporate allocations", a hard funding problem gets even harder.
Nobody Is An Expert
How knowledge workers work is changing rapidly -- there's no accepted 'best practices" that I've seen. And, most recently, the advent of a whole slew of 2.0 technologies is changing everything again!
Many IT organization prefer to look outside for best practices that they can emulate in their environment. Nothing wrong with that -- but when it comes to knowledge worker support, there's so much variety that it'll be hard to find a repeatable template.
And There's More, I"m Sure ...
But by now, I think I've illustrated my point -- comprehensive, programmatic support of knowledge workers is a very hard job for IT organizations.
Most everything about it flies in the face of traditional IT process and mindset. But that doesn't mean it isn't important, or shouldn't be a focus area.
I'm Starting To Gather Tidbits Of Success
Some larger IT groups have an "advanced technology" function, or similar look-out-ahead function. And, when I meet these people, they're very interested in this whole topic. However, they may not have the ability to take the vision into reality, but it seems to be a frequent starting point.
Certain industries (e.g. biotech, energy exploration, financial trading) take their knowledge workers *very* seriously. And, as a result, they've established IT teams that meet with a cross-section of these power users on a regular basis to understand how they work, what they need, etc.
And, when I meet these IT people, they're extremely interested in the topic, and are making progress.
Ironically, I tend to meet a few IT groups who are using some of these technologies within IT (e.g. blogs, wikis, IM, etc.) but not outside of IT. I ask them "what about the rest of the business" and they shrug their shoulders.
And they wonder why I give them a strange look ...
So, What Does The Future Hold For You?
Does your organization have a focus on supporting knowledge workers in new ways? Do you think this will be more important in the future, or less important?
Have you figured out ways around the organizational, measurement and funding challenges? Or is it just accepted that it needs to be done regardless?
I'd be interested in your perspectives ... thanks!