Master project-management lecture for several of my LIS courses.

1. Project management
Dorothea Salo
LIS 855

2. What is a project?
• Stupid question? Maybe not.
• A project is an endeavor that:
• Has a defined goal or product, such that when that is
reached or produced, the project ends. (A standing
committee is not a project. “Cataloging” is not a project.)
• Has defined, limited resources (time, people, materiel).
• Has a person or group accountable for the results.
• Project management
• is a defined set of tools and techniques designed to lead
to the desired outcome,
• some of which will be overkill for some projects,
• but which are almost always useful to think about.

3. What happens without it?
• Projects fail. The end goal or product never
happens.
• Projects go over schedule or budget constraints.
• People are fired. (Though usually not in
libraries.)
• People lose respect for other people, burn out,
leave...
• Organizations fail or die.

4. Parts of a project
• Sponsors: who holds the purse strings?
• Stakeholders: who wants the project result?
• Charter: statement of what the project is,
has, and is expected to accomplish
• Leader(s)/project manager(s)
• Schedule/end date (more on this in a bit)
• Resources
• Human: who’s working on the project (often measured in
FTE, but don’t be fooled; often you’ll have parts of several
people, not all of anybody)
• Budget
• Project-specific equipment

5. Project planning
• Goals: charter, schedule, resource allocation
• Project manager has to manage up
• Argue for project’s strategic importance.
• Keep sponsor group and stakeholders from asking for the
moon and stars.
• Avoid unrealistic schedules, resource allocations.
• Don’t kid yourselves: THIS IS HARD.
• Your job as PM, if they’re yanking you around, is to get
people in your corner... or bail.

6. Scheduling
• Make a list of what has to get done.
• Don’t order it, or figure out who’s doing what, or any of
that stuff at this point. Just make a list.
• May have to hold a meeting or talk one-on-one with
people.
• “Critical path analysis”
• Figure out which tasks depend on which other tasks.
(E.g. “I can’t make JPGs from master TIFFs until the
photos have been scanned to TIFFs.”)
• “Critical path:” must-dos, in order.
• Make educated guesses about how long each must-do
will take. Add up those times. That is your MINIMUM
time-to-project-completion.
• Trust me, it’ll take longer than that.

7. The PM’s job
• To sponsors and stakeholders: blame target
• Sorry, but that’s the reality. Thicken your skin.
• To the people working on the project: umbrella
• You handle storms from above.You protect your people from
sponsors and stakeholders.You take their concerns upward.
• To everyone: COMMUNICATOR
• Make sure information is where it needs to be!
• “I didn’t know that!” is your fault.
• You will be the shot messenger. Cope. It’s your job to.
• To the project: coordinator and nudge
• Are things happening as they need to be? Why not? FIX IT.

8. Gathering information
• The MAJOR expense in almost every project
is PEOPLE’S TIME.
• Time is money!
• Formula: (salary + benefits) / 2000 = hourly cost
• How do you make educated guesses about
how long it takes people to do things? You
keep track while they’re doing them!
• This is where formal project-management
tools can help you.
• They can also warn you when the project is going off-
schedule or over budget.
• Your next project will be better-planned!

9. Project post-mortems
• Take time to think. Maybe collectively, maybe
not (depends on politics).
• What went wrong? What didn’t go according
to plan?
• These are not necessarily the same thing! If the plan was
wrong but the project went great, that’s a lesson.
• Blame games are never useful. Workarounds are.
• What’s next?

10. Common pitfalls
(after Mistlebauer 2005)
• “Scope creep”
• You argue your sponsors and stakeholders down to a
reasonable set of outcomes.
• Then they want more. And they’ll tell you they asked for
more in the first place. And they won’t give you any more
resources.
• This is why you have a project charter. And why you make
stakeholders sign off on it. And why you may revisit or
renegotiate it mid-project, if you need to.
• Resist the librarian “good service” tendency.
• Critical path failure
• Your sole programmer has a heart attack. Or a new job.
• Can’t predict or defend. Welcome to crisis management.

11. Common pitfalls
(after Mistlebauer 2005)
• “Big-bang” implementation
• Big change all at once! Folks WILL rebel. BE TRANSPARENT.
• Training? What training? DO NOT DO THIS.
• Too much ambition
• Starting with idea, not with need.
• DO NOT solve problems that nobody has.
• No buy-in from senior management
• This can be hard. Senior management may be risk-averse.
• Depending on people you don’t control
• ... or whose bosses can pull them away from your project
• No cost-benefit analysis

12. Common pitfalls
(after Mistlebauer 2005)
• Death marches: unrealistic delivery dates
• Leads to: less time commitment from people than needed
• Leads to: late and over-budget
• Poor communication
• Underestimating technical difficulty
• Non-techie librarians do this a LOT.
• Using the wrong tech
• Don’t get fixated on specific tools too soon! They may be the
wrong tools! CHOOSE SOFTWARE LAST.
• Documentation? What documentation?
• Of requirements as well as outcomes

13. Common pitfalls
(after Mistlebauer 2005)
• Testing? What testing?
• Leads to: Usability? What usability?
• This is the project that never ends... no, it goes
on and on my friends...
• Over-rigidity: projects sometimes must change
• And sometimes you even need to admit “this isn’t working;
let’s call it off before we waste more time.”

14. Doing it right
(after Mistlebauer 2005)
• Treat stakeholders like customers
• Do requirements and specs IN WRITING
• in print or pixels!
and don’t change anything without stakeholders agreeing
• Pad your estimates (my wording, not hers)
• Check in often
• Watch risks carefully
• Deal with conflict fast, while it’s still small
• Underpromise and overdeliver
• Don’t chase the shiny!
• Have a process and stick to it

15. Known issues with standard
PM methods
• Fantasy budget and schedule estimates
• because nobody’s heeded the people who do the work!
• and standard methods aren’t good at midstream
corrections, assume perfect knowledge at beginning
• Death marches
• the project isn’t a priority UNTIL IT SUDDENLY IS
• or the project is held to the aforementioned fantasies
• Assumes PM can crack whip
• with multi-unit collaborations, this is often not the case
• Clunky, slow, bureaucratic

16. New method: Agile PM
• (you’ll also hear “scrum”)
• Chief difference: instead of planning the
project by assigning it to people, you plan
people’s time by assigning it to projects
• Helps avoid overscheduling, death marches
• Makes priorities explicit
• Other differences:
• quick frequent checkins
• short work “cycles,” after which everybody (stakeholders
included) stops to assess and rethink

17. Portfolio management
• Nobody has just one project going at a time.
You should be so lucky! Ever!
• Organizations with too many projects...
• ... burn people out. (The best people, too.)
• ... engage in unproductive slapfights for resources.
• ... have projects fail unnecessarily.
• ... apply resources to the loudest or most politically
expedient rather than best projects.
• ... flail. A lot.

18. How to do it
(after Vinopal 2011)
• Inventory themetadata! Who, what,projects. much.
organization’s
• With project when, how
• Assign responsibility for managing project
portfolios.
• Realistically? In libraries, this means management does it.
• Assess the organization portfolio. of problems?
the existing
•Does have patterns
• What projects succeed and fail? Any patternsis, by the way.)
pattern may not be what you initially think it
there? (The
• Where do projects fit into mission and strategy?
• Start to make conscious, reality-based decisions.
•And track them!

19. PM tools
• Legion! Mostly traditional rather than scrum.
• Communication tools as well as planning tools
• Open source: dotproject
• Online: Basecamp, plugins to Evernote, etc.
• Expensive/proprietary: Confluence
• The trick, as always, is adoption.
• You don’t NEED a tool to PM well, for projects
under a certain size/complexity. But a tool
might help you. Experiment!

20. Meeting management
• Librarianship: lots and lots of meetings in a
building with books in it.
• Okay, I’m being flippant. But it feels like this some days!
• Calculate the $-cost of a meeting sometime.
• The answer will scare you. IT SHOULD.
• Only hold a meeting when there’s no other way to get the
work done. Standing meetings should be avoided, especially
when the only agenda item is progress reporting. Progress
reporting is what email is for!
• Only include the people who need to be there in order to get
the work done.
• Sounds like common sense; isn’t.

21. Planning a meeting
• Figure outto get workorof the meeting. Who needs to
the
• be there to get this work done?
What has done decided in this meeting?
• Writemeeting outcomes, in order of schedule, starting each with a
an agenda. (Latin: “things to be done”)
• verb like “decide” or “produce.”
List
• “Discuss”NEVER USE IT.
meeting.
is NOT AN OUTCOME, and it is DEATH to a good
• Addlist. action items” or “Decide next steps” to the end of
the
“Assign
• Carveexactly to this, but it’s a good advancethe items. (You won’t
stick
up the allotted meeting time among
organizer for
people, and it helps shut up blowhards.)
• Email agenda nopeoplethan 24 hours in advance. you
less
• do, list those things in the email!)
More if you want to prepare specific things. (And if

22. Meeting scheduling
• People are busy. Respect that.
• This is part of the reason to keep meetings small!
• Mantra: their world is larger than you.
• Schedule as far in advance as possible.
• Calendars fill FAST.
• (Some of you will have trouble with this around your
clients. Do your best.)
• Virtual meetings can work.
• So can Doodle.

23. Running a meeting
• Two major roles: facilitator (probably you)
and notetaker (NEVER the same person as
facilitator)
• Facilitator goals: keep on schedule and get the
work done, avoiding bloodshed.
• Tricky political maneuvering involved.
• Whole books on the “avoiding bloodshed” bit!
• Notetaker goals: record important insights,
decisions made, action items (and who is
responsible for them)

24. After the meeting
• Notetaker pretties up and emails notes
• Possibly web-based storage for these
• Facilitator does post-mortem
• Did the work get done? If not, why not?
• Was there bloodshed? Why?
• Did we miss something? How do we catch up?
• Where does this leave the project?

25. Thank you!
• Copyright 2012 by Dorothea Salo.
• This lecture and slide deck are licensed under
a Creative Commons Attribution 3.0 United
States License.