Dashboards provide high-level summaries for executives

This plan outlines how, when, and to whom information is distributed

Analogous estimating uses historical data for high-level cost predictions

CPI = EV/AC = 30,000/30,000/40,000 = 0.75 (Over budget).

Fast-Tracking overlaps tasks to compress the schedule (may increase risk).

Control Scope ensures only approved changes are implemented.

This matrix categorizes stakeholders based on their current vs. desired engagement levels.

Stakeholder registers track roles, influence, and communication needs.

The project charter formally authorizes the project and grants the PM authority to allocate resources.

Requirements validation is a precursor to successful product delivery, because validated requirements record exactly what stakeholders want done. This information is used by the project team to complete the work. Through ongoing collaboration with stakeholders and continuous refinement of the user stories on the product backlog, the connection between the work performed and the various requirements is maintained. The project team knows when the work is complete and meets the validated requirements by referring to the listed acceptance criteria and definition of done (DoD). The refinement of user stories on the product backlog, if it happens continuously throughout the iterations of the project, will help to reduce any chance of variance from the quality, stakeholder, business, or other requirements.

The use of a quality audit will provide verification of the process, not the product. Verification is a process by which the business analyst reviews the requirements or other product information for errors, conflicts, and adherence to quality standards. A product demo and user acceptance testing (UAT) can be parts of quality checking, but the UAT is typically done at the end of the project.

The burnup chart shows the progress over time in story points, displaying the actual work completed. The product roadmap tells the story of the product vision at a high level and is used for planning purposes. The business analyst seems to be comparing the product vision with what has been completed thus far, perhaps to help set priorities for what should be done next.

If a product owner places a user story on the product backlog, that user story is intended to be developed as part of the project.

User stories discussed or considered during an iteration review are not yet approved. An iteration review, also known as a sprint review, is a meeting held at the end of an iteration to demonstrate the work that was accomplished during that period. This meeting is crucial for assessing progress, gathering feedback, and planning future work. Teams will discuss any number of user stories during an iteration review, but they only commit to developing it when it appears on the product backlog. Likewise, even if a stakeholder approves a user story, it is still the product owner’s decision to select the story for development. The complexity value of the story is not relevant to whether it is selected for the project.

Stakeholder collaboration is the best practice for requirements gathering. This approach emphasizes the importance of involving all relevant parties to ensure the requirements capture the actual needs and objectives of the project or initiative. Stakeholder buy-in is often essential to project success.

The business need for a project indicates what can solve a problem or enhance an aspect of a business. In addition to requirements provided by named stakeholders and business requirements, a business analyst should consider market demands, legal demands, and technological advances.

Best practices and organizational structure are organizational process assets (OPAs) that are assumed in the context of a business case.

Nobody knows the length of the first iteration, so the project team just needs to pick a duration and see how it works. If anyone external to the project team decides, the team loses autonomy and self-management. Agile teams make decisions on their way of working—including iteration length—and can adjust the cadence if necessary.

Setting up a separate meeting is the best option for two reasons. First, only two team members are involved in the issue and second, the daily coordination meeting is not supposed to accommodate conflict management or issue resolution and should be kept within its timebox.

Waiting until the next retrospective session is not a good idea, since issues need to be resolved as soon as possible. Remember that waiting is a waste to be avoided in agile projects. Finally, asking the team to work on something else won't make the roadblock disappear on its own. The situation needs to be faced, discussed, and resolved.

Throughput analysis assesses the number of items being completed in a fixed timeframe. Ideally, agile teams should not multitask and dedicate their full support to a single project.

While colocation increases the productivity of team members, the product manager’s work does not count toward throughput. Even if the product backlog is well-defined or the scope is stable and no changes are requested, throughput is a metric about execution and is therefore related to how well work is executed, not planned.

An adaptive approach is beneficial for developing an experimental product because it enables the continuous feedback needed to guide the product roadmap or showing the way forward toward project success. Collaboration in general with stakeholders is essential to developing a viable product. Since the technology is new, we can expect that acceptance criteria would be unknown or incomplete. Acceptance criteria are a set of conditions that is required to be met before deliverables are accepted. In business analysis, acceptance criteria are built to evaluate the product requirements and solution. Acceptance criteria provide a basis for shared understanding among stakeholders about what constitutes a successful outcome for a project or a specific deliverable. The material is unknown, so the team will need to perform ongoing tests until the product meets stakeholder requirements.

The need for documentation should not be a criterion to determine which strategy to adopt to manage the project, since any project management approach is capable of creating documentation in a project. Likewise, the product owner’s risk appetite would not be a deciding factor in the team’s decision on their way of working.

The most appropriate project approach is an adaptive one. The project needs to be able to adapt quickly to changes in the requirements but also needs to meet the timeline. An adaptive approach is more appropriate for this project because it is built for the purpose of progressing scope in line with requested changes.

A predictive approach is not appropriate for this project, because the change control process may not be able to respond to changes quickly enough. The requirements for the software application are likely to change, and a predictive approach will not be able to adapt to these changes in time.

A Gantt chart is a type of bar chart that illustrates a project schedule and includes milestones. The project schedule network diagram is a graphical representation of the logical relationships, also referred to as dependencies, among the project schedule activities.

Kanban boards are task boards used for organizing work into logical tasks. A resource calendar documents the availability of project resources. A Pareto chart (also called the 80/20 chart) helps to identify the highest priority task in a long list.

A potential problem with adding more team members to a project team is communications failure. This can be adjusted by increasing the number of channels in the communications management plan.

The technology should not need to be updated. The new stakeholders should be added to the stakeholder engagement plan, but this will not necessarily ensure these stakeholders are included and able to communicate with one another and the project team as needed. That planning and management is performed in the communications management plan.

Project managers use the communications channel formula to manage the challenge of expanded communications in a numerical way. The communications channel formula is:

Number of communications channels = N × (N – 1)/2

Where N = Number of project stakeholders

The number of people on the project makes communications a challenge. Neither the budget size nor the technical complexity poses the greatest communications challenge. The more people we involve, the harder it is to communicate about our budget and technology.

The requirements traceability matrix allows a project manager and business analyst to map the product requirements from the original requirement—for example, the user product specification—through the development process and to the final deliverable.

A quality management plan is the component of the program or project management plan that describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives. The work breakdown structure (WBS) will show the total scope of work. These tools will be useful but you still need to use a tool that tracks fulfillment of the objectives. Finally, the release plan sets expectations for the dates, features, and/or outcomes expected to be delivered over the course of multiple iterations and is not used in predictive planning.

Project managers using predictive development approaches decompose the project scope into a work breakdown structure (WBS). The WBS identifies the full level of effort required for a project and arranges it in a hierarchical structure.

A schedule, no matter how detailed, will not be able to portray the full level of effort, or work required, to complete a project. Stakeholder collaboration is also required to understand the scope of a project, but the collaboration is only part of the work needed to decompose the work on a project. Earned value analysis (EVA) is an important tool that combines the cost, schedule, and scope factors to measure and evaluate the progress on the project work, but only after this information has been determined in the WBS.

Using three-point estimating—averaging the duration of the most likely, optimistic, and pessimistic scenarios—can help define an approximate range for an activity’s duration or time that it will take to complete the work.

When planning for risk responses a team would use expert judgment, critical thinking, and brainstorming. Contract management requires leadership, great communication skills with vendors and procurement, and knowledge of contract types and particulars. Resource leveling is a tool used for assigning people to work in consideration of compression of project duration or optimizing a schedule. Three-point estimating is not helpful in this task.

Because requirements should be as clear as possible, the project manager and business analyst need to keep working with these stakeholders to decide what to prioritize. Methods for collaboration and prioritization include multicriteria and MoSCoW (must have, should have, could have, won’t have) analyses and voting. The cause-and-effect diagram is used to discover the root causes of an issue. A RACI (responsible, accountable, consulted, informed) matrix is used to document roles and responsibilities on a project.

The team should look in the risk register. The risk register is a comprehensive document that records the details of all identified individual risks to a project. This document includes information about the person responsible for managing the risk, probability, impact, risk score, planned risk responses, risk categories, risk triggers, and timing information. Secondary risks arise as a direct result of implementing a risk response. Once a set of risk responses has been developed, it should be reviewed to see whether the planned responses have added any secondary risks. Residual risks are risks that remain after risk responses have been implemented. The review should also assess the residual risk that will remain once the response actions have been executed.

A risk management plan is a comprehensive document that outlines how risks will be identified, analyzed, responded to, monitored, and controlled throughout the project. This document includes ground rules, procedures, roles, responsibilities, risk categories, tolerance levels, and communication strategies to ensure effective risk management and project success. The risk management plan will contain the details of the processes the team will use to perform various risk management activities, including tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project. We can use a risk matrix to assess and prioritize risks based on their probability of occurrence and the impact they may have on the project. The risk matrix is typically represented as a grid where risks are plotted according to these two dimensions, helping project managers decide which risks need to be managed and which can be ignored. A risk breakdown structure is a hierarchical framework used in project management to identify and categorize potential sources of risk. This framework helps project managers systematically break down and analyze risks, ensuring comprehensive risk identification and management.

Conflict management is an essential interpersonal and problem-solving skill for project professionals and requires emotional intelligence (EI). Conflict happens in all projects and can involve any number of people. Projects operate in dynamic environments and face many mutually exclusive constraints, including budget, scope, schedule, and quality, which can lead to conflicts. It is common to want to avoid conflict, but not all conflict is negative. How conflict is handled can either lead to more conflict or better decision-making and stronger solutions. Addressing conflict before it escalates beyond useful debate leads to better outcomes, but intervention is not always necessary. Outcomes of conflicts are handled at the project manager’s discretion but if they are recorded in a project artifact, it should probably be in the lessons learned.

The project sponsor establishes the project vision and goals. The project sponsor also communicates the vision, goals, and expectations to the team; advocates for the project and the team; and keep projects aligned with business objectives.

The project manager facilitates execution of the project vision and goals to realize the project sponsor’s vision. While a key stakeholder plays a crucial role in ensuring a project's success, their role is about supporting achievement of the established vision and goals. The business analyst role connects the business with the project team or those who provide the required solution to the business’s requirements and needs.

A key skill of a project manager is to communicate effectively with stakeholders. A communications management plan is a document that describes how the project information will be communicated to the stakeholders, as well as the frequency, format, and content of the communication.

A stakeholder register identifies and analyzes the project stakeholders, including their roles, interests, expectations, and influence. A stakeholder engagement plan identifies the strategies and actions required to promote productive involvement of stakeholders in program and project decision-making and execution. A RACI (responsible, accountable, consulted, informed) matrix will delineate the roles and responsibilities of project team members and stakeholders but it is not intended to explain their communication preferences.

The stakeholder engagement plan is a strategic document that outlines how to effectively engage stakeholders throughout the life cycle of a program or project. The stakeholder engagement plan, therefore, can guide a project manager and team in how to work effectively with project stakeholders to achieve the desired participation levels for the project. Stakeholders include the customer or client, so effective engagement with these stakeholders is essential to the health and outcome of a project.

The team member’s alert about the weather calls attention to a potential risk, and the budget limitation represents a constraint. The likelihood of bad weather is based on weather forecasts and scientific predictions, so we can consider this a situation that should be planned for by using the risk register. A constraint is a limiting factor that affects the execution of a project, program, or portfolio. For now, the client’s budget limitation is a constraint we should be aware of. If it negatively affects the project, it may become an issue.

Assumptions are beliefs or statements taken for granted without proof. An issue is a realized risk or a problem that occurs in a project and that the team needs to take action on right away. Neither the future nor likely bad weather or budget limitation are issues right now.

A purpose alignment model provides a framework to support strategic or product decision- making. The framework is used to categorize options by aligning them with the business purpose they support. The model helps a product team link business strategy to product strategy.

A business analyst uses gap analysis to identify the differences between the current state and the desired future state of a business process, system, or organization. Therefore, it is too broad of an instrument to determine the value of a specific feature. Prioritization is a method of ranking options by factors such as value, complexity, or importance. Benchmarking allows us to compare our product or project with another that has established values or metrics. This comparison helps identify best practices and areas for improvement.