Lynda.com Project Management Fundamentals: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
No edit summary
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 target that states the end result of the project.
:*''Project Goals'' are high-level target that states the end result of the project.
*:Easy to understand.
:*Easy to understand.
*:Create objectives that define the goal:
:*Create objectives that define the goal:
*::Specific
::*Specific
*::Measurable
::*Measurable
*::Realistic
::*Realistic
*::Time-Related
::*Time-Related


====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.
*::Hold requirements meetings. (marcin)
::*Hold requirements meetings. (marcin)
*::Observe end-users
::*Observe end-users
*::Interviews
::*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?
*:::Identify who your stakeholders listen to.
*:::Identify who your stakeholders listen to.
*:::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.
*::It’s important that the stakeholders understand what the project is about and buy into it.
::*It’s important that the stakeholders understand what the project is about and buy into it.


====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
*:::Purpose
*:::Purpose
Line 101: Line 101:
*:::Authority specifics
*:::Authority specifics
*:::A formal declaration of authority by the project sponsor.
*:::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.
::*When the project is ready to go, the project sponsor distributes the project charter to the team members.



Revision as of 05:36, 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 target that states the end result of the project.
  • Easy to understand.
  • Create objectives that define the goal:
  • 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
  • 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.