Risk Management
Assumptions: Assumptions are factors that we believe to be true, although these factors are not confirmed to be true. Assumptions add risk to a project since it is possible that they will turn out to be false. Assumptions can impact any part of your project life cycle and resulting solution implementation, so it is important to document and analyze them.
People make assumptions about things that they believe to be true every day. When was the last time that you left the house headed out to do your errands and calculated the time it would take to get those errands done based upon your assumptions for what you needed to do, where you were stopping and what traffic would be like along the way? Of course, there was always the risk that you would get those errands done in more time than you planned if the order of stops, what you did at each stop and the traffic did not behave as you assumed it would behave [LTIB].
Constraints: constraints are fixed boundary conditions or limits on what you can do. Going back to the morning errands example, you may find yourself constrained by the speed limits on the road you are traveling, the hours that the stores are open and the particular products that you can find in any given store. In this example, constraints are the things you cannot change but that you need to be aware of and manage to [LTIB].
Project Risk: Project risk is defined by PMI as 'an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives'.
Quality Management
Project quality management is all of the processes and activities needed to determine and achieve project quality.
Project Quality Plan:
Quality Requirements:
Quality Philosophies and Principles: The overall purpose for developing project quality plan should be grounded upon the quality philosophies and principles--
-A focus on customer satisfaction
-Prevention of mistakes
-Improving the process to improve the product
-Making quality every team member’s responsibility
-Fact-based management (based on hard evidence)
Standards: Standards provide the foundation for any quality plan, which can be defined in terms of the project’s deliverables, including quality attributes or dimensions associated with each deliverable.
Metrics: Metrics are vital for gauging quality by establishing tolerance limits and identifying defects, where a defect (bug) is an undesirable behavior associated with the product or process.
Verification: Verification focuses on the process-related activities of the project to ensure that the deliverable meets its specified requirements before final testing of the system begins.
It requires that the standards and metrics be defined clearly. It focuses on asking the question of “whether we followed the right procedures or processes.
Three types of verification reviews
i. Technical reviews – to ensure that the solution will conform to the specified requirements.
ii. Business reviews – to ensure that the solution provides the required functionality specified in the project scope and requirements definitions.
iii. Management reviews – compare the project’s actual progress against the baseline project plan.
Validation: Validation attempts to determine if the deliverables meet the customer or client’s expectations. Unlike verification, it occurs toward the end of the project. Testing makes up the majority of validation activities.
Requirement, Scope, and Deliverable
Requirement: Requirements define the product behavior. They indicate what is that users want from the product.
A carpenter needs to be able to drill 2-inch holes. This is the requirement. He needs a drill-bit that can drill 2-inch holes.
Scope: Scope indicates the activities that need to be done in order to achieve the requirements. Scope is about figuring out what goes into creating the drill-bit that has a diameter of 2-inches, and the acceptable tolerance limits.
Scope can achieve partial set of requirements when the requirements are implemented across multiple phases or iterations (if you are using Agile methodology) by scoping part of requirements in each phase/iteration.
In short, requirement is outward facing – specified by customer/business; and scope is inward facing – to be implemented by the project to satisfy requirements.
Deliverable: Something that is created and is of value to the customer. Project deliverables are the output produced after completing a project or task.
Measurable Organizational Value
Measurable Organization Value (MOV) is the projects overall goal and measure of success. In the IT field it must align with the organization's objective, mission, and goals.
The MOV MUST:
Be Measurable
Provide Value to the Organization
Be Agreed Upon
Be Verifiable
The MOV should be based on and support the organization's goal and strategy
Assumptions: Assumptions are factors that we believe to be true, although these factors are not confirmed to be true. Assumptions add risk to a project since it is possible that they will turn out to be false. Assumptions can impact any part of your project life cycle and resulting solution implementation, so it is important to document and analyze them.
People make assumptions about things that they believe to be true every day. When was the last time that you left the house headed out to do your errands and calculated the time it would take to get those errands done based upon your assumptions for what you needed to do, where you were stopping and what traffic would be like along the way? Of course, there was always the risk that you would get those errands done in more time than you planned if the order of stops, what you did at each stop and the traffic did not behave as you assumed it would behave [LTIB].
Constraints: constraints are fixed boundary conditions or limits on what you can do. Going back to the morning errands example, you may find yourself constrained by the speed limits on the road you are traveling, the hours that the stores are open and the particular products that you can find in any given store. In this example, constraints are the things you cannot change but that you need to be aware of and manage to [LTIB].
Project Risk: Project risk is defined by PMI as 'an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives'.
Quality Management
Project quality management is all of the processes and activities needed to determine and achieve project quality.
Project Quality Plan:
Quality Requirements:
Quality Philosophies and Principles: The overall purpose for developing project quality plan should be grounded upon the quality philosophies and principles--
-A focus on customer satisfaction
-Prevention of mistakes
-Improving the process to improve the product
-Making quality every team member’s responsibility
-Fact-based management (based on hard evidence)
Standards: Standards provide the foundation for any quality plan, which can be defined in terms of the project’s deliverables, including quality attributes or dimensions associated with each deliverable.
Metrics: Metrics are vital for gauging quality by establishing tolerance limits and identifying defects, where a defect (bug) is an undesirable behavior associated with the product or process.
Verification: Verification focuses on the process-related activities of the project to ensure that the deliverable meets its specified requirements before final testing of the system begins.
It requires that the standards and metrics be defined clearly. It focuses on asking the question of “whether we followed the right procedures or processes.
Three types of verification reviews
i. Technical reviews – to ensure that the solution will conform to the specified requirements.
ii. Business reviews – to ensure that the solution provides the required functionality specified in the project scope and requirements definitions.
iii. Management reviews – compare the project’s actual progress against the baseline project plan.
Validation: Validation attempts to determine if the deliverables meet the customer or client’s expectations. Unlike verification, it occurs toward the end of the project. Testing makes up the majority of validation activities.
Test
|
Description
|
Unit testing
|
It is at the module or object level, including white box testing,
black box testing and gray box testing
|
Integration testing
|
It tests whether a set of logically related units work together
properly after unit testing is complete.
|
Systems testing
|
The system is tested as a whole to verify usability, performance,
stress, compatibility and documentation
|
Acceptable testing
|
To certify that the system satisfies the end customer’s scope and
detailed requirements after system testing is complete.
|
Requirement, Scope, and Deliverable
Requirement: Requirements define the product behavior. They indicate what is that users want from the product.
A carpenter needs to be able to drill 2-inch holes. This is the requirement. He needs a drill-bit that can drill 2-inch holes.
Scope: Scope indicates the activities that need to be done in order to achieve the requirements. Scope is about figuring out what goes into creating the drill-bit that has a diameter of 2-inches, and the acceptable tolerance limits.
Scope can achieve partial set of requirements when the requirements are implemented across multiple phases or iterations (if you are using Agile methodology) by scoping part of requirements in each phase/iteration.
In short, requirement is outward facing – specified by customer/business; and scope is inward facing – to be implemented by the project to satisfy requirements.
Deliverable: Something that is created and is of value to the customer. Project deliverables are the output produced after completing a project or task.
Measurable Organizational Value
Measurable Organization Value (MOV) is the projects overall goal and measure of success. In the IT field it must align with the organization's objective, mission, and goals.
The MOV MUST:
Be Measurable
Provide Value to the Organization
Be Agreed Upon
Be Verifiable
The MOV should be based on and support the organization's goal and strategy