Lynda.com Project Management Fundamentals: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
No edit summary
Line 4: Line 4:


====Problem Statement====
====Problem Statement====
:*''Problem Statement'' documents help define the problem or opportunity.
:''Problem Statement'' documents help define the problem or opportunity.
:*Projects are started to solve a problem or take advantage of an opportunity.
:Projects are started to solve a problem or take advantage of an opportunity.
:*Keep the problem definition simple.
:Keep the problem definition simple.
:*Do not start talking about solutions until the problem is clearly defined.
:Do not start talking about solutions until the problem is clearly defined.
:*Ask ''why'' 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.
:''Project Goals'' are high-level targets that state the end result of the project.
:*Easy to understand.
:Easy to understand.
:*Create ''objectives'' that define the goal. Objectives should be:
:Create ''objectives'' that define the goal. Objectives should be:
::*Specific
::*Specific
::*Measurable
::*Measurable
Line 20: Line 20:


====Strategy====
====Strategy====
:*There is often more than one strategy for achieving a specific goal.
: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.
:Brainstorm possible strategies with a team based on the problem statement, goal, and objectives.
:*Evaluate the brainstorming ideas using a ''Strategy Matrix''.
:Evaluate the brainstorming ideas using a ''Strategy Matrix''.
:*Ask: Is this strategy feasible?
:Ask: Is this strategy feasible?
:*Ask: Are the risks of this strategy acceptable?
:Ask: Are the risks of this strategy acceptable?
:*Ask: Does this strategy fit the culture of the organization?
:Ask: Does this strategy fit the culture of the organization?


====Requirements====
====Requirements====
:*''Requirements'' provide the details of what the outcomes must look like.
:''Requirements'' provide the details of what the outcomes must look like.
:*Don't include requirements that aren't necessary.
:Don't include requirements that aren't necessary.
:*Make sure you have all the necessary requirements.
:Make sure you have all the necessary requirements.
:*Techniques for gathering requirements:
:Techniques for gathering requirements:
::*Reuse existing requirements - if this project is like a past one.
::*Reuse existing requirements - if this project is like a past one.
::*Build a prototype - test the idea and evaluate it.
::*Build a prototype - test the idea and evaluate it.
Line 37: Line 37:
::*Observe end-users interacting with the product.
::*Observe end-users interacting with the product.
::*Conduct interviews.
::*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.
: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====
:*''Deliverables'' are the products or services that are delivered.
:''Deliverables'' are the products or services that are delivered.
:*Can be tangible (products) or more abstract (services).
:Can be tangible (products) or more abstract (services).
:*They help you measure progress.
:They help you measure progress.
:*Process:
:Process:
::*Start by defining end deliverables.
::*Start by defining end deliverables.
::*Next, define intermediate deliverables.
::*Next, define intermediate deliverables.
::*Next, define success criteria so you know your progress is on track.
::*Next, define success criteria so you know your progress is on track.
:*Deliverables should be able to be completed in between status reports.
:Deliverables should be able to be completed in between status reports.
:*How do you know the deliverables you receive are what you need?
: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'' help you determine that your deliverables are what you need.
::*Success criteria should be clear and quantifiable.
::*Success criteria should be clear and quantifiable.


====Assumptions====
====Assumptions====
:*''Assumptions'' are things that are believed to be true but are not confirmed.
:''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.
: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 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.
:Ask people to describe project success.


====Risks====
====Risks====
:*''Risks'' are situations or events that might negatively affect your project.
:''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.
: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.
:Document risks at the start of the project.


====Scope Statement====
====Scope Statement====
:*''Scope Statements'' define the boundaries of what is included and what isn't included in the project.
:''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.
: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.  
:''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.
:Sometimes team members expand the scope without management knowing it. When assembling the team, make sure they understand the scope statement.


====Stakeholders====
====Stakeholders====
:*''Stakeholders'' are people who have a stake in the outcome of a project.
:''Stakeholders'' are people who have a stake in the outcome of a project.
:*Major ''stakeholder roles'':
:Major ''stakeholder roles'':
::*Project Customer
::*Project Customer
::*Project Sponsors
::*Project Sponsors
::*Functional Managers
::*Functional Managers
::*Team Members
::*Team Members
:*How do you work effectively with your stakeholders?
:How do you work effectively with your stakeholders?
::*Make a ''stakeholder analysis'':
::*Make a ''stakeholder analysis'':
:::*Identify what motivates your stakeholders?
:::*Identify what motivates your stakeholders?
Line 82: Line 82:
:::*Identify the objectives that the stakeholders care about and their priorities.
:::*Identify the objectives that the stakeholders care about and their priorities.
:::*Document the stakeholder's contribution to the project.
:::*Document the stakeholder's contribution to the project.
:*Stakeholders are crucial to the success of your project.
:Stakeholders are crucial to the success of your project.


====Approval====
====Approval====
:*Get approval from project stakeholders.
: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.
: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.
:A face to face sign-off meeting is more effective.
::*Review the project summary to make sure the project stakeholders agree with it.
::*Review the project summary to make sure the project stakeholders agree with it.
::*Obtain signatures.
::*Obtain signatures.
Line 93: Line 93:


====Project Charter====
====Project Charter====
:*''Project Charters'' are formal announcements of the initiation of the project and the delegation of authority to the ''Project Manager''.
:''Project Charters'' are formal announcements of the initiation of the project and the delegation of authority to the ''Project Manager''.
::*Includes:
::*Includes:
:::*Name of the Project
:::*Name of the Project

Revision as of 05:44, 19 February 2012

Lynda.com Project Management Fundamentals

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.