CIL2010: Black Ops Ninja-Style Technology Projects
This session was a panel presentation on how to quickly implement technology projects with covert, black-ops, ninja-style approaches. The panelists included myself, Amanda Etches-Johnson, and John Blyberg.
The session has its own hashtag, #CILninjas, with a live-stream of comments and questions which is worth perusing for your own enjoyment and edification ;) Update: Our hashtag for the session was a trending topic on Twitter during our presentation and for a little while after. Wow!!! The power of Twit-brarians!
So, without further ado, the tips:
John – Getting people on board by finding key advocates and embedding them throughout the library organization as cheerleaders.
Amanda – Stick to project goals that fulfill your library’s mission and goals.
Sarah - Blend into the environment and sneak up on people, ninja-style. Sometimes you can make some changes without anyone really noticing. Or you can sneak a project through. Slowly introduce your idea through covert emails, mentions at meetings, and then when you announce your project it won’t seem so foreign or inconceivable to people. People respond better to the familiar, even if it is something they’ve only heard one other time. Example: adding circulation contact links in the catalog on the My Account pages.
John - Have a vision in your mind that you can help people be passionate about (oftentimes because what is there is not passion-inspiring). He gave the example of SOPAC implementation at Ann Arbor District Library.
Amanda – Follow evidence-based practice. Start with a literature search and ask your colleagues what their experiences are. If there isn’t evidence to support what you want to do, don’t give up, but at least then share what you have done with others so that there is now information for others to use to support their projects.
Sarah – Avoid collateral damage. Don’t step on any toes power-wise. Don’t hurt anyone else’s unit, or staffing, without their say-so. Involve everyone who needs to be involved early on. Get users involved early. Let them help define the project’s goals, you help them with the how. Respect the knowledge and insights of your coworkers.
John – Answering a question about what if you fail with your project? Deploy like a fire jumper. You drop in and you hold an area. If you’re not committed to devoting all of the resources necessary to make your project a success, there’s no point in doing it. But it’s okay if you fail. You learn from failures. “People learn from a legacy of failure.” If you are wrong about a project, admit your mistake and analyze why you couldn’t make something work through a post-mortem. Was it because the idea was bad? Was it because there weren’t enough staffing resources involved? Apply those lessons for the next time you want to try something out.
Amanda – Don’t focus on the small, inconsequential items. Use a team-based approach for decision-making.Teams can focuso n smallerr
Sarah - Answering a question about pushing forward on something without asking for permsision vs. getting stakeholders on board early: It’s a judgement call. If you know from experience that their objections will not be based on fear instead of reality, then push ahead. My tip: Trust and follow your instincts. If it sounds like a good idea to you, believe in your instincts. You’re not stupid. If you’ve done research and thought about it, it’s likely a good idea. Example: We had a really junky horrible graphic design for our new website that a paid designer produced (paid well). It was crap. But we paid for it. Our new web librarian, Nate Hill, came in and on his second day showed me a mock-up for a new design he’d done just as an exercise. It was head & shoulders above what we had from the designers. My instincts said to use the new design, and we did, and it paid off.
John – Know when to quit. It’s not about what you’ve put into it, it’s about what you get out of it. It’s important to not dig your heels into a bad project when you know it’s bad. Question from audience: sometimes it’s okay to implement a stupid project just to show that it’s a stupid idea. Use your judgment about when to implement something. It may undermine trust in your expertise or projects in the future.
John – Win over the hearts and minds of your users. Give people stability so they can do their jobs at the end of the day. If what you’ve created is not rock-solid, don’t do it. We need to move from a culture of reaction to a culture of innovation. If there are problems, solve them at the root so that it doesn’t plague you moving into the future. Figure out why it’s a chronic issue and how to fix it. Be high profile about being “the fixer” who makes their lives easier.
Question: How do you say no without offending them? Ask them to do some research and show there is a user need and ability to support the project. Oftentimes that will end in the project dying out anyway. Make sure that the person suggesting the idea has some personal investment in the project and is willing to put in time and effort to support it. Otherwise they’re telling you what to do, and that’s not a recipe for success. Amanda will often paper-prototype the website requests she gets and tests it to see if it would or would not fly.
Comment: Don’t show all of your cards. Keep some of the basic suggestions in reserve so that stakeholders can make the suggestion themselves and sound like they have had a contribution to the project.
Comment: There are positive ways to say no.
cil2010, computers in libraries