The UC Libraries are pleased to announce new campus-based open access fund pilots to support UC faculty members who wish to make their research findings immediately and freely available to the public. Funded in part by the California Digital Library, these new open access funds will help pay the article processing charges for UC authors who want to make their articles available via open access publishing.

About Open Access: Open Access (OA) literature is free, online, and available to anyone. An open-access article has limited copyright and licensing restrictions which means anyone, anywhere, with access to the Internet may read, download, copy, and distribute that article. The business models for some open access journals shifts the cost of publication from subscriptions to authors by charging the author an article processing fee. In many fields, particularly the sciences, that fee is then charged to a research grant. Recognizing that not all scholars have grant monies to draw on, the California Digital Library has collaborated with UC campus libraries to develop this pilot program.

Links to the UC campuses participating in the OA Publishing Fund pilot can be found on the Reshaping Scholarly Communication website.

For further questions, please contact your campus Scholarly Communication Officer.

Image courtesy of the Oakland Public Library

Blind wandering is the kind of thing that happens when you don’t have a plan, even a short-term plan, like the two-week sprints that are often the norm in Agile shops. Krulwich reports that we are somehow constitutionally incapable of sticking to a straight line if we can’t see a major landmark such as a mountain top, or a celestial marker like the sun or moon. Researchers have yet to determine why this is. They’ve run repeated tests, and the results are consistent. Left to our own devices, it turns out that we spiral back to our starting point.

Needless to say, from a project management perspective, this is no way to get work done. Of course, it is true that many good project plans are not strictly linear, or perhaps more accurately, not single-path-linear. Indeed, the more complex the project, the more parallel paths are required between beginning and completion. Usually, in software and interface design development, there is even an iterative loop (or two or three) along the way.

But I think we do have landmarks, in effect. These would be the milestones on a waterfall project plan, and the sprint backlog in the agile world. I’m calling them landmarks, because they are the pointers that keep us going in a forward direction, even if the path has some twists and turns.

Let me say that I have experienced group processes without landmarks: ones in which the participants go over and over the same material, making and un-making the same decisions. It can be tremendously unpleasant, not to mention costly. Perhaps you recognize this shapeless landscape too. Now we know that it’s our nature to act this way, and unless we intervene and impose some mountains (or celestial orbs) we will wander back to the beginning, again and again. It’s clear that having (and using) even a simple plan with high level milestones is far better than having no plan at all.

After many months and a lot of very early morning conference calls with my European colleagues, I am delighted to make this announcement. The core group that worked on this second iteration of the scheme came from:

• British Library
• California Digital Library
• CISTI (Canada Institute for Scientific and Technical Information)
• DTU Library (Technical Information Center of Denmark)
• ETH Zurich (Swiss Federal Institute of Technology Zurich)
• GESIS (Leibniz Institute for the Social Sciences, Germany)
• TIB (German National Library of Science and Technology)
• TU-Delft (Delft University of Technology)

Other members were involved in an advisory capacity as well. And, this iteration of the scheme also benefited greatly from the many helpful comments offered during the community review period we conducted in the late summer and early fall of 2010.

There are several key features to the metadata scheme, and my colleague Angela Gastl and I discuss these thoroughly in an article in the recent DLIB issue on research data. Briefly, these include a small mandatory set limited to those properties required for a data citation, as well as a carefully selected optional set that allows for the description of data and other resource relationships as desired.

The mandatory set is:

• Identifier
• Creator
• Title
• Publisher
• PublicationYear

It is also notable that the DataCite organization is committed to supporting the scheme in a way that makes both very useful to DataCite’s own members  and also available to the broader community.

On the “useful to DataCite’s own members” thread, I’ll say from California Digital Library’s perspective that we are very glad that the scheme is now finalized. As some readers know, our DataCite application is EZID. Now, we will be able to update our local application to the DataCite standard. Look for increasing functionality and services over time.

EZID (with DataCite inside) is one of the key tools you need to take control of the management and distribution of your research, share and get credit for it, and build your reputation through its collection and documentation. Read more about EZID here, or contact us.

Image courtesy of the Bancroft Library

By early spring, I had a manual process in place, and in July, we went live with the automated charting, showing the trends on 11 measures from our 5 programs. The measures fall into two categories: numbers of objects and usage volume. We can add new measures easily, although we are careful about adding too many. After all, a dashboard can only get so large before the driver is too distracted to see the road ahead.

I mentioned in a July post that the tool we use is AmCharts, a tool that can extract data from .csv or .xml files and then display the data in configurable Flash charts, graphs and tables. My partner in this implementation has been Seán O’Hara of CDL’s Infrastructure and Applications Support Group. In addition to developing the dashboard reports, Seán also created an interface for the data suppliers to use to upload their monthly statistics.  He’s done great work,and I’m so grateful for his help!

I also want to thank the data suppliers, who month after month, provide the data to create the reports. This is a sizable group: Stephen Abrams, Sherri Berger, Jason Colman, Bobbi Perkins-Hill, Lisa Schiff, and Leslie Wolf. Most, if not all, of these folks have developed metrics and even dashboards at the program level. We are all learning from each others’ experiments and experiences with performance measures.

Have you tried any experiments along these lines?

Image courtesy of the Santa Ana Public Library

Certainly, depending on your circumstances, this could be quite beyond reach. This past year has introduced some drastic measures in many libraries, so not everyone will look around and see ends meeting.

But there are some places where the dramatic changes have created unusual opportunities. I will say, for myself, that my year has been filled to the brim with work that is often engaging and demanding, even if sometimes puzzling. This is bounty of a kind. Some days, the brim overflows, actually.

Too, I have smart, capable and stimulating co-workers both inside my library and outside, in the many organizations with which we partner. I am very grateful for all that I’m learning as we charge ahead into strange times where less is more and down is up. One thing is certain: all of us who are working in this space are part of inventing new forms of library service together. We are picking our way through boundaries that seem tied up in barbed wire and bureaucracy on the one hand, and then appear to be curiously free of any landmarks on the other.

I feel lucky to be where I am, doing what I’m doing. When I changed careers almost five years ago, I was looking for more meaningful work. I think I’ve found it. In fact, I think we all have our hands full of important work to do right now, because we live in “interesting times,” as they say.

For this, I say thanks.

Image courtesy of Covina Public Library

As broadcasters had reminded us, this was the first championship for the Giants since the franchise had moved to San Francisco from New York in 1958. I’m guessing that very few of the fans lining the streets remember the Giants from those pre-1958 days, nor do they recall that the Giants’ cross-bay rivals the Athletics were once the Philadelphia Athletics. (The outcome of the 1911 matchup was the same as the 1989 earthquake-series.)

This little foray into baseball trivia is a reminder that affiliations come and affiliations go. Even beloved ones, the ones that cause us to paint our faces and wear beards and panda hats.

And that is why our EZID Service Guidelines say “For best results, identifier strings should be opaque (non-meaningful), globally unique, transcription-safe, and reasonably short. Opaque strings tend to age and travel better than identifiers containing widely recognized meaning.”

EZID is our new service that makes it simple for digital object producers (researchers and others) to obtain and manage long-term identifiers for their digital content. I’ve talked about it a little bit here before, when I mentioned that persistence was not “just” a matter of ensuring that links don’t break.

Of course, this issue of ensuring that links don’t break involves more than a little tinkering. Most particularly, it depends upon a set of services like EZID (and those that underlie EZID), as well as the ongoing maintenance that owners of identifiers provide. But the whole exercise is made easier when the identifiers themselves do not have embedded “freshness dates” in the form of names, brands, or phrases.

What if, in your post World Series enthusiasm, you decided to start all your identifiers with /sfgiants/? Let’s go ten or fifteen years into the future and imagine a despicable owner comes along and takes the team south to San Jose. What then? It’s like a bad divorce. Do you rename all your identifiers? You have hundreds or even thousands. If you don’t, the branding you once thought was so sharp becomes a pointed reminder of things past.

The solution to this problem is simple: avoid mixing love, marketing, meaning, and anything else with your identifiers. Keep them inscrutable. Use metadata to convey the story you want to tell and save.

To me this is a provocative phrase, “reduce the cost of change.” Highsmith and Cockburn are thinking about the technological costs, which are the kinds of things that Agile is explicitly designed to address. I believe this idea can reach much farther. When the new software is delivered, or the new process is introduced, or the new plan for expansion is announced or, let’s admit, when the new cutbacks are detailed, there are human costs that play out over weeks or months. It follows then, that whatever we can do to reduce those costs will increase our organizational agility.

In the case of software development projects, the Agile practice of including business stakeholders in the development process can certainly mitigate these impacts. But even with that care-taking, there will still be some communication planning required between the participants in the projects (the innies) and those who just keep doing their ordinary jobs (the outies).

Plenty of us have trouble with change. And so, if we find ourselves in organizations that are undergoing a change of direction or any kind of disruption, might it not be an appropriate question to ask, what can I do to reduce the human cost of change?

This reminds me of the topic of resilience I touched on back in March. Then, I quoted from a Harvard Business Review article on “bouncing back from adversity.” What I didn’t include in March, but I’ll add here, are some of the focusing questions that the authors, Joshua D. Margolis and Paul G. Stolz, give to point teams forward in trying times.

• Who on my team can help me, and what’s the best way to engage that person or those people?

• How can I mobilize the efforts of those who are hanging back?

• What strengths and resources will my team and I develop by addressing this event?

• What can each of us do on our own, and what can we do collectively, to contain the damage and transform the situation into an opportunity?

Do you think these are helpful questions?

These questions came up at a meeting here. Some felt that bringing certain projects to successful conclusion was, indeed, heroic. They thought it took special determination, that something had been saved by the project manager’s actions. It might have been the team’s reputation, or the organization’s resources, or a deliverable that another team was depending upon.

Others believed that, if heroics were called for, then the project manager had not been doing a good job in the first place. These folks expected good project management to result in regular schedules, adrenaline-free Fridays, and a basic lack of unforeseen circumstances. No silver capes required.

I don’t think things are quite this cut and dried, myself. Project managers don’t always have the luxury of starting from scratch, picking a dream team, or even picking the team at all. Sometimes, the project manager joins the project mid-stream, or even toward the end. Depending on the state of affairs left by the previous project manager, the new guy or gal may not have such a good set of maps from which to start working. That means getting a handle on the project, managing the team, and delivering the service or product is an uphill battle. If that person helps the team succeed, is he or she a hero? Or simply doing a good job?

Let’s think too about the loneliness of the long-distance project manager. When I started that sentence, I intended it to be about the project manager tackling a multi-year project, the kind of thing that requires a sustaining of momentum through institutional budget cycles, staff turnover, software upgrades, and more. But it seems to me that it also applies to the project manager who is located in one city while the project team is located in at least one other place. There is energy expended to sustain momentum there as well, and there is a multiplier factor when the distance is greater than two timezones away.

You begin to get a sense that “doing a good job” in project management is actually a shifting notion, and something that’s gotten quite a bit more complicated in the last ten or fifteen years, with the increasing speed of software development changes and the ever-widening geographic scope of project teams.

In a world where a librarian can become an action figure, maybe it’s time to revisit what it means to be a hero.

Cause and effect myth-making is a flavor is misleading memories, one of the three red flags of bad decision-making that Andrew Campbell, Jo Whitehead and Sydney Finkelstein wrote about in a Harvard Business Review piece last year (Why Good Leaders Make Bad Decisions, Feb 2009, 60-66.) The other two are inappropriate self-interest and distorting attachments. The presence of any one of these factors can through off the judgment of the best and smartest decision-makers.

What happens is that our brains engage in “high levels of unconscious thinking.” The end result is that you think you know the right thing to do or the right decision to make, but it’s colored by the undue influence of a past experience, a strong attachment to someone involved in the situation or your own interests in the outcome. According to the HBR article, you can’t help making a bad decision, if any of these factors are involved, unless you take some counter-balancing action. They recommend these steps (I’m paraphrasing):

• Get exposed to additional experience and thinking,
• Build in more discussion and chances to hear dissenting views, and
• Seek additional review.

Another look at the foibles of our psychological makeup is available in the book Sway by Ori Brafman and Rom Brafman. The book’s subtitle is “The Irresistible Pull of Irrational Behavior.” Sway is an exciting, if somewhat disturbing tour of the “hidden currents and forces” underneath our ordinary exteriors. These include (and I’m paraphrasing here too):

• loss aversion (the willingness to do almost anything to avoid losses),
• value attribution (the tendency to go with first impressions);
• and the diagnosis bias (ignoring all evidence that contradicts these first impressions).

Sadly, the Brafman’s report that “the the more there is on the line, the easier it is to get swept up into an irrational decision.” They too have suggestions for working against our instinctual responses, and there is overlap with the HBR steps, but these proposals seem to involve a little more personal work.

To combat our fierce desire to avoid loss, the key is to take a long term view. It turns out that the loss we fear most is short term. The antidote to value attribution is a commitment to observation, to seeing things for what they really are. And, overcoming a diagnosis bias involves truly keeping an open mind. It also helps to open up decision-making processes to others.

So, if you are engaged in any decision-making, it may be worth your attention to these instinctual “hidden currents.” Particularly if the decisions you need to make are very important, there’s a good chance that you can improve your decision-making outcome by opening your process up to review, dissenting opinions, and consideration of the long-term perspective. That’s what the psychological studies are saying, in any case!

Since then, I’ve been thinking more about patterns in the kind of work we do, and I think there are several different ways that patterns enable inventiveness.

Patterns can act like building blocks upon which, or from which, we create something entirely new. An example of this is modular or component development, such as the Merritt Micro Services launched recently by CDL’s UC3 team. These are discrete services that can stand alone or plug in together to create exactly the curation system needed for a local solution. The UC3 components are open and can also interface with components created by other developers, and so, in this very real way, they are a basis for innovation.

Image courtesy of the Allis-Chalmers (Oxnard Plant) Archives, Oxnard Public Library Photograph Collection

In a slightly altered manner, patterned processes can also enable innovation. That is, by codifying some procedures and techniques, it’s possible to analyze work flows, which can then lead (sometimes) to innovations in the way work gets done. It can also (sometimes) free up resources. This kind of work has to be undertaken by those who truly understand the domain, or the results can be counter productive.

An example of this kind of process analysis is work that the Next Generation Technical Services Task Force groups have been considering. Their collective charge has been, in effect, to look for places in the UC Libraries’ technical services where common and repeatable processes can be done once and not 10 times, so that scarce resources can be allocated to the special and innovative work that wouldn’t otherwise be possible.

In this case, there is a double dose of creativity. The solutions being proposed are, in many cases, innovative. And, if they are adopted, and succeed, then they will release resources for other creative work.

In project management, we use patterns too. When assessing risk, we are looking out at the road ahead and identifying patterns we’ve seen before, hoping to avoid the potholes. When we use proven techniques and templates, we hope to capitalize on knowledge we’ve gained through experience, freeing ourselves to focus on unusual situations that may arise.

The trick in using patterns, and this is as true in the world of design as it is in the world of project management, is to know when to apply the rule and when to depart from it. You have to know when to adapt, to look around and see that the place you’re in is a specific place that demands creativity from you and offers you the promise of new discoveries.