Lynda.com Project Management Fundamentals: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(20 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== | ==Overview== | ||
<blockquote>"Author Bonnie Biafore lays out a set of principles for efficiently managing projects. The course examines the concepts of project management, from defining the problem, establishing project objectives, and building a project plan to meeting deadlines, managing team resources, and closing the project. The course also provides tips for reporting on project performance, keeping a project on track, and gaining customer acceptance."</blockquote> | |||
::- [http://www.lynda.com/Business-Project-Management-tutorials/Project-Management-Fundamentals/80780-2.html?srchtrk=index%3A1%0Alinktypeid%3A2%0Aq%3Aproject%20management%0Apage%3A1%0As%3Arelevance%0Asa%3Atrue%0Aproducttypeid%3A2 Lynda.com] | |||
===Initiating=== | ===Initiating=== | ||
---- | |||
====Problem Statement==== | ====Problem Statement==== | ||
:*''Problem Statement'' documents help define the problem or opportunity. | |||
:*Projects are started to solve a problem or take advantage of an opportunity. | |||
:*Keep the problem definition simple. | |||
:*Do not start talking about solutions until the problem is clearly defined. | |||
:*Ask ''why'' until the problem is clearly defined. | |||
====Project Goal==== | ====Project Goal==== | ||
:*''Project Goals'' are high-level targets that state the end result of the project. | |||
:*Easy to understand. | |||
:*Create ''objectives'' that define the goal. Objectives should be: | |||
::*Specific | |||
::*Measurable | |||
::*Realistic | |||
::*Time-Related | |||
====Strategy==== | ====Strategy==== | ||
:*There is often more than one strategy for achieving a specific goal. | |||
:*Brainstorm possible strategies with a team based on the problem statement, goal, and objectives. | |||
:*Evaluate the brainstorming ideas using a ''Strategy Matrix''. | |||
:*Ask: Is this strategy feasible? | |||
:*Ask: Are the risks of this strategy acceptable? | |||
:*Ask: Does this strategy fit the culture of the organization? | |||
====Requirements==== | |||
:*''Requirements'' provide the details of what the outcomes must look like. | |||
:*Don't include requirements that aren't necessary. | |||
:*Make sure you have all the necessary requirements. | |||
:*Techniques for gathering requirements: | |||
::*Reuse existing requirements - if this project is like a past one. | |||
::*Build a prototype - test the idea and evaluate it. | |||
::*Hold requirements meetings. (marcin) | |||
::*Observe end-users interacting with the product. | |||
::*Conduct interviews. | |||
:*With your goal in mind, document your requirements by writing detailed statements of what must be accomplished by the project to satisfy the objectives. | |||
====Deliverables==== | |||
:*''Deliverables'' are the products or services that are delivered. | |||
:*Can be tangible (products) or more abstract (services). | |||
:*They help you measure progress. | |||
:*Process: | |||
::*Start by defining end deliverables. | |||
::*Next, define intermediate deliverables. | |||
::*Next, define success criteria so you know your progress is on track. | |||
:*Deliverables should be able to be completed in between status reports. | |||
:*How do you know the deliverables you receive are what you need? | |||
:*''Success criteria'' help you determine that your deliverables are what you need. | |||
::*Success criteria should be clear and quantifiable. | |||
====Assumptions==== | |||
:*''Assumptions'' are things that are believed to be true but are not confirmed. | |||
:*Get assumptions out in the open to make sure everyone is on the same page. | |||
:*Ask questions about what people expect, what they envision when they think about the project, don't be afraid to ask multiple times to make sure the story doesn't change. | |||
:*Ask people to describe project success. | |||
====Risks==== | |||
:*''Risks'' are situations or events that might negatively affect your project. | |||
:*Identify risks early in a project so the management team can make a decision to move forward with a project. | |||
:*Document risks at the start of the project. | |||
====Scope Statement==== | |||
:*''Scope Statements'' define the boundaries of what is included and what isn't included in the project. | |||
:*Can also include an out of scope statement that clarifies assumptions about what is outside the boundaries of what the project is. | |||
:*''Change management processes'' control the small requests that come into a project. | |||
:*Sometimes team members expand the scope without management knowing it. When assembling the team, make sure they understand the scope statement. | |||
====Stakeholders==== | |||
:*''Stakeholders'' are people who have a stake in the outcome of a project. | |||
:*Major ''stakeholder roles'': | |||
::*Project Customer | |||
::*Project Sponsors | |||
::*Functional Managers | |||
::*Team Members | |||
:*How do you work effectively with your stakeholders? | |||
::*Make a ''stakeholder analysis'': | |||
:::*Identify what motivates your stakeholders? | |||
:::*Identify who your stakeholders listen to. | |||
:::*Identify the objectives that the stakeholders care about and their priorities. | |||
:::*Document the stakeholder's contribution to the project. | |||
:*Stakeholders are crucial to the success of your project. | |||
====Approval==== | |||
:*Get approval from project stakeholders. | |||
:*Do not mail or email the project summary to your stakeholders and have them sign on the dotted line. They might not read the packet and fully committ. | |||
:*A face to face sign-off meeting is more effective. | |||
::*Review the project summary to make sure the project stakeholders agree with it. | |||
::*Obtain signatures. | |||
::*It’s important that the stakeholders understand what the project is about and buy into it. | |||
- | |||
====Project Charter==== | |||
:*''Project Charters'' are formal announcements of the initiation of the project and the delegation of authority to the ''Project Manager''. | |||
::*Includes: | |||
:::*Name of the Project | |||
:::*Purpose | |||
:::*Name of the Project Manager | |||
:::*Responsibilities | |||
:::*Authority specifics | |||
:::*A formal declaration of authority by the project sponsor. | |||
::*When the project is ready to go, the project sponsor distributes the project charter to the team members. | |||
Latest revision as of 05:57, 19 February 2012
Overview
"Author Bonnie Biafore lays out a set of principles for efficiently managing projects. The course examines the concepts of project management, from defining the problem, establishing project objectives, and building a project plan to meeting deadlines, managing team resources, and closing the project. The course also provides tips for reporting on project performance, keeping a project on track, and gaining customer acceptance."
Initiating
Problem Statement
- Problem Statement documents help define the problem or opportunity.
- Projects are started to solve a problem or take advantage of an opportunity.
- Keep the problem definition simple.
- Do not start talking about solutions until the problem is clearly defined.
- Ask why until the problem is clearly defined.
Project Goal
- Project Goals are high-level targets that state the end result of the project.
- Easy to understand.
- Create objectives that define the goal. Objectives should be:
- Specific
- Measurable
- Realistic
- Time-Related
Strategy
- There is often more than one strategy for achieving a specific goal.
- Brainstorm possible strategies with a team based on the problem statement, goal, and objectives.
- Evaluate the brainstorming ideas using a Strategy Matrix.
- Ask: Is this strategy feasible?
- Ask: Are the risks of this strategy acceptable?
- Ask: Does this strategy fit the culture of the organization?
Requirements
- Requirements provide the details of what the outcomes must look like.
- Don't include requirements that aren't necessary.
- Make sure you have all the necessary requirements.
- Techniques for gathering requirements:
- Reuse existing requirements - if this project is like a past one.
- Build a prototype - test the idea and evaluate it.
- Hold requirements meetings. (marcin)
- Observe end-users interacting with the product.
- Conduct interviews.
- With your goal in mind, document your requirements by writing detailed statements of what must be accomplished by the project to satisfy the objectives.
Deliverables
- Deliverables are the products or services that are delivered.
- Can be tangible (products) or more abstract (services).
- They help you measure progress.
- Process:
- Start by defining end deliverables.
- Next, define intermediate deliverables.
- Next, define success criteria so you know your progress is on track.
- Deliverables should be able to be completed in between status reports.
- How do you know the deliverables you receive are what you need?
- Success criteria help you determine that your deliverables are what you need.
- Success criteria should be clear and quantifiable.
Assumptions
- Assumptions are things that are believed to be true but are not confirmed.
- Get assumptions out in the open to make sure everyone is on the same page.
- Ask questions about what people expect, what they envision when they think about the project, don't be afraid to ask multiple times to make sure the story doesn't change.
- Ask people to describe project success.
Risks
- Risks are situations or events that might negatively affect your project.
- Identify risks early in a project so the management team can make a decision to move forward with a project.
- Document risks at the start of the project.
Scope Statement
- Scope Statements define the boundaries of what is included and what isn't included in the project.
- Can also include an out of scope statement that clarifies assumptions about what is outside the boundaries of what the project is.
- Change management processes control the small requests that come into a project.
- Sometimes team members expand the scope without management knowing it. When assembling the team, make sure they understand the scope statement.
Stakeholders
- Stakeholders are people who have a stake in the outcome of a project.
- Major stakeholder roles:
- Project Customer
- Project Sponsors
- Functional Managers
- Team Members
- How do you work effectively with your stakeholders?
- Make a stakeholder analysis:
- Identify what motivates your stakeholders?
- Identify who your stakeholders listen to.
- Identify the objectives that the stakeholders care about and their priorities.
- Document the stakeholder's contribution to the project.
- Stakeholders are crucial to the success of your project.
Approval
- Get approval from project stakeholders.
- Do not mail or email the project summary to your stakeholders and have them sign on the dotted line. They might not read the packet and fully committ.
- A face to face sign-off meeting is more effective.
- Review the project summary to make sure the project stakeholders agree with it.
- Obtain signatures.
- It’s important that the stakeholders understand what the project is about and buy into it.
Project Charter
- Project Charters are formal announcements of the initiation of the project and the delegation of authority to the Project Manager.
- Includes:
- Name of the Project
- Purpose
- Name of the Project Manager
- Responsibilities
- Authority specifics
- A formal declaration of authority by the project sponsor.
- When the project is ready to go, the project sponsor distributes the project charter to the team members.