The root problem is that impactful information in the agile team was NOT passed to the predictive team in time to prevent the malfunction. Broadcasting retrospective lessons learned is the best way to reach the broadest group in a timely way.

Agile adoption is enabled through communicating and demonstrating its benefits.

In this case, the client needs to be aware of the impact of the recent plug-in issue on business and costs.

The first principle of the Agile Manifesto focuses on value: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Markets are driven by the value consumers attribute to the offerings. The team needs to focus on understanding the value consumers seek and the value competitors offer in order to product successful recommendations.

Frequent release of smaller incremental products is the fastest way to get return on investment. MMFs are ready for public launch, whereas MVPs are releases that are just able to function. Reducing the team would NOT enable acceleration of value, as is required in this case.

The Definition of Ready and user value ranking in the backlog address the root problem, which is that the team is NOT focusing on value.

The client says the final product MAY NOT be acceptable, so, the project manager should review the acceptance criteria with the client to see if anything was missed and to get an understanding of why the client thinks the product MAY NOT be acceptable. Satisfying all acceptance criteria implies the needs of the stakeholder have been met.

The feasibility study will support the business case to begin a new project.

To ensure that the deliverables are realistic, the project manager needs to conduct a feasibility study and then evaluate the results. NONE of the other choices will ensure realistic deliverables.

The business case and project goals need to be understood first before a charter can be written. Building a team and a schedule come later in the process.

The project charter is one of the most important project documents. It defines many aspects of the project which are critical to the new project manager’s understanding of the project strategy, as well as the tactical execution. Any actions taken before reading the official project charter will NOT be informed with this critical information.

Without validating compliance of the solution before developing it, the team would waste effort at best, and at worst, put the organization at risk of non-compliance penalties. NOT initially seeking approval from the steering committee is in line with agile practices of communicating directly between units rather than through management layers.

A foundational assumption to release the product has become a “show-stopper”. Marginal economic analysis determines if there is a viable way forward. Identifying minimal releasable features can mitigate the economic loss.

The project has contractually committed to deliver infrastructure to the customer.  Failure to account for the embargo is the fault of the vendor, NOT the client. Adding an agile track is the only choice which can fulfil the committed deliverables. Accepting penalties without attempting to fulfil commitments is bad business practice; adding layers of insurance or contingency to mitigate risk will lead to further cost penalties.

The agile track is correct because a launch project would include time-sensitive milestones, thus the work is more suited to waterfall. However, the compliance work should run concurrently with gathering more information to support the launch.

The context of this scenario requires the project manager to influence the organization (sponsor) and recommend next steps after reviewing and understanding compliance requirements and consequences.

Clearly documenting how key requirements have been met is a great way to ensure quality and identify any gaps that need to be addressed.

Checking with your trusted legal representative is the best first step before going to the CCB, because the project is in a highly regulated industry.

This new law can have a profound effect on the project. It will certainly lead to new potential risks, new assumptions, and a possible charter change.

Since compliance is mandatory and it impacts scope, schedule, and cost, a change request needs to be submitted. Other possible actions are updating the issue log and escalating the issue to senior management to find a timely workaround, which could eventually be resolved as a change. Because compliance is required by law, the risk CANNOT be avoided. At this stage, updating the project management plan is NOT a corrective action.

Five (5) sprints can cover the ten (10) week window, and flexibility gives the best chance to complete work in an ad-hoc manner.

Continuous and incremental customer/user feedback is the best way to ensure that the product addresses identified and non-identified needs throughout its development.

In the Close Project or Phase process, the project team formally transitions the final product, service, or result to the production support team. The receiving group signs documentation, agreeing to accept the final product, service, or result. Once signed, the owner is responsible for changes, adjustments and resolving technical issues.

When closing the project, the project manager reviews the project management plan to ensure that all project work is completed and that the project has met its objectives. The project documents are updated accordingly. In this case, those documents are the final report, project document updates, and organizational process assets updates.

Project closure and hand-off will ensure knowledge transfer to production and/or operations.

Project closure guidelines or requirements will contain the organization’s procedures to follow.

Accepted deliverables that were formally signed off by the customer or sponsor during scope validation are then forwarded to the Close Project or Phase process. Formal documentation is then signed by the customer or sponsor acknowledging final acceptance of the project’s deliverables.

During project close out, lessons learned and knowledge gained throughout the project are transferred to the lessons learned repository for use by future projects.

The retrospective is used to review lessons learned and suggest corrective actions for the next iterations.

The lessons learned repository must be present throughout the project, using different facilitating techniques.

The project manager needs to be proactive and review the activities with the team members and identify resolution strategies.

Update the issue log to reflect resolution of the issue. Then update lessons learned register about potential risks for future projects.

After a new compliance issue is raised, the issue log should be reviewed and updated, as needed, prior to taking action.

Stakeholder resistance was anticipated and multiple risk responses are likely to exist, so reviewing the risk register is the correct response. Agile planning would enable frequent retrospectives to refine the risk responses, which could be more flexible than a fully predictive response.

The root problem is that impactful information in the agile team was NOT passed to the predictive team in time to prevent the malfunction. Broadcasting retrospective lessons learned is the best way to reach the broadest group in a timely way.

Iterations based on time and materials is the best approach, because it enables the team to expand the project without delaying the project start. The agile iterations can act as placeholders for an unknown volume of work.

A predictive approach within agile processes is correct because the deployments follow an unchanging sequence. Maximizing deployments would require handling as many parallel deployments as possible given a set of changing conditions processed in an agile way.

Development and operations collaboration (early and constant) and automation of both domains is at the heart of DevOps. Virtualization and machine learning are enablers of efficiency but NOT DevOps methods. Development testing on deployment sites is impractical and inefficient.

In this project, two (2) deliverables have unknown durations or changing requirement sets—both of which are appropriate conditions for use of the agile life cycle. Deliverable 2 requires strict schedule control and external dependencies, which require a traditional or waterfall project life cycle.

If NO historical information is available, then consulting with subject matter experts is the next best thing a project manager can do to prepare the project plan.

Benchmarking should be used to identify best practices.

Common visibility of work in progress would enable better aligned work planning. Common milestones and dependency integration across the two tracks will promote synchronized delivery. The other approaches are wrong because story size should always be as low as possible; agile progress should NOT be reduced to match the predictive schedule, otherwise the project would have to be fully predictive; and the nature of a strictly sequential, predictive IT workflow is NOT compatible with software development needs.

A contract is a mutually binding agreement that obligates the seller to provide the specified products, services, or results; obligates the buyer to compensate the seller; and represents a legal relationship that is subject to remedy in the courts.

A contract is a mutually binding agreement that obligates the seller to provide the specified products, services, or results; obligates the buyer to compensate the seller; and represents a legal relationship that is subject to remedy in the courts.

A bidder conference is a meeting between the buyer and prospective service providers prior to proposal submittal. Conferences ensure that all prospective bidders have a clear and common understanding of the procurement, and NO bidders receive preferential treatment.

The procurement management plan needs to be updated, since it captures the process of documenting project procurement decisions, specifying the approach, and identifying potential sellers. The key benefit of this process is determining whether to acquire goods and services from outside the project and, if so, what to acquire as well as how and when to acquire it.

The Definition of Ready is updated to ensure that the ML output triggers the agile team’s analysis. The risk register is updated to plan for risks relating to adapting and learning new technology and ways of working. The resource management plan is updated because the machines running the ML routines are resources necessary to complete the work.

Two (2) launch workstreams will need to run in parallel to avoid delay to the non-EU launch. Lack of known requirements makes it impossible to plan the EU launch with a predictive approach. Existing milestones must be maintained to avoid loss.

Submitting a change request starts the Perform Integrated Change Control process. Once the change request is submitted, the project manager and team analyze the impact of the change to the project and can verify whether an element in the product actually does lead to health issues in customers. Whatever it is, the issue or concern should be investigated first before taking action.

Following the formal change control process is the best way to control unnecessary project changes.

You need to analyze and understand impacts of any change to the project before submitting the change to the change control board. A change control board relies on the project manager to provide all available information for effective decision making.

The project manager first needs to understand what impact (if any) this absence will have on the project, before taking any action.

The change management plan is a component of the project management plan that establishes the change control board, documents the extent of its authority, and describes how the change control system will be implemented.

Every documented change request needs to be either approved, deferred, or rejected by a responsible individual, usually the project sponsor or project manager. The responsible individual will be identified in the project management plan or by the organizational procedures. When required, the Perform Integrated Change Control process includes a change control board (CCB), which is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project and for recording and communicating such decisions. Customer or sponsor approval may be required for certain change requests after CCB approval, unless they are part of the CCB.

Agile favors obtaining direct and practical/actual user feedback over formal data collection processes or competitor analysis.

The spike is correct because items should be sufficiently researched to determine the best way to deliver business value and phrase sufficiently detailed, testable stories.

The objective of user tests is to provide the earliest possible input to adjust the product to user needs. Thus, a large amount of negative input is a success because it enables a large amount of improvement faster.

Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and/or analysis of risk response alternatives. These changes can require adjustments to the project management plan and other project documents.

Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result.

This is a case in which basic product characteristics may be affected by the change and might not be captured in the product vision. The product owner is responsible for shaping the product in collaboration with stakeholders.

Some agile teams want to favor faster progress by completing less complex stories before more complex ones. Prioritization of backlog should be value-based, not speed-based.

The scope management plan provides details on how project and product scope will be defined, validated, and controlled. It is needed to help control the scope of the project.

The scope management plan documents how the project and product scope will be defined, developed, monitored, controlled, and validated. The key benefit of this document is that it provides guidance and direction on how scope will be managed throughout the project.

The scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated.

The 100% rule states that any work package in the WBS should consist of 100% of all work for that work package. Since the WBS is a work package itself (the project), and since the WBS should contain only work packages that are in-scope, any missing work packages should be added to the WBS and recalculated.

Experts are a source of experience and knowledge. Given the increased risks of a new and potentially complex market, using expert judgement is recommended. Prototypes are an excellent way to gain a better understanding of the product and to gather requirements.

The Definition of Done lists all criteria that must be met to consider a task/story completed.

The main problem is high context-switching when working on multiple teams, which is resolved by 100% dedicated teams. Root-cause analysis would pinpoint this and other problems to address.

Behavior-Driven Development is an extension of Test-Driven Development whereby automated tests and simulations are created before developing the product. Flaws are discovered by forcing the tests to fail before producing the unit in a way that will pass the tests.

Specific acceptance criteria should be defined and checked in the Definition of Ready of any impacted item before estimation to ensure all effort is accounted for.

TDD ensures a quality standard before development, but continuous user input is the most important to determine the target.

The new project manager needs to consult with the senior project manager to find out what practices and processes are already in place.

Statistical sampling involves choosing part of a population of interest for inspection—for example, selecting 10 engineering drawings at random from a list of 75. The sample is taken to measure controls and verify quality. Sample frequency and sizes should be determined during the Plan Quality Management process.

This team has decided together to continue prioritizing their work and offering a way to share their successful ways of working with the organization by inviting others to attend their retrospectives. They did not have to agree to the portfolio manager’s suggestion, although it seemed to be a genuine improvement measure for the organization. Quite legitimately, because their environments can be very fast-paced and busy, agile teams need to ensure their work is conducted at a sustainable pace. Protecting their team’s time and space, ideating, voting, and offering a way to share their success with others in the organization—all demonstrate their agile mindset and values.

This agile event or ceremony is a product demo or review meeting, where the core features and capabilities of a product are demonstrated to customers. These happen during testing intervals, which fits the description in the scenario. It is neither a standup, which happens daily, nor a team conversation, which would indicate a retrospective. A scrum of scrums is a meeting of several teams together.

In this case, the project manager should understand the estimated cost of the work that needs to be done before conducting procurement, so that there is a baseline for comparison when the bids are submitted. The only way to do this is by obtaining an independent estimate first. Then hosting a bidder conference can help ensure that any vendor bidding on the project has all the information they need and is able to ask questions before submitting a viable bid for consideration. Whether bids are submitted by knowledgeable vendors with accurate estimates or budgets or not, the project manager needs to know the approximate cost of the work.

Even though a change can negatively affect or distract from a project’s goals, if a powerful and influential stakeholder insists on it, the change must be taken seriously. Hence the work should be done as required by the company owner, despite the delay and cost involved. Execute this change like any other by submitting a change request and obtaining approval from the change control board (CCB) after determining the cost and time required for the change.

Because this is a serious design flaw that impacts product quality and project success, it must be rectified. The best approach is to obtain change request approval for the execution of the missing work.

A project manager has a good understanding of the project team and stakeholders for this project and is now ready to establish the project management framework. This is the next step in the project and, through servant leadership, can show the team how it is done, which will also satisfy the stakeholders. The other tasks should also be performed, but the first step for the project manager to complete on this list is to establish the project framework.

In this scenario, the project manager and product owner should work together to assess the impact of the change. Key stakeholders should be consulted to quantify the impact to the schedule and budget and help determine the business priority of the change and ensure it aligns with the project’s objectives. Escalating the final decision to the project sponsor might be necessary if the assessment determines that the change is required but is outside any delegated authority for approval.

The dependencies between these two projects present a great challenge to the project B team. They need to balance their internal and stakeholders’ priorities as well as the owners of project B, who are also stakeholders. The only way to do this is to prioritize positive project outcomes.

Although there are concerns, there is no proof the developer is doing anything sinister or wrong. Playing vigilante is the opposite of an environment built on trust and psychological safety and may create negative morale. By checking the nondisclosure agreement (NDA) and signed security protocols first and ensuring the team is reminded of the ground rules in the team charter, you have done your due diligence as project manager. If needed, any concerns should be discussed with the project sponsor.

The best approach here is to utilize the retrospectives by maintaining the healthy and strong relationships among all stakeholders. As a new member of the project team and new to an agile working environment, they will need help understanding expectations, how a psychologically safe environment works, and coaching from the team. Unfortunately, clients and customers sometimes do react passionately or negatively; this is reality. A unified, empowered team culture built on effective and safe communication and organizational policies is the best defense against this kind of behavior. It is not a project team’s job to coach a client or customer on emotional intelligence (EI).

The team member has acted to close a project without the team. While the team member might have had the best of intentions or produced a positive outcome, their way of working is out of scope for healthy project team communication. Team members should not act alone, without the product owner, to close a project. Although virtual teams can suffer from poor communication, the problem here could also be a weak sense of team identity or a team member who does not have the correct training or know the team’s way of working. The team member might have even ignored the team’s way of working for professional advancement or in the genuine best interest of the project. Whatever the case, this team is disunified and it needs to be reunified. Revisit the correct project process roles and responsibilities at the next retrospective and examine how well this team’s framework is working to make necessary changes.

Resistance to change can be a natural response, and project managers should know how to work with organizational change management methods and owners to facilitate positive receiving environments for their projects. Working with the process owner to create a transition plan or including a pilot for the project can be effective ways to ease this organization into a change. Incentivizing is not a sustainable solution, and ignoring a problem is hardly ever the best option. Providing further training can be perceived as a burden to end users, and it should take place before the implementation.

A successful adoption of agile should be led ideally by someone who has already adopted it and can be an advocate and coach. The other choices would not be as advantageous to the organization.

The project manager needs to communicate with these very public and resistant stakeholders. When factors in the external business environment create a substantial impediment to project work, such as what has happened here, it is first up to you to find a solution. In this case, stakeholder engagement and collaboration should be used. Local and online stakeholder groups can learn about the project’s objective through a neutral, creative medium, and if it is done well, it is possible that some people may be convinced or a compromise reached. Going ahead with the work in a clandestine and forceful way is not the best choice, because these kinds of heavy-handed actions can have negative consequences. The other options to delay or end the project do not indicate an opportunity to collaborate with stakeholders, which is required.

We examine value and base decisions for project scope based on available data. After that, we can invest in a proof of concept (POC). These stakeholders have had enough time to collaborate, but it is clear they cannot agree and move forward without help. They have contributed enough initial ideas for you to examine the potential value, schedule, and cost of each as the first steps.

When a new project manager joins a project and find an incomplete business case, the immediate solution is to determine what information is needed to understand what the business wants and needs from the project.

A project charter includes a high-level description of the project’s goals and a lot of information about the project. At this point, contracts may or may not be executed and the workspace may or may not exist. Acceptance criteria are decided on when it is time to complete the next step, starting with the project management plan. The only step on this list that should be completed now is to facilitate a peer review of the document ahead of obtaining approval.

The project manager needs to prioritize the long list of defects before taking action. A Pareto chart will show the defects by volume, from greatest to least. From this visual, the project manager can see what is causing the greatest defects and deal with those first.

Since the actual cost (AC) exceeds the planned cost (PC) and this project has a fixed budget, the team should find out if they can adjust quality to deliver on scope. In this software development project, this may involve identifying and removing any unnecessary work or features and prioritizing critical project requirements. The budget is fixed, so the team needs to stay within that parameter. Renegotiating vendor contracts will take time and carries risks.

You need to ensure the team is using measurement units as described in the schedule management plan. Directing them without checking the schedule management plan is an incorrect choice for a project that is using this project management plan component. Designing a tool is just going to complicate things, will take time, and is not an appropriate solution considering the effort and money invested. You could consider consulting the project management office (PMO), which would have been more appropriate while creating the schedule management plan.

You need to ensure the team is using measurement units as described in the schedule management plan. Directing them without checking the schedule management plan is an incorrect choice for a project that is using this project management plan component. Designing a tool is just going to complicate things, will take time, and is not an appropriate solution considering the effort and money invested. You could consider consulting the project management office (PMO), which would have been more appropriate while creating the schedule management plan.

This project has been authorized and is proceeding, whether the stakeholders are ready or not. The project manager’s job during the next 3 weeks is to prepare to start the project work. Even if the conversations will be difficult, the project manager needs to have them with the stakeholders now. Asking for more money to hire external resources is also a good idea in case the stakeholders cannot provide staff to meet the project’s needs. Using AI is an innovative tool, which is becoming commonplace, but it carries risks that would need to be evaluated before the tool is used; this adds time to the schedule.

Estimate to complete (ETC) indicates the projected remaining amount of money that will be spent based on past performance. The project manager can look at the money spent during the first 4 months of the project. Because this project occurs every year, a project manager can easily access the past years’ performance metrics to determine how much more money to allocate to the budget.

The best approach here is to perform an impact analysis and be transparent with the team members regarding the project status and their roles in project success. Based on the result of the analysis, collaborate with them on a solution that will not negatively affect the project.

In this case, the new project manager is assuming control of a project that did not have proper stakeholder engagement planning. Stakeholder support is always needed. The project sponsor can help but they and the team have already been consulted. Clearly, research is required, and the project documents are a good place to start. After identifying and engaging the stakeholders, the new project manager should collaborate with the team to determine levels of participation. Although it is true that the lessons learned repository has a lot of information, it is important to identify, analyze, and engage the stakeholders as soon as possible.

A server outage is a problem or issue that has occurred and for which a solution must be found. Negotiations seek a likely budget of US$50,000 to solve infrastructure difficulties, so the team can make the assumption, or working hypothesis, or the cost. The possibility of a delay is a statement of risk that something may happen, namely if the server is stopped abruptly there might be data loss. Finally, a known infrastructure capacity limitation explains a constraint, or limiting condition to the work.

After identifying a high-risk item with a costly contingency plan, the project manager’s next step should be to evaluate the cost-benefit analysis of the contingency plan before implementing it. This will help the project manager to determine if the cost of the contingency plan is worth the risk mitigation benefit. The project manager should also consider other risk management options such as risk avoidance, risk acceptance, and risk transfer. By evaluating the cost-benefit analysis and considering other risk management options, the project manager can make an informed decision on how to proceed. Implementing the contingency plan without evaluating its cost-benefit analysis may lead to unnecessary expenses and negatively impact the project budget. Waiting to see if the risk materializes may lead to missed opportunities for risk mitigation, increased costs, and project delays. Ignoring a high-risk item is not a proactive risk management approach and may lead to serious consequences if the risk materializes.

With new stakeholders in the key role of project sponsor, it is imperative to engage with them to discover their needs and expectations for both the project and communication with them. With the arrival of a new person in the role of project sponsor, even though they are already familiar with company policies and organizational process assets (OPAs), they are still new to the project. You should engage them properly and personally about the project. The original project sponsor has left, so they will be replaced in the communications management plan and stakeholder engagement plan; there is no need to add another channel.

The best approach here is to update the risk management plan that should already be in place. The issues on this project are evident because the risk management plan is not updated. Using a predictive approach does not guarantee better risk management. The project is already using a hybrid approach, so a risk management plan should have been in place and continuously updated. After the plan is updated, the risk register can be modified.

The key issue in this question is the stage of the project and its criticality. Using Tuckman’s Ladder Model as a guide to team dynamics, adding an unknown resource for a short period of time means the project team will start from the forming stage and won’t reach their maximum productivity right away. This is a best-case scenario, because the outcome can be a far more serious disruption to the team dynamic at a critical point in the project. That risk is too high. Approvals can be expedited, and we can assume that since the project is business critical, the company would have paid for the extra resource. Option D presumes that a reprioritized backlog would deliver an inferior or inadequate product. But because this project team is using an agile development approach, any backlog decisions will have a strong chance of delivering positive outcomes for the customer.

The project manager needs to get this problem fixed as soon as possible. The RACI chart and the conflict between the vendor and the team lead should also be addressed but this can be done later. Escalation is typically the option taken when the issue is beyond your authority and too complex to solve on your own.

To facilitate a smooth transition in this case, agile training and an open discussion about the transition are required. The project team needs to understand the transition process and have input in decision-making before adopting an agile way of thinking and working. Taking this step without the collaboration and buy-in of the team might create resistance and hinder the transition process. Creating a detailed plan for the transition is an example of a plan-based method that the team is trying to move away from, so this is not a good choice because the project team and the project manager all need to shift to the agile mindset.

When choosing the appropriate project approach, project managers should make their selection based on which will deliver the best value for that specific project. In this process, it is also important that the project manager educate stakeholders about the rationale behind the choice of a specific approach. Since the project manager and project team will plan and deliver the project, this decision should not be escalated to the project sponsor; however, the customer and other stakeholders may provide input.

The question states the vendor has completed the work as per the technical specifications mentioned in the contract. Therefore, the seller has met the acceptance criteria described in the terms and conditions of the agreement. Realistically, you would likely negotiate a new or amended contract with the seller to align the deliverable with your requirements better. Therefore, among all available options, accepting the deliverable and negotiating a new or amended contract are the best answers to this question.

Developing a stakeholder engagement plan and communicating regularly with stakeholders is the most effective approach to engaging stakeholders in a highly visible project with significant community impact. It is essential to engage with stakeholders, understand their concerns, and develop strategies to address them. Communication is critical to building trust with stakeholders and ensuring their support for the project. Engaging with stakeholders is necessary to address their concerns and ensure project success. However, since these stakeholders are already detractors, you might spend a lot of time and energy getting involved in discussions or arguments that do not benefit the project. While ignoring stakeholders’ concerns can lead to negative public perception, legal problems, and project delays, indulging them is also the wrong strategy.

Regular communication with stakeholders throughout the project is the best approach to preventing defects caused by incomplete requirements gathering and poor communication. This approach helps in identifying and resolving issues early on and ensures stakeholders are kept informed of the project’s progress. It also helps in building a strong relationship with the stakeholders and ensuring their expectations are managed. Since the work for this project takes a hybrid development approach to software development, we can assume that complete requirements gathering is not likely to be possible. In software development, requirements can change throughout the project and the project team needs to be flexible to accommodate these changes. Assigning a dedicated team for requirements gathering is a good approach; however, it might not always be feasible due to budget and resource constraints. Holding stakeholders accountable for incomplete requirements might create a negative impact on the project team’s relationship with the stakeholders. This approach may lead to a breakdown in communication and damage the project team’s reputation.

Although the key stakeholders were part of the project assessment, the project manager should present the report details and the project priorities established by the project sponsor. This way the stakeholders will understand the reasons for the changes to be made and the project manager can get their support for the implementation.

Conflict or disruption is a normal part of an agile team environment; frustration in this context can be understood and processed with empathy. Neither the project team member, nor the customers, nor the stakeholder did anything wrong. Feedback can come from any stakeholder or source and can take many forms. The project team only has some control over how they receive it and what they do with it. However, the product owner may be able to play the role of intermediary and speak to the stakeholder about how to deliver this feedback in a more useful way. The team member’s concern should be discussed at the next retrospective, where the project team can also discuss and circulate guidelines for stakeholder feedback so that it is useful for product and team development. Using the incident as a learning opportunity to improve the project team environment is also a good answer.

It is great the project team wants to keep working—it shows they have a good work ethic and dedication. As a project professional, one of your roles as a steward is to ensure the continuous learning and improvement (CI) of the team. In this case, you need to be the advocate for CI. As with any issue, we should analyze first, then take action. Reminders are not strong enough in most cases for meaningful action to take place. Adding or increasing visibility of actions—as ensuing lessons learned or a review of the team chart and ground rules is on the agenda—is a worthwhile response. However, these actions are not as active as taking steps to find the root cause and resolve the issue—if only to gather information to analyze.

This risk, once it occurs, is no longer a risk—it is an issue that requires action. So neither updating the risk register nor developing a response is going to help now. The project team’s job is to determine what action to take. This situation was unexpected and was neither planned nor budgeted for in the contingency budget. The contingency budget is used for addressing expected problems. When an unexpected problem arises and needs to be dealt with, the project team should activate the management reserve to fund an emergency response.

The contract with the hazard specialists should be sufficient to ensure a good, collaborative working relationship with the project team. Provided the specialists are given all the internal information they need and there is a collaborative way of working, the project work should proceed smoothly. The project team and the specialists should be working with one another, not in parallel. The project team, not just one person, should understand the risk factors that will affect the project and its compliance as much as possible.

The role and title of project manager or team lead can vary by project and organization. In general terms, the profession has embraced self-organizing teams and adaptability as core tenets, and the project manager or team lead is no longer the sole person responsible for and focused on delivering results. Instead, we focus on servant leadership, which is the practice of leading the team by focusing on understanding and addressing the needs and development of team members in order to enable the highest possible team performance. A person taking on this role should balance strategic thinking with daily project work. Understanding that learning is continuous also plays a part in self-organization, so we think of tenets rather than fixed guidelines for leadership characteristics. One such tenet of servant leadership is to understand the vision of the project, not just the daily issues; the servant leader should figure out how to create a balance between daily and strategic work in the context of a project and team. Therefore, the only question in this list to be answered with “yes” is: Can anyone be a servant leader?

Inspection is a quality control technique used in the Control Quality process to verify that products or deliverables conform or comply with specific quality standards, specifications, or other criteria. This happened during the catalog review. To avoid this issue from being repeated, the project team should perform quality improvement methods in the future. This may include updating their review and approval processes to ensure compliance with regulatory requirements and implementing training programs for designers and photographers to understand the compliance requirements. Decision-making and problem-solving are parts of quality management and should occur before implementation and during monitoring and controlling. Data analysis does not apply in the act of examining a photograph. Audits check compliance with standards, policies, and procedures and can be used in the future. Testing is similar to inspection and also used in the Control Quality process—in this case, the catalog review.

An agile approach to managing projects is driven by the 12 principles of the Agile Manifesto, one of which is: Agile processes promote sustainable development. The project sponsors, developers, and users should be able to maintain a constant pace throughout the project. Sustainable development involves the use of ideal time, factoring planned leaves, and avoiding overtime or holiday working. Additionally, in this context, the project team lead or facilitator should ensure that the go-live dates are not arbitrary but based on achievable targets. Overtime should only be used as a contingency in the case of an emergency. It is not appropriate to motivate team members to work extra hours to meet project goals unless it is an exception. Team rewards should not be linked to working overtime or dealing with unreasonable time lines. Increasing the project cost baseline is not the appropriate way to deal with team members working overtime.

Increasing costs of products and services directly affects projects, so project teams need to adapt. An increase across all vendor services is probably a sign of a big change in the external business environment. Issuing a new request for proposal (RFP) with a cost limitation will not likely be successful because every vendor is affected. The solution here is to understand what is causing the price increases and seek a solution for the project that is sustainable. The project team might then choose to create a revised budget with the new costs of vendor services and goods, namely the estimate at completion (EAC) which will tell them the expected total cost of completing all work expressed as the sum of the actual cost (AC) to date and the estimate to complete (ETC). The product owner or project sponsor will decide whether the organization can or wants to continue supporting the project. Because it is early in the project, this is the most sustainable solution for the long-term health of the project. Management reserves and the contingency budget should be used for covering expenses resulting from issues, not to support a project budget that has been impacted because of external environmental factors.

This risk, once it occurs, is no longer a risk—it is an issue that requires action. In an agile environment, the team lead, in this case a scrum master, facilitates the self-organizing team to take action and find a solution. The team should discuss the issue during the next standup meeting for awareness, but this is only the first step in problem solving. Since this issue is both from an unidentified risk and poses a serious threat, it requires action first.