Presenter: Ernie Nielson, BYU
UO attendees: Sara Brownmiller, Shirien Chappell, Kirstin Hierholzer, Jon Jablonski, Barbara Jenkins, Cara List, Erin O'Meara, Blake Scott, Laine Stambaugh, Laura Willey, Dean WaltonThese are informal notes taken by SChappell.
Staff comments about the workshop
How we're using what we learned:
- Video Storage Project (November, 2007)
- another one
What is a project? It's work that has a definite beginning and end, and it has specific deliverables and a budget. It might morph into becoming "non-project work" for somebody if the program or process becomes a permanent new service, but as a project it begins, it gets planned, it gets built or installed or implemented, and it ends. Overview:
What makes projects fail?
- Communication issues: maybe it's set up so that all communications have to go through one person and there's a bottleneck, or maybe several different parts of the project are side-barring and nobody knows what they're saying, or maybe nobody knows who they're supposed to be telling their stuff to. Maybe communications aren't going to the right people at the right time in a way that can be understood.
- Priorities are not set: too much work in an organization and nobody's said which is most important to do by when.
- Role definition is poor: folks don't know who's in charge of what, or maybe one person is in charge of everything and it's just too much, or maybe several people seem to be in charge of the same thing.
- Unclear objectives: people don't know exactly what is expected of them, what they're supposed to be doing, when they're supposed to be doing it, or even if they're involved at all.
A successful project planning process:
- is step-by-step by nature. You have a clear path to follow, step by clearly-defined step.
- is iterative. At any time in the step-by-step process if something changes (resources, scope, or schedule of the project) you can go backwards to the appropriate step in that process and adjust for the change, then start moving forward again. And you can do this again and again, as you find out more information or as things change. You don't have to be a victim: if sponsors/customers change the project on you, you have a process for going back and adjusting the variables and then continuing on.
- is self-correcting: it corrects itself because of that iterative nature.
- is scaleable. One size fits all. You can use a good planning process for a large project or for a tiny one.
In the absence of a good process we debilitate good people.
Multiple projects make a program. Several programs make a portfolio. Portfolio Management is maintaining several projects at the same time. The Portfolio manager has several project managers reporting to her. Portfolio management includes getting the right people on the right projects at the right time -- knowing that some projects mature at different times (which may free or constrain various people's schedules) and picking the right projects. The Portfolio manager needs to know what resources are available (people and tools) and then needs to tell the organization what non-project work should be left behind so that the project work can take priority.Before starting a project it's a good idea to inventory current projects. Find out if folks are doing what they think are projects when they're really non-project work, and vice versa.
A little something about a project manager:
- You don't have to agree with or like the project: you just have to make it successful.
- You're responsible for creating an environment that is predictable, consistent, and reliable, and as stress-free as possible for the members of the team and the people who report to them.
1.0: Establish Project Context:
1.1: Review the Project Information:
- 1.1.1 Review project documentation before starting a project.
- 1.1.2 Project Manager validates her understanding with the project's Sponsor. (The Sponsor is the person high enough in the organization to cut through red-tape and get things done for the project manager. She often is the person who assigns the project and has the last say over scope, resources, and schedule.)
1.2 Establish the Planning Structure:
- 1.2.1: Create the planning team.
- 1.2.2: Figure out how the project will be governed.
- Set up rules of conduct.
- Figure out your organization's metrics.
- Talk about amount of rigor to be used in various parts of the project.
- Use the constraint matrix to figure out what part of the project "gives" if there are not enough resources or time to do it all.
- Figure out whether there are inherited policies and procedures the team is expected to use.
- Find out what tools will be available to the team (Gannt charts, etc.) and whether anybody knows how to use them.
2.0: Plan the Project
2.1: Define the Project Scope:
- 2.1.1: Write a clear, concise, and complete Project Objective Statement. It has 25 or fewer words and is clear (no ambiguity, no jargon), concise, and complete.
- 2.1.2: Figure out the Management and Planning Approach.
- 2.1.3: Validate Scope and Approach with Sponsor.
- 2.1.4: Create the Work Breakdown Structure.
2.2: Create the Preliminary Resource Schedule:
- 2.2.1: Create Preliminary Project Schedule.
2.3: Complete the Plan:
- 2.3.1: Reconcile Plan and Program Objectives.
- 2.3.2: Verify that you have support from the sponsor for the proposed changes.
- 2.3.3: Create the Risk Management Plan.
- 2.3.4: Confirm that you have support from the sponsor for the Risk Management Plan.
- 2.3.5: Finalize the Plan.
3.0: Execute the Project:
3.1: Manage the Project.
3.2.1: Close-Out the Project:
- 3.2.1: Transfer stewardship.
- 3.2.2: Close the Project.
- 3.2.3: Confirm with Sponsor that the project is done.