DC2009:PM Principles - Introduction to Project Management

From Managing Nonprofit Technology Projects Wiki
Revision as of 17:35, 13 January 2016 by Miriam (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


This session is targeted at those newest to nonprofit technology project management. After some initial framing and overview, this will be a question-driven session, providing answers that will enable participants to decide what other sessions will best serve their needs.

Session Notes

Project Management

Lead by Adam

  • Intro by going around the room about what we would like to know about PM

* Getting people to use the same tool * How to see around the curve to head off potential pitfalls & create solutions before things happen - to have foresight * Basic 101 skills + "managing up" * Tips, tricks, & tools for accidental project managers - how to hold vendors accountable to budgets & deadlines * Accidental PM * How to empower PMs on non-profit to buy-in to technology projects they are using (bc they require babysitting) * Basics 101 + identifying necessary components * Needs help in making vendors accountable - build better relationships & manage risk

  • Roles & responsibility definition, vocabulary, basic components in place to start a project -
  • Adam is an informal project manager (had managed tech project for 12 years)

* Being able to anticipate things before they happen * Being in touch w vendors, people in project management - risk management

  • Establish an PM framework to set goals is important (to hold vendors accountable)
  • Make list of lesson-learned to work w next vendor
  • Sussing out the source of the problem
  • What are the roles & expectations of the project? (eventually to hold the vendor accountable)
  • Matrix - managing across lines - role definition is important (& get it in writing!)_
  • What are you trying to accomplish with the project?
  • Make regular defined check-ins to keep tabs on the project
  • Which should come first - role(s) definition &/or definition of scope?
  • What is the communication framework? (ex: wki, daily/weekly emails, etc.)
  • Different rhythms for different stakeholders (frequency & depth)
  • Who are the different kinds of stakeholders?
  • Transparency via communication protocol
  • Three pillars of PM - project mgr. keeps these in balance

* Time * Scope - What are you expecting to accomplish? Is the business problem solved? How is success defined? * Budget

  • Reactive vs. pro-active management - scaling back the scope
  • Managing expectations to avoid scope creep
  • Scope shrink - does this "cut" defeat the overall purpose? (ex: "It works, but no one uses it.")
  • Vendor relationship must be mutually beneficial - vendor must be full partner
  • Business analyst is also known Project Manager
  • PM keeps things in scope & sometimes defines the project as well

* Who can help determine the scope?

  • Anticipating risk

* What can go wrong? * If things are late, what happens? (Critical Path in Gantt Chart speak) <---- point of failure, PM needs to pay special attention to this point * Put possible areas of delay at beginning of project (ex: making sure licenses are purchased, software installed, business process/workflow, decision-making [What are the requirements? Where is the end of the scope?]) * What are the potential areas of failure? Where do things break down? * What are the critical success factors? Are the right people in the team? Are there any big events for the org coming up? How is the project being received? Is there pushback? What is the org barometer to the project? How are barriers overcome? Vacations/time away from staff & vendors? * Build buffers * Is the content ready? (to the staff) * Are all the pieces in the right place? What does the PM need before starting? * Definition of parts & pieces (early one) provides a framework to refer back to

  • Case study [Keith took notes on this part]

* Staff member is responsible for all things IT, is not part of the conversations that involve her projects, still seen as "newb" * Tradeoffs with the give & take * Building consensus around shared vision & goals (ex: How our website should look - ask the stakeholders?) * Work on the repercussions - give them the work case to "guide" decision-making * Asking questions - to develop a common understand - What do you need? How I can help you get to that point? Pick your battles. * Ask the manager what they need from you?

  • Transparency, roles & responsibilities, defining goals/problem/outcomes (critical success factors)