There’s nothing like your 25th anniversary since graduating from library school to cause you to reflect. I recently attended a 25th anniversary reunion at the Faculty of Information Studies at the University of Toronto, my alma mater. Reconnecting with old friends and colleagues was great and stirred up many memories of a fairly young, newly married, and very green librarian heading out into the big world.
What have I learned in those over 25 years, and is any of it useful? Each of these points below has at least one story underpinning the learning - and usually many. As I wrote this column, I was surprised by how many little rules and insights drive my perceptions of innovation and product development. Hence, this column mushroomed into a three-parter. And, as I find to always be the case, there was some pain and some gain associated with learning these insights. I can’t guarantee that each philosophy will work as well for you as they do for me (or as the kids say YMMV – Your Mileage May Vary) or in every situation. Also, when I look them over I see that some are attitudes more than aptitudes. That’s interesting to me. Attitude is everything. When you’re positive, positive things happen. Anyway, I have collected this list over a few years and thought that I would share it with you this summer. So here goes:
1. Iteration is everything.
In this new Web-enabled (Web-dominated) world of information service and delivery, we are dealing with a technology that is still in grade school (less than ten years old), and many of its major players range from pre-school to primary grade age. We just are not going to get it permanently right with a few development cycles. We are in a continuous development state, and this state will likely last for many years. Indeed the invention of the book took many centuries to standardize what we consider an intuitive format today! So, we must focus on continuous iterative development of our interfaces, Web sites, content, and services. And, every once in awhile, we have to be ready for that forklift upgrade. I know I see evidence of this in the evolution of Sirsi OPAC and Web interfaces, such as the evolution from green screens through WebCat/Web2, iBistro/iLink, and now Sirsi Enterprise Portal Solution (EPS). It seems that every five to seven years you need to rebuild and take advantage of emerging standards and new technology innovations. But, during that period until the next big thing comes along, we tweak and adjust and add new features as we iterate to achieve the improvements we need.
2. Good not Perfect
Closely related to the first point, this is one that many of us have difficulty dealing with. We are, after all, a profession that covets the perfect catalog record, believes that we can organize all of the world’s knowledge for universal access, AND sits behind desks offering to answer all comers’ questions. Pretty nervy! It is a challenge for us to know when to release new products and services and when to decide something is done, finished, and complete. Perfection as an attitude gets in the way of this decision. When our stock-in-trade was mostly uncorrectable hard copy, this served us well. Now that we spend so much time in designing malleable interfaces, Web products, and content that is correctable and improvable on the fly, we need to decide when good enough is good enough. A valued colleague used to quote this “Good Not Perfect” aphorism in so many meetings that we bought her a t-shirt. It broke the perfectionist mindset logjam so often, and we all benefited from the real learning derived from working with the real product instead of the product in our minds.
 |
3. It’s not the number of steps that cause delays in development - it’s the space between the steps.
Have you ever been frustrated with how long it takes to accomplish projects? Of course you have. I have noticed that it’s not the number of steps in your project plan that determines how long the project takes. It’s when you take a breather between every step that causes delays. Now, I am not saying that rushing is good, but good project management minimizes the space between the steps and stays focused on achieving the milestones and ultimate goal. I know that many Web sites benefit from regularly scheduled updates and improvements. Others seem to stay static and fossilized for years until they require complete removal and rebuilding. By sticking to a pattern of innovation and improvement, things stay dynamic and engaging.
4. Freeze and Go!
The right metaphor for much electronic development is seasonal change - not revolution or evolution. With services delivered by humans, we can adjust and adapt as we see changes. Technology driven products and services are a different matter. Products are usually released in a somewhat fixed state. Changing them too often confuses the user, but changing them not often enough causes them to risk stagnation or even fossilization. Choosing the correct cycle is an art. If you do something revolutionary, it is often called “ahead of its time” in retrospect but doesn’t achieve too much acceptance in the present, and the evolutionary approach can be death by a thousand cuts to sysadmins and users everywhere. Therefore, I like the seasonal metaphor where changes are collected and released on a simple schedule (quarterly, semi-annually, etc.). This requires some rigor in the process where the release is defined and the specification is respected so that the release can be frozen, tested, and released. Then the development team can “go!” - moving on to the next step. I have seen too many Web sites and content projects risk failure through random tinkering, second guessing, and poor management of good ideas for improvement. Don’t let this happen to you.
5. Prefer action over study.
If you or your team is studying something to death - remember that death was not the original goal! I have been in libraries where their systems folks in the host institution were studying whether to upgrade from Windows 95 to 98 in 2005! Scary. Although we have a great core competency in research and study, we must know when to fish or cut bait. In risk-averse cultures this is particularly difficult. What needs to be learned and understood is that delay is as big a risk as poorly considered action. Pilots and good processes reduce your risk (and provide learning opportunities too). This philosophy is closely related to the one where an enterprise values its conservative culture and gradually declines due to its lack of adaptation to modern expectations.
6. Brainstorm, Mock-Up, Build, Alpha, Rebuild, Beta, Pilot, Test, Launch, Evaluate, Re-Do.
And there’s the process. It’s pretty simple, and many make the mistake of trying to skip a step. I’ve rarely seen a skipped step that didn’t cause problems later. Each step can be quite small and contained. You don’t need to bet the organization’s future on a single initiative – writ large in the strategic plan. You do need to actively seek to have many projects at different stages of development in your funnel. That way you have built innovation processes into the DNA of your culture. By building teams focused on a few key initiatives – for example virtual reference, Rooms, and Web portals – you can focus attention and run several projects in parallel. This starts to create excitement and a practical image of action over study.
7. Remember the rule of six (6) in usability testing.
You get very diminishing returns after asking the same question of like people. Sometimes we think that we can reduce the risk from the implementation of our innovative product features and functions by testing it with hundreds of users. Some research (and personal experience) leads me to believe that this volume of testing just increases your costs and delays delivery. For example, if you’ve designed a Web site for teen cardholders in your community to podcast their personal book reviews, then you likely only need to test it with six teens in your community to find out enough to iterate an improved version to test again. This technique will improve your product faster, and you’ll learn more. You’ll also get closer to your target market’s needs and values when you work with them personally rather than reviewing hundreds of pages of click reports! For example, if you add a blog or a new library calendar to your library portal, test it with six people and integrate the learning from their experiences into your next iteration.
8. Remember the 15% rule.
Humans have extreme difficulty in actually seeing a comparative difference of less than 15%. I once read that research shows that when we see the light from 100 candles, we don’t see a difference in brightness until 115 candles are lit. Interesting - I understand that the same thing is true of sound volume, color variation, and other matters of human perception. Indeed, in job evaluation systems, jobs are not considered sufficiently different until there is a 12.5-15% difference in the job’s points. So, what I have learned here is that innovation needs to be sufficiently different from what was there before for humans (users) to see the difference. Some people think that making 100 things 2% better will make a perceptible difference. This isn’t likely true, and for our purposes, we should probably attempt to make a much smaller group of initiatives 15% or more better. I also think that this is why single, small introductions of new features on library portals are often missed or ignored until they’re pointed out. They’re not sufficiently different to be perceived and noticed. Therefore, it might be better to make grander changes to bring attention to new services and products in our virtual space.
9. Use the 70/30 rule.
“I agree with 70% of the plan and can live with the other 30%.” That’s the key to consensus decision-making. Lord knows the time wasted trying to achieve 100% agreement to all points and ideas. If you can lead your team to agree to this principle, you have made a major step forward in breaking the logjam of unmade decisions in “almost” complete projects. Of course, major stumbling blocks that some team members can’t agree on must be worked through. Don’t let the minor ones hold up progress. Remember the iteration rule – there’s always another season to make changes based on user experiences.
10. Remember the old 80/20 rule standby.
No matter how few or how many users you have, 80% of your usage / revenue / statistics, etc. will come from 20% of your users. If you remove 80% of your users who aren’t delivering good user numbers, you’ll still be getting 80% of your use from 20% of your users. Don’t let some spreadsheet demon lure you into the productivity trap. Remember that 80% of users, who are not using your product or service a lot, are your non-users and also your future or emerging new users, users who are still getting comfortable with the product, users from other demographics where you’ll discover new products and services to create, and users who are just at a different point in the adoption curve. If you want to grow, you have to be a big tent to find all of your future users. If we only surveyed folks who came into the physical library, how can we be sure we’re meeting the needs of our virtual users?
11. Remember the 90/10 rule.
It’s true enough that 90% of your costs in both time and money are in implementation, not development. It’s a crying shame, but it’s true. Never underestimate the amount of time and effort that will be required after you have given birth to your baby product or service. Just like human babies they require a lot of effort, expense, care and feeding, training, and support to bring them up to their full potential. And like kids, be patient, they’re marvelous when they’re all grown up!
So, there’s the first eleven. Watch for the next set in the August issue of Sirsi OneSource.
Stephen Abram, MLS, is Vice President, Innovation for Sirsi Corporation. He is the past president of the Ontario Library Association and the past president of the Canadian Library Association. In June 2003 he was awarded SLA’s John Cotton Dana Award. Stephen would love to hear from you at stephen.abram@sirsi.com.
