Code4Lib Pre-Conf: Project Management (pm4lib)

Lead by Rosalyn Metz, Becky Yoose

Not agile, because with a single person team, it’s difficult to do SCRUM, so only agile-ish.

What are we working on?

Being with ‘what are we working on?” Have a meeting

This goes into helping to figure out the scope of the project.

5 why’s: basically, ask why 5 times. Everyone write down their answers. e.g. Want to redesign the website, but turns out because they don’t know what services are provided.

Scope

List of goals that you want to achieve, but what if you don’t know what your goals are?

Goal setting using SMART goals. Gives you a structure to work off of, and helps with project monitoring.

  • S: Specific – should answer who/what/when/where
  • M: Measurable
  • A: Attainable – realistic given current resources
  • R: Relevant – goes back to scoping, making sure addressing issues
  • T: Time-bound – marking milestones & progress

Also helps you narrow down your scope, and leads into project charter.

Goal vs. Task: More general, what needs to get done vs. implementation details

Examples:

  • Design and develop an interactivity module from other code by the end of September. – will want to break down, more of a project objective
  • Initiate development of code with team [add time].
  • Testing API to see if meet requirements [add time/who].
  • Have [person] teach one workshop with at least 20 registrants this summer at [this office].

Who are you dragging into this project?

Stakeholders

  • project executive sponsor – whether the project happens
  • project sponsor – person who makes decision resources, people, budget, etc.
  • project manager – person responsible for moving the project forward, beholden to executive and sponsor, also note person who comes up with idea is not always the manager
  • team members – people doing actual work
  • others

Do this on your own or with someone trusted. Don’t do this with the stakeholders in the room.

You want to understand their place in the project, reason they’re there, the support they will provide.

If some people don’t need to be always be there, keep them up to date e.g. status report meetings. Take up little time, and do their influence. Be the protector for your team if need be.

Not everyone is going to be happy.

Make sure they’re in conversations up front, to see why it needs to happen. Will already have had the ‘why are we doing it this way’ conversations. See also Dealing with defensiveness in high conflict people.

If have unknown stakeholders, you might want to delay project until have all the necessary resources are in place.

Project One Pager

This is your project charter. It covers

  • objective – conscise high level thing you want to achieve
  • outcomes – your SMART goals, inumerate things need to be achieved to reach the objective
  • out of scope – include things people will likely ask for
  • team – who and role (not necessarily stakeholders) e.g. developer, handling metadata, user testing
  • schedule – high level milestones, but might leave out and add after approval

Work Breakdown

Your work then needs to be broken down. Need to break into the small tasks. e.g. Goal of teaching cohort -> registration, marketing, book space, etc.

Want to team to come up with tasks, but can help them.

One person might be responsible, but that person can decide how it gets done. Give people a couple of days and come back.

It’s okay where what you’re doing is preparing for the next project.

The majority of the time should be spent planning rather than the work.

Time Estimates

It’s to create the schedule and understand the cost. Frequently realize it’s not worth it.

The only way to estimate time is to do time tracking. Might try Harvest.

Time tracking can be a real eye opener.

Tend to vastly underestimate or overestimate, so best to use buffers.

Choose a realistic buffer. Applying the percentage to the entire project. Usually start with 10-15%: T / (1 – B%)

Use Fibonacci numbers (1, 3, 5, 8 – never higher) to assign numbers, see SCRUM in 10 easy steps article. e.g. Do 16 points of work every week.

Difficulty seems to be not getting developers to track time, but staff people outside of IT to track time. Approach by making workflows more efficient, more realistic. You can play the dumb person and ask how long it takes.

Can ask your vendors whether they have a project plan.

Budgeting

  • estimating time ( in hours)
  • salary/hour
  • benefits (as a percentage of income)

cost = P1(hour * salary/hour) + P2(hours * salary/hour) + …

Important to keep track of meetings when tracking your time.

Use a spreadsheet to calculate cost of total, plus number of hours per week for each team member (and the cost). For example, if can only commit more than 20%, should not be spending 40 hours in a week on the project.

Tracking

What do you track? It depends on who is funding the project.

If grant funded, depends on what is required based on the grant. Sometimes grants don’t cover certain things, or institution needs matching funding.

Internally, contact your supervisor, their supervisor, or contact person in another department.

The key is to keep it transparent.

Reporting Progress

Budget (spreadsheet) only one piece of reporting.

Have a communication plan (see example).

Team standing meetings meant to be very short. All people involved in that portion of the project say 3 things:

  1. what did you do after the last meeting?
  2. what are you planning before the next meeting?
  3. issues preventing from work getting done

Informal, but technical = daily grind.

Status reports in comparison, regular, more formal, but regular

Reporting is absolutely necessary and needs to be clear, consistent, concise. Stakeholders feel like they’re involved in the project even if they’re not really.

Handling Issues that Arise

A lot of people fall back to issue tracking system, is not a project management strategy.

Need to work out workflows around tickets. Are you going to use it for communication, time tracker? Customize system for that use which statuses, attachments, granularity, etc. Internal vs. external notes.

Who is responsible for which types of issues. Have primary and secondary contact.

Also, what is timely matter? Depending on during or outside of business hours.

May need to convince users to submit the information the new way. Talk to them about it not ending up in a black hole. Make sure have confirmation that issue has been added.

Need to also make sure the tickets are in scope. Go back to project charter if need to reference something.

Tracking Systems

Redmine

  • support consortial digital repository
  • open source
  • different user permissions
  • email features
  • good adoption
  • time tracking in 15 minutes increments
  • will make Gantt charts for you
  • lessons learned: don’t overload users with the emails from the issue tracker

Basecamp

  • previously used Trello
  • paid service, web based
  • can have pre-made teams, templates
  • can import whole teams or templates e.g. checklists
  • calendars can be exported and show on public page
  • integrates well with google docs
  • text features to throw notes together
  • has API
  • good for managing resources as well

Trello

  • basically a big whiteboard/sticky note system
  • but very basic

Github

  • track issue and for code, plugged into webserver
  • one repository for each project
  • one meta project to track all projects, including non-code projects
  • can be difficult to search or filter issues
  • everything in one place
  • has email notification
  • can’t assign due dates or track time
  • can assign issues to larger milestones which can have due dates but have had mixed success

JIRA

  • great customization
  • can take a lot of time to customize
  • but will do whatever you want it to do

Different tools work at different organizations. Tools are only as good as the people that are using it. Need to be consistent about using it.

Do whatever you can to make it easier e.g. single sign-on.

Finishing Projects

When is it done? Met the outcome and objectives.

However, it doesn’t mean you can wash your hands of it.

Project Post-Mortem

Learn from your experiences. Take those lessons learned and apply into future projects.

Might be a presentation or report, template, etc.

Why did it go wrong? Some things that are external you cannot control, but internal things you can change.

Once you finish the project, you have a product.

Product Management

While the project is done, you need to continue to maintain it.

Product owner = product manager. Lifecycle function dealing with planning, marketing, maintenance throughout the entire life of the product.

Product manager is the heart, mind and voice of the user. Not your own voice.

Have to make the hard product trade off decisions. e.g. which features to include.

Provide a second opinion on how things work. Create a trust relationship with the development team so you can ask questions.

See also, “How to be a program manager” and “on product management“.

Take Away

The most important thing is communcation.

For the session, also see Erin’s notes for pm4lib, and little_wow’s etherpad notes.

LibTechConf 2014: Agile Project Management and ITIL for Libraries

Presented by Andrew McAlorum

As a whole, libraries do a bad job of managing IT projects and services. Agile and ITIL are two sets of frameworks or methodologies that can help with that. Continue reading “LibTechConf 2014: Agile Project Management and ITIL for Libraries”

Code4LibBC: Shifting Perspectives: From Disability Accommodation to Universal Design

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”

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”

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.

Slides

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

Slides

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

Baby Porcupine

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

Slides

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.

kitty in snow

Getting Staff on Board and Using a CMS: Moving to WordPress

The hardest part of moving any website is getting staff trained and changing their workflow to actually use the CMS. We previously had a static HTML type site, so everyone would email changes to one or two people. It was a big shift to suddenly have people take care of their own content.

As part of the training session, I briefly reviewed why we moved the website to a CMS and more importantly, how it benefits our patrons. It covered the usual, shifting resources and staff time, less maintenance, keeping content current, etc.

Tutorials

I found the best WordPress tutorials for staff were the WordPress.com support articles related to creating content. The only differences come from the plugins that are installed, but in our case, this only affects the “Upload/Insert” section above the editing area.

We also have access to lynda.com video tutorials, so I suggested the relevant sections (5 + 6) of the WordPress Essential Training.

I also wrote up a short blurb on how to check for broken links in a more visual way (and for our non-WordPress pages). I basically referred them to install and use LinkChecker (a Firefox plugin).

Content Guidelines

In addition to training staff on the actual CMS, I wrote two sets of guidelines for them to follow.

  1. General Guidelines on ‘Writing for the Web’
  2. Using WordPress to Make Content Accessible (to come in a future post)

To make it easy for staff to use, I wrote it as a page on the intranet (with anchor links for a short table of contents), and also made a PDF version for them to easily print it off.

Making Staff Responsible

I think the most important step in shifting web content management from a single team to the entire staff is assigning responsibility. If no one “owns” a page, it will not be regularly reviewed. If you assign ownership, at least it increases the chance of that happening. Here are the short blurb I wrote on staff’s responsibility of content:

Page Ownership Responsibilities

While you may delegate the task of creating or updating content on any page you own, you are ultimately responsible for it. This includes:

  • Content is up to date
  • Content, especially audio/visual, conform to Accessibility Guidelines
  • Copyright is cleared for all content (if applicable)
  • Transferring ownership when needed (long term leave, end of term)

Please Note: When links are found to be broken, you will automatically be notified via e-mail. However this is not a full-proof system as many broken links will not be “marked” broken. See the ‘How to Check for Broken Links’ page for more information.

Assigning Ownership

We explicitly mention that editing of pages can be delegated, because we decided that librarians would be responsible for pages. We identified and changed each page’s author to the librarian who would become the owner.

We still have about a dozen pages outstanding in which our team maintains as needed, but we also expect that staff may edit it if they find mistakes.

The Result

So far, it’s been fairly successful (yay!). While I get calls on occasion for help, staff seem to be finding it easier to use than Drupal (which we have for our intranet), and most seem to have no problems using it.

Content on a lot of pages are being updated, though as always, it really depends on the owner. One of the problems is that we migrated the existing pages, and there’s a lot of overlap in information, which we really need to consolidate. So, making the website better as a whole will take a bit more time, but at least content is now being updated on a more regular basis.

Getting Quick Feedback: Updating the Help Page

In the past month or so, it became very evident to many of the librarians that the research help page on our site needed to be revamped. As we’ll be piloting a new “Book a Librarian” service next month, I thought it would be a good time to roll out a new help page as well.

Old Research Help Page

There were so many problems with this page, not least of which was that the page and the sidebar had the exact same links only in a different order.

We had a bit of a tight timeline, since I essentially had 3-4 weeks to make mockups, discuss it with the group, get feedback from staff and students, make the page, and get it live.

Getting Quick Feedback

Part 1: The “Committee”

It wasn’t a formal committee, but it was essentially an ad hoc working group. I presented all three mockups to the group. If the group couldn’t agree on one, then I would have taken two of the mockups to staff and students for feedback. However, since the group felt quite strongly about mockup #3, I decided to go ahead with that mockup to gather feedback.

Part 2: Asking the Students – Survey

I decided to do two versions of the mockup based on the meeting’s discussions. Mockup #4 is exactly the same as mockup #3 except with the chat widget in the middle.

Mockup #4

We taped the mockups on a movable whiteboard and offered candy as incentive. We pulled students aside as they walked past on the main floor and asked them some basic questions on:

  • how easy it is to find what they’re looking for,
  • whether they understood all the terms, and
  • which design they preferred and why.

We had decided on getting however many students we could in an hour. Since it was a quieter day, we ended up with 7 students.

Part 3: Asking the Staff – Open “Silent Forum”

In order for all staff to have a chance to provide feedback, without having to gather them all together, we decided to post the mockups in the staff room with a couple of questions to think about (similar to the student ones). Sticky note pads and a pen were left for staff to write their comments.

The Results

Of the students we asked, more of them preferred #3 with the chat on the side, because they would never use it. On the other hand, the students who preferred #4 thought the right-side chat widget would be ignored or even mistaken as an ad. Other reasons for #4 included:

  • balanced and symmetrical
  • more aesthetically pleasing
  • better division of groupings
  • helps to promote the Ask chat service

Of the staff that provided feedback, they unanimously chose #4 for many of the same reasons that students provided.

Other feedback resulted in my adding:

  • a header for the chat widget,
  • “Hours & privacy policy” link for chat widget,
  • hover behaviour for chat widget,
  • tooltip text for “TRSM”, and
  • changing the wording of “YouTube” to avoid branding.

While we could’ve gotten more feedback, I think we got enough to help improve the page and implicit confirmation that it works.

New Research Help Page

Launch

The page, along with the new “Book a Librarian” service and a revised “Research Help Services” page is set to go live on Oct 1.

We will likely also be changing the “Ask Us” logo in the header to direct to this page as opposed to the “Contact Us” page as it does now. Hopefully, it’ll help to promote our services and resources, and get people to the right place.

WordPress Development: Lessons Learned & Downsides

After 8 months, I have finally finished with WordPress development. I definitely learnt a lot, especially in terms of how the back end works and some more PHP.

Lessons Learned

The most important one:

know more PHP than I did.

Admittedly, I knew very little. While I have some experience programming, I only took a 2 day course in PHP. Not having to look up every little thing would have saved me invaluable time.

The other big one was definitely:

know more WordPress.

The documentation is obviously written for programmers (in most cases, those familiar with WordPress). So once again, I spent a lot of time looking things up. In this case, it was even more difficult because I usually had to rely on a couple of different tutorials and piece things together, making things work through trial and error.

Of course, I didn’t have much choice. And if there is one really good way to learn something is to be thrown into it, and make it happen.

Plugins

WordPress could really use some improvements though. One area is definitely in the plugins area. There is little to no cooperation between plugin authors, so there may be anywhere from zero to fifty plugins that do similar things, but all work differently and are of varying quality.

One of the reasons I’ve been posting a lot of plugins review is not only for my own records, but in the hopes that it’ll save other people time from looking through the mass amount of plugins. Unfortunately, because plugins come and go like the wind, plugin reviews become out of date very quickly.

Search

The one other thing I wish WordPress would improve is their search. While the site search uses Google, the plugin search is pretty bad and so is the internal built-in WordPress search. For the plugin search, you cannot refine your search in any way, and the sorting doesn’t seem to work properly.

The built-in WordPress site search (and dashboard pages/posts search) is also pretty bad. It’s organized by date and there is a plugin that allows you to sort by title, but it does full text searching and does no relevance ranking whatsoever. If it even did the minimum of “do these words match words in the title, if yes, put those higher” then that alone would be a huge improvement.

Conclusion

While I think WordPress is a great platform (and it’s open source!), there is definitely room for improvement and may not be the right platform for everyone. In comparison, for example, I get the impression that Drupal has a more cooperative and supportive community with better plugin support and development. On the other hand, I find WordPress easier to teach users.

If I had to do it again, I would definitely have taken the time to learn more about the overall WordPress framework and how different parts fit into the puzzle before diving into making the theme.