CAPM Exam Notes

Module 2: Projects and Project Management

• Project: A temporary endeavor undertaken to create a unique product, service, or result.
  • Endeavor: Something that delivers values as a product, service, or result. Ex: a bridge adds value. Even a small dinner could add value.
  • Temporary: Has a beginning and an end Ex: buildng a bridge is a temporary endeavor.
  • Unique: Has a unique set of requirements. May presume that the bridge is unique and requires its own plan. The unique characteristics of this bridge make it a unique structure and project.
• Projects are vehicles for change
  • A process in determining the feasibility of a project is called business analysis.
  • Business analysis is the practice of enabling change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders.
  • Business analysis is vital in determining the feasibility of a project to resolve issues, address gaps, enhance capabilities, and other objectives.
  • We use business analysis to determine business strategy, organizational goals, and project practitioners’ focus and intersection.
• Projects offer several components which enable the desired change and effective value delivery within organizations.
  • Projects are temporary, so businesses can protect themselves from overextending their financial and human resources.
  • Temporary projects have timelines that assist them in staying on budget and accountable to other dependent business operations.
• Turning a Goal into Reality: connection between organizational and project goals.
  • How feasible the opportunity is
  • How rea the challenges-or risks-are
  • Whether the investment will be worth it
  • Asking about potential revenue, approximate cost, the customer base, risks, and timeline, you are thinking about the feasibility of the new service or change to the business.
• Research and Results Analysis to Build a Business Case
  • What are the next steps to justify a project?
  • Invest time and effort to ask questions.
  • Conduct research, analyze results, and build a business case.
  • Finally, make a decision: “Yes” or “No?”
  • Build a business case that explores and justifies the business need and identifies potential benefits and value.
• Who Authorizes a Project?
  • Project sponsors (sometimes called executive sponsors) authorize the project and are accountable for enabling success.
  • Project sponsors can have a project vision.
  • Usually, stakeholders closer to the project will have the vision. The sponsor will provide support and resources for the project.
  • Project manager can help formalize or fine the vision into a project vision statement.
  • The project charter documents the project vision and formally authorizes the existence of a project.
• Project Initiation
  • The business analyst-an external consultant, VetVive partner, or other individual-should be able to offer much of the information the project manager or team needs to start planning and working.
  • Project vision statement-🡪project charter🡪project sponsor🡪list of stakeholders🡪a business case🡪measurable strategic objectives
    • Project vision statement- a concise, high-level description of the project that states that project’s purpose and inspires the team to contribute to the project.
    • Project charter: a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.
    • Project sponsor: an individual or a group that provides resources and support for the project, program, or portfolio, and is accountable for enabling success.
    • List of stakeholders: an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
    • A business case: identifies business needs, including the proposed benefits and value, feasibility study, cost/benefit analysis, and more.
    • Measurable strategic objectives: include any objectives that can be quantified, i.e. objectives key results, key performance indicators, and so on.
  • The project manager or team needs this authorization to use organizational resources for project activities.
• Project Management
  • The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.
    • Application: conducting business analysis eliciting requirements, estimating costs, communicating, motivating the team.
    • Guiding the work: The project manager guides the project team-including project assistants, coordinators, team members, specialists, contractors-to deliver the intended outcomes. Managing the project involves: planning, organizing, controlling.
    • If it’s planned entirely from the beginning, it’s a predictive life cycle. If it’s planned as the project progresses, it’s an adaptive life cycle. If it’s a combination of a plan that’s been outlined with the expectation of changes, then it’s a hybrid approach.
• Project management offers a number of benefits.
  • Success: improving the chance of project success.
  • Satisfaction: increasing satisfaction for all stakeholders
  • Efficiency: completing projects within scope, on schedule, within budget, and with acceptable quality
  • Optimization: using company talent and resources optimally
  • Focus: enabling customer focus and introducing quality focus
  • Risk management: reducing the impact of risk, including unexpected events and project failure
• Operations
  • The ongoing execution of activities that follows an organization’s procedures to produce the same result or a repetitive service.
  • Operations are permanent in nature-they’re ongoing.
• Program
  • Related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually.
• Portfolio
  • Projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.
    • Orgaizational needs: The emphasis is on building, sustaining, and advancing the organization. Project portfolios are planned to achieve strategic objectives.
    • Sharing resources: A portfolio enables an organization to share resources across the projects and programs of the portfolio.
    • Better management: The portfolio perspective allows the portfolio manager to manage risks and optimize resources across the portfolio’s projects and programs.
    • Tracking and controlling: Portfolios also allow the portfolio manager to track the progress in achieving the strategic objectives of the organization and to change the priorities of projects and programs.

Module 3: Organizing for Project Performance

• Team Development Stages
  • Forming: when people are polite
  • Storming: weight of tasks include
  • Norming: team settles into a groover
  • Performing: operating without supervision, when everyone on the team is on the same page
  • Adjourning: Team members have grown close
• Predictive
  • Project managers are typical project leaders in predictive teams. They are given authority by the organization to manage the project and see it through to completion.
  • Project team comprises a variety of roles and responsibilities that depend on the work to be done and the project objectives being accomplished.
• Adaptive
  • Self-organizing teams are typical in adaptive environments. In this team setup, everyone on the team leads. The ideal team is cross-functional, meaning they can work in many different areas, for example design, testing, building, and administration work.
• Other Team Positions
  • A project coordinator or project assistant is a junior practitioner n project management. They are often assigned specific roles on projects, such as scheduling, monitoring processes, or testing.
  • Functional managers refer to the existing organizational hierarchy in which the project is performed. Project team members may work in their normal business departments in addition to project work.
  • Specialists, consultants, contractors, and subject matter experts (SMEs) are widely used in project environments. These people have skills or expertise or time that the team does not have. They fill resource or talent gaps and ay be internal or external to the organization performing the project.
  • A change control board is unique to predictive projects. This is a group of stakeholders appointed to approve change requests during the project.
  • Adaptive team may have the additional roles of agile coach and scrum master, and team members may belong to communities of practice. Agile coaches work to the spread the benefit of the adaptive mindset throughout the organization.
  • Project management office (PMO) is a governance structure within larger organizations that supports project management work and initiatives. There are varying kinds of PMOs, but they all do similar things, supporting project management throughout any organization.
• Recommendations for Managing Conflict
  • Focus on Issues
    • Conflict is based on people perceiving situations differently.
    • The focus should be on resolving the situation, not casting blame.
    • Think back to your own experience in navigating a conflict. Were you able to keep communications open and respectful?
  • Focus on the present
    • Stay focused on the current situation.
    • Bringing up the past will not resolve the current situation.
    • Think back to your own experience in navigating a conflict. Were you able to use these techniques?
      • Why is it important for individuals to feel safe when they communicate?
      • How can you foster that feeling of safety?
  • Search for alternatives together
    • Damage can be repaired by looking for resolutions as a group.
    • Collaboration can strengthen relationships and move the conflict into a problem-solving space.
• A unilateral decision may lack the necessary perspectives and fail to recognize important experience or contexts.
• Stakeholders are engaged individually to recommend a single plan of action.
  • A stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
• Types of Project Stakeholders

• Stakeholder Rules
  • The project team will obtain inputs from the product owner and product manager. The product owner’s and manager’s needs and desires will shape the project.
  • The product owner is responsible for maximizing the value of the product. They manage the backlog, which is a list of work that needs to be done.
  • The product manager focuses on the external business environment, including:
    • Getting funding
    • Interacting with customers
• Process Owners and Managers
  • A process owner has the authority and accountability for a specific business process and its objectives. A process owner would address the efficiency and effectiveness of a business process so that it benefits the business.
  • Process managers look after business process execution. A single process can be managed, but in modern business, more than one process is managed.
  • When the project is over, the new process will be transitioned to the process owner.
• Business Analyst
  • Responsibilities include assesses project feasibility, prepares the business case, provides inputs for requirements, collaborates with the team, enables project transition to business, and verifies benefit realization
• Three Processes for Managing Stakeholders

• Stakeholder Register
  • Stakeholder registers include pertinent information.
  • It identifies all parties interested in the project.
  • You should create the stakeholder register as soon as the project sponsor signs the project charter.
• Levels of Interest
  • Unaware: when a stakeholder doesn’t know about the project or its benefits and other impacts.
  • Resistant: when a stakeholder is aware of the project, resistant to the project objectives, and resistant to the changes that the project introduces in its environment.
  • Neutral: when a stakeholder is aware of the project and they’re neither resistant to nor supportive of the project objectives or impact.
  • Supportive: when a stakeholder is fully aware of he project and they support the changes and project outcome.
  • Leading: when a stakeholder is not only aware of the project and potential impacts but they are also willing to be a champion and engage fully to ensure the success of the project.
• Stakeholder Engagement Assessment Matrix
  • One tool you can use is a stakeholder engagement assessment matrix.
• Power Interest Matrix
  • The power interest matrix helps you categorize stakeholders according to their power and interest in the project.
  • The Y-axis denotes “power,” and includes their ability to interrupt or make changes to the project.
  • The X-axis includes their level of interest, which is the alignment between stakeholder objectives and project goals.
  • 
• Salience Model
  • The salience model is another way to categorize stakeholders.
  • There are 3 elements that help you weigh how much priority you should give a stakeholder.
    • Power: level of authority
    • Urgency: immediate needs
    • Legitimacy: appropriateness
• PMI Talent Triangle
  • Ways of Working: technical project management, the right tools at the right time
    • Value creation enabled through application of this skills includes: scheduling, managing financials, issue log creation, development of a risk matrix, work plan creation, quality assurance procedures, lessons learned protocols
  • Power Skills: collaborative leadership, communication, innovative mindset, empathy
    • Value creation enabled through application of this skill includes: establishing and maintaining a vision; motivating others; displaying interpersonal, communication, and negotiation skills
  • Business Acumen: practice strategic and business management; cultivate effective decision-making
    • Value creation enabled through application of this skills includes: building effective, collaborative relationships with other project stakeholders; implementing strategy that maximize business value; developing a project mission, strategy, goals, and objectives as well as the products and services expected of the project
• Project managers perform complementary roles on projects, including those of coach, to motivate team members; working member, as part of the project team; negotiators who facilitate and expedite various agreements throughout the project life cycle and servant leader, which is arguably the most important role because it creates collaborative and productive team cultures.
• Maslow’s Hierarchy

• Herzberg’s To-Factor Theory

• Emotional Intelligence
  • Emotional intelligence is the capability to understand and influence not only one’s own emotions but also emotions of others.
• Four Tenets of Ethics in Project Management
  • Responsibility
  • Respect
  • Fairness
  • Honesty

Module 4: Business Analysis Frameworks

• Business analysis: Activities performed to support the delivery of solutions that align with business objectives and provide continuous value to the organization.
• Business analysts perform the work that support projects. This can include gathering data from internal stakeholders, conducting market research, and creating a business case for a new project. Portfolios are managed by portfolio managers or by senior management. The other choices are examples of work performed in the business work that the business analyst could potentially support, but not perform.
• What Does a Business Analyst Do?
  • Determine Needs: determine problems and identify business needs and benefits.
  • Elicit Requirements: Elicit, analyze, and document stakeholder requirements.
  • Identify Solutions: Identify and recommend viable solutions and measure their value.
  • Communicate: Ensure stakeholders have the information they need when they need it.
  • Facilitate Delivery: Facilitate the successful implementation of project and realize value.

• Functions of a Business Analyst
  • Strategic business analysis
  • Eliciting and analyzing requirements
  • Feasibility studies and definition of new business opportunities
  • Scoping an opportunity and identifying a preliminary solution
  • Preparation of a business case for a solution

• Requirement: A condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.
  • Example: Stakeholders may require that the new billing software must generate the monthly sales report currently used by the accounting group.
  • A requirement should be independent of the design of the solution that addresses it.
  • A correctly defined requirement is unambiguous, complete, necessary, feasible, and verifiable.
• Requirements Traceability Matrix

• Business requirement is a high-level statement of a business objective or business goal. Any type of requirement that is not a technical requirement.
  • Formula: To [business outcome], the organization [needs to/should] implement [solution]. To meet General Data Protection Regulation (GDPR) compliance, the organization needs to implement two-factor authentication on accounts where personal data are stored.
• Stakeholder requirements describe the needs of a stakeholder or a stakeholder group. User stories can help capture stakeholder requirements. To construct a stakeholder requirement, focus on what the need is, not how to deliver on it.
  • Ex: Customers must be able to view available seats to select their preferences before the ticket is purchased.
• Solution requirements describe specific characteristics of a solution.
  • Functional requirements describe a solution’s specific behaviors from the system's perspective. Ex: Calculate the total ticket cost, including local sales taxes.
  • Non-functional requirements describe the environmental conditions or qualities for the product to be effective. Ex: The system must be able to support 10,000 concurrent connections.
• Transition requirements describe how the solution will be deployed and released into production. Are temporary and will not be performed again after the project is complete.
  • Ex: Three trained support staff must be available during the first month after the system has been implemented to assist with any support queries that may be received.
• Project requirements describe the work needed to deliver unique solutions.
• Quality requirements validate the project completion and the fulfillment of requirements.
• Requirements management plan describe how the requirements will be analyzed, documented and managed.
• Requirements: Define and Elaborate
  • A business rules catalog, a type of rule model, is a table of business rules and related attributes. You can create and update the business rules catalog when you identify business rules.
  • The definition of ready is a series of conditions that the entire team agrees to complete before a user story is considered sufficiently understood so that work can begin to construct it.
  • The glossary is a list of all definitions for terms and acronyms about a product.
  • The product backlog is the list of all product backlog items, typically user stories, requirements, or features, that need to be delivered for a solution. Most often, the items in a backlog are written as user stories. Can be referred to as the requirements traceability matrix for adaptive.
  • A requirements management tool allows requirements and other product information to be captured and stored in a repository. When defining and elaborating requirements, the requirements are often stored in a requirements management tool.
  • Story elaboration is the process by which user stories are further detailed with additional information until they are ready for development.
  • Story slicing is a technique used to split epics or user stories from a higher level to a lower level.
  • A use case is a process model that uses textual narrative to describe the system-user interactions to achieve successful completion of a goal. This model is frequently used to identify and elaborate requirements.
• Key Processes in Business Analysis
  • Business Analysis in Planning
  • Stakeholder Identification

• • Stakeholder Analysis
    • The process of systematically gathering and then analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project.
    • Stages of Stakeholder Analysis

• • • Power is the extent to which a stakeholder has the power to affect the project, authorize aspects of the project, or otherwise decide things about the project-whether they choose to exert that power or not.
    • Impact is the degree to which a stakeholder’s role impacts the project’s scope, timeline, or cost.
    • Attitude is the type of positive or negative view of the project that the stakeholder tends to display or hold.
    • Beliefs are root conviction or approaches that a stakeholder tends to apply to the concept, organization, or execution of a project.
    • Expectation is the vision that a stakeholder has about a project in terms of its outcomes, execution, or approach.
    • Influence is the extent to which a stakeholder can (or does) choose to use their power to impact a project in some way.
    • Proximity is the degree to which a stakeholder’s role is directly associated with project’s definition or execution.
    • Stakeholders could remain disinterred; however, their views/authority can be necessary for a successful outcome. Interest in a project can also be a direct challenge when a stakeholder with such power becomes overly involved in the project.
  • Stakeholder Engagement and Communication
  • Transition to a Future State
• Responsibility Assignment Matrix (RACI)
  • Responsible: The person who owns the project, task, or work.
  • Accountable: The person who will sign off on the work, judging its completion and how it meets quality standards.
  • Consulted: People who have the ability or knowledge needed to complete the work.
  • Informed: People who must be kept informed of the work but are not necessarily consulted.
• Predictive vs Adaptive
  • Predictive approach: There is a structured sequential progression among well-defined phases.
    • The business analys’s role is clearly defined and delineated.

• • Adaptive/Agile approach: Activities repeat.
    • The business analyst performs same business analysis tasks as the predictive approach. However, the requirements continue to evolve in adaptive projects.
    • Business analyst must do their work iteratively throughout the project.
    • There is generally less emphasis on official documentation.

Module 5: Business Analysis Domains

• The 5 Business Analysis Areas
  • Business Analysis Planning: Deals with activities that identify the best approach. The process of coming to an agreement regarding the business analysis activities the team will be performing and the assignment of roles, responsibilities, and skill sets for the tasks required to successfully complete the business analysis work.
  • Needs Analysis: Business analysis work that is conducted to analyze a current problem or opportunity.
  • Requirements Elicitation and Analysis: Eliciting requirements from stakeholders and analyzing the information gathered from that elicitation.
  • Traceability and Monitoring: Include activities to ensure that the requirements and their links leading to product delivery are managed successfully throughout the project life cycle.
  • Solution Evaluation: Includes the processes to validate a partial or total solution that is about to be or has already been implemented.
• Business Analysis Planning
  • Focuses on 1) determining and analyzing project requirements & 2) tailoring and evaluating activities required to deliver the proposed solution.
  • Key Activities
    • Identifying stakeholders: Identify who has an impact on the success of the project.
    • Understanding and engaging stakeholders: Group stakeholders by their needs and determine the engagement level.
    • Requirements management: Identify requirements and the processes for validating, verifying, and approving those requirements.
    • Evaluation: Define a plan for evaluating success.
    • Project approach: Business analysis planning is based on the project approach and life cycle predictive, adaptive, or hybrid approach.
  • Business analysis plan describes how the requirements will be elicited, analyzed, documented, and managed across the project.
  • Requirements management plan covers planning decisions for both the product and project requirements.
• Needs Analysis
  • Needs analysis is the business analyzing a problem or opportunity. A successful needs analysis should answer the following questions:
    • What project solution addresses the problem or opportunity?
    • Is the proposed solution a good use of organizational resources?
    • What business value will be realized?

• • Perform these key business tasks during the needs analysis:
    • Review the existing documentation.
    • Assess organizational goals and objectives.
    • Clarify the needs, problems, and objectives.
    • Evaluate various options.
    • Create a solution scope.
    • Draft a situation statement.
    • Conduct a solution cost-benefit analysis.
  • Needs Analysis Processes
    • Identify problem or opportunity.
    • Assess current state.
    • Determine future state.
    • Determine viable options and recommend a solution.
    • Facilitate product roadmap development.
    • Support charter development.
    • Assemble business case.
• Business Analysis Planning
  • The key goal of business analysis planning is to formulate an understanding of the situation the organization is considering addressing.
  • “Sizing up” the situation is gathering relevant data to understand the problem or opportunity.
  • Benchmarking is the process of comparing metrics or processes from one organization against those of similar organization.
• The situation statement is an output of the identify problem or opportunity process.
  • Problem of A🡪Has the Effect of B🡪With the Impact of C
  • This ensures a solid understanding of the problem or opportunity. If the situation statement is uncertain or erroneous, or if stakeholders have different perspectives, you risk identifying the wrong solution.
  • The next step is to seek agreement from business stakeholders.
    • Stakeholder approval ensures that the situation statement correctly defines the problem or opportunity.
    • The business analyst initiates and facilitates a formal or informal approval process, depending on the organization.
• Assess the Current and Future States
  • The key goal of assessing the current and future states is to formulate an understanding of the situation the organization is considering addressing.
  • The organizational goals and objectives help a business analyst document business requirements.
  • Relevant goals and objectives provide context and direction for business need-based changes and solutions.
• Key Input: Situation Statement
  • The situation statement is a key input in assessing the current state and proposing changes in a future state.
  • Analyze the current environment to identify factors that may cause a problem or an opportunity.
  • Assess the desired future state to identify capability gaps and provide solutions.
• Tools for Assessing Current States
  • Pareto Diagram: Also known as the rule of 80/20, a Pareto diagram communicates the results of a root cause analysis.
  • Process Flow: This type of diagram describes business processes and the ways stakeholders interact with those processes.
  • Value Stream Map: This tool, which is like a process flow, can be used to identify process steps that add value (such as a value stream) and those that do not (such as waste).
  • Root Cause Analysis: Various techniques can be used to determine the basic underlying reason for a variance, defect, or risk.
  • Ishikawa Diagram: The cause-and-effect, Ishikawa, or fishbone diagram can be used to depict a problem and its root causes in a visual manner.
  • Five Whys: In this technique, someone seeking to understand a problem’s cause asks “why” as many as 5 times.
  • SWOT Analysis: A technique that facilitates discussions with stakeholders when formulating a strategic conversation in reaction to changes in the marketplace or organization. SWOT stands for strengths, weaknesses, opportunities, and threats.
• Tools for Defining Future States
  • Affinity Diagram: A graphical figure that shows categories and subcategories of ideas that cluster or have an affinity with one another.
  • Feature Model: Provides a visual representation of all the features of a solution, arranged in a tree or hierarchical structure.
  • Gap Analysis: A technique for comparing 2 entities, usually the as-is and to-be states of a business.
  • Kano Analysis: Used to model and analyze product features by considering the features from the viewpoint of the customer.
  • Process Flow: Used as a tool to depict the business process in its current state and model changes in the process that would be seen in potential future options.
  • Alignment Model: Helps a product team link business strategy to product strategy.
  • Solution Capability Matrix: Provides a simple visual way to examine capabilities and solution components in one view and identifies capabilities to address in the new solution.
• The Outcome of These Processes
  • The outcome of these processes should be clear SMART business goals and objectives and a description of required capabilities and features.
  • After the current (or “as-is”) situation’s capabilities and needed capabilities are assessed, identify any gaps or missing capabilities that exist between the current and needed states. These are the capabilities that need to be added.
  • These capabilities, known as “to-be” features and functions, can be easily identified by performing gap analysis, which involves contrasting the current state to the future state to identify disparities or gaps.
• What Does This Process Involve?
  • Determining viable options and recommending solutions involves:
    • Applying various analysis techniques
    • Examining possible solutions
    • Determining which option is the best one for the organization to pursue
• Benchmarking
  • Comparing your organization to established standards
  • Providing information when data cannot be collected or insufficient information exists
• Cost-Benefit Analysis: A financial analysis tool that compares portfolio components, program, or project benefits to costs.
  • Conducted as part of portfolio or program management activities and requires an understanding of financial analysis.
  • Included in the business case that demonstrates the most viable option
• Elicitation
  • Elicitation pulls information from sources. Some effective business analysis assessment techniques are:
    • Brainstorming: Brainstorming helps generate ideas quickly.
    • Facilitated workshops: A facilitator leads structured workshops with a stated objective.
    • Interviews: Interviews gather business analysis performance information from team members.
    • Personas Modeling: Personas focus on the customer’s goals, requirements, concerns, and frustrations.
• Feature Injection
  • Features that provide immediate value are the focus of feature injection discussions and analysis.
  • It guides the team to analyze only those features deemed to be of the highest value.
  • A 3 step approach:
    • Determine business value
    • Inject features
    • Spot examples
• Valuation Technique: Estimate option returns. Common value techniques include:
  • Internal rate of return: An estimation of an investment’s projected annual yield, incorporating initial and ongoing costs.
  • Net present value: Provides insight into whether an investment will provide value. The higher the net present value is, the greater the value an option is expected to provide.
  • Payback period: The time needed to recover an investment. The longer the payback period is, the greater the risk will be.
  • Return on investment: The percentage return on an initial investment. It is calculated by dividing the total projected net benefits by the cost of the investment.
• After analyzing viable options and recommending solutions, the business analyst assists in creating the following outputs:
  • Feasibility study results: Results from the feasibility analysis are summarized.
  • Recommended solution option: Recommended solution options provide one solution that best addresses the business need.
• Facilitate Roadmap Development
  • A project roadmap: 1) provides a high-level view of product features and their build and delivery order; 2) communicates the product vision and its life cycle highlighting how a product evolves; 3) facilitates understanding of how a product supports organizational strategy as it is refined and improved
  • Output from the Business Analysis
    • Feature Model: Represents all the features of a solution arranged in a tree or hierarchical structure.
    • Product Visioning: Sets the high-level direction for a product or a product release.
    • Story Mapping: Orders user stories by business value and user actions.
• Product roadmap provides a high-level view of product features and their build and delivery order.
  • Strategy information: Information about how the product supports the overall organizational strategy.
  • Portfolio: The relationship of the product to the portfolio ad how the product relates to the other products in the portfolio.
  • Initiatives: An overview of different projects being considered or currently in development that are related to the product.
  • Product Vision: An explanation of the intended customers and how needs are to be met, tying together what is being developed with why it is being developed.
  • Success Criteria: Metrics that can be used to determine solution success.
  • Market Forces: Any external issues that influence or shape the development of the product.
  • Product Releases: The process of identifying the expected product release dates and the themes or high-level features that each release includes.
  • Features: Capabilities that the product will provide, paired with the product releases, which are typically prioritized by a group of pre-set criteria.
  • Timelines: The time window in which the feature sets are expected to be delivered.
• Assemble Business Case: Components
  • Problem/Opportunity: What is prompting the need for action? You can use a situation statement to document the business problem or opportunity to be addressed.
  • Analysis of the situation: This depicts how a potential solution supports and contributes to the business goals and objectives. You can include the root cause(s) of the problem or the main contributors to an opportunity. You can support the analysis through relevant data to confirm the rationale.
  • Recommendation: These are the results of the feasibility analysis for each potential option. You can specify any constraints, assumptions, risks, and dependencies for each option. You can rank the alternatives and list the recommended solution with an explanation.
  • Cost-Benefit Analysis: This explores the costs and benefits related to the recommended option.
  • Evaluation: This is a plan for measuring benefits realization. This plan typically includes metrics for evaluating how the solution contributes to goals and objectives.
• Support Charter Development: The process of collaborating on charter development with the sponsoring entity and stakeholders using the business analysis knowledge, experience, and product information acquired during needs analysis and business case development efforts.

• • Iterative Process: Recognize a needs analysis is an iterative process; the sooner you change a poor solution, the better.
  • The business analyst collaborates with the project sponsor and stakeholders to develop the project charter. Collaboration is a key word in this process because it is the combined effort of the business analyst with the authority of the project sponsor and agreement among stakeholders to cooperate that enables development of a project charter.
  • The project sponsor and stakeholders approve the project charter, and in the project charter, a project manager is named or authorized to lead the initiative or run the project.
• Requirements and Elicitation
  • Predictive project scope management and the domain of requirements elicitation and analysis have notable overlap. Two distinct components:
    • Eliciting requirements from stakeholders
    • Analyzing the information gathered
  • Document requirements and model data to develop a business-appropriate solution.
  • These 2 tasks are strongly related and improved over time, making this domain analysis domain.
  • Key Activities in the Requirements and Analysis domain:
    • Elicit requirements
    • Analyze, decompose, and elaborate requirements
    • Evaluate product options and prioritize requirements
    • Create a requirements baseline
    • Sign of on requirements
    • Write requirements specifications
    • Validate requirements
    • Specify acceptance criteria
  • Elicitation information involves several additional tasks.
    • Support executive decision-making
    • Apply influence successfully.
    • Assist in negotiation or mediation.
    • Resolve conflict and negotiate with stakeholders to reach a consensus.
    • Define conflicts and explain techniques to prioritize.

• • Preparing for Elicitation Activities
    • Determine the objective: Set an objective for each elicitation activity. Elicitation activities should illustrate the project’s value and benefit.
    • Determine the participants: Less experienced participants require additional time to become familiar with the context.
    • Identify the resources: Examples or resources include having access to existing systems or documents.
    • Identify the questions: Questions need to be prepared in advance, and a business analyst may also want to consider how elicitation results will be captured.
    • Set the agenda: If prework is required or any of the participants, it is recommended to consult with them beforehand and distribute preparation materials and topics.
    • Schedule the elicitation activity: Schedule the appropriate amount of time for each stakeholder group, and secure the meeting room, projectors, whiteboards, flipcharts, and writing tools for the elicitation activity.
• Elicitation Techniques

• Requirement analysis has 3 objectives: 1) Ensure stakeholders understand the requirements; 2) Present the requirements in sufficient detail; and 3) Ensure that stakeholders see the business value of a project.
• Requirements Analysis: Key Processes
  • Determine analysis approach: The determine analysis approach determines what data to analyze, which models to produce, and how to verify, validate, and prioritize requirements.
  • Create and analyze models: Create and analyze models represents product information for analysis.
  • Define and elaborate on requirements: Define and elaborate requirements helps to refine and document product information at the appropriate level of detail, format, and formality for the life cycle.
  • Define acceptance criteria: In define acceptance criteria, you agree on what proves one or more solution components were developed successfully.
  • Verify requirements: The verify requirements process ensures quality requirements.
  • Validate requirements: You validate requirements to meet business goals and objectives.
  • Prioritize requirements: Prioritizing requirements and other product information is the final key process to understand how the individual components demonstrates the product’s ability to achieve stakeholder objectives and rank the work.
• Create and Analyze Models

• Analysis Models by Category
  • Scope Models: Scope models assist in defining project scope by structuring and organizing the business domain being analyzed.
    • Scope statement: This document specifies the requirements in detail and descries what features are in scope or out of scope.

• • • Ecosystem map: An ecosystem map shows applicable systems, their relationships, and the data passed between them.

• • • Context diagram: A context diagram is a representation of a system and human interaction within a solution.

• • Process Models: Process models describe the step-by-step movement of data, resources, or documents in the context of the organization.
    • Process flow diagram:

• • • Narrative use case:

• • • User stories: INVEST- Independent, Negotiable, Valuable, Estimable, Small, Testable
    • Story map:

• • • Grouping stories by release:

• • Rule Models: Rule models show business constraints that a proposed solution must enforce.
    • Business rules catalog: A business rule is a specific directive that is defined and managed centrally. Business rules serve as criteria when identifying solutions and are ultimately associated with conditions when implementing a system. Business rules describe how to constrain or support team behaviors within the operations of a business. Business stakeholders may often want or need to change the business rule to support business operations, so they must have a highly configurable design.
      • In a business rules catalog, business rules and their related attributes are listed by ID, title, description, constraints, and references.
    • Decision Tree: Can graphically model the choices to uncover a solution.
    • Decision Table: Business rules are often modeled with decision tables. Decision scenario combinations can reveal new requirements.
  • Data Models: Data models document data stores and the flow of data. Eliciting and representing data from complicated data models requires a skilled data analyst.
    • Entity relationship diagram: An entity relationship diagram is a popular business diagramming tool for data-driven applications.
    • Data dictionary: Lists the data fields and attributes of those fields for a data object, as we showed on the previous screen.
      • Ex: Entries (rows) may exist for credit card numbers, event dates, tickets purchased, etc. Columns may be made for format, length, required field, etc.
    • Data flow diagram: Shows the data inputs and outputs for each process in the project.
  • Interface Models: Interface models show a solution’s relationships to understand its interfaces and details.
    • Wireframe:

• • • Display-Action-Response:

• • • User Interface Flows:

• • • Report Tables:

• Traceability and Monitoring Key Tasks
  • Trace Requirements
    • Traceability monitors product requirements from origin to their deliverables.
    • Traceability is bidirectional because requirements can be traced to the solution and back to business needs.
    • Project managers must assess new or modified requirements and obtain stakeholder approval.
    • A business analyst can trace a stakeholder’s requirement, which is explicitly defined in the business needs and goals, through all subsequent steps and ensure that it is correctly implemented in the system.
    • Ex of traceable artifacts: work breakdown structure deliverables, test cases
    • Requirements traceability matrix: The link between the development of a business case for an initiative through to the project that is authorized to fulfill the strategic goals of that initiative. The requirements traceability is created during the pre-project phase, as the business analyst builds the business case, and it is used and updated during the project by either the business analyst or a project team member. For smaller systems, a spreadsheet is capable of creating a requirements traceability matrix.

• • Monitor Requirements
  • Update Requirements
    • Throughout traceability and monitoring, the status of all requirements must be communicated to stakeholders using appropriate communication methods.
    • Knowledge of approval levels is crucial to the success of a project, and all members of the project team must be informed of who can approve specific changes.
    • Approval levels specify who has the authority to approve certain requirements.
    • Types of Approval
      • Approval vs. Sign-Off: Business stakeholders may approve a set of requirements at the conclusion of an elicitation workshop, but the sponsor may be the person to sign off on the requirements.
      • Review vs Approver: A database analyst might be involved in modeling requirements and reviewing the database schema.
      • Approval Authority vs. Accountability: A business analyst has the authority to approve requirements, but the project manager has accountability for scope and requirements management.
      • Rejection of Requirements: It is not always clear who can reject requirements. In some organizations, the power to reject requirements is granted only to those who are permitted to sign off on them.
      • Approval of Changes: A change control board is a formal governing group that reviews, evaluates, approves, delays, or rejects changes to the project and records and communicates them.
  • Communicate Requirement Status
    • When a requirement change is proposed, perform an impact analysis to evaluate how it will affect other requirements, the product, the project, and the program. An impact analysis evaluates a proposed change by assessing its risks, required work, and scheduling and cost implications.
    • Performing an impact analysis allows project changes to be considered in an integrated manner, reducing project and product risk that typically results from changes made without considering the program, project, and end product.
    • The business analyst assesses cost, scheduling, and conflict issues by comparing the change request to the requirements baseline and existing solution components.
  • Manage Changes to Requirements
    • The business analyst assesses how far along the solution is in the development cycle and works with product development project team members to get feedback on how the proposed change, if approved, will impact current and future work.
• Solution Evaluation

• Solution Evaluation Domain Processes
  • Evaluate solution performance: Solution validation determines if the solution or component is delivering the intended business value.
  • Determine a solution evaluation approach: Determine how, when, and by whom performance will be measured for the organization or solution.
  • Evaluate acceptance results and address defects: Identify and resolve product problems. Compare the defined acceptance criteria against the solution and decide what to do.
  • Obtain solution acceptance for release: Decide whether to release a solution into production and whether to transfer product knowledge like risks, issues, and workarounds Solution sign-off occurs here.
  • Evaluate the deployed solution: To evaluate project success after solution implementation, assess the product.
• The Solution Evaluation Domain process includes addressing: 1) How will performance be measured?; 2) When will performance be measured?; 3) Who will conduct the evaluation?
  • Acceptance criteria are concrete and demonstrable conditions that have to be met for the business stakeholders or customers accept the item.
  • They may take the form of lists of acceptance criteria for each user story in an adaptive approach or a list of higher-level acceptance criteria for a release or solution in a predictive approach.
• Test-Driven Development Approaches
  • Test-Driven Development: Developers write the test case before writing the code. As the solution is developed, it is validated against the test case.
  • Acceptance-Test-Driven Development: Work begins in the iteration before the actual solution development. The business analyst, business customers, and testers write acceptance criteria for user stories.
  • Behavior-Driven Development: The behavior of the final software or solution is documented before the developers begin to write actual code.
• Considerations for Identifying Evaluation Criteria
  • Actual Project Costs: Actual project costs can be used in financial evaluations like return on investment or net present value.
  • Metrics Derived from Measurement of Cost, Effort, and Duration: Project performance can be measured by variation from cost, effort, and duration.
  • Change Requests: Change requests can be tracked as indicators of project volatility.
  • Rejection of Requirements: It is not always clear who can reject requirements. Only those authorized to sign off are permitted in some organizations.
• When Will Performance Be Measured?
  • With a predictive approach, an entire project solution is tested at the end of the project. At the end of the life cycle, evaluation activities such as user acceptance, testing, and solution release are conducted.
  • With an adaptive approach, you test a solution incrementally. Evaluation in iterative projects is tightly associated to solution release cadence. You test at the end of an iteration when you deliver a minimal viable product increment.
• Who Will Conduct the Evaluation?
  • Scope and performance validation involves planned sponsor or customer meetings to formally approve deliverables.
  • The evaluate solution performance tasks is led by the business analyst or any individual playing the business analyst role.
  • Requirements analysis, traceability, testing, and evaluation are complementary activities.
  • Adaptive life cycles define acceptance criteria with concrete examples as part of a user story. The acceptance criteria and the user story definition support each other. They reach an agreement between business stakeholders and solution developers.
  • Formal requirement traceability matrixes verify that requirements support business objectives and that testing covers them.

• Types of Verification Process Used
  • Peer Reviews: One or more coworkers review the work completed by the business analyst.
  • Inspections: A formal and rigorous review in which anyone close to the work inspects completeness, consistency, and conformance to internal and external standards.
    • Walkthrough; reviewing requirements with stakeholders and conforming validity
    • Day in the life testing; testing a solution in a real business setting with real users and real data
  • Validating the Scope: Involves external stakeholders and ensures that a product is ready for delivery upon completion of the solution.
  • Verifying a Deliverable: An internal quality control process that ensures product functionality as specified through quality checks.
• Accepting the Solution for Release
  • Implementation strategy: The team decides on whether to release a partial or full solution into production.
  • Transitioning Knowledge: Involves communicating and archiving knowledge about the product, risks, known issues, and workarounds.

Module 6: Life Cycles, Development Approaches, and Common Elements

• Project life cycle: The series of phases that a project passes through from its initiation to closure. It represents the entire lifespan of a project, from the initial idea or concept to the final deliverables and project completion Each phase in the project life cycle has its specific objectives, activities, and deliverables, and thy are typically completed in a logical sequence.
• The phases of the project life cycle are: ideation (feasibility); planning; design; build (executing, monitoring and controlling); and closing.

• A project phase is a collection of logically related project activities that culminates in the completion of one or more deliverables.
• A phase gate is a point for deciding whether a project should be continued or terminated. Stopping a project can mean cost savings. Steering committee members review the project and decide whether to continue or not. A phase gate blocks further progress until approval.
• Project vs Product Life Cycle
  • Because of their similar sound and appearance, the words “project” and “product” can be mistaken for each other or even used as synonyms; it’s easy to get confused.
    • Product: An artifact that is produced, quantifiable, and is either an end item or a component item.
    • Product Life Cycle: The series of phases that represent the evolution of a product, from conception through delivery, growth, maturity, and eventual decommissioning. It begins with the conception of a product and the beginning of its development. The product is then typically withdrawn from the market after a sales increase, a sales apex, and a gradual decline.
    • Project Life Cycle: The series of phases that a project passes through from its initiation to closure. Project life cycles intersect with product life cycles.
• Project Governance
  • Small business inherit project governance principles from accepted project management frameworks. Knowing they exist is a step towards having a strategic view.
  • Project Governance: The framework, functions, and processes that guide project management activities to create a unique product, service, or result to meet organizational, strategic, and operational goals.

• Projects are subject to the same frameworks as their parent programs. Project’s structure and culture will inherit that of the organization.
• Impact of Organizational Structures
  • Organizational structure is about organizing people and processes.
  • Organizational structures can have a huge impact on how projects work within an organization.
  • The impact of organizational structures can include project leadership style.
• Types of Organizational Structures
  • Functional: Project are assigned to a specific functional division. Assignment is based on the functional division’s areas of expertise and ability to support a successful outcome.
  • Projectized: Organizations that derive their revenue from project work are often structured as dedicated functional project teams. Project managers typically act as functional manages. They tend to be fully empowered to make decisions and are likely to have dedicated administrative and financial resources.
  • Matrix: The matrix organizational structure merges functional and dedicated project organization structures. Mature organizations may have a project management office (PMO). A dedicated project manager is typically assigned to manage teams including resources from different functional areas.

• Project Management Office (PMOs)
  • Modern PMOs maximize the delivery of value.
  • Help centralize and coordinate the management of projects.
  • Provide support functions such as training, standardized policies and tools, and archives of information.
• Types of PMOs
  • Supportive: Supportive PMOs provide a consultative role to projects. They supply artifacts, facilitate training, and provide access to information from other projects.
  • Controlling: Controlling PMOs provide support and require projects to comply with set standards. Compliance may involve adopting certain frameworks, using templates, or other conformance.
  • Directing: Directive PMOs take control of project by directly managing the projects or shared resources.
  • Agile Center of Excellence: In organizations that favor adaptive life cycles, a new PMO is emerging called an Agile Center of Excellence or value delivery office (VDO). They are emerging within organizations that are adopting more decentralized structures.
• Steering Committee
  • A steering committee sets a project’s direction. It typically consists of executives. It serves as a unified authority over priorities and resources. It reviews major project risks.
• Organizational Process Assets and Enterprise Environmental Factors
  • A project environment is full of internal and external influences and factors.
  • Organizational process assets (OPAs) comprise the project knowledge base and library of information. The plans, processes, polices, procedures, and knowledge bases that are specific to and used by the performing organization. They are all the implicit assets used by an organization when managing projects.
    • Templates, business plans, processes, policies, protocols, and knowledge
  • Enterprise environmental factors (EEFs) are factors that are outside of the control of the team and that affect the project in some way. Two types of environmental factors exist: internal and external. Internal examples include organizational culture, infrastructure, employee capability, resource availability etc. External examples include legal restrictions and regulatory environment, commercia/external database use, academic research, social and cultural influences and issues etc.
• Defining a Development Approach
  • A development approach is a method used to create and evolve a product, service, or result during the project life cycle, such as predictive, adaptive, or hybrid method. The development can demonstrate specific characteristics such as being iterative or incremental.
    • Value: Project teams use adaptive approaches to deliver value iteratively with frequent feedback and adjustments to improve outcomes.
    • Responsive: The iterative development approach differs from linear project management. It improves responsiveness to changing requirements, alignment with stakeholders’ needs, and project risk management.

• Project Performance Domain
  • A project performance domain is a group of related activities that are critical for the effective delivery of project outcomes.
  • The Eight Domains
    • Stakeholder: Addresses activities and functions associated with stakeholders.
    • Team: Addresses activities and functions associated with the people who are responsible for producing project deliverables.
    • Development Approach and Life Cycle: Addresses activities and functions associated with the development approach, cadence, and life cycle phases of a project.
    • Planning: Addresses activities and functions associated with the initial, ongoing, and evolving organization and coordination necessary for delivery project deliverables and outcomes.
    • Project work: Addresses activities and functions associated with establishing project processes, managing physical resources, and fostering a learning environment.
    • Delivery: Addresses activities and functions associated with delivering the scope and quality that a project was undertaken to achieve.
    • Measurement: Addresses activities and functions associated with assessing project performance and taking appropriate actions to maintain acceptable performance.
    • Uncertainty: Addresses activities and functions associated with ris and uncertainty.
• Project and Product Scope
  • Scope is the what” of the project. The project scope includes the work and the processes. The product scope includes the physical components.
  • Fixed Scope: We know the details of the product, service, or result. We are ready to start the project once these are known.
  • Flexible Scope: The team understands what the need to build, but they are still considering some of the finer details.
  • Hybrid Scope: Hybrid approaches combine aspects of predictive planning with the flexibility of an adaptive approach.
  • Scope is closely related to the project requirements. Requirements are gathered through the requirements elicitation process. In adaptive projects, business analysts help generate user stories, which describe what the stakeholders want.

• Scheduling Basics
  • The schedule is tailored to suit the type of project, the work, and the frequency of stakeholder engagement.
  • Predictive Project Schedule
    • The project manager sets a start and end point and estimates the duration of the project.
    • The timeline is given in the project charter, listing milestones and key dates.
    • There are two key tools and techniques you need to know about.
      • Critical Path Method: The critical path method is the sequence of activities that represent the longest path through a project, which determine the shortest duration. This is how project managers estimate the shortest possible duration for project work.
      • Work Breakdown Structure: The work breakdown structure (WBS) is a diagram that includes all project work broken into individual squares, which are arranged on a hierarchical diagram. Using this, the project manager can assign a duration to each activity.
  • Adaptive Project Schedule
    • Roadmap: The product roadmap gives an overview of how work should progress, with key milestones and perhaps some target dates.
    • Story Mapping: The estimation of work happens at the user story level, and it uses descriptive words to estimate and describe the work rather than giving a specific duration of time.
    • Backlog: The backlog gives a general framework to start the work. The team chooses the work they can and should complete next.
    • Sprints: While the pace of work may seem or feel quick, adaptive teams work at a sustainable pace. Work moves along in blocks called iterations or sprints.
    • Feedback Loops: Feedback loops are characteristic of adaptive approaches. The team finds out what needs to be improved, changed, or fixed to meet stakeholder needs.
    • Repetition: Adaptive schedules involve doing the same work in cycles over and over again until the customer is happy. It also means doing the same work a little at a time.
  • Hybrid Scheduling Approach
    • Most projects use a hybrid scheduling approach.
    • Businesses don’t often know what is specifically needed from the start.
    • A hybrid schedule can enable teams to state and work towards a fixed deadline while incorporating feedback loops throughout.
• Basics of Budgeting, Resourcing, and Procurement
  • Predictive Budgeting: A predictive budget approach with the controls of a cost baseline and plan-based controls is the best choice.
  • Budgeting Processes
    • Funding Limits and Baselines: In predictive planning, the project manager performs a funding limit reconciliation, sets a cost baseline, and figures out the budget at completion (BAC), which is the sum of all budgets, established for the work to be performed.
    • Earned Value Management (EVM): During the project, the project manager and team use metrics-typically earned value management (EVM)-to assess how the project is using the budgeted amount. It is also used to measure and monitor the health of the project schedule.
    • Adaptive Budgeting: Adaptive teams also work with organizational budgets. They use some type of agile budgeting method, whether it’s just in time budgeting or burn rates.

• Resourcing Introduction
  • As part of a project team, you are a human resource for the project, or a “talent.”
  • Making or having procurement plans is also an important part of resource planning.
  • Resourcing Tools
    • Responsibility Matrix: A grid that shows the project team members assigned to each work package.

• • • Responsibility Assignment Matrix: Shows stakeholders who are responsible, accountable, consulted, or informed.

• Adaptive Teams
  • Adaptive teams are cross-functional and composed of team members who can accomplish much of the work by self-organizing. If skills outside the project are needed, it’s time to engage the procurement process.
• Procurement Contract
  • A contract is an agreement between the buyer and seller to perform the sale. If there is a team gap, the project manager can request that a contractor be assigned.
    • Contracts: A procurement statement of work is a document that describes the requirements of a given project. Once that statement of work is complete, contracts may be solicited. Contracts are typically classified into one of three categories: fixed-price, cost-plus, and time and materials.
    • Solicitation: Once the expectations for the contract are known, a procurement solicitation document may be created. This document is published to a variety of subscriber organizations as a way to advertise that work is available. It can come in many forms, but the most common one is called a request for proposal, or RFP.
• Quality Basics
  • Quality: The degree to which a set of inherent characteristics fulfills requirements.

• • Compliance
    • Compliance is the degree to which something does or does not meet a given standard. Projects inherit compliance requirements from the organization. Predictive projects will create a quality management plan. Adaptive teams use inherent quality methods, including retrospectives.
  • Basics of Integration and Tailoring
    • Project professionals integrate all planning activities to deliver value. This can take the form of using a formal plan to integrate all the different project plans. It can also mean taking a holistic view of the project and figuring out how to weigh all the considerations.
  • Change: A modification to any formally controlled deliverable, project management plan component, or project document.
    • The change management plan: establishes the change control board (CCB); documents the extent of its authority; and describes how the change control system will be implemented.
    • Anyone can create a change request. It’s logged in the change log and sent to the CCB. Then it is rejected or approved.
    • A change request is a part of the perform integrated change control process. Retrospectives are adaptive project ceremonies that are used for change control.
  • Adaptive Change
    • Many projects would be more effective with a more flexible, quicker, or even an “experimentation-based approach” mindset.
    • Adaptive approaches offer these capabilities.
    • The Product Owner acts as the CBB as the sole approver of changes and new features.
  • Risks, Issues, Assumptions, and Constraints
    • Constraints: Project boundaries or limits variables such as time, cost, or scope. For example: deadline of July 23 (time constraint), 200 seats max (scope constraint)
    • Constraints may also shift and change. For example, a cut in budget may impact quality or scope. Balancing these shifting constraints is an ongoing project activity. It may involve meeting with the customer, sponsor, or product owner to present alternatives. It may be within the team’s authority to make trade-offs between constraints such as scope and quality.
    • Risks: An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. Negative risk: threat (ex: supplier going bankrupt). Positive risk: opportunity (ex: talented business analyst is joining your project.)
      • Every project should have a strategy or plan to deal with risk.
      • Risks are assessed early and recorded in the business case and project charter.
      • When a project is authorized, stakeholders should know the high-level risks.
      • Risks are evaluated for: impact, probability, severity, and advance notice.
      • Documentation about risks is kept in a risk register.
      • Risk Vocabulary
        • Inherent Risk: Any business endeavor will involve profit or loss. Business risks can be competitive, legislative, monetary, and operational.
        • Risk Appetite: Risk appetite is the degree of uncertainty an organization or individual is wiling to accept in anticipation of a reward.
        • Risk Threshold: Risk threshold is the level of risk exposure above which risks are addressed and below which risks may be accepted.
        • Trigger Condition: A trigger condition is an event or situation that indicates that a risk is about to occur.
    • Assumptions: Factors in the planning process that are true, real, or certain without proof or demonstration. For example: “Dr. Ahmud Khalif will oversee the design of the aircraft radar system.”
      • Assumptions are often not problematic for your project.
      • Assumptions create a set of operating conditions for the project. They are built into the planning, budgeting, and execution steps.
    • Issues: Risks that have occurred. They are conditions or situations that may have an impact on the project objectives. Example: faulty line of code that leads to buggy software. Previously a risk, it is now an issue since it has occurred.
      • Issues log: The project manager maintains a list of all issues in the issue lg. The issue log captures information about: a question or discovery, who fist raised the issue, who will research it, what impact it might have, and when the next update is expected.
• What is Communication?

• • Communication Techniques include feedback, attentive listening, and interpretation of nonverbal cues.
  • A communication blocker can impede the flow of effective communication. Stakeholders may not get the message for a variety of reasons: spam filters, excessive acronyms, heavy workload.
  • Blockers can cause project team miscommunication and even rifts, jeopardizing project success.
    • There are 2 main communication blockers:
      • Filters: sender and receiver communication filters exist. Some common examples which can affect the perception of communication: language, culture, and terminology differences; dysfunctional emotional behaviors; traditions; “talk past each other”
      • Barriers: Communication barriers interrupt project communications. Some common examples: poor Internet connection; resistant mindset; acceptance of misinformation as fact; and interpersonal conflict.
  • Communication Methods
    • Formal written: project charter, project plans, project reports, contracts
    • Formal verbal: presentations, updates, and briefings
    • Informal written: memos, emails, and notes
    • Informal verbal: casual conversations

• Putting Together a Communications Management Plan
  • The communications management plan is usually a component of the project plan however, it may be independent depending on complexity. Creating and adhering to a communications management plan will contribute to project success.
• Answering Five Critical Questions
  • What is being communicated?
  • Why is it being communicated?
  • To whom is it being communicated?
  • How is being communicated?
  • When is it communicated?

• Critical Communication Skills

• • Three processes related to communications management:
    • Plan communications management
    • Manage communications
    • Monitor communications
  • Key Requirements for Effective Communication
    • Analyze communication needs
    • Determine communication methods
    • Communicate effectively
    • Confirm communication effectiveness
• Problem Solving and Communications
  • Project management problems are puzzles that must be solved. Each member of the team contributes to problem-solving.
  • Problems, ranging from minor to major, can impede work and create frustration and delays.
  • Common terms for project management problems: issues, obstacles, blockers, impediments, challenges.
  • Problem-Solving Artifacts
    • The issues log is updated by predictive teams.
    • If the risk becomes an issue, a solution, followed by action..a risk management plan, is needed.
    • Adaptive teams meet daily for standups and retrospectives to brainstorm solutions.
    • Some agile contexts call the issue log the impediments log (list). This artifact tracks progress regardless of name.
    • By solving or easing impediments, the project team can deliver business value faster.
  • Problem-Solving Techniques
    • Techniques include data gathering, research, critical thinking, creative approaches, quantitative/logical approaches, and expert judgement.

• • Communication as Key
    • An environment of open communication promotes honest and safe dialogue, productive meetings, problem-solving, brainstorming, and so on. This is the cornerstone for other positive team performance factors including shared understanding, trust, and collaboration.

Module 7: Predictive Approaches

• If the answer to any of the following questions are “yes”, we should consider the predictive approach.

• Project Management Process Groups (used in predictive approach)
  • Initiating Process Group: Includes the processes that define a new project by obtaining authorization to start the project or phase. Ex: develop project charter
  • Planning Process Group: Includes the processes that establish the total scope of the effort, define and refine the objectives, and develop the course of action required to obtain those objectives. Ex: develop project management plan
  • Executing Process Group: Includes the processes performed to complete the work defined in the project management plan to satisfy the project requirements. Ex: direct and manage project work
  • Monitoring and Controlling Process Group: Includes the processes that track, review, and regulate the progress and performance of the project. Ex: control scope; dealing with issues and risks
  • Closing Process Group: Includes the processes that formally complete or close a project, phase, or contract. These processes verify that the defined processes are completed within all the other process groups to close the project or phase, as appropriate, and formally establish that the project or project phase is complete.
• Factors to Consider When Tailoring Project Life Cycle
  • Product/Deliverable
    • Compliance/Quality: For critical projects with high compliance requirements, it is normal to see more documentation, testing, and requirements traceability.
    • Type of Product/Deliverable: Physical products typically have slower rates of change and less ability to accept late-breaking changes. They are more likely to follow a more predictive life cycle. Intangible products that manipulate ideas and data are more likely to suit an iterative or agile approach that incorporates frequent reviews to confirm progress and direction.
    • Industry/Market: Fast changing markets need to be able to respond to competitors quickly. Highly regulated markets need appropriate documentation and compliance certification; this takes time and careful planning; they probably suit a predictive approach.
    • Technology: Stable technology should be more knowable. If the requirements are also stable and defined, it should be possible to create detailed plans. Rapidly evolving technology will likely find detailed up-front plans less valuable than more sense-and-respond prototyping and exploration with frequent plan updates and reprioritization.
    • Time Frame: Short time frame projects can be executed using either predictive or iterative approaches. However, we would likely aim to expedite approvals, artifact creation, and decision-making. Maybe appoint a product owner to act as approver, and change the control board process. Could be done with an agile or hybrid approach.
    • Stability of Requirements: Many changes to requirements suit agile approaches with frequent review points to check the evolving product, change, or service. They also employ lightweight and flexible requirement management systems (product backlogs, independently prioritized user stories etc) to make inserting changes and reprioritizing scope efficient. Changing statements of work, requirements lists, and work breakdown structures take more time to refactor.
    • Security: Confidential or classified data may influence who can evaluate early versions of the product. Confidential or classified data will likely require additional testing procedures, audits, and 3^rd party review. A hybrid or predictive approach that plans for these elements could be beneficial.
    • Incremental Delivery: If elements can be demonstrated early, even if they’re not completed, then the short iterations with frequent demonstrations of an agile approach are likely a good fit. A predictive approach with frequent demonstrations (this would now be a hybrid) might also work.
  • Project Team
    • Project team size
    • Project team geography
    • Organizational distribution
    • Project team experience
    • Access to customer
  • Culture
    • Buy-in
    • Trust
    • Empowerment
    • Organizational culture
  • You can tailor engagement, tools, methods & artifact and processes in a predictive approach.
• What is a Project Charter?
  • A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.
  • The project charter also provides a high-level description of the project’s what, why, when, who, where, and how.

• Resource calendar identifies the working days, shifts, start and end of normal business hours, weekends, and public holidays when each specific resource is available. It contains information on which resources potentially will be available during a planned activity period-which is useful for estimating resource utilization.
• Resource management plan: This component of the project management plan provides guidance on how project resources should be categorized, allocated, managed, and eventually released. A resource management plan may include: identification of resources, acquiring resources, and roles and responsibilities. It may contain additional information as well.
• Procurement Management
  • The process your project team goes through to acquire goods and services from outside your organization.
  • Procurement Contract: A mutually binding agreement that obligates the seller to provide specific products and services and obligates the buyer to provide money or other valuable considerations in return for them..
    • Fixed-Price: An agreement that sets the fee that will be paid for a defined scope of work regardless of the cost or effort to deliver it. Also known as lump-sum contracts, are used in delivering a well-defined product or service for a fixed price. May include incentives for meeting; the seller take the greatest risk. Specifications are critical.
    • Cost-Plus: A type of cost-reimbursable contract where the byer reimburses the seller for the seller’s allowable costs, plus a fixed amount of profit. The seller is paid for the actual costs incurred, plus a fee or margin representing the seller’s profit. The buyer takes the greatest risk.
    • Time and Materials: A type of contract that is a hybrid contractual arrangement containing aspects of both cost-reimbursable and fixed-price contracts. An estimated number of hours is provided. The buyer takes the greater risk. Time and materials contracts are most suitable where there is only a high-level scope for the project and specifications are not very detailed up front. Additions and changes can make this an open-ended contract that puts the buyer at the seller’s mercy for the added cost of modifications.
  • Bid Document includes the procurement contract, statement of work, and background context.
    • Requests for Information: A type of procurement document whereby the buyer requests a potential seller to provide various pieces of information related to a product or service or seller capability. Buyer asks for information to help understand what might be possible as a solution for the requirements. A request for information asks for the submission of information to help the buyer understand what might be possible as a solution for the requirements.
    • Requests for Proposal: A type of procurement document used to request proposals from prospective sellers of products or services. In some application areas, it may have a narrower or more specific meaning.
    • Requests for Quotation: A type of procurement document used to request price quotations from prospective sellers of common or standard product or services. Sometimes used in place of request for proposals and, in some application areas, it may have a narrower or more specific meaning.
  • A bid conference is a meeting that allows sellers interested in submitting a bid to ask questions and gain clarification.
  • A bid walk-through is an event where seers visit the site to understand the full context of the requested work to determine a proper bid for services or products.
  • Bid submission: an offer to provide the requested products or services at a particular rate or cost. Bid submissions may be regulated by various levels of government to ensure fairness or diversity. Internal organizational policies may require obtaining bid submissions from a particular number of possible sellers.

• Project Management Plan
  • Project management plan: A document that describes how the project will be executed, monitored and controlled, and closed.
  • Roadmap
    • Defines what is to be done, by whom, when, and for how much
    • Explains how the work is to be monitored and controlled
    • Lists the deliverable
  • Organization Culture Factors
    • Collect requirements: The process of determining, documenting, and managing stakeholder needs and requirements to meet objectives.
    • Sequence activities: The process of identifying and documenting relationships among the project activities.
    • People and resource management: The process of defining how to estimate, acquire, manage, and use team and physical resources.
    • Define scope: The process of developing a detailed description of the project and product.
    • Estimate activity durations: The process of estimating the number of work periods needed to complete the individual activities with estimated resources.
    • Identify risks: The process of identifying individual project risks as well as sources of overall project risk and documenting their characteristics.
    • Create work breakdown structure: The process of subdividing project deliverables and project work into smaller, more manageable components.
    • Develop schedule: The process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create a schedule model for project execution and monitoring and controlling.
    • Plan risk responses: The process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure as well as to treat individual project risks.
    • Define activities: The process of identifying and documenting the specific actions to be performed to produce the project deliverables.
    • Plan quality management: The process of identifying quality requirements and/or standards for the project and its deliverables. This process documents how the project will demonstrate compliance with quality requirements and/or standards.
  • Baselines
    • Scope baseline: The scope baseline establishes what the team needs to achieve and how much work is needed to complete these goals through a work breakdown structure and its associated work breakdown structure dictionary.
    • Schedule baseline: The schedule baseline is the approved version of a schedule model. It helps project managers track task durations and milestone, allowing them to identify any potential delays.
    • Cost baseline: The cost baseline is the approved version of the project budget, excluding any management reserves. It allows managers to track actual costs against the budget, identifying potential cost overruns.
  • Additional Components
    • Change Management Plan: A change management plan describes how the change requests throughout the project will be formally evaluated, authorized, and incorporated.
    • Configuration Management Plan: A configuration management describes how the information about the items of the project (and which items) will be recorded and updated so that the project’s product, service, or result remains consistent and/or operative.
    • Performance Measurement Baseline: A performance measurement baseline is an integrate scope-schedule-cost plan for the project work against which project execution is compared to measure and manage performance.
    • Project Life Cycle: A project life cycle describes the process and series of phases that a project will pass through from its initiation to its closure.
    • Development Approach: A development approach describes the product, service, or result development approach, such as predictive, iterative, agile, or a hybrid model.
    • Management Reviews: Management reviews are points in the project when the project manager and relevant stakeholders will review the project progress to determine if performance is as expected or if preventive or corrective actions are necessary.
• Identifying Requirements and Defining Scope
  • Requirements and Scope
    • Requirements: A requirement is a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.
    • Scope: The scope is the sum of the products, services, and results to be provided as a project.
    • Scope creep: Scope creep is the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.
    • Scope baseline: The scope baseline is the approved version of a scope statement, work breakdown structure, and its associated work breakdown structure dictionary that can be changed using formal change control procedures and is used as the basis for comparison to actual results.
  • How Will You Gather Requirements + Define Scope?

• • Developing a Scope Statement
    • Is a formal document, signed by stakeholders, that provides the basis or making all project decisions. Defines all the products, services, and results to be provided. Ensures customer satisfaction and is the basis for avoiding scope creep.
  • Avoiding Scope Creep
    • If unaddressed, the scope of a project may gradually increase over time without appropriate changes to the schedule or budget. Uncontrolled growth in the scope of a project can impact its schedule and cost.
    • If your scope statement is broad and imprecise, it can leave room for scope creep to occur.
• Creating a Work Breakdown Structure
  • Work Breakdown Structure: A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

• • The level of decomposition is often guided by the degree of control needed to effectively manage the project.

• Estimating Schedule, Duration, and Resources

• Milestones
  • A significant point or event in a project, program, or portfolio. Milestones help a project manager to track progress along the timeline of a project.
  • A milestone has no duration or resources assigned.
  • Project software tools can show views of milestone completion, comparisons of estimates with actual progress, etc.
  • Developing milestones is an iterative process.
• Identify Activities
  • An activity is a distinct, scheduled portion of work performed during the course of a project. Activities have a distinct beginning and end. When the sub-steps of an activity are completed, the whole activity can be regarded as completed. Several related activities can be combined to form a summary activity.
  • Use logic to sequence activities and milestones together. The points at which these activities connect with each other are called a relationship. Every activity and milestone except the first and the last must be connected to at least one predecessor and one successor.

• • Estimating Durations
    • Analogous estimation: Analogous estimation relies on a comparison to similar activities in the past. This method is also useful to estimate the time or budget for a whole project during the pre-project phase when the project charter is developed.
    • Parametric estimation: Parametric estimation is based on using metrics-such as cost per square foot-that are known from projects in the past.
    • Three-point estimation: Three-point estimation uses one of two formulas that use the same three data points: an optimistic estimate, a pessimistic estimate, and a most-likely.
  • Scheduling
    • Forward Pass: Assign a start date to the start milestone. Moving through the network from activity to activity-from left to right-in the sequence defined by the logical relationship, assign start and finish dates to each activity and milestone.
    • Backward Pass: Assign a finish date to the end milestone; this could be the same date as the one calculated by the forward pass, or a different date applied as a constraint. Work backward through the schedule-from the right to left-until you arrive at the start milestone, assigning another set of start and finish dates to each activity.
    • Calculate Float: Subtract the early finish date from the late finish date. This is the float for the project. If this number is negative, the dates are not feasible without changing the plan.
  • Crashing and Fast Tracking
    • Crashing consists essentially of adding people or equipment to critical activities to shorten their durations. Crashing typically increases project costs, while fast tracing increases the risk of rework as activities are started before their predecessors are completed.
    • Fast tracking consists of overlapping critical activities rather than working them strictly in sequence.
• Critical Path
  • The sequence of activities that represents the longest path through a project, which determines the shortest possible duration.
  • Float is the amount of time a schedule activity can be delayed or extended without delaying the project finish date. The critical path doesn’t have any float; it defines the overall project length.

• • A project can have multiple critical paths. Such a project has a higher level of risk since failure to meet any of these might result in delay.
  • Critical path activities are those activities contained in the critical path. Critical activities are those activities vital to the success of the project schedule, even if they are not on the critical path. All activities on the critical path are considered critical, but not all will be on the critical path.
• Identifying Budget and Cost
  • Create a Project Budget
    • Estimate costs🡪Review🡪Add extras🡪Set tolerances🡪Get approval
  • Estimating Durations
    • Expert Judgement: Expert judgement is making a judgement based on skill, expertise, or specialized knowledge in a particular area. It can be based on someone’s training or educational background, career experience, or knowledge of the product or market.
    • Analogous estimation: Analogous estimation relies on a comparison to similar activities in the past. This method is also useful to estimate the time or budget for a whole project during the pre-project phase when the project charter is developed.
    • Parametric estimation: Parametric estimation is based on using metrics such as cost per square foot that are known from projects in the past. This method is often used in earlier stages of a project when proposals must be provided, but no detailed information about each activity has been possible yet to develop.
    • Three-point estimation: Three-point estimation uses one of two formulas that use the same three data points: an optimistic estimate, a pessimistic estimate, and a most-likely estimate.
      • Estimate = (Optimistic + Likely + Pessimistic)/3
      • Estimate = (Optimistic + (4 x Likely) + Pessimistic)/6
• Identifying Quality Requirements
  • Scope and requirements focus on what needs to be delivered. Quality focuses on performance levels that need to be met.
  • Identifying the quality requirements and standards to which the project will be subject, then documenting how the project will meet and show that it has met these requirements and standards.
  • Standards establish benchmarks products or services must meet to be in compliance with that standard.
  • Regulations are requirements imposed by a government body. They can regulate products, processes, service characteristics, even how to handle compliance (de facto vs non-government).
  • Validation: Quality requirements are implemented so teams can validate that all products, services, and interim outputs meet their requirements.
  • Plan: Part of the larger project management plan, the quality management plan describes how the organization’s quality processes, approaches, and standards will be implemented in the project.
  • Appraisal Costs: verification, quality audits, supplier rating
  • Prevention costs: product or service requirements, quality planning, quality assurance
  • Internal failures: waste, scrap, rework
  • External failure: service and repair, complaint, returns
• Identifying and Managing Risk
  • Risk: An uncertain event or condition that, if it occurs, can have a positive or negative effect on one or more project objectives.
  • Risks can be both positive and negative. Risks with positive outcomes are called opportunities. Risks with negative outcomes are called threats.
  • Risk management: The processes necessary to increase the probability and impact of positive events and decrease the probability and impact of negative events.
  • Possible Responses to Threats
    • Escalate: Escalation is appropriate when a threat is outside the portfolio, program, or project scope for which you are responsible.
    • Avoid: Avoid the risk when the portfolio, program, or project team acts to eliminate a threat or protect activity from the impact of the risk.
    • Transfer: When you transfer the risk, you shift the responsibility of a threat to a third part to manage the risk and bear the impact if it occurs.
    • Mitigate: When you mitigate risk, you take action to reduce the probability of it occurring or reduce the impact of it occurs.
    • Accept: When you accept risk, you acknowledge its existence but decide not to act directly.
  • Possible Responses to Opportunities
    • Escalate: Escalation is appropriate when an opportunity is outside the portfolio, program, or project scope for which you are responsible.
    • Exploit: Your organization may choose to exploit high priority opportunities to ensure that the opportunity is realized.
    • Share: Sharing involves transferring ownership of an opportunity to a third party or group, so it shares some of the benefits if the chance occurs.
    • Enhance: Enhancing is used to increase the probability of an opportunity and its impact.
    • Accept: When you accept an opportunity, you acknowledge its existence but decide not to act directly.
  • Risk Identification Techniques
    • Brainstorming: Brainstorming is a technique for generating spontaneous ideas or from a group. When brainstorming is used as a group risk identification method, the ideas and thoughts of one individual serve to stimulate ideas in the other participans.
    • Ishikawa Diagram: Ishikawa diagrams are also known as fishbone or cause-and-effect diagrams. In this technique, the risk is mapped onto a branching diagram, allowing them to display the root causes of risk visually.
    • Delphi Technique: Under the Delphi technique, a facilitator polls subject matter experts to identify risks in their areas of expertise. The facilitator gathers these initial responses and circulate them without attribution to the entire group. The group members are then encouraged to revise their contributions based on those of others.
    • Interviews: Interviewing experienced project, program, or portfolio participants, stakeholders, and subject matter experts can identify risks. Interviews are one of the primary sources of risk identification data gathering.
    • Prompt Lists: Prompt lists enumerate risk categories to detect the most relevant to the project, program, or portfolio. A prompt list can be helpful as a framework for brainstorming and interviews.
    • Questionnaires: Questionnaires encourage broad thinking to identify risks; however, it requires quality questions to be effective.
    • Root Cause Analysis: Root cause analysis seeks to identify basic causes of risks that may be visible symptoms of more fundamental forces. It may also identify familiar sources of several risks, leading to broad-reaching risk response strategies. Care needs to be taken when using this technique to distinguish between risks that is, uncertain causes of impacts and issues which are certain causes of impacts.

• • • The risk management plan is a set of guidelines, formats, and procedures to be followed when managing risks.
    • During the planning stage, a project manager should identify, classify, an analyze and evaluate the risks. Addressing and monitoring the risks comes later, during the execution and monitoring and controlling phases. And closing the risk happens when the risk is no longer active or relevant.
• Integrating the Plans
  • Moving parts of projects: charter, plans and schedules, processes and people, budgets and reports, work breakdown structures, risk breakdown structures. All these moving parts interact. Integration is a critical skill for project managers.
  • Levels of Project Integration
    • Process Level: Project management may be seen as a set of processes and activities. Some of these processes take place once; others happen several times. They often overlap. Integrating these is critical if the project is to succeed.
    • Cognitive Level: There are many ways to manage a project. The method selected depends on the specific characteristics of the project. Project managers apply their experience, insight, ways of working, power skills, and business acumen to the project.
    • Context Level: The world in which projects are happening is changing fast. Project managers need to be aware of the project context and these new aspects when managing the integration. Then they can decide how to best use these new elements of the environment in their project to achieve success.
  • Handling Change Requests
    • Clarify the need for change. 🡪 Formally log and document the change. 🡪 Evaluate the change and document its impact. 🡪 Get a decision on the proposed change. 🡪 If the change is approved, create a new baseline, and update all project documentation. 🡪 Communicate to the team and impacted stakeholders.
  • The most important response to change is to prevent it from getting out of control.
  • The way we ensure that the project management plan remains integrated during execution is by using the perform integrated change control process to control any changes to plans or baselines. Part of this process is the change control board (CCB), which is an integral part of project change control.

Module 8: Project Work and Delivery

• Directing and Managing Project Work
  • This process involves various aspects of project direction and management, including acquiring resources.
    • Managing the team and project work
    • Managing quality and risk
    • Managing communications
    • Managing stakeholder engagement
    • Managing talent and procurement
  • Predictive approach for executing work
    • Planned work (ex: WBS (work breakdown structure)
    • Approved change requests
    • Deliverables
    • Work performance data
  • Adaptive approach for executing work
    • Planned work (ex: backlog items that include change requests, defect fixes, and refactoring)
    • Agile metrics (work performance data)
  • Factors-Adaptive Approaches
    • Organizational process assets (OPS): Organizational process assets are used by the performing organization (ex: templates, business plans, processes and policies, protocols, knowledge).
    • Enterprise Environmental Factors (EEF): Internal factors are internal to an organization that can arise from within the organization (ex: templates, frameworks, methodologies). Factors externa to the organization that can enhance, constrain, or have a neutral influence on project outcomes (ex: marketplace conditions, regulatory environment, social and cultural influences, academic research, political climate).
  • What is the primary responsibility of the change control board (CCCB) in the change management process? Reviewing, evaluating, and approving changes.
• Predictive Communications Management

• • The 3 processes associated with communications are plan communications management, manage communications, and monitor communications.
  • There are 2 types of communication blockers: filters and barriers.
    • Communication barriers: poor Internet connection, resistant mindset, acceptance of misinformation as fact, interpersonal conflict
  • 4 Communication Methods
    • Formal written: Project charter, project plans, project reports, and contracts
    • Formal verbal: Presentations, updates, and briefings
    • Informal written: Memos, emails, and notes
    • Informal verbal: Casual conversations
  • Push vs Pull Communication
    • Push: use for high priority information or high priority stakeholders.
    • Pull: use for lower priority information or lower priority stakeholders. Receivers can pull or retrieve communications as they need the information. Senders emit ush communications or disperse information outputs.
• Communications Management Plan

• • Some key elements in the communications management plan:
    • List of process deliverables to be included
    • Escalation procedures
    • List of meetings required
    • Revision procedures
    • Communication requirements analysis
    • Policies for communication
    • Procedures and technologies to be used
    • Glossary
    • Appendix
  • It is not unusual for project managers to spend 90 percent of their time planning, organizing, executing, and managing project communications.
  • Communication is more than talking or sending project status reports. It involves brainstorming, meeting with key stakeholders, creating and communicating project document artifacts, checking for understanding, handling conflicts, and engaging stakeholders.
• Project Controls
  • Project teams use forecasts to consider what might happen in the future. Quantitative forecasts seek to use past information to estimate what will happen in the future.
  • Earned Value Management (EVM) Tools
    • EVM reveals how well the project is adhering to the plan at any given point.
    • Earned value analysis (EVA) is a method that allows the project manager to measure work progress beyond cost and schedule reports.

• • • Cost variance (CV) is a percentage of how much your project is deviating from its schedule. The amount of budget deficit or surplus at a given point in time. CV = EV (earned value) – PV (planned value)
    • Schedule variance (SV) is the difference between the earned value and the planned value. The amount the project is over or under budget. SV = EV -AC (actual cost); >0 ahead of schedule, =0 precisely on schedule, <0 behind schedule
    • Cost performance index (CPI): expressed as the ratio of earned value to actual cost. CPI = EV/AC. <1 over budget, =1 on budget, >1 under budget
  • Estimate at Completion
    • Sum of actual cost to date and estimate to complete. Final cost= costs incurred + cost anticipated. EAC (estimate at completion) =BAC/CPI
  • Estimate to Completion (ETC)
    • Estimate to complete predicts the extra cost to finish the project with current progress and budget. ETC= EAC – AC (actual cost)
  • The expected total cost of completing all work, expressed as the sum of the actual cost to date and the estimate to complete. The cumulative expected cost of the project over time. EAC= BAC/CPI & CPI= EV/AC
  • Expected cost to finish all the remaining project work. Present moment until the end of the project. ETC= EAC-AC
  • Variance at Completion
    • Amount of budget deficit or surplus, expressed as the difference between the budget at completion and the estimate at completion. VAC= BAC-EAC; <0 (not good), >0 (good)

• Managing Risk and Addressing Issues
  • Risk Response Plan
    • Description of each identified risk
    • Its impact on project objectives
    • Prevention or mitigation strategy
    • Any new secondary risk
  • Dealing with Threats Resolved
    • Avoid: Avoid risk by having your project team take action eliminate it or protect from the threat’s impact.
    • Transfer: You transfer risk by shifting ownership of a threat to another party to manage the risk or to bear the impact if it occurs.
    • Mitigate: When you mitigate a threat, you take action to reduce its probability. Timely mitigation is usually more effective than repairing the damage after it occurs.
    • Accept: When you team acknowledges the existence of a threat but decides it’s not worth doing anything about.
    • Escalate: Escalation is appropriate when your project team or project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed authority.
  • Seizing Opportunities
    • Exploit: When you exploit an opportunity, your project team acts to ensure it can extract all possible value from the opportunity.
    • Escalate: Escalation is appropriate when your project team r project sponsor agrees that an opportunity is outside the scope of the project or that the proposed response would exceed your authority.
    • Share: Sharing involves allocating either a portion or all of the ownership of an opportunity to the party that can best take advantage of the opportunity.
    • Enhance: This is when you and your team act to increase the probability of occurrence or the impact of an opportunity As with threats, taking early enhancement action is often more effective than trying to improve the opportunity after it occurs.
    • Accept: As with threats, when you accept an opportunity, you acknowledge its existence but don’t make any plans to take advantage of it.

• • Addressing Issues
    • Issue identification: When we identify an issue, we document it in the issue log.
    • Ownership: Each issue is assigned to an “owner” responsible for resolution.
    • Issue complexity Some issues may involve multiple tasks, but the owner oversees the process.
    • Learning: We link issues back to the original risks, helping us learn and improve for the future.
• Quality Management
  • Process Groups in Quality Management
    • Plan quality management: Planning for quality is an important step. This involves the principle of planning quality rather than performing inspections for quality.
    • Manage quality: This involves carrying out and executing planned quality activities. It’s regularly auditing the project performance to ensure it meets standards.
    • Control quality: This involves monitoring project results to ensure that they meet the relevant quality standards.

• • Cost of Quality Methodology
    • Cost of quality methodology helps you find the optimal balance for investing in quality prevention and appraisal.
      • Prevention costs: Costs incurred to keep away from defects and failures. Help avoid quality problems. Associated with design, implementation, and maintenance of quality management system.
      • Appraisal costs: Costs incurred to determine conformance to quality requirements. Help measure and monitor quality-related activities. Associated with evaluation of purchased materials, processes, products, and services to ensure that they conform to specifications.
      • Internal failure costs: Help with finding and correcting defects before the customer receives the product. Costs incurred when the results of work fail to reach design quality standards.
      • External failure costs: Help with correcting errors found after the product was sent to the customer. If you consider these failures holistically, you need to think about the future of the product after it’s been in operation for months or years, not just at the handover date.
  • The longer a defect remains unattended, the higher goes the cost to rectify it. Same applies for change. The later comes a change, the higher gets the cost to accommodate it.
  • Quality Management Tools
    • Reviews, walkthroughs, and inspections: As a manager, you gather significant data about quality through direct inspection, or first-hand examination of the work or product.
    • Cause-and-effect diagrams: You can us the cause-and-effect diagrams, which are also known as fishbone or Ishikawa diagrams, to find out the root cause of a problem.
    • Pareto principle: It denotes the 80/20 rule. It states that 80 percent of consequences arise due to 20 percent of root causes. If we address the critical 20 percent of the core causes, we can achieve an 80 percent improvement in quality.

• Closing the Project or Phase
  • Closing Project Activities
    • Review customer acceptance of deliverables
    • Ensure a smooth transition to the customer
    • Inform organizational stakeholders and update relevant processes
    • Prepare a final project report
    • Address legal, regulatory, and contractual obligations
    • Archive project information
    • Release and reallocate resources as needed
  • Transition and Benefits Realization
    • Identify a benefits owner for the project
    • Create a plan for transitioning the project
    • Collaborate with business partners to execute the plan
    • Include necessary training and documentation
    • Ensure a successful transition of the product/service
    • Focus on realizing project benefits for the business
  • Knowledge Capture and Transfer
    • Gather technical and tactical knowledge
    • Document team skill improvements
    • Collect valuable insights for current and future teams
    • Conduct a “lessons learned” meeting
    • Ensure active participation and share experiences from all team members

• Stakeholder Process: Stakeholder Management
  • Engaging Stakeholders
    • Assists in identifying the requirements of the various groups
    • Determines how to make sure that the needs of those groups are fulfilled. It’s a key element of the project process and the project manager’s responsibility.
  • Stakeholder Management Processes
    • Identify stakeholders: During this process, you’ll create a stakeholder register and rate them for their positive or negative impact on the project.
    • Stakeholders engaged and involved: Develop a plan for keeping your stakeholders engagement and involved.
    • Monitor and manage stakeholder engagement: Put your plan into action.
  • Levels of Stakeholder Engagement
    • Unaware: The stakeholder is not aware of the project, its advantages, or other consequences, and may even be uninformed that it is a stakeholder.
    • Resistant: The stakeholder is aware of the project, is unhappy with the project objectives, and is resistant to the modifications introduced by the project in its environment.
    • Neutral: The stakeholder is aware of the project and is neither resistant to nor supportive of the project objectives or impact.
    • Supportive: The stakeholder fully understands the project and strongly supports the changes and project conclusion.
    • Leading: The stakeholder is aware of the project and its potential consequences and is willing to be a champion and fully participate in the project’s success.

• Stakeholder Process: Manage and Monitor Stakeholder Engagement
  • Power Interest Matrix

• • • Keep Satisfied: Stakeholders with a high level of power and a low level of interest are important and must be satisfied They can complicate the progress of the project for apparently minor reasons.
    • Manage Closely: Stakeholders who have high power and high level of interest in the project should be actively and closely managed throughout the project life cycle.
    • Monitor: Stakeholders with little interest and impact must not be overlooked. Check them regularly; as the situation changes, they may have an impact on the project in the future.
    • Keep Informed: Stakeholders who have low power, but high interest can play a vital role in creating influence, reducing resistance, and spreading communication.
  • Stakeholder Engagement Strategies
    • Getting stakeholder to participate actively: 1) requires good communication and interpersonal skills, 2) involves identifying an appropriate solution
    • Engaging stakeholders: Getting stakeholders interested in the project.
    • Incentivizing stakeholders: Giving some kind of reward to reluctant stakeholders to encourage participation.
    • Isolating stakeholders: Separating the partner or the stakeholder group that is being the most difficult.

Module 9: Adaptive Approaches

• Agile/Adaptive Mindset
  • Agile Manifesto has 4 principles: 1) We value individuals and interactions over processes and tools; 2) we value working software over comprehensive documentation; 3) we value customer collaboration over contract negotiation; 4) we value responding to change over following a plan.
    • Value 2- value Working Software over Documentation
      • Pros of working software: valuable to end users
      • Pros of documentation: an important component of projects
      • Cons of documentation: can be time-consuming if overdone; shifts focus from the deliverable
      • Implement a lean management style with: low overhead, recordkeeping and authorization, only where needed, and emphasis on project deliverable
    • Value 3 – Customer Collaboration over Contract Negotiation
      • Collaborate with the client to: understand their needs, define their requirements, and provide quality deliverables
    • Value 4 – Responding to Change over Following a Plan
      • Plans should provide a broad direction and guide how to manage changes.

• Structure and Culture of Adaptive Teams

• • Attributes of high perform teams: open communication, shared understanding, shared ownership, trust, collaboration, adaptability, resilience, empowerment, recognition, colocation, limited team size, and experienced members.
  • Predictive approach
    • Distinct team roles
    • Hierarchical, centralized management leadership: project management activities are shared among a project management team; project team members are responsible for completing work.
  • Adaptive approach
    • Cross functional team roles
    • Distributed management and leadership: project team may self-organize to complete a project a team member may serve as a facilitator to enable communication, collaboration, and engagement.

• • Delivery cadence: Stakeholders use timeboxing to work and contribute to the project.
  • Self-organization: Members take on different responsibilities to meet project challenges.
  • Value-based prioritization: Teams decide which tasks to prioritize by focusing on the value each delivers.
  • Iterative and incremental delivery: Customers verify and validate requirements during feedback intervals, and the team adapts development accordingly.
• Servant Leadership
  • Servant leadership is a style of leadership that focuses on understanding and addressing the needs of project team members to maximize their performance.

• • Servant leader behaviors: encourage and develop the team, shield time from diversions, and remove obstacles.
• Requirements for the Adaptive Project Environment
  • Scope are the products, services, and results delivered by the project. The scope can be defined, evolve over time, and be discovered.
  • Scope Decomposition
    • Scope statement: Use a scope statement to identify the major deliverables of a project and the acceptance criteria for each deliverable.
    • Product backlog: The product backlog contains all the features and user stories required for the product.
  • A theme is broken down into epics, features, and user stories
    • Epics: Themes are broken down into epics. Epics are logical containers for a user story. Epics are broken down into features.
    • Features: Features are a set of related requirements described as a short phrase or function. They represent specific behaviors of a product. Each feature has multiple user stories.
    • User stories: A user story is a clear and concise description of a requirement as seen from the end user’s perspective. Details of a user story are fleshed out in the end to avoid wasteful planning.
  • Completion Criteria of a Theme
    • Acceptance or completion criteria: Document all the criteria that should be met before the customer accepts the deliverable or before the project is considered complete in a scope statement.
    • Definition of done: The definition of done is used with adaptive approaches. It is a checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use.
  • Iterations: A timeboxed cycle of a development on a product or deliverable in which all of the work that is needed to deliver value is performed. User stories and tasks are the 2 logical planning units of an iteration.

• • • An iteration planning meeting is used to clarify backlog items, acceptance criteria, and work effort.
      • Backlog items include the product backlog which is an ordered list of user-centric requirement that a team maintains for a product.
      • Story point estimating (work effort) is when project team members may assign relative points of effort required to implement a user story. It implements how difficult a story is in terms of complexity, risks, and effort involved.

• • Retrospective meeting is a lessons-learned meeting to explore and improve both process and product. It’s done to determine if improvements can be made by running experiments or process tailoring. It improves team performance and ensues high quality of processes and the product.
    • Tools used during retrospectives: Miro board or whiteboard (add items under categories, make decisions based on recent iteration) and start/stop or retrospective starfish wheel (categorize work processes and evaluate product development)
  • Iteration vs Sprint Review

• • When to Use An Adaptive Approach
    • Key questions: 1) Are the requirements complex, uncertain, or unlikely to change?; 2) Do you need early feedback from customers?; 3) Is the organization receptive to the necessary flexibility for an adaptive approach?
  • Adaptive/Predictive Selection Criteria
    • Product, service, or result: These criteria use specific attributes of the expected outputs a project generates to help you make a choice.
    • Project: These criteria use specific attributes of the project management configuration to help you make a choice.
    • Organization: These use attributes of the organizational context of a project to help you make a choice.

• The Steps Associated with Adaptive Projects
  • Concept
    • Activities (repeatable): sponsors charter the project after reviewing the business case; create a high-level view of product; acquire talent and build the adaptive team
    • Artifacts (updated discovery): project charter, product vision document, product roadmap, high-level portfolio of requirements
  • Construct and Deliver:
    • Activities (repeatable): plan, construct, and execute iterations; collect requirements and estimate effort; create a prioritized backlog, a timetable for delivering iterations, iteration goals and tasks to complete
    • Artifacts (updated discovery): produce release plan, user stories, product backlog, iteration plan
  • Close:
    • Activities (repeatable): continue delivering benefits; close the project or phase
    • Artifacts (updated discovery): final product
• Adaptive Projects: The Concept Step
  • Vision statement: A summarized, high-level description of the expectations for a product such as target market, users, major benefits, and what differentiates the product from others in the market.
  • A good vision is clear, concise, and actionable and it: summarizes the project with a powerful phrase or short description, describes the best achievable outcome, creates a common, cohesive in project team members’ minds, and inspires passion for the outcome.
  • Vision Statement Format
    • Elevator statement: If you step into an elevator with a key stakeholder, you should be able to tell them the purpose and outcome of the project in 30 seconds.
    • Press release vision statement: Assume that the product is available and describe what a press release should say about it.
    • Product vision board or product datasheet: Answers several questions- 1) what is the project purpose?; 2) what is the target group?; 3) what are the benefits?; 4) what are the achievable outcomes?
  • Product roadmap: A high-level timeline that depicts such things as milestones significant events, reviews, and decision points.
    • The product releases must be easy to understand and abstracted from detail.
    • The roadmap must be flexible.
    • If the product owner seeks to introduce produce releases out of order, that should be possible.
    • Features targeted for a certain release should be able to be moved around.
    • Each release should be able to be done by different teams working simultaneously if it becomes necessary to compress the project timeline.
• Adaptive Projects: Iterative Process

• • Product owner: prioritizes product backlog
  • Iteration: team completes work during iteration; iteration duration is usually around 1-4 weeks; team meets every day for coordination.
  • Iteration review: reviewing the product; reviewing the process
  • Retrospective: team reflects on the experience of working together?; what were the success points?; where the challenges?
  • Acceptance criteria provide clarity about the expectations of a user story. Without them, the development team might be unclear about the outcomes. Balancing user stories and determining the sequences of epics are part of the refinement process but aren’t as immediate as a clear acceptance criteria. Maintaining consistent user stories labels helps with organization but doesn’t directly impact a sprint’s clarity or outcome.
  • User Story Mapping Sessions are specifically designed to break down and detail requirements for upcoming sprints. Quarterly reviews, feedback surveys, and product demos are methods to gather feedback, show product increments, and engage stakeholders but are not specifically designed to gather detailed requirements for an iteration.
• Adaptive Projects: Collecting and Decomposing Requirements

• • Which of the following is part of iteration planning: Reviewing upcoming requirements and reviewing and updating user stories are both part of iteration planning. Selecting key features for a release and decomposing a high-level theme into a feature happen before iteration planning.
• Adaptive Projects: Prioritization
  • Prioritization Schemes
    • Simple Scheme:

• • • MoSCoW Prioritization Scheme:

• • • Dot Voting or Multi-Voting Scheme:

• • • Buy a Feature:

• • • Kano Model: The X axis is functionality and the Y axis is customer satisfaction.

• • • Stack Ranking:

• • Project Artifacts
    • Product Backlog: The product owner develops the product backlog at the product level. The product owner identifies high-value user stories. The team includes the selected features in the first release.
    • Release Backlog: Product owner identifies features to be implemented for a release. Product owner priorities features to build minimum viable product.
    • Sprint Backlog: Team establishes the priority of work items. Interdependent items can constrain the priority order.
    • Scrum Tasks: Developers sequence daily tasks in a chosen order.

• Adaptive Projects: Developing a Release Plan
  • The adaptive approach to planning: 1) adapts to changing user requirements, 2) focuses on delivering the most valuable features, and 3) identifies the fewest number of usable and functional features.
  • Minimum viable product: A concept used to define the scope of the first release of a solution to customers by identifying the fewest number of features or requirements that would deliver value.
  • Methods to estimate adaptive projects:
    • Absolute estimate: explicit actual quantities (ex: prototype will take 100 hours to complete)
    • Relative estimate: applicable within a given context
    • Story point: comparative values for relative estimation (not an actual unit of measurement)
• Adaptive Projects: The Close Step
  • Release the project personnel.
  • Review whether the deliverables achieved the intended benefits, value, and vision.
• An Overview of Adaptive Frameworks
  • Some of the common adaptive frameworks are:
    • Lean: a mindset of for increasing efficiency in production processes and reducing waste.
    • Scum: has 3 components – accountabilities, events and artifacts
      • Accountabilities: used to be referred to as roles, are the participants who create the project outputs. For example: scrum master
      • Events: Event are the various actions to be carried out by the roles. For example: spring review.
      • Artifacts: The documents developed the roles during the execution of the project. For example: product backlog

• • • Kanban: Kanban means card you can see or visual board or sign. It helps to manage the work in progress and improve project workflow. Kanban boards help reduce bottlenecks, improve efficiency, and increase quality.

• • • Extreme Programming (XP): Iterative, incremental and timeboxed. Involves actual customers, collocated teams, user stories, and standups.

• • • • Slack: the team allocates time for other activities that are not related to deliverables.
      • Test first: Before coding, developers create a test that will prove that unit of work is technically correct.
      • Continuous integration: Product increments are integrated continuously, so that no increment can cause product failure.
      • 10 Minute Build: The team automates their build process so it executes in less than 10 minutes.
      • Quarterly planning: The team plans ahead for the upcoming release.
      • Weekly iterations: The weekly cycles build the incremental design.
      • User stories: These describe the requirements from customers’ perspectives.
      • Pair programming: A pair of developers share a single machine to collaborate on tasks.
      • Colocation: All team members, including the product owner, sit together in one locations as a whole team.
      • Informative Workspace: The work area promotes transparent communication.
      • Sustainable pace: The team avoid excessive stress at work and overtime.
    • Feature-driven, dynamic, and crystal frameworks: Implements features large projects. Supports best agile practices.
      • The goal of feature-driven development is to deliver client-valued functionality, or “features first.”

• • Eliminating Waste steps
    • Identify value: consider the customer perspective when you identify value. It is not the lean or project team that specifies the value.
    • Study the value stream: A value stream is all the actions taken to deliver a product, from the initiation phase through product launch. It begins and ends with a customer.
    • Investigate waste in the flow: Eliminate waste in the flow by removing non-value-adding steps and focusing on essential value-adding or value-enabling steps.
    • Streamline the process for agility: Consider customer priorities to optimize delivery.
    • Perform continuous improvement: Evaluate the flow and activities constantly.

Module 10: Measurement Tracking and Managing Uncertainty

• Conditions Associated with Uncertainty
  • Ambiguity: Ambiguity exists when there is contradictory or missing information, conflict, or changes to scope, timeline, team, or stakeholder expectations, etc.
  • Complexity: Complexity can exist when a project is difficult to understand, foresee, and keep under control even with reasonably complete information about the project system.
  • Volatility: Volatility occurs when a project changes quickly and in unpredictable ways. Volatility usually impacts project cost and schedule.

• Opportunity and Threats Related to Uncertainty
  • Dealing with Opportunities
    • Exploit: Extract all possible value from the opportunity.
    • Escalate: Escalate an opportunity when your project team or project sponsor agrees that an opportunity is outside the scope of the project or that the proposed response would exceed your authority.
    • Share: Allocate either a portion or all of the ownership of an opportunity to a party that is best able to take advantage of the opportunity.
    • Enhance: Increase the probability of occurrence or impact of an opportunity. Taking early enhancement action is often more effective than trying to optimize improve the opportunity after it occurs.
    • Accept: Acknowledge the existence of an opportunity, but don’t make any plans to take advantage of it.
  • Dealing with Threats
    • Avoid: Eliminate the threat or protect your project from its impact.
    • Transfer: Transfer a threat by shifting ownership of the threat to another party to either manage or bear the impact if the threat occurs.
    • Mitigate: To mitigate a threat, take action to reduce its probability. Early mitigation action is more effective than repairing the damage after it occurs.
    • Accept: Acknowledge the existence of a threat but decide not to do anything about it.
    • Escalate: Escalate a threat when your project team or project sponsor agrees that the threat is outside the scope of the project or that the proposed response would exceed your authority.
• Detect and Resolve Problems on Adaptive Projects
  • Resolving Problems Steps
    • Understand the problem: The project team must clearly state the problem before they resolve it.
    • Measure the problem: Assess the impact of the problem and identify root causes.
    • Devise a plan: After you have obtained data and insight to solve the problem, you need to develop a plan to manage the problem.
    • Resolve the problem: Use your plan to resolve the problem. The plan should have clear objectives and measurable targets.
    • Check the resolution: Measure the effectiveness of the plan, check if the problem has been resolved or mitigated as expected.
  • The cause-and-effect diagram is used to determine the root cause of a problem, not to address its severity.
• Measuring Performance: Metrics
  • Lagging metrics help evaluate whether we met our objective. Leading metrics give us a valuable view of the future.
  • Effective Metrics
    • Smart: Specific clearly defines what the expected outcome needs to be.
    • Measurable: Measurable states the criteria you will use to evaluate progress and results.
    • Achievable: Achievable asks whether the people assigned have the necessary resources, tools, or skills to get the job done.
    • Relevant: Relevant asks whether the metric accurately measures the team’s performance.
    • Timely: Timely states the amount of time needed to get the work done, stating the start and end date to achieve the result.
  • Main Benefits of Agile Metrics
    • Tracking progress
    • Supporting decision-making
• Documenting Controls
  • To document controls, you can use: product backlog, definition of done (DoD), definition of ready (DoR), and Kanban board
  • The product backlog describes the features, changes, bug fixes, infrastructure changes, or other activities a team may deliver to achieve a specific outcome. It is the single authoritative source for things that a team works on. The presence of a product backlog item on a product backlog does not guarantee that it will be delivered.
  • The definition of ready (DoR) is a set of criteria that must be met before a user story or task can be considered “ready” for development. A spring or iteration transforms the selected items that meet the Definition of Ready into increments that satisfy the Definition of Done.
    • The acronym INVEST helps us to remember a widely accepted set of criteria, or checklist to assess the quality of a user story
    • INVEST: independent (of all others), negotiable (not a specific contract for features), valuable (or vertical), estimable (to a good approximation), small (to fit within an iteration), testable (in principle, even if there isn’t a test for it yet)
  • Definition of Done is a set of criteria that must ensure all work is complete and meets necessary quality standards before it can be released. Even though the definition of done might vary, the team should agree on the definition to eliminate surprises or changes.
  • Kanban board is a visual control for work items that shows state, progress, and work-in-progress (WIP) limits. Kanban boards are used to control WIP. When teams juggle between multiple tasks, they waste a lot of time, become inefficient, and don’t get much work done.
  • Projects using an iterative approach need to close phases and projects just as predictive projects do.
  • Instead of signing a contract, the product owner may verbally approve a release roadmap or product backlog. The customer or sponsor often verbally confirms the delivery and formal acceptance of deliverables. If the demonstrated functionality meets the stakeholder needs, then a verbal approval is issued.
  • Adaptive projects more frequently capture similar lessons learned information in retrospectives. For adaptive projects, conduct retrospectives at the end of each iteration or sprint and capture what “went well,” “what could have gone better,” and suggestions for improvements and experiments to run in the next iteration or sprint.
• Information Radiators
  • A type of visual control that displays project information that conveys key information to all team members. Also known as “big visible charts,” they ensure everyone on the team has access to updated information at all times, thus facilitating transparency and preventing miscommunication. Whiteboards, posers, easel pads, giant TV monitors – these are all examples of media that teams use as information radiators.
    • An information radiator visually displays key project information so people won’t need to ask for information.
    • An information radiator should show whether the team is on track, behind, or ahead on completing their work.
• Communicating Adaptive Project Metrics
  • Adaptive project metrics can be communicated using:
    • Burndown chart: highlights pending work. Shows the amount of work that has been completed in an epic or a sprint and the total work remaining. Burnup charts are used by teams to monitor performance and team progress.
      • Advantages: sed to manage the team’s time, helps to avoid surprises at the end of the iteration, motivates eh team to work at a continuous and sustainable pace
      • Disadvantages: Does not separate the impact of changes in scope from rates of progress.

• • • • The ideal work time (dashed line) shows the rate at which the team should complete tasks by the end of the iteration.
    • Burn up chart: Release burn up charts show the work that’s been completed.
      • Advantages: Monitor performance and team progress. View scope increases and actual team progress.
      • Disadvantages: Show only part of the total picture; do not show tasks in progress.

• • • Velocity chart: measures quantity of work done during each iteration. It is normally measured in points. Velocity is applied by teams to project their schedules. For example: Total backlog=400, velocity=40 & iterations=10
      • Advantages: Velocity is a simple way to project schedules and costs.
      • Disadvantages: Velocity is easy to manipulate because points are manually identified. Points cannot be easily compared across teams, as each teams sets its unique velocity.

• • • • Velocity rates are specific to teams because each team uses its own measurement scale to estimate the story points.
    • Cumulative flow diagram: Show 3 distinct contours representing work at different stages of completion. They are used to visualize the team effort over time; analyze the stability of a workflow; and understand project issues, cycle times, and completion dates.
  • Throughput: It helps measure the team’s productivity. Throughput refers to the numbers of unit produced during a specific interval.
    • Example: If a company can manufacture 80 cars during an 8 hour shift, the manufacturing process generates a throughput of 10 cars per hour.
  • Cycle Times
    • To control cycle and lead times, you should be able to monitor them and control the tasks associated with them. Cycle time is the amount of time it takes to complete a task.
      • Control charts: Control charts are used to monitor cycle times, and they can reveal possible productivity improvements and problems in execution processes. They can account for cycle times in single projects or across projects, and they can be used to compare productivity between teams if the tasks are relatively similar.
      • Lead time: Lead time is a direct function of how many tasks are entering the system and how often. Lead time is the duration between the start and completion of a process. For example, during times when many tasks are entering a system, the lead time for a single task will increase because the likelihood that tasks are waiting for execution is increasing. Monitoring and controlling lead time helps to balance the system’s capacity for executing tasks. When lead time increases, it could be a sign that the system’s capacity for the current demand is not sufficient.
      • Throughput: The cycle time is closely associated with work in progress, which is a count of all started tasks that have not yet been finished. Limiting the numbers of tasks in the system can ensure better throughout. A good example of the concept of throughput is street or highway lanes dedicated to buses or other high occupancy vehicles.
  • Leading indicator: measures activity or other factors that have occurred in the past.
  • Leading indicator: a trend line or predictor of future performance.
• Risk and Change in Adaptive Projects
  • PESTLE tool: Consider the political, economic, social, technological, legal, environmental, and competitive issues that can tug at a project’s effectiveness.
  • Conditions leading to uncertainty: project complexity, system dynamics, time pressure, technological novelty, and uniqueness
• Tracking and Managing Risk in Adaptive Projects
  • Adaptive approaches are used in situations of high uncertainty and with high variability in the project scope.
  • Adaptive teams use daily coordination meetings (previously known as daily standups) to share information between team members.
  • Risk Severity= Impact x Probability

• • Conditions of uncertainty can create risk.