Think Like a Project Manager

Editor's Notes

• #3: I’m a project manager, as are many of you, whether you know it or not, so let’s talk about managing projects. Why are projects important? Projects help us get things done. Projects keep us relevant, moving forward. Projects evolve into sustained processes. All of our ongoing services began as a project.
• #4: Project Management Principles – What is a project? For the purposes of today’s talk: Temporary - Specific Beginning and Ending Dates Unique – Not a routine Operation Goal Oriented – designed to create a specific service, product or result Collaborative – Not something you do all by yourself Defined Scope and Resources Must be On Time, On Budget, Fulfilling defined requirements Project: Special Events, Construction or Renovation, Marketing campaigns, software implementation, NOT a Project: Ongoing collection maintenance, running regular programs, most reference desk activities
• #5: The Project Manager leads the project from inception through execution and implementation. Must manage resources, risks, and communication to successfully achieve project goals and objectives. May or may not be doing the work him/herself – but is always accountable for making sure the project is completed on time, within the budget, and to project specifications.
• #6: PM issues in libraries – Despite the large number of projects we do, Libraries are rarely project focused. Few library professionals are trained in making projects successful. Keeping all of the wheels in motion and synced up is a specialized skill set. Few libraries are organized in a project-centered way. Libraries focus on the CS end of things and relegate projects to secondary – without realizing that project outcomes directly impact CS and organizational goals. Projects are often only supported if they don’t interfere with the desk schedule or the materials budget. Few of us even understand what’s going on when we undertake a project, which opens us up to all kinds of risk. This makes us slower, less cost-effective, reduces efficiency, and helps foster a culture where change is HARD. There are 10 basic things we in the library world can do to shift our way of thinking to be more project oriented.
• #7: Functional managers are usually put in charge of projects by default, regardless of PM skills. But is this always the best way? Does it always have to be the department head? Or someone in the department at all? Project Manager – Ability, Authority, Accountability Ability - Get the right person – not necessarily the functional manager. This is a specific skill set Authority - Give this person the authority needed to get the job done. A big problem for libraries, which are usually organized functionally Mgmt should give official authority and allot a % of staff time under this person’s supervision Mgmt should give separate $ to this person for a budget Encourage a good relationship with functional managers Accountability - Who are they accountable to? What are they accountable for? Who is accountable to them? Define these things before the project starts Require project updates – helps with authority, too. Create an accountability matrix around them (RACI) to define roles clearly
• #8: A good tool for establishing the PM’s role in relation to other stakeholders An important tool for developing your Communication plan: RACI matrix. Defining stakeholders and establishing their roles from the BEGINNING in a way that can be communicated clearly **** Grid: Stakeholders/Activities – each one assigned a role. Responsible – Who is responsible for the execution of the task? Who’s doing the work? Accountable – Who is accountable for the tasks and signs off the work? Who’s ass is on the line if this work isn’t done? Consulted – Who are the subject matter experts who to be consulted? Who gets a say in this aspect of the work? Informed – Who are the people who need to be updated of the progress? Who just gets told about it? Helps establish a project within the organization – accountability, authority, expectations In libraries, it is essential that the expectation from the outset of the project is that NOT EVERYONE GETS A “C”
• #9: PMI defines projects in terms of Process Groups: Initiate, Plan, Execute/Monitor & Control, Closing Planning - Most important process group This is an all too often ignored or slighted element in library projects. Libraries that skip right into the “doing” rather than spending enough time planning set themselves up for failure. This doesn’t just mean talking about it. Make real plans! Formalize things a bit! Cover all areas! Risk, QA, Procurements, Communication Have a plan for your plan and contingencies for your contingencies
• #10: Once the Plan is in place THEN you can do. Too many library projects get derailed because people just jump right into the work. You need to clearly define the WHAT before you can figure out the HOW. You need to know where you’re going before you can figure out how to get there. Make a formal, detailed plan for every aspect or the project. Communicate. Follow the plan.
• #11: Once a plan is initiated and a PM assigned, get to the work of Planning, beginning with some really boring stuff. Ask: WHY ARE WE DOING THIS? THE PLANNING HIERARCHY - create documents that formally define these things! Format doesn’t matter as much as being able to come back and refer to this over the course of the project. Objectives - Must be clearly defined at the outset the foundation of the project. What are the outcomes we ultimately need to come out of this project? Goals – SMART and must serve the objectives – measurable goals that can actually be met to further the objective Requirements – fundamental to defining project success, product acceptance Activities – What must be done to meet requirements, reach goals, and address objectives – specifics!! Project Scope – The Requirements and activities tell you what’s involved in getting this project done
• #12: Focus on your scope. Do not invest any project resources into anything that is not on the list. Libraries often fall into the trap of so desperately wanting to “go above and beyond: This is excellent for Customer Service, but Deadly to Project Management In PM, once the scope is defined, you do no more, no less. The PM is there to make sure that’s the case. Because if you start adding in things to make the project even better (above and beyond!)… THE DREADED SCOPE CREEP
• #13: NO SCOPE CREEP DO NO MORE, NO LESS THAN DEFINED IN THE SCOPE (which you have formally documented and has been approved by the sponsor, so it can’t be messed with) Do not invest project resources in anything whatsoever that’s not on the list. Not to say, the list can’t change, but changes should be added formally, using the same process to ensure that they are actually necessary to the success of the project. Beware of the phrase “While we’re at it…” – Directors and supervisors are THE WORST at this Keep a list of extras that don’t make the cut. Those can form the basis of another project.
• #14: More yelling. Let’s call it Tough Love. The two most important parts of the planning process, IMO – Scope Definition and Communication planning. Even if I’m working on a teeny tiny little project, I never skip or skimp on these. Your project will live and die based on how well you have defined the scope and how well you communicate. YOU MUST develop a formal Communication Plan. This will help with: Expectations management Stakeholder “buy-in” Project execution Documentation Project plan changes Project execution reporting Lessons Learned
• #15: YOU MUST develop a formal Communication Plan. This will help with: Expectations management Stakeholder “buy-in” Project execution Documentation Project plan changes Project execution reporting Lessons Learned Positive communication, leading by example Promote your team = promote your project
• #16: Communication within a group is complicated. Communication Paths PM is responsible for making sure that these paths are accounted for and the communication is happening! It’s your job as the PM to be a Communication Facilitator Keep all Stakeholders involved through all parts of the process. Planning is essential for this! If you don’t have a strong communication plan to start form, this all falls apart pretty quickly. And so does your project.
• #17: What else do we need to be sure to include in the planning process? Resources – What do you have at your disposal to make the activities happen, and thus realize the objectives? This comes AFTER you’ve planned the objectives, goals, etc and set the scope. This is the part libraries often skip straight into, and often underplan anyway. We like to get to the “doing” part, but this introduces risk to the process and can seriously undercut the likelihood of meeting your objectives. So it’s critical to carefully plan and document the resources you’ll need for the project. What resources are we talking about? Primarily TIME, BUDGET, STAFF (physical resources, too, but I usually lump that in with budget)
• #18: Who do you have on your team, and what skill sets and availability do they bring? What are the firm deadlines? How flexible can your timeline be? What about the money? Will it cover the requirements? What needs to be adjusted due to constraints of any of there?
• #19: The ideal situation - Objectives should drive resources. How PMs are taught – determine scope, and then assess what resources you need to do everything there. If you don’t have the staff, time, money, either reassess the objectives or find more resources. Don’t let anyone tell you it’s never this way!! I’ve had many times when this is the case. If the project has enough value for the organization, there are usually ways to scare up the right resources to accomplish the project goals. If the resources aren’t there, project objective need to be sacrificed to one degree or another.
• #20: Reality – often how the project is presented is in a way where the objectives are effectively determined by the resource constraints Libraries often start with this. “We have $10,000 to build a new Web site”. When put this way, the objectives are automatically constrained from the beginning When you say, “We have 3 children’s librarians who can do storytimes at the beach this summer” Instead of, “We have set a goal of 5 beach storytimes a week - how many children’s librarians do we need to support that”? You’ve already put a cap on your goals. In these cases, present the best possible Outcomes based on the constraints…. But also suggest ways that stretching the constraints may result in a significantly better ROI. “If we were to push the deadline back three more weeks, we could meet these additional objectives as well…” This is toughest when accompanied by goals from the outset. For example: “We have $10,000 to spend on buying and implementing software that will do XYZ…” I’d suggest that when presented with an initial resource constraint: Create a project plan based on that constraint AND a plan based on objectives and have an honest talk with your sponsor. If it matches up, GREAT!! If not, you should not be afraid to suggest that the organization (to really do it RIGHT) may need to spend more, supplement staffing, extend the timeline, etc. Or reassess your objectives
• #21: Tools to figure this all out – Methods, Documentation templates and PM Software Techy Project Planning tools (see my other presentation) MS Project, Smartsheet, other PM planning tools Asana, Trello other task management tools Communication Tools – Slack, email File Sharing tools, Dropbox, Sharepoint, etc Collaboration Tools – G docs, etc PM Templates (planning, documentation)
• #22: Activity Register – Define Activities in line with scope WBS – Sequence the activities to create dependencies Schedule – Assign durations and dates Gantt Chart – Chart it all out with resource allocations See pmi.org
• #23: Risk Management Planning – DO NOT SKIP THIS Begins in Planning Process “What could possibly go wrong” List those things! Predictable risks: prepare for them Be ready with the fire extinguisher Unpredictable risks: Give leeway for this. (Ex: schedule management – never schedule resources for 100%. I use a 40%/90% guideline)
• #24: Risk Management Cycle Begins in the planning process and continues to churn through the other project phases. Formalize your plan for playing this out and dealing with problems = NO PANIC
• #25: Documentation is key. Tedious, sometimes seems unnecessary or secondary to actually getting things done. BUT documentation can seriously help avoid rework, provide a foundation for training or project changes, and makes closing procedures much, much easier. Leaves a record of what was done – great fro future troubleshooting and for developing new projects.
• #26: Take time to close out your projects right – huge benefit to future projects Formally accept project requirements ALSO Document “Lessons Learned” with your team Debrief and Discuss what you’ve learned, what didn’t go so well, what was great, and what you’d do better in the future. Write this all down in a list of “Lessons Learned” that will be distributed later. Refer to this list when planning other projects
• #27: Look into Project Management as a field of expertise to draw from. PMBOK from pmi.org Focus on Planning to begin thinking more like a Project Manager and lead to more project success. Efficiency Reduced Risk Adaptability Foundation for future SUCCESS!!