For this presentation, I decided to speak more broadly on accessibility (rather than focus specifically on web accessibility), partly because it’s so short (5-10 minute lightning talk) and partly due to the fact that despite it being a “Code4Lib” regional, we wanted to promote cross collaboration across all skill and knowledge levels. I still used a technology example, but had physical space related examples as well. Continue reading “Code4LibBC: Shifting Perspectives: From Disability Accommodation to Universal Design”
Category: Methodology
Planning a Regional Code4Lib: North 2013
As I have recently joined the code4libBC planning group, I thought I would reflect a little on how the planning happened and worked for code4lib north even though it was a while ago. Continue reading “Planning a Regional Code4Lib: North 2013”
Guide Reflow: Deciding on Your Accessible Format
We have two existing guides that help coordinators and students decide on their preferred format, but they seem to reflect all the formats we could produce rather than the more practical reality of what we normally produce. Continue reading “Guide Reflow: Deciding on Your Accessible Format”
Services Card Sort & Revised IA
So this time I did a proper card sort, because the services section is a lot bigger than the others. How to group services and the pages therein is also a lot less clear cut. Continue reading “Services Card Sort & Revised IA”
Code4Lib Pre-Conference: Fail4lib
Being a smaller session, there was a lot of tangents and what not, so apologies if the notes seem a little disorganized.
—
How do you measure “value” or success of projects in library setting where ROI is not measure in the amount of money?
Some Flavours of Failure
- technical failure
- failure to effectively address a real user need
- overinvestment
- outreach/promotion failure
- design/UX failure
- project team communication failure
- failure to start
- launch failure
- no usage
- missed opportunities (risk-averse failure)
Most of these issues boil down to a break down of communications of some sort.
What does a Project Manager Do?
Sometimes the problem is not knowing what a project manager does. The person who comes up with the idea thinks they run the project; think that they know everything to make the decisions. Or, they become the one dictating all the requirements.
A lot of the issues are political. No way to move it over to having systems oversight.
Making the Distinction?
Project manager is in charge of day to day operations. Project lead is thinking about high level requirement, more strategically, and becomes liaison between systems and the rest of the library. (e.g. public services project, would have public services librarian) Decisions are made collaboratively.
Once it settles in, make an oversight team for maintenance purposes.
The Culture of Process
Product is the reflection of the process? But, want to see evidence of process. Without ‘evidence’ of the process, what about accountability and transparency? The evidence can also be a good reference so that you don’t have to explain.
Get people to meet to discuss what they’re going to do. Can cut down a lot in the amount of time spend doing things that aren’t needed, and waiting for dependencies.
Staff frequently also think they know what users want better than users.
Project FUBAR Lightning Talk
Major Projects
- Islandora + digital repository initiative on campus
- Sierra – ILS
- EZProxy
Timeline
- Islandora: lots of delays in development
- ILS: had to go beta early
Option for Failure?
- mission critical projects, must be salvaged
- how to deal with other people’s projects failure – vendors didn’t deliver
- plan for the worst before the worst happens
How to Successfully Survive a Mandated Project
- practice good communication
- know the political ramifications of your actions to yourself and the chain of command
- work to manage expectations
- be prepared to clean up any messes and make any changes
- Souce: Ellern, Jill. “How to Successfully Survive a Mandated Project,” Computers in Libraries 31, no. 9 (Nov 2011): 16-20.
The Right Approach
This is a reference to the Dilbert comic called “The Right Approach”, which a porcupine says that “we must stick them with quills – it’s the only way!”, because the ‘correct’ approach in any situation is the only approach you know.
While the project I worked on wasn’t quite like this, it was more the ‘the status quo’ is the best approach.
Project Failures
Seagull failure
- “seagull manager flies in, makes a lot of noise, craps on everything then flies off again leaving a big mess behind” -urbandictionary
Examples – Fail Projects
Never went live
- statistics dashboard for collections and services
- web app to add photo information to specific photo collection
Fail by Bloat
- Instruction workshop scheduler – supports weird business rules
Managing Risk
- building diverse teams
- expecting dead ends
- having fall-back plans
- learn to say ‘no’ (preventing project creep), list features and possibly impact and complexity
- fault-tolerant schedules
- establishing flexible goals at the start
- communicate
- making sure it fits in the strategic plan (helps with funding)
- prototype/drafting to make sure it’s feasible
- make product resilient, assuming someone will try to break it
- launch checklist by VCU
It’s All About Communications
Need to communicate with the staff. Present and allow feedback. Need to give people an outlet to provide feedback and response to feedback. You don’t need to implement most of it.
Don’t assume that the person is ignorant, dumb, or just out to get you. You’re not always right, and sometimes ideas are tossed in just to make people think.
When a Project has Failed
Do a post-project review and go over the failure points. Post-mortem meetings can be very cathartic (even if it ends up being a rant).
Learn from your mistakes. You should always do this even if the project didn’t actually fail.
Cold
Now it’s back to braving the cold at the end of the pre-conference day.
