Category: Projects

Fighting the right battles

Mark GouldLeave a comment

Perhaps a more appropriate title for this post might be “not fighting the wrong battles.”

Over the past few weeks, I have come to a realisation that at various points in my career I have spent too long trying to achieve things that were actually impossible.

They weren’t impossible because they couldn’t be done. They were impossible because something about the organisation made them so.

Sometimes these were small projects, sometimes major programmes of change. The detail is irrelevant. The point is that, even though I could persuade important people to join me on the journey, I didn’t spot that success depended on a number of factors that would never fall into place.

So what are the right battles? Simple: the ones that are genuinely winnable. Anything else is a waste of effort. Hope rarely triumphs against institutional inertia. No matter how much someone wants something to happen, if success depends on someone else who doesn’t care or who actively works against it, it will never happen.

What does winnable look like? The key is to be sure about the essential components. The following questions should help.

  • What is the bare minimum to demonstrate success?
  • What resources are needed to make the project work?
  • Will the support you are promised really materialise, or are people just paying lip-service to your ideas?

The first question is probably the most important, but the hardest to answer. It’s important because you have to know when a project comes to an end. Goals like ‘creating a knowledge culture’ are really difficult because they seems to promote a worthwhile end, but it is impossible to say when the job is done. If something can’t be said to be complete, its success or failure cannot be assessed. What measurable change is there?

Breaking a vague notion into measurable components then leads to the next two questions, which are simply a means of gauging how likely it is that the end might be reached. Few projects, especially in the knowledge context, can be completed without significant assistance from other areas of the organisation:

  • IT: is this a technology project that needs to fit with other things that the business is demanding?
  • HR: does your project affect the way incentives are managed across the organisation? Is that an easy change, or something that demands significant realignment?
  • Finance: few things are free — what other costs are coming up, and how are they prioritised?

The reality is that few organisations can do everything that might be suggested. Projects will often be dropped because there isn’t the resource this year or because too many other things are happening in a similar area. But if the things you want to achieve keep hitting resistance, it is more likely that your goals don’t fit what the organisation is comfortable with. In other words, you’re trying to achieve the impossible.

What to do in such a situation? In general, there are only three real options when faced with difficult challenges: accept things; change them; or leave.

  • If change in the organisation is impossible, can your goals be achieved in different ways?
  • If no change is possible, is there any merit in staying just to maintain the status quo (and possibly make some minor tweaks)?
  • If neither of these is attractive, take the decision to leave as quickly as possible. The sunk cost fallacy applies.

 

What ‘focus’ really means

Mark Gould2 Comments

I have written previously about the need for organisations (and individuals) to choose a focus. The idea also came up in a meeting I had this week. During that meeting, I recalled something Jony Ive said about Steve Jobs and his relentless pursuit of focus. It’s in this video.

What focus means is saying ‘no’ to something that — with every bone in your body — you think is a phenomenal idea, and you wake up thinking about it, but you say no to it because you’re focusing on something else.

Ive mentions keeping some ‘sacrificial’ ideas that he could claim to have rejected, but Jobs knew that he had no passion for those — for him, focus demanded that one could only follow one passion.

This is a rare discipline, but it is worth pursuing. To do otherwise is to try riding two horses.

It’s not my problem

Mark Gould1 Comment

As I was catching up on my RSS feeds this morning, something by Jack Vinson caught my attention.

Tools of the trade

When LinkedIn launched groups, in which like-minded people could discuss topics of common interest, it seemed like a sensible idea. Unfortunately, it is much easier to start a group than to search for an existing one, so there are many groups covering similar ground. As a result, one ends up being a member of a multitude of groups and participating in none.

Unlike me, however, Jack has engaged with some of these discussions, and in one in particular (referenced in his blog post) he tries to move the responses to a standard question in an interesting direction.

The question (posed by a knowledge manager in the mining industry) was simple enough:

I need to put together an AFE (authorization for expenditure) to start the KM program in my company, but the executives are still asking ROI questions. They have the mandate to innovate but just don’t get it. KM is about setting the baseline for indirect ROI or am I wrong?

Naturally enough, this produced some interesting answers focusing on measuring ROI or on ways of persuading the executives by other means. Jack’s response came from at the problem from a different angle:

Maybe it is not time to implement software? Instead approach the executives with the problems they have articulated (such as “innovation”), and propose changes to the process that will help remove or reduce the severity of the problems. A lot of that will have to do with the way people work, regardless of whether there is specific software in place to make it happen. What can you do with the software you have today? What could you do in addition if you were to buy the software you are proposing to buy?

I found this recasting of the question really valuable. Too often, issues are raised about the ROI of particular interventions (social software, KM activities, and so on), but account is rarely taken of the price of doing nothing. The fact is that these projects are rarely undertaken for their own sake — at least, they shouldn’t be. Instead, they are (or should be) proposals to deal with an existing business problem. That problem usually belongs to someone else — whether that be a manager in a particular part of the business, or someone in the leadership team. As Dave Snowden put it in a discussion panel at last weeks KCUK conference, we need to think about what the objects of KM are. He proposed just two:

  • improving decision making
  • creating the conditions for innovation

Given that the decision making process generally belongs to someone else, they need to judge whether (a) it is in need of improvement and (b) how best to improve it. We have a role in helping them with those judgments (by showing them alternatives, for example), but they have to make the call whether a KM approach is the right one.

Ultimately, then, it is our job to show people what is possible, and to offer a variety of options for resolving problems. Our preference for one solution over another may well be misinformed — we can rarely appreciate the full context. That is one reason why many big KM projects have failed in the past — they were not driven by the business, and so the investment that really counts was missing.

In search of failure

Mark Gould1 Comment

I am speaking at a conference tomorrow, looking at case studies of KM systems implementation. During my preparation, I was struck by how much I was concentrating on the things that went wrong. On reflection, I think this is correct.

Last week, Shawn Callahan asked why business writing tended not to use examples:

I suspect it takes more time to find an example and it’s much easier to espouse an opinion.

For example, I’m writing a client report at the moment and I’ve asked my client to send me a couple of examples illustratinh how their information system has been used to have a bottom-line and positive impact on the business. I also asked for examples of when the system had been misused or failed the organisation. My client could immediately think of examples of the latter and is still looking for our positive examples.

So maybe it’s harder to find the positive stories and business report writers have a tendency to want to show strength and a positive outlook, and this is more easily done, especially with time pressures, with opinions. The problem is, we are creating a false intellectual economy because without the examples your readers don’t know what you really mean and instantly forget the main ideas.

On Friday, Dave Snowden shared seven principles of knowledge management. One of them is “tolerated failure imprints learning better than success.” I think this is right, and it probably explains why examples of success do not stick in the mind.

Imagine: if we run a project and it is successful — a KM system is launched and people use it happily. How do we know why it is successful? What are the elements that generated that success? These systems are generally complex and so we can’t point to anything that is particularly responsible things going well. Was it the good relationship between KM and IT? Was it the user interface? Was it the underlying tehcnology? Was it the internal communications about the project? Was it good leadership? Was it good project teamwork? Was it actually a success? There is no way to be sure.

However, when things do not go quite right we can suspect immediately what the cause was. Is the system hard to use? That’s probably because the UI is a nightmare. Does everyone ignore it? That’ll be down to the fact that we are asking people to do something that doesn’t fit into their normal working pattern. Does it crash on a regular basis? Oops, we underspecified the hardware. And so on. We can learn from these things and try to avoid them in future projects.

I might go further than Dave: I am not sure that we learn anything from success at all. As Phil Rosenzweig explains in his book, The Halo Effect, successes are often dependent on a specific set of circumstances and are poorly understood by those who write about them. Rather than learning from success, Rosenzweig suggests that we are more often deluded by it.

So when we look at a success, all we can say reliably is that there is no guarantee that if you do what I did you will succeed in the same way. Contrariwise, in the case of failure, if you do the same as I did (by act or omission) you are likely to fail in the same way. In both situations, you may even fail in a different way.

Document management and collaboration

Mark Gould2 Comments

James Dellow has neatly summarised a discussion about the relative merits of wikis and document management in law firms. Reading both reminded me that I owe an former co-conspirator my view on document management systems as a tool for collaboration. I hope what follows will suffice.

Like most law firms, we have a document management system (DMS). It was adopted some time ago as a replacement for personal network folders. Compared to what it replaced, the principal benefits of the DMS for us are:

  • capture of key pieces of metadata at the point of document creation or storage
  • an effective audit trail and versioning capability
  • ease of search

We are now in the throes of a project to change the way the DMS works so that documents are presented to users in a set of ‘workspaces’ and folders, rather than as a mass of undifferentiated records. (The suppliers call this mode ‘matter-centric’, which is fine for the lawyers, but not especially meaningful for business services people or for work which is not a formal client matter, so we are referring only to electronic workspaces.)

The outcome of this work will be to enhance the potential for collaborative document creation and editing. In the old network folder model, a document clearly ‘belonged’ to the person whose filespace it was stored in. Without an effective search mechanism it was often difficult to find documents without guidance from their author, and practically impossible to discover interesting (and useful) information serendipitiously. This changed radically when we first implemented the DMS. As documents were stored in a common space, people were more inclined to work jointly on them. The openness of that space also meant that people could see much more clearly what was going on around them. However, there were still cultural and technical obstacles to deep collaboration.

In order to protect the integrity of documents, the DMS locks them while they are being edited. This, naturally, means that they need to be unlocked before being available for editing by anyone else (read-only viewing is still possible). Because of the variety of ways in which people access documents — at the desktop, through a web client, or checked out to a laptop for offline working — it is often the case that documents are unavailable for editing for significant amounts of time. This technical issue leads people to revert to thinking of documents as ‘belonging’ to their first author.

As the DMS holds all of our documents, it is essential to be able to apply some form of document-level security. The document creator can restrict access (to view and/or edit) to individuals or groups, but typically our people have come to use this setting in a much less granular way — it boils down to a simple choice between complete openness (document open to all to view and edit) and absolute secrecy (where the document is effectively invisible to everyone else). The middle setting — read-only for everyone but the author — is also used widely by people who have discovered that the way the DMS locks documents when they are opened can lead to them being locked out of their own documents. As a result, although the default system setting is for openness, many people have chosen more restrictive settings that limit the information capacity and collaboration potential of the DMS.

For these reasons, at least, I am not convinced that a formal DMS facilitates collaboration particularly well. For law firms, the features offered by a DMS to protect business-critical documents are likely to be more important than full-blown collaboration. However, there are other documents where a more informal sharing of responsibility is appropriate.In an environment where the robustness and wizardry of a full-blown DMS is less important than facilitating collaboration, such as for academic writing, I think a wiki probably suffices. My experience of collaboration in an academic context is limited to co-authoring with just one other person at a time. However, even this small-scale sharing of responsibility is different in nature to the collaboration I see in a law firm. I imagine that scientific papers with six or seven authors will be different again. In academic collaboration, the audit trail tracking who has read and printed a document is less significant than a record capturing each and every edit, whether minor or not. I would have welcomed being able to use a wiki page to facilitate my co-authoring activities, in preference to Microsoft Word. I am not sure what value a DMS would bring to academic collaborations that a wiki could not offer. Culturally, and technically, the wiki appears to be better suited to the flexibility of academic relationships.

Effectively, I think the reason why this might be is that the object of a DMS is different from a wiki. As its name suggests, the DMS is all about documents (which are containers for content). I think a wiki is less about manipulating documents, and more about the content itself (and, in part, the human and information relationships expressed by that content).

Projects, choice and satisfaction

Mark Gould1 Comment

Patrick Lambe points to an article in the Des Moines Register reporting on research done at the University of Iowa.

The team’s paper, “The Blissful Ignorance Effect,” shows that people who have only a little information about a product are happier with their purchases than people who have more information, the U of I reported. The paper will be published in an issue of the Journal of Consumer Research.

“We found that once people commit to buying or consuming something, there’s a kind of wishful thinking that happens and they want to like what they’ve bought,” Nayakankuppam said in a prepared statement. “The less you know about a product, the easier it is to engage in wishful thinking. The more information you have, the harder it is to kid yourself.”

This is not a surprising conclusion to anyone who has read Barry Schwartz’s book, The Paradox of Choice, or seen the video of his presentation at TED in 2005.

Psychologist Barry Schwartz takes aim at a central belief of western societies: that freedom of choice leads to personal happiness. In Schwartz’s estimation, all that choice is making us miserable. We set unreasonably high expectations, question our choices before we even make them, and blame our failures entirely on ourselves. His relatable examples, from consumer products (jeans, TVs, salad dressings) to lifestyle choices (where to live, what job to take, whom and when to marry), underscore this central point: Too many choices undermine happiness.

There is a resonance in this for me. When we do projects, we spend a long time ruminating over a massive range of choices: which supplier should we go with; whose solution fits our needs better; how should we customise the system; how can we meet the (conflicting) expectations of people in the firm; and so on. The issues identified by Schwartz and by the Iowa researchers are magnified when we have to make choices on behalf of the firm. We, making choices, are less likely to be happy that we have done the right thing in the end than if we were choosing a solution just for ourselves. People in the firm, for whom the choice is made, are much more likely to challenge the result than if they had been involved or had been choosing for themselves.

In understanding our psychology better, Schwartz offers us a hope of satisfaction. If we recognise that too many choices undermine our happiness, we may become happier with our selection: we would have been as unhappy with any other choice that we might have made. Likewise, in managing projects, we can be more resolute in the decisions that we make by recognising that any choice will make some people unhappy, and that the least happiness will result from trying to please everyone.

The only challenge after that is to persuade people that the outcome is for the best, in the best of all possible worlds.