I was chatting this week with a few colleagues in the High-Performance Workplace (HPW) research area and we started wondering how people think about the application of tools, practices, processes and methodologies to support end users in an HPW.

It seems to me that some of the basic software types are easier to link to a value. In most cases, we know how this software "applies" to a business need. For example:

• Infrastructure software, or software that makes hardware and other software systems run (networks, operating systems, enterprise management, database management systems, middleware brokers, security). These are "keep the lights on" software, and they aren't difficult to justify buying because they're often the backbone of the organization.

• Enterprise/business applications or software that's designed to support specific business processes (ERP, CRM, supply chain). Again, the application to the business and the impact on end users' needs are generally clear.

• Development tools or software that can be used to build other software applications (portals, Web development tools, service-oriented architecture — SOA). Their purpose is to create new applications — which, in most cases, have a clearly defined purpose in terms of the impact on businesses and users.

And then … there's a "weird" class of software that's sometimes called "tools" — meaning software that people can use in many different ways. How tools are specifically applied to support the business isn't always clear.

Think of these software "tools" as you would a hammer. You can use it to build a house or hang a picture — in other words, it can be used for and applied to thousands of purposes and benefits. The types of things we might put in this category include word processing, spreadsheets, business intelligence tools, search mechanisms, communication and collaboration tools, some of the mobile devices, gaming and instant messaging, to name a few. The problem for buyers and senior managers is that there often isn't an obvious and direct link between the "tool" and its benefit, making it difficult to justify the costs associated with acquiring them, and difficult to define.

As a result, many organizations have had a hard time figuring out what people are "doing" with these tools. For lack of a better definition, these organizations have been calling them "productivity" tools. However, in many ways, this misses the point because it doesn't drive us to determine the added business value of enabling users to be more innovative, and to discover, lead, learn and team (see "The High-Performance Workplace Defined").

We need to ask ourselves how these tools "apply" to our business needs. The idea of an "application" for use in supporting an HPW isn't a "package application," but rather the application of processes, methods, resources, practices and technologies to support a business need. In other words, how can the various types of applications (that is, "applied," not packaged application) of these tools, processes (and so on) support business needs from a top-down view? This business need may be innovation, competitive intelligence, strategic planning and discovery, research and so on.

Is there a new way of thinking about application? Will our idea of buying software have to change? How does the evolution toward SOA or consumer technologies affect how we think about applications, or apply tools, people and processes?

Submit a Comment | Permalink

The example of a hammer is a well chosen one. It highlights exactly what the problem is that hampers introduction of truly break-through performance tooling.

From a central IT perspective, the use of a hammer is obvious: as a hammer, to hammer, a nail, and not a screw.

From the end-user perspective a hammer could be something totally different, a weapon, an extension of the hand if you just can't reach, or something totally different again.

Until you've witnessed a user using a tool for something very different to what it's originally made for, it's difficult to see the point.

Instead of searching out there for the killer apps for our users, why don't we embrace users bringing tools into work (obviously in a controlled manner), and just seeing how they use them to increase their productivity. If it does, then you've found the right app, if it doesn't, throw it out again.

We should broaden our horizons about what might be a productivity enhancing application.

One of the best descriptions and how to approach this area is an article by Andrew McAfee. He is the person that coined the term Enterprise 2.0. What is discussed here is the "Function IT and partly Network IT" parts of the article. These together have the ability to transfrom organisations or confuse them, depending on their abaility to manage and embrace change!

The majority of these tools do not tell you the best way or any way to use them (unlike ERP systems etc), it is up to the user/organisation to do this. Much of the time we get this wrong and wonder why the hype of the vendor for a particular tool does not seem to add up in real life. For example in my area of expertise, enterprise architecture, there are many tools that vendors say will help us solve all our EA problems. The fact is, the majority of EA communication and modelling is done with PowerPoint and Visio and if one is lucky, in conjunction with a CMDB. The issue is that each organisation has some different slant on what they want to achieve and communicate so the process of using the tool varies and there is no one way of doing the process. It is hard to justify the investment of dollars (both real and in time) of builing all the processes around the use of a tool that, only a few people in an organisation will use.

The flip side is that the successful use of these tools (see the Ducati example in the article) can be transforming.

http://harvardbusinessonlin...

“... how can the various types of applications ... of these tools, processes (and so on) support business needs from a top-down view?”

I would turn this pivotal question around: How can a top-down view effectively encompass tools and processes that are applied to business needs in an essentially bottom-up, creative manner?

My answer in a nutshell is to task _people_ with supporting business needs, and task _tools_ with enabling people to do so effectively. Nothing new here, but a couple rhetorical devices to help steer this are:
1) When contemplating business needs, complement the “productivity” rubric with the notion of “enabling.”
2) When weighing costs and benefits, insist that any discussion of “efficiency” must first address “effectiveness.”

It is not a qualitatively different whether your lead carpenter asks for a new kind of chisel or your lead financial analyst asks for a new OLAP database: the decision process is essentially the same. What seems to be happening differently lately is that the chisel vendor is pitching the financial analyst.

To cure this, when you ask your people "What does this do for us and how is it used?" if the answer is "So-and-so can use this to accomplish such-and-such" then get so-and-so in the room, and start by asking "Why do you do such-and-such?"

Very often, implementation of these projects is driven by the grand vision of CXO. Nothing wrong with this approach except that the implementation goes for a toss.

Vision works top to bottom but implementation works bottom to top. The end user (the final end user)should be educated and sold on the benefits of using the tools and only then sucess of the project will be guranteed.