View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Master project-management lecture for several of my LIS courses.
Master project-management lecture for several of my LIS courses.
Project management Dorothea Salo LIS 855
What is a project?• Stupid question? Maybe not.• A project is an endeavor that: • Has a deﬁned 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 deﬁned, limited resources (time, people, materiel). • Has a person or group accountable for the results.• Project management • is a deﬁned 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.
What happens without it?• Projects fail. The end goal or product never happens.• Projects go over schedule or budget constraints.• People are ﬁred. (Though usually not in libraries.)• People lose respect for other people, burn out, leave...• Organizations fail or die.
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-speciﬁc equipment
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.
Scheduling• Make a list of what has to get done. • Don’t order it, or ﬁgure 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.
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.
Gathering information• The MAJOR expense in almost every project is PEOPLE’S TIME. • Time is money! • Formula: (salary + beneﬁts) / 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!
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?
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 ﬁrst 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.
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-beneﬁt analysis
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 difﬁculty • Non-techie librarians do this a LOT.• Using the wrong tech • Don’t get ﬁxated on speciﬁc tools too soon! They may be the wrong tools! CHOOSE SOFTWARE LAST.• Documentation? What documentation? • Of requirements as well as outcomes
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.”
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 conﬂict fast, while it’s still small• Underpromise and overdeliver• Don’t chase the shiny!• Have a process and stick to it
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
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
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 slapﬁghts for resources. • ... have projects fail unnecessarily. • ... apply resources to the loudest or most politically expedient rather than best projects. • ... ﬂail. A lot.
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 ﬁt into mission and strategy?• Start to make conscious, reality-based decisions. •And track them!
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: Conﬂuence• 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!
Meeting management• Librarianship: lots and lots of meetings in a building with books in it. • Okay, I’m being ﬂippant. 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.
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 speciﬁc things. (And if
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 ﬁll FAST. • (Some of you will have trouble with this around your clients. Do your best.)• Virtual meetings can work.• So can Doodle.
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)
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?
Thank you!• Copyright 2012 by Dorothea Salo.• This lecture and slide deck are licensed under a Creative Commons Attribution 3.0 United States License.