Project Management... not as dull as you may think

I'll be honest, some of this week's reading was not the most exciting, curl up by the fire stuff I've ever delved into. But it was probably some of the most important readings I've had to date. (Sometimes I think I say that each week.) Out of the stiffer material, I had to laugh at H Frank Cervone's article on How not to run a digital library project especially his observation that the thought of project management causes librarians eyes (and just about everyone else's) to glaze over. His humor and down-to-earth language get the point across without being overly academic.

I get that same simultaneous understanding and panicked look from people now when I start preaching the virtues of project management and risk management. Arguing the case to make sure we get the equipment we actually need, are able to use, and have the capacity to maintain instead of just spending money because "If we don't it goes away" is not the most pleasant of experiences but I'm now convinced you have to take that perspective for any project to be effective and efficient. Keeping a goal and end date in mind is great advice that gets left out a lot. The comforting thought here is that we are obviously not alone. Scope creep, incorrect budget projections, lack of buy-in and wild guesses seem to be the norm. I've seen this not only within my department but at the University level as well.

I can't recommend Cervone's writings enough. Do a check in the Wilson or Ebscohost databases for "library project management" and his articles dominate your search results. Much of them are included in our IRLS 672 readings this week. That's because he knows what he is talking about.

Large technology projects at universities have very high stakes and a good project manager who has successfully coordinated the complex iterations of a project can save thousands if not millions of dollars, thousands of hours of work and the sanity of the people working on it. Also, knowing when to pull the plug on escalation or when a project simply won't work as intended is critical to preventing ultimate failure and undo waste. Mark Keil's article Pulling the Plug: Software Project Management and the Problem of Project Escalation graphically lays out the factors that contribute to scope creep and overgrowth of projects to the point that they suffocate themselves. How many projects are implemented, even though no real plan or analysis was thought out, only to end in failure after half a million dollars and years of work have been needlessly thrown away?

I'll have to go over the project management articles again to get more out of them. It was a lot to take in within a week but the overall concepts of organization, preplanning, dynamic groups, being user centric and honest about your success and failures have already sunk in.

Reviewing IRLS672

When I started this course I felt pretty knowledgeable about the in's and out's of Digital Repositories. I realized I didn't know much about the back end of things but really didn't think to much about it, since our developers generally handle that stuff.

I think quite differently now. The back end "is" the repository and how you set up your system's architecture is crucial to the maintenance, delivery, and organization of the data you are trying to present. The most helpful aspect has been looking at what you are building and determining, in advance, what you plan to do with it and how you will get there.

Pre-planning with functional requirements, data modeling, and just having concrete goals are paramount and I have already been integrating those aspects in what I am doing right now.

I also have a much greater understanding (not complete of course) and respect for the programmers, developers, and system administrators I work with everyday. A digital repository isn't just about a clean interface and fancy widgets but robust relations between objects and efficient ways of getting to them.

I can have conversations and attend meetings where topics like our database infrastructure (Fedora, MySQL, PHP, etc.) don't make my eyes glaze over.

I also realize I have much more to learn and must always be educating myself on the technologies and examining the functional goals of collections and interfaces we propose. This is something that will be a constant in any digital enterprise I participate in.