Wanted: Librarians, Cataloguers, Programmers, IM talent

We are looking for new talent and have openings to fill. Are you an experienced professional skilled in cataloguing, metadata classification, controlled vocabulary development, web development, .NET programming or application development?

If so, please send your resume today to jobs@xist.com

The Fall Guy Information Management Consultant

I once told a client that information management consultants are sometimes hired as fall guys. Not officially, of course, for how would you request this in an open tendered bidding process? But unofficially, as an additional “value for money” kind of benefit, consultants can take a bullet for the client, shield them from blame or function as the sacrificial lamb (to mix metaphors).

How so?

Many times an information management consultant is hired to provide analysis, problem solving and propose an array of potential solutions. Many times this work produces recommendations that cause turbulence within the organization, disrupt standard business processes, alter roles and responsibilities, or compel people to invest time and effort to learn new types of technologies. Many times people don’t welcome these changes and prefer their status quo because although not perfect, these processes are familiar and people have learned how to cope with the inefficiencies. But many times change is necessary and it’s going to happen whether or not people resist.

Moving people through change can be difficult for a variety of reasons. The more I work with organizations the more it seems to me that they are guided by laws of physics.

An object in a state of motion will remain in that state unless an external force acts upon it

- to paraphrase Newton’s first Law of Motion

An inert object requires an external force to set it in motion

- to paraphrase Galileo’s Law of Inertia

After the information management consultant has made their recommendations the organization is left to implement the plan. Most often people willingly accept these changes because they understand the collective benefits but, particularly for plans that introduce changes in turf and reshuffling of responsibilities, this process can be difficult.

This is where the fall guy angle comes in it.

People want to know why they are forced to change. They want to know the external force that acts on them to change their motion or disturb their state of inertia. Ultimately everyone must work together afterwards so for these types of changes the information management consultant is a good fall guy. For those who are outspoken and resistant, the explanation that the change was approved because the information management consultant made these recommendations can have value. As stupid as it sounds, it allows people to focus their bitterness on the consultant instead of their coworkers, which in turn helps them to salvage their working relationships.

There I said it. I don’t encourage people to do this, but I understand why it happens. It doesn’t happen a lot because most of the time it can be avoided with clear communication. But when it does happen, it can be the last contract you have with the client for a while. In this case, turn out the lights, close the door behind you, and don't look back. In time the phone will ring again to discuss a new requirement.

A follow-up to this is now required: The fragile reputation of the information management consultant.

Lessons in Finishing the Job

A long time ago (for me) when I was an undergrad at university, I had a discussion with some other students and a professor about knowing when an essay is complete enough to hand in. In some disciplines, such as math and science, there is a point in problem solving where an answer is found, an absolute, which is the trigger point for stopping the problem solving exercise and submitting your work. These are the black and whites, the binaries, where there is an identifiable dividing point between the unknown and known. But what about the greys? What about those disciplines that don’t have quantifiable answers, which are based on arguments and opinions? Since they do not produce quantifiable answers the problem solving exercise is seemingly endless.

My line of work – research and user needs assessments, information management consulting, information architecture design, user interface design, indexing, classification, search logic design, application development – constantly faces this challenge. So when is enough enough? When do you say when, when you know their isn’t an absolute answer to be found?

The answer that resonates the strongest with me is:

The best essay is a done essay

It’s a simple concept. But for an undergrad student it is a good mantra to learn. Before I learned this, research as an undergrad was a painful experience. I learned that professors were very accommodating for students like me who agonized in the pursuit of a brighter polish for their work. Getting an extension for deadlines was straightforward and seemed good at first, because you had more time to refine your essay. But after a while I learned it created backlogs and time management eddies as new deadlines approached for work not yet started. Instead of improving the situation this pattern of deadline deferment compounds the original problem and compromises the quality of the work. The quality of the first essay will likely improve, but at the cost of the quality of the subsequent essays. So the concept that the best essay is a done essay supports the view that you need to finish what you start within the time you have and move on so that you can maintain similar quality levels for future work. Of course for this to hold true you need to know your subject matter and have confidence in your abilities.

In professional life, many times I see people don’t know how to finish their work or projects. There are multiple reasons for this, and some are even valid, but in many cases they can be avoided. The reasons that annoy me most are:

1. Involving too many people in the process, especially those who have no vested issue in the project’s final outcome. Don’t ask everyone in the organization to participate in the process, ask only those who bring the required opinions and expertise to complete the work and fulfill the tasks at hand. Bringing superfluous opinions into the project costs valuable project time and introduces the possibility of alienating people. After all, if you are going to ask someone to give input, out of respect you should at least address their contributions whether or not it was useful. The people management and communication skills required to pull this off requires time and effort, which needs to be closely guarded to keep projects on schedule and completed on time.
2. Revision redundancy. There must be a strong urge within us to revise opinion-based work. Revisions are not bad, per se, but there is a point where you need to accept that the work will never be perfect. It will, however, be good enough to achieve the project’s original requirements. I can’t tell you how many times I have seen revision cycles lead right back to the original starting place.
3. Too much noise and too many messages. Less is more. It takes courage to produce less, but the message will be clearer if you don’t obscure your analysis or recommendations in a nest of ideas, theories, visual or cognitive images. Break out what is the heart of the matter and express it clearly, while setting the other secondary ideas aside. You need to know that a project is done when it’s done. Many times people cannot resist the urge to do more than is needed, perhaps because the answer seemed so simple that they need to show more effort was invested.

Now to hold true to this revelation that the best essay is a done essay, and that less is more, I will end this blog entry right here. Or right here, or here …

Done.


Posted by Chris Savage at 10:42 AM

Statements of Work that Work

Outsourced strategic planning and research projects can fail for more reasons than they can succeed. At the end of a project that fails to meet expectations, people tend to sift through the smouldering ashes to look for the initial cause. This is not a high moment in human behaviour, with client and contractors showing courage to accept responsibility. It is usually marked by defensiveness, doubt and uncertainty with each party hoping to clear their name and pin the blame elsewhere or at best hope the blame falls somewhere else. It doesn’t have to be this way and it can be easily avoided.

The first step to successfully outsource a contract is to define the project scope at the outset. This means to draft a stable, clearly written statement of work (SOW) that both parties can review and agree upon. Many times the SOW is an outcome from dialogues between the client and contractor to review the undefined, nebulous but gradually coalescing requirements. In traditional library terms, this is the reference interview: the stage when an information professional listens to the client describe their information need. In this stage the information professional walks the client through a series of questions to narrow their options and focus on priorities and outcomes. The key to do this properly is to understand that most times people have difficulty expressing their information need. They may have an idea of what they want but the words to describe it in relation to secondary and tertiary needs are often misunderstood. By the end of the reference interview both parties should have a clearer sense of the client’s requirements and priorities.

After this process a detailed statement of work should be created. In most cases it is the client’s responsibility to do this. :) This is an important activity, and if done poorly it can condemn the project to failure, so beware.

Statement of work writing is a skill. Along with the request for proposal the SOW is the first part of a dialogue to establish the scope of the project. The second part of the dialogue is the contractor’s proposal. Done properly the proposal should reflect the SOW including its aims and objectives. The SOW not only defines the deliverables but also sets the tone for how the final report will be used and by whom. One of the most common problems I have seen with poorly drafted SOWs is that they aim too high and use lofty, hyper-academic writing styles. Maybe this is born from the fear that unless the SOW is written to sound like it is the most important project ever conceived that the contractor won’t take the project seriously, or serious enough to do a decent job. But good intentions can be misguided. From what I have seen, if the SOW is written in a style that sounds lofty, far reaching and GRAND, then the odds are that the final report will be same. In some cases the final report should be grand with fantastic, far reaching plans for a bold future that challenges the reader. In most cases, however, the final report just needs to be actionable; something that can be translated into practical terms to achieve a very real end. This leads to my first maxim for writing statements of work:

If you need someone to build you an X-wing fighter, don’t ask for the blueprint to develop a Deathstar.

This means, don’t make a big problem out of something small. If the project is small, then let it be small and don’t try to build it up into something grander than it is. Just because it is a small requirement does not mean it isn’t important, after all. The converse of the first maxim is also true but much less common:

If you ask for a nuts and bolts report you will get a nuts and bolts report.

The SOW sets the tone so it must be clear in its needs, audience, and the intended use of the final deliverables. The style and language used is important so that the client and contractor can coordinate their vision for the final deliverables.