diff --git a/tech-far-hub/content/resources/case-studies/case-study-challenge-navigating-stakeholder-and-decision-making-challenges.mdx b/tech-far-hub/content/resources/case-studies/case-study-challenge-navigating-stakeholder-and-decision-making-challenges.mdx
new file mode 100644
index 00000000..fdbe969b
--- /dev/null
+++ b/tech-far-hub/content/resources/case-studies/case-study-challenge-navigating-stakeholder-and-decision-making-challenges.mdx
@@ -0,0 +1,230 @@
+---
+slug: case-study-challenge-navigating-stakeholder-and-decision-making-challenges
+template: case-study
+page_type: case-study
+heading: Case Study Challenge - Navigating Stakeholder and Decision-making Challenges
+promo_description: This case study reflects an authentic scenario that Acquisitions professionals could experience when procuring digital services. It is intended to simulate the conditions faced when acquiring digital assets and the associated risks and barriers presented by diverse stakeholders with varied personalities and perspectives.
+media_image:
+media_alt_text:
+is_featured: true
+nav_weight: 10
+---
+By Cynuria Consulting
+
+
+This case study was a finalist selected as part of the [Digital Acquisition Professional Program Case Study Challenge](https://www.challenge.gov/?challenge=ditap-case-study). To see the original case study, click [here](../../../../tech-far-hub/static/assets/files/navigating-stakeholder-and-decision-making-challenges-ditap-case-study.pdf).
+
+
+## Overview
+This case study reflects an authentic scenario that Acquisitions professionals could experience when procuring digital services. It is intended to simulate the conditions faced when acquiring digital assets and the associated risks and barriers presented by diverse stakeholders with varied personalities and perspectives. Learners are provided a comprehensive view of the situation, along with details regarding each stakeholder group and objective data to support their concerns in acquiring the new software. They will be prompted to consider relevant policies, procedures, and opportunities to source additional data, to further align their approach with the requirements.
+#### Approach and Delivery Format
+The scenario presented in this case study is designed to be universally applicable to a variety of government agencies. It is designed for flexibility in delivery mode and the time allotted to complete it. Each milestone includes a percentage of time needed to complete the analysis allowing for a flexible delivery over days, weeks, or more. The exercise also includes facilitator instructions and tips for delivery. Learner instructions guide them through navigating the case study and completing each exercise milestone.
+Learners will analyze proposed solutions, considering the benefits and drawbacks of each option. There is no single correct solution for this case study, and learners will be encouraged to explore the many potential pathways, and consider them using tools that include a cost-benefit analysis and a Strengths - Weaknesses - Opportunities - Threats (SWOT) analysis to uncover additional insights. Based on their analyses and feedback from peers and the facilitator, learners will propose a creative solution with a written analysis and a final presentation.
+The exercise is broken down into five milestones to engage learners as they fully analyze the scenario while receiving feedback throughout the experience. This encourages learners to adjust their positions as they learn new information, gain additional insights, and further develop their approach. Their final proposed solution will be presented in a simple slide deck format and should reflect an innovative and creative approach that considers the needs of the stakeholders, the challenges and barriers presented, and the benefits gained.
+## The Exercise
+### Facilitator Instructions
+#### Prepare for Delivery
+Review the case study background information, key stakeholders, problem identification, data, and evidence carefully. Familiarize yourself with the potential solutions and challenges presented through the scenario.
+Consider how you will distribute the case study exercise to learners.
+ - **For an in-person, facilitator-led experience**, the case study can be printed and shared with learners before a live session to allow time for review. Links to additional resources are provided within the case study, so learners may need devices to access these online resources.
+ - **For a virtual facilitator-led format**, electronic versions of the case study may be distributed for download or online viewing.
+> [!TIP]
+> Facilitator Tips: Throughout the case study exercise, you will see Facilitator Tips in “tip” alert blockquotes that provide guidance for facilitators to further engage learners.
+
+> [!IMPORTANT]
+> Learner Reflection Exercises: There will also be points where focused reflection will be suggested in “important” alert blockquotes, and the facilitator can naturally weave those into the activities.
+#### Introduce the Case Study Exercise
+##### Case Study Overview
+Share the case study below, highlighting the purpose, key issues, stakeholders, and the problem to be solved. Clearly state the learning objectives and the objectives for each milestone.
+This case study focuses on the challenges of navigating multi-stakeholder decision-making as an Acquisition team member procuring digital services. This case study focuses on Casey, a federal agency Contracting Officer (CO), tasked with acquiring a cloud-based Customer Relationship Management (CRM) system. While moving through the process of selecting and procuring a service, Casey faces resistance from two key stakeholders: the IT team and Compliance Officers. This case study focuses on how Acquisition officers can consider varying and sometimes opposing needs of stakeholders in the decision-making process.
+##### Purpose
+The purpose of this case study analysis is to consider creative solutions to a realistic scenario learners may encounter as an Acquisition team member procuring digital services, as there is often no single way to solve a problem. In this exercise, learners should carefully analyze the information and research provided and determine a solution that accounts for the varied stakeholder needs involved. Their analysis should include the research or data used to support their solution. To fully analyze the case, learners will engage in several exercises to consider the case from different perspectives using different analysis techniques.
+##### Learning Objectives
+After considering this case study and forming a solution, learners will build the skills to:
+ - Analyze conflicting stakeholder priorities in the CRM acquisition process.
+ - Evaluate potential solutions for integration and data security.
+ - Develop a strategy that addresses all concerns and ensures the CRM meets agency requirements.
+### Learner Instructions
+#### Overview
+In this exercise, you will analyze a case study that presents a real-world scenario. Your task is to critically evaluate the situation, identify the key issues, and develop well-reasoned recommendations. This exercise will help you enhance your problem-solving and decision-making skills as a member of the Acquisition team.
+You will also be provided with links to several additional supplemental resources. Use this material to determine the best course of action and as additional guidance in evaluating the situation.
+After reading the scenario, you will consider three key questions and use them to support your analysis. These questions will be discussed as a group with your peers and facilitator.
+ - How can Casey balance the cost and time implications of custom integration solutions?
+ - What strategies can ensure data security measures do not impact system performance?
+ - How can Casey mediate stakeholder concerns to reach a consensus?
+#### Milestone Exercises
+You will complete this case study analysis through several milestone exercises leading to a final proposed solution presentation. Each milestone exercise will be reviewed with your peers and your facilitator. As your analysis progresses, you will use new information uncovered from each milestone to form your final opinion on the appropriate approach to solving the problem presented. There are five milestone exercises: (1) Stakeholder Analysis, (2) Evaluation of Integration Solutions, (3) Evaluation of Data Security Solutions, (4) Written Case Study Analysis, and (5) Final Presentation.
+> [!TIP]
+> **Facilitator Tip:** Encourage learners to take notes throughout their case study analysis and capture research information. One method to use is the Split Page strategy. using the left side of a page to capture details from the case study and the right side to document notes, research, and ideas.
+## The Challenge
+Globally, government agencies have been moving to cloud computing, using cloud-based services from outside vendors to allow them to serve their customers more easily and streamline their systems.
+Specifically, cloud-based Customer Relationship Management (CRM) systems let organizations grow, respond to change, and save on costs, which helps them provide better services and improve the ways they operate. For example:
+ - The United Kingdom’s Home Office implemented cloud-based CRM systems to better manage citizen interactions and streamline internal processes.
+ - Australia’s Taxation Office (ATO) uses cloud-based CRM solutions to enhance customer service, improve case management, and facilitate better communication with taxpayers.
+ - Singapore’s Infocomm Media Development Authority (IMDA) employs cloud-based CRM systems to engage with businesses and the public effectively, supporting its digital transformation initiatives.
+The United States has adopted the same approach to using cloud-based solutions across the
+government. In October 2018, the Office of Management and Budget (OMB) released the [Federal Cloud Computing Strategy](https://cloud.cio.gov/strategy/), or Cloud Smart, which was part of a Federal government IT Modernization effort. The Cloud Smart initiative fostered a cloud adoption and implementation effort to accelerate the pace of cloud computing software adoption within the federal government. To meet the demands of the initiative, agencies are directed to consider ways to extend their current resources to maximize value, reskill and retain staff, and enhance security situations. The goal of the adoption of cloud computing software is to harness the power of new technologies that expand capabilities within each agency to serve the public.
+One successful adoption of a cloud-based CRM within the US government is the General Services Administration (GSA) using Salesforce, a leading cloud-based CRM platform, to manage interactions with various stakeholders and improve service delivery.
+The [Chief Information Officers Council](https://www.cio.gov/about/vision/#:~:text=The%20Chief%20Information%20Officers%20Council%20%28CIO%29%20Council%20is,use%2C%20sharing%2C%20and%20performance%20of%20Federal%20information%20resources.) worked with the OMB, the General Services Administration, and other agencies to determine opportunities for optimizing agency usage of cloud services. One of the opportunities realized was the adoption of Customer Relationship Management (CRM) software to improve shared knowledge across agencies.
+Adopting cloud-based systems has its benefits, including centralized access across distributed agencies and teams, streamlined data flows and consolidated information, and smoother service experiences. However, there are also significant drawbacks that cloud computing technologies present, such as security breaches, regulatory compliance, and infrastructure challenges.
+Target users for the new system would be broad, including budgeting, contracting, test and evaluation, logistics, human resources, and more. Experience with using and adopting such a system would also vary depending on the agency’s and individual’s experience using these tools.
+The process of acquiring new digital assets like this is a complicated one. Unlike the private sector, the level of coordination and collaboration necessary to ensure the successful adoption within the federal government requires involving many key players and stakeholders, including a CO, a Program Manager (PM), Information Technology (IT), Compliance Officers, and others. Some challenges that can complicate the collaboration across these stakeholders include communication, risk assessment, cost, timelines and schedules, performance, defining requirements, contract type, and solicitation methods. Navigating these complexities requires an analytical mindset to consider many competing priorities and needs of each stakeholder.
+> [!TIP]
+> **Facilitator Tip:** In the next section, learners are introduced to the players in the scenario. Learners may not be given all the information up front. Remind learners that as they work through the case study, research and other activities may uncover additional information.
+### The Players – Part I
+#### Acquisitions Office: Casey
+After more than a decade in acquisitions, Casey, a Senior Acquisition Specialist, is no stranger to complex projects. With Federal Acquisition Certification in Contracting (FAC-C) Level 3 under their belt, Casey has gained a reputation as the agency’s go-to expert for acquiring cutting-edge software. But this time, something was different – Casey was handed a project that would push the limits of their expertise: acquiring a cloud-based CRM system.
+As Casey left a recent meeting with agency leadership, having received the assignment, a sense of excitement and apprehension stirred. While Casey has acquired many software solutions, acquiring a cloud-based system like this one would be a first. While Casey knows how a CRM generally works, considering the array of implications of this type of cloud-based software starts to become clear. The agency’s legacy systems were relics of a bygone era, often barely functional, yet touching them carried massive implications. The questions started swirling:
+ - Who does this impact?
+ - How will I establish effective communication among all of these stakeholders?
+ - Do I need a communication plan, risk management plan, or charter?
+ - What might the other teams involved be cautious of when approaching this?
+
+Having managed several large IT acquisitions before, Casey knows coordination starts with two key groups: the IT department and Compliance Officers. Casey has a long-standing relationship with both of these departments and a few close colleagues who may be allies as they work through the process.
+The challenges of the acquisition aren't just about technicalities. Casey was acutely aware that this project would have ripple effects—some beneficial, some dangerous. If successful, Casey would solidify their standing as a top specialist, potentially opening doors to career advancement. But failure could attract congressional scrutiny and public outcry, not to mention the internal politics of the agency, where trust had been hard-earned. In any contracting endeavor, vendors who are not selected or those that do not meet small business requirements may post challenges.
+Through recent training, Casey has learned that when negotiating among stakeholders, it’s important to take an empathetic approach, making sure each stakeholder feels heard and understood throughout the decision-making process.
+> [!IMPORTANT]
+> **Learner Reflection Exercise:** How can Casey use empathy when talking with key stakeholders? How might a lack of empathy create conflict among stakeholders when discussing their concerns?
+#### The IT Department: Alex
+Alex also has had a long career within IT, transitioning to the federal government several years ago after many years in the private sector, where innovation was faster and less bogged down by bureaucracy. The federal government is an entirely different beast. Alex hears reports from the Chief Information Officers Council and the progress they’re making toward the Cloud Smart initiative. While Alex is familiar with it, adoption has been slow across agencies, so direct experience with how such tools integrate into the existing systems is limited. The IT department knows that implementing these solutions has become a priority for many agencies, but integrating cloud-based systems into the agency’s legacy infrastructure would be a logistical nightmare. To try to anticipate the challenges these new solutions may present, Alex and the IT team have conducted some preliminary research into the implications of a cloud-based system, but have not shared their findings broadly.
+Beyond the technical aspects, Alex has experienced the adoption of new systems before and knows the human element of new software adoption can present significant challenges, including training staff on new software, universal adoption of systems, and the quality and consistency of use. Alex knows plenty of career government employees who are hesitant to adopt any new systems, adapt to change, or consider new approaches. “This is the way we’ve always done it,” is a common phrase Alex hears often when talking about new initiatives or systems.
+#### The Interaction - Acquisitions Office and IT
+Casey’s first move was strategic: to meet with Alex, the IT department's steadfast leader. Having worked together on numerous acquisitions before, Casey and Alex had a rapport built on mutual respect and shared success. But as Casey broached the topic of the cloud-based CRM, Alex’s reaction was more restrained than usual.
+Casey shares the newest assignment with Alex and asks for feedback. “We’ve done some initial research,” Alex shares, leaning back thoughtfully in the chair. “But the truth is, this cloud solution could create significant challenges. Legacy systems in this agency are over two decades old. Getting them to speak to the cloud—without causing disruptions—won’t be easy.”
+Casey listens closely, knowing that Alex's concerns are valid. But the real issue, Alex notes, is not just technical. “The human element,” Alex continues, “that’s where we’ve seen real resistance. You’ve got career employees who hate change. They’ll fight it at every step.”
+Casey nods, recalling the murmurs of discontent from employees whenever anything new was introduced. But the conversation with Alex has illuminated something deeper: the agency’s reluctance isn’t just technical, it’s cultural.
+Alex notes that their experience with adopting cloud-based software has been limited so far. With the newness of the initiative, most agencies haven’t gotten as far as the acquisition process.
+“I just keep thinking about this integration challenge,” Alex continues. “There’s been some recent interest and movement, though, that might help you.” Alex shares that the Information Technology Category and Cloud Solutions Category Teams have also been working with the OMB to support centralizing information about cloud initiatives and resources for procurement. From that work, they’ve formed the [Cloud Information Center (CIC)](https://cic.gsa.gov/) and have specifically outlined [information for acquisitions](https://cic.gsa.gov/acquisitions/overview). Alex suggests Casey start there for more information on how this impacts the project.
+“We’re going to need to bring in Compliance, though. We won’t get far without them. The good news is, we work pretty closely with each other, so I know where to take this next.” Casey asks to be part of those conversations. “It’ll be easier if I meet with the Compliance Officer myself. We can usually come to a consensus pretty easily. I’ll report back with our thoughts.” Casey is mildly concerned and a little put off by the limited engagement with the two teams, but trusts the professional nature of their relationship and knows Alex will perform due diligence.
+> [!IMPORTANT]
+> **Learner Reflection Exercise:** If the next step is a meeting with the Compliance Officers, what is the desired outcome from the meeting, and what should Alex come prepared to discuss? Are there any risks to consider?
+### The Players – Part II
+#### Compliance Office: Riley
+Riley is a seasoned Compliance Officer. With nearly two decades of experience, Riley has been participating in the Senior Executive Service (SES) Candidate Development Program, and the eventual promotion and probable appointment to a leadership position would be a distinction for Riley, who has successfully led and managed teams and projects while functioning as a GS-15 within the agency. Riley’s current supervisor will continue to monitor performance and may be a good source of support and guidance during this CRM acquisition process.
+With the primary job function of examining, evaluating, and investigating whether or not a project or system complies with laws and regulations, Riley and other Compliance Officers know that other teams perceive them as the barriers to projects, presenting the reasons why something cannot be implemented. Being referred to as the “government watchdog” doesn’t always leave a good impression. Riley spends the day reviewing various elements of the [Federal Acquisition Regulations (FAR)](https://www.acquisition.gov/browse/index/far) system to confirm any new acquisitions align with the regulations.
+As the government has focused on modernizing its systems, reviews and audits have focused on cybersecurity issues and data security, and Riley is keenly aware of these important topics.
+#### The Interaction - IT and the Compliance Office
+Riley sees a meeting request from Alex to discuss a cloud-computing software acquisition. Cloud computing has been on Riley’s radar for a few years since the Cloud Smart initiative launched. From a security perspective, Riley and other Compliance Officers encourage agencies to take a risk-based approach when considering cloud solutions. In a report to the President, it was clear that agencies should emphasize “data-level protections and fully leverage modern virtualized technologies.” Protecting data is the primary concern for Compliance Officers, generally, but particularly when considering cloud-based solutions.
+Riley is relieved to be talking with Alex so early in the acquisition process. The best way to lower risk is to openly communicate and collaborate with the IT team as they think about implementation and infrastructure needs. When they meet, Alex shares the IT team’s concerns regarding integration. “The problem,” Riley started, “is that we’ve seen other agencies rush through the cloud acquisition process and end up violating compliance. Contracts were mishandled, data security was compromised, and vendors didn’t meet the standards.” These concerns are valid, but ones that can be overcome.
+For Riley, the larger concern is compliance with the FAR and ensuring data security–these are non-negotiables. One potential significant challenge that comes to mind is the [Federal Risk and Authorization Management Program](https://www.fedramp.gov/program-basics/) (FedRAMP). FedRAMP will also require a review to ensure that vendors have cleared their security requirements. Moving too quickly through any of these systems opens up the risk for potential security breaches and privacy concerns, ones that raise flags for the Compliance Officers.
+“I agree that agencies need to start adopting these solutions,” Riley shares, “but, honestly, the security risks have me on high alert.” Over a series of meetings, Riley and Alex brainstorm potential solutions, but none of them sufficiently satisfy both party’s concerns.
+Alex reports back to Casey. “We’ve been thinking through several options, but this is proving tougher than usual. We’re having a hard time coming to a consensus on a single approach.” Casey recognizes that negotiation and relationship-building skills would be an asset to these ongoing conversations and proposes an Integrated Project Team (IPT). Casey knows that IPTs provide a more holistic approach to project management, allowing representatives from different areas to effectively work together throughout the project's life cycle. On the other hand, IPTs can be difficult to manage because of diverse team member backgrounds and the need for consensus building. “I really think I can help here,” Casey responds. “If the three of us work together, I can learn more about the sources of the issues and their level of impact on any solution we identify.”
+#### The Interaction - Acquisitions Office, IT, and Compliance Office
+During their joint working sessions, Casey asks Alex and Riley to share the major issues the acquisition presents.
+“We’re talking about major disruptions,” Alex warned. “Either we update our legacy systems, which will cost us months, or we risk serious operational downtime with the new cloud system. Any solutions requiring custom integration mean my team will be drained. They all have other duties. Not to mention, they’re the ones who have to directly engage with user resistance.”
+Riley adds, “With proper planning, testing, and cross-departmental coordination, these challenges can be mitigated. We would have to create a strong strategic plan for a successful implementation. Updating legacy systems to meet the new demands of the cloud system, raises major concerns for me as I think about ensuring regulatory compliance. Newly developed solutions may require compliance reviews, risk management policies, and additional implementation strategies.” Alex’s face shows some disagreement. “But, updating legacy systems might mean fewer complications because the tools have already been audited and approved.” Alex leans back in the chair with arms crossed.
+Riles continues, “From a security perspective, whether we update legacy systems or develop newly built custom integrations, data security is a critical concern. In either option Alex has proposed, we’d have to run regular security audits and updates to protect the organization’s infrastructure. This would create serious issues with time, resources, and potential disruptions. But, what about developing and implementing advanced encryption and access controls?”
+“This might help avert security threats, but encryption would slow everything down. Increased latency, more storage issues, and potential performance crashes. My team has to handle all of that and we just can’t take those hits.”
+Both Alex and Riley believe that their concerns should be the driving influence on the decision-making process.
+### Potential Pathways for Solution Development
+As the weeks go by, the tension between Alex and Riley simmers just beneath the surface. Both departments are adamant that their concerns should shape the decision-making process. But Casey, with a calm and steady hand, begins to steer the group toward a middle ground. As a group, they determine that there are two options to address each of the larger issues: Integration
+and Data Security.
+ 1. **Integration Issues:**
+ - **Solution A:** Develop custom Application Programming Interfaces (APIs) to integrate the CRM with existing legacy systems. This option is tailored but involves higher costs and longer development time.
+ - **Solution B:** Upgrade legacy systems to improve CRM compatibility. This simplifies
+integration but requires substantial investment and may disrupt operations.
+ 2. **Data Security Concerns:**
+ - **Solution A:** Implement advanced encryption and access controls. This ensures strong protection but may affect system performance.
+ - **Solution B:** Conduct regular security audits and updates. This maintains data protection standards with fewer immediate impacts on system performance.
+#### Data and Evidence
+With these proposed solutions in mind, Casey researches some industry white papers and reports, case studies, vendor documentation, academic papers, and IT cost management studies, and finds that:
+ - **Quantitative data:** Custom APIs will cost 20% more and take 30% longer to implement than system upgrades. Advanced encryption could add 15% overhead to system performance, while regular audits would require additional staffing and resources.
+ - **Qualitative data:** The IT department suggests custom APIs provide long-term stability but at a higher initial cost. Compliance officers emphasize that advanced encryption is critical for federal data protection requirements, while regular audits are easier to manage but require ongoing attention.
+> [!IMPORTANT]
+> **Learner Reflection Exercise:** There is often more than one possible solution to satisfy the stakeholders and requirements. Are there other solutions Casey has not yet considered?
+### Facilitator Instructions
+#### Group Discussion
+After learners have read the complete case study, break the group into small teams. Encourage them to identify the main problem(s), analyze the stakeholders involved and their competing priorities, explore the root causes of the issues (including logistical and personal), and develop additional potential solutions.
+Alternative delivery modes: If delivering the exercise in a virtual experience, teams can be created using virtual breakout rooms. If delivering asynchronously, use tools such as discussion boards to encourage collaboration and discussion among the team members.
+After teams have had time to discuss, bring them back together to share their insights with the larger group. Provide feedback or pose additional questions to encourage learners to explore other perspectives or alternative solutions.
+> [!TIP]
+> **Facilitator Tip:**
+> - Circulate between groups (if delivering in person) or among breakout rooms (if delivering virtually).
+> - Each milestone activity has a suggested percentage representing the relative proportion of time to spend on that activity. Adjust actual timing accordingly.
+### Learner Instructions
+**Discussion Questions:** Consider the questions below and discuss them with your team.
+ - How can Casey balance the cost and time implications of custom integration solutions?
+ - What strategies can ensure data security measures do not impact system performance?
+ - How can Casey mediate stakeholder concerns to reach a consensus?
+
+**Completing the Analysis:** To complete this case study analysis exercise, you will further analyze the case study and complete a series of milestones. Each milestone provides an opportunity to consider the case study from a new perspective.
+ - For **Milestones 1, 2 & 3**, you will use various analysis tools to develop a deeper understanding of the stakeholders, their challenges and needs, and the benefits and drawbacks of the proposed solutions.
+ - For **Milestone 4**, you will complete a written analysis of the case study and develop your proposed innovative solution, using the details from the case study and the additional resources to support your findings.
+ - For **Milestone 5**, you will develop a presentation slide deck to summarize and deliver your final findings.
+
+**Additional Resources:** Consider these additional resources as you complete each milestone:
+ - Integration feasibility report and cost analysis
+ - Data security assessment and encryption impact study
+ - [Federal Acquisition Website](https://digital.gov/topics/acquisition/)
+ - [USDS TechFAR Hub - Get Started](https://techfarhub.usds.gov/get-started/)
+ - [GAO Cost Estimating and Assessment Guide](https://gaoinnovations.gov/cost-guide/index.html)
+### Milestone Exercises
+#### Milestone 1: Stakeholder Analysis (15%)
+**Objective:** Articulate the different perspectives and concerns of stakeholders to better manage their expectations.
+To complete this milestone, create a stakeholder map (simplified sample below) to align each group of stakeholders to their levels of influence, needs, concerns, and motivations. Key stakeholders to consider include: IT, Compliance Officers, Users, Management, and others you identify in your analysis (e.g., Executive Leadership, Finance, Human Resources).
+##### Proposed Solution:
+| Stakeholder or Group | Influence Level (L/M/H*) | Impact Level (L/M/H) | Interest in Proposed Solution | Key Risks and Expectations |
+| --- | --- | --- | --- | --- |
+| | | | | |
+| | | | | |
+* **L/M/H** = Low, Medium, High
+#### Milestone 2: Evaluation of Integration Solutions (15%)
+**Objective:** Evaluate the trade-offs between custom APIs and upgrading legacy systems to make an informed decision.
+To complete this milestone, systematically evaluate numerous factors to make a decision that ensures alignment with your organization’s strategic goals and operational requirements. For example, you will assess the current state and needs, evaluate custom APIs, create a life cycle cost estimate and also analyze the Strengths, Weaknesses, Opportunities, and Threats (SWOT) of each option provided in the case below. Then make a decision and plan for integrating and monitoring the chosen solution and its performance.
+#### Milestone 3: Evaluation of Data Security Solutions (15%)
+**Objective:** Determine the most effective data security solution that aligns with the agency's needs without compromising system performance.
+To complete this milestone, develop a life cycle cost estimate and conduct a SWOT analysis of each option provided in the case below to address the data security challenge.
+
+##### Life Cycle Cost Estimate
+Developing reliable cost estimates is crucial for realistic program planning, budgeting, and management. While some agency guidelines on cost estimating are thorough, other agency guidance is limited regarding processes, procedures, and practices for ensuring reliable cost estimates. This structured approach ensures that cost estimates are thorough, credible, well-documented, and useful for decision-making.
+Several government agencies are recognized for their leadership in setting standards and providing guidance for cost estimating for digital or IT acquisitions including GAO, USDS, GSA, DoD, and DHS. For this case, the GAO process is presented for consideration. The sample GAO 12-Step Life Cycle Cost Estimate (LCCE) Process visualized below comes from the [GAO Cost Estimating and Assessment Guide](https://gaoinnovations.gov/cost-guide/index.html) and addresses the gap between agencies with detailed guidelines and those without. The graphic below is illustrative - please refer to the full size version in the linked Guide.
+
+
+
+The guide outlines key steps in the cost estimating process: the purpose, scope, and schedule of a cost estimate; a technical baseline description; a work breakdown structure; ground rules and assumptions; data collection; estimating methodologies; sensitivity and risk analysis; documenting and presenting results; and updating estimates with actual costs. Note that for this exercise, you do not need to identify specific dollar amounts when considering costs.
+
+##### SWOT Analysis
+When completing the SWOT analysis, address the considerations for each of the four elements in the diagram below.
+
+
+
+#### Milestone 4: Written Case Study Analysis (30%)
+**Objective:** Craft a well-rounded solution that addresses technical challenges and stakeholder concerns, ensuring successful CRM implementation.
+To complete this milestone, use findings from Milestones 1-3 to develop a strategy. Propose a final solution that balances all needs and parties involved.
+An effective analysis of a Case Study includes the following elements:
+
+
+
+#### Milestone 5: Case Study Analysis Final Presentation (25%)
+**Objective:** Effectively communicate the proposed strategy and reflect on the decision-making process to gain insights for future scenarios.
+To complete this milestone, prepare a final presentation summarizing your approach, findings, and recommendations included in your final written case study analysis in Milestone 4. Reflect on challenges presented during analysis. Include 6-8 slides that include these sections: Title slide, summary, approach, key challenges, findings, and recommendation.
+Your analysis will be assessed on your group’s ability to address stakeholder concerns, propose creative yet viable solutions, and justify your recommendations. Effective analysis considers:
+ - **Stakeholder Management:** Facilitate ongoing discussions with IT and Compliance teams to address concerns and update on progress.
+ - **Integration:** Opt for custom APIs to integrate with legacy systems, allocating additional resources for development.
+ - **Data Security:** Implement advanced encryption and schedule regular security audits to ensure protection and compliance.
+> [!TIP]
+> **Facilitator Tip:** While each milestone could be completed independently asynchronously using the resources provided, ideally learners will present their analyses to the other groups to collect perspectives and feedback from their peers.
+## Evaluation & Feedback
+### Learner Instructions: Evaluation Criteria
+The facilitator will evaluate each group’s analysis and presentation on a scale of 1-5 (1 = Unsatisfactory, 5 = Excellent) considering the following elements of the exercise:
+ - **Understanding the Problem:** This criterion assesses how well the analysis identifies and understands the core issues and challenges presented in the case. It includes recognizing the key problems for each set of stakeholders, their implications, and any underlying factors contributing to the scenario.
+ - **Quality of Analysis:** This criterion looks at the depth and thoroughness of the analysis. It includes how well the analysis examines the evidence, evaluates each proposed solution, and provides a logical and well-reasoned argument. The analysis should be clear, coherent, and demonstrate critical thinking.
+ - **Use of Evidence and Resources:** This criterion evaluates the extent to which the analysis is backed by credible evidence. It considers how well the analysis integrates data, facts, and research findings to support its arguments and conclusions. Strong use of evidence strengthens the credibility of the analysis.
+ - **Creativity and Originality:** This criterion assesses the uniqueness and innovativeness of the analysis. It considers whether the analysis offers new insights, creative solutions, or a fresh perspective on the case. Original thinking can add significant value to the analysis.
+ - **Clarity and Organization:** This criterion focuses on how clearly and logically the analysis is presented. A well-structured analysis should have a clear introduction, body, and conclusion, with each section flowing logically from one point to the next. The clarity of writing and the organization of ideas are key factors here.
+> [!TIP]
+> **Facilitator Tip:** Individualized feedback will help learners refine their approach as they prepare for the final presentation. Share that:
+> - Balancing stakeholder concerns involves considering both technical feasibility and regulatory requirements.
+> - Effective stakeholder engagement and communication are crucial for resolving conflicts and reaching consensus.
+## Conclusion
+### Facilitator Instructions
+With the full class, debrief a summary of the evaluation and feedback (recapping the case study’s objectives and invite learners to share their initial reflections), then ask learners to share their insights below with the other participants. Once the debrief exercise is complete, offer Congratulations as drafted below.
+### Learner Instructions
+Take a few minutes with a few of your fellow learners to make some notes about the following reflections, and share with the class as guided by the facilitator.
+ - Highlight key insights and connect them to the case study’s concepts, addressing any questions or clarifications needed.
+ - Summarize the main takeaways and discuss how they can be applied in real-world scenarios. Identify one you would like to analyze in the future.
+ - Summarize your experience on the exercise process.
+### Congratulations! :tada:
+You’ve successfully navigated the complexities of this case study analysis exercise, demonstrating exceptional dedication and analytical skills. Completing this extensive set of exercises is no small feat, and your commitment to understanding and applying the concepts is truly commendable!
+Through this exercise, you have showcased your ability to tackle real-world acquisition challenges and derive insightful solutions. This achievement highlights both your technical expertise and your critical analysis skills for future success as a Contracting Officer.
+Keep up the great work and continue to build on this accomplishment. Well done!
diff --git a/tech-far-hub/content/resources/case-studies/case-study-challenge-project-rainbo.mdx b/tech-far-hub/content/resources/case-studies/case-study-challenge-project-rainbo.mdx
new file mode 100644
index 00000000..fa214944
--- /dev/null
+++ b/tech-far-hub/content/resources/case-studies/case-study-challenge-project-rainbo.mdx
@@ -0,0 +1,202 @@
+---
+slug: case-study-challenge-project-rainbo
+template: case-study
+page_type: case-study
+heading: Case Study Challenge - Project RAINBO
+promo_description: This case study reflects an scenario that Acquisitions professionals could experience when procuring digital services. It is intended to simulate the conditions faced when acquiring novel technologies.
+media_image:
+media_alt_text:
+is_featured: true
+nav_weight: 10
+
+---
+
+By Lynne Cuppernull and Dan Ward
+
+
+This case study was a finalist selected as part of the [Digital Acquisition Professional Program Case Study Challenge](https://www.challenge.gov/?challenge=ditap-case-study). To see the original case study, click [here](../../../../tech-far-hub/static/assets/files/rainbo-case-study.pdf).
+
+
+## Project RAINBO – Case Study
+
+It was 8:30 am on a Monday morning. Yvette was enjoying a cup of tea at her desk and collecting her thoughts before her team’s weekly staff meeting. She smiled to herself as she recalled how well last week’s program review went. One executive even commented, “I wish every team worked as smoothly as this one.”
+
+She enjoys being the program manager for Project RAINBO (Reliable AI Network for Better Outcomes). Her team is tackling a big challenge in digital healthcare data management. Specifically, RAINBO is charged to increase accuracy and availability of large amounts of healthcare data, identifying trends and quantifying the efficacy of treatments much faster than traditional methods. The team is pursuing some emerging AI technology, which holds the potential to be a truly revolutionary approach to improving healthcare outcomes.
+
+While the technology is interesting, and she cares deeply about the mission, what Yvette likes best is the people. She is proud of how well the team works together and supports each other. People are friendly and interested in each other, and the project is famous for having outstanding off-site events. Sure, a few tough questions didn’t get answered during the latest review, and there are some big decisions that still need to be made, but Yvette is confident they can do what needs to be done because the team is so close and supportive of each other.
+
+She’s about to discover that things are not as smooth as she thinks.
+
+Thirty minutes later, everyone is gathered in the conference room for the staff meeting. In keeping with the team’s practice of “connection before content,” they spend a few minutes in casual conversation, asking about each other’s weekend activities, before getting down to business.
+
+Yvette opened the meeting by reflecting on how positive the program review was, focusing specifically on the team’s collaborative way of working together. “We had a really strong performance because we all supported each other and listened to all voices. In keeping with that, I’d love for you all to share your thoughts with the group!”
+
+Roman, the contracting officer, spoke up first.
+
+“I agree last week went smoothly, even though we didn’t exactly stick to the agenda, but it was also incomplete. We never did make a decision on my proposal about assigning roles and responsibilities. Like I explained, we need to assign roles because we’re spending too much time having conversations where everyone weighs in on everything , then we end up with a consensus that is not actually correct. Experts should be making these decisions, no offense.”
+
+“On that note,” he continued, “I also need your approval on my proposed acquisition and contracting strategy. I already laid out all the required steps and carefully addressed all the policy compliance requirements. We need to get this signed off and locked in, so there will be no ambiguity, no surprises, and everyone will know what to do.”
+
+“I still have a few questions about Roman’s proposal,” chimed in Greg, the project’s chief engineer. “And a couple ideas of new things we could try. We need to make sure there’s still some flexibility in the plan and we’re able to take advantage of new ideas. The technology we’re talking about is still really new. I want to experiment with a series of prototypes and run a pilot with a few clinicians.”
+
+Roman cut him off. “Look, this isn’t a science fair project, and we can’t just play around with…”
+
+“Hey now,” interjected Greg, “Playing around is exactly what we should do, and it kind of is a science fair project. We’re talking about brand new digital technologies. We literally don’t know how this AI system works or what it can do. ‘Playing around’ is not frivolous, it’s about exploring and learning.”
+
+Roman sighed and sat back in his chair, rubbing his eyes.
+
+“I’m not against learning, Greg. We just need to do it the right way. That means following the procedures and having an approved plan, with milestones and predictable structure…”
+
+“Sure Roman, I’ll just put my next discovery on the calendar. How about I have a scientific breakthrough every other Thursday. Would that work for you? Or would you prefer Wednesdays?”
+
+“Or we could just use technology that already works, instead of playing around with stuff that we don’t understand and might not do what we need it to do. This is a program office, Greg, not a mad scientist’s lab. We have Tech Readiness Levels for a reason. Anything below a TRL 7 is just too risky to even consider. If we don’t know how the technology works, we literally can’t rely on it, and that means we’re doing it wrong.”
+
+“TRL 7? Seriously?” Greg barely managed to stay seated. “Do you have any idea how fast digital technology is maturing? If we limit ourselves to today’s TRL 7, by the time we get it on contract and delivered, the system will be obsolete, particularly given how slow your contracting approach would be. Given the pace of change in today’s digital environment, we should be looking at TRL 4 if we have any hope of avoiding irrelevance, and using innovative contracting methods that help us go faster.”
+
+“We can’t just be a loose cannon and do whatever you want…”
+
+“We can’t just be a bunch of bureaucrats and never try anything new…”
+
+“Guys, let’s keep it respectful,” said Yvette, wondering where this antagonism is coming from. She didn’t see anyone talking like this last week.
+
+“You’re right, sorry,” said Greg. “It’s just that this AI system is covering new ground, and it’s important that we have creative space to explore the tech. And yes, even play around with it. That’s why I proposed a modular contracting strategy based on rapid prototyping. The DoD is showing some excellent results with their Middle Tier of Acquisition pathway, and we should do something similar.”
+
+“Oh here we go again,” sighed Roman. “Greg, you’re a smart engineer. I’m sure you’ll come up with a ton of exciting new ideas if you play around long enough. But acquisition and contracting is my area, not yours. And have you heard about some of the problems the DoD is running into with those MTA projects? How about this - I won’t tell you how to write code or whatever, and you don’t tell me how to do a contract.”
+
+“Um, weren’t you telling me how to run my prototypes a minute ago?,” Greg responded. “And yeah, I should have a say on our Acq Strat! FAR 39.103 says agencies are supposed to use modular contracting to the maximum extent practicable when acquiring major systems of information technology. That’s what I’m…”
+
+“Yvette, this is why I proposed those roles and responsibilities,” Roman said, cutting off Greg and turning his attention to the Program Manager. “It will be chaos if everyone is in everyone else’s business. Do you really want engineers quoting the FAR? And let me point out that when the FAR uses the phrase ‘to the maximum extent practicable,’ that is not exactly a clear, unambiguous mandate. I strongly disagree with Greg’s suggestion that modular contracting is the right move here. It would make things less efficient and would be much riskier. The FAR gives specific guidance on how to do traditional, monolithic contracts, so that is much safer from a compliance perspective. Plus, how do we ensure full and open competition if we also require interoperability between modules from different vendors, which is definitely a requirement for an IT network like RAINBO? I promise we’d end up with a protest. This is why I recommend we don’t do a modular contract, and why we should leave questions like that to the experts.”
+
+“Yvette, I admit I’m not a FAR expert,” Greg responded. “And no, this isn’t an easy or risk-free approach. But if we’re looking for easy and risk-free, we’re in the wrong business. There are so many things we haven’t tried yet, so many new possibilities to explore. For example, the Periodic Table of Acquisition Innovation has some really interesting stuff in the Alternative Authorities section that we haven’t tried yet, and they directly relate to how we do the tech.”
+
+“Here you go again,” Roman answered. “But sure, since you mentioned the PTAI, I am interested in the Acquisition Automations section. My proposal aims to use stuff from that section to automate a lot of our work, which will be much more efficient.”
+
+The conversion continued for some time, with other members of the program office weighing in on their diverging preferences. After an hour, Yvette called for a pause.
+
+“I think maybe we need to take a break,” Yvette proposed. “Last week was a big event and there’s a lot to process, so let’s all get a breather.”
+
+---
+
+Back at her desk, Yvette hopped onto a video call with her mentor Nell. She shared the results of the recent program review and the subsequent staff meeting and the disagreements surfacing between team members. After listening carefully, Nell asked, “Before we get into the technical contracting issue, I have a question that’s a bit more foundational. What are you seeing emerge that is most important for Roman?”
+
+Yvette shook her head and said, “Roles and responsibilities and plans and processes and efficiency.” She continued, “Which is all well and good but I am worried that much structure will hamper our team’s collaborative vibe.”
+
+Nell smiled and said, “I understand your concern, though my question was only about what is most important for Roman, not how you feel about it.” Yvette noded and chuckled slightly at the familiar advice. It was not the first time Nell gently pointed out that Yvette was inserting her own point of view instead of staying focused on the issue at hand.
+
+Nell then asked, “What is most important for Greg?”
+
+Yvette replied, “Creating new things and having fun with them! Well, experimenting with them rapidly and prototyping them, which is fun for Greg.” She stopped herself before saying what else she was thinking, which is, “Sometimes Greg is so quick to move on to the next experiment he doesn’t stop to learn from the first or share what he has learned with the team.”
+
+“And what about you? What would you say is most important for Yvette?”
+
+Yvette sighed, “You know me, Nell. I want everyone to be supported and included. I’m a mentor, I care about each person’s professional growth and I’m in this for the long haul. I want Greg to be Greg, and Roman to be Roman, and all of us to be friends.”
+
+Nell reflected for a moment on what she heard from Yvette, then said, “I have a tool that might help understand these different views of what is most important. Would you like me to share it with you?”
+
+“Yes, please!” Yvette exclaimed.
+
+“It’s called the Competing Values Framework (CVF). It was first published back in 1983, as a result of some research into organizational culture, specifically around the question of what makes organizations effective. It’s been updated a bit since then, as you might imagine.
+
+“The model is based on the finding that most organizations can be described using two dimensions, represented by a horizontal and vertical axis each running between opposite or "competing" values. This creates four quadrants, each of which was assigned a color for reference. Here, take a look.”
+
+Nell shared her screen to show the diagram below and began to explain the image.
+
+
+
+“The x-axis is about an organization’s orientation, whether they prioritize looking internally or externally. The y-axis is about whether they prioritize being flexible or being focused.”
+
+In an aside, Nell added, “I love that the opposite of flexible isn’t inflexible, it’s _focused_. And the opposite of focused isn’t unfocused, it’s _flexible_. That is such a positive way of looking at the differences.”
+
+She continued, “The easiest way to understand it is to look at what happens in each sector. Let’s start at the top right, with the green quadrant. Organizations or people in this quadrant value being flexible and externally-oriented. The result is they put a lot of energy into exploring new ideas, being creative, and challenging limits. Green values doing things _first_, and they love surprises. In a word, the verb associated with this quadrant is _create_.”
+
+Nell continued, “The upper left quadrant, Yellow, is internally oriented, but still with an emphasis on being flexible. Organizations or people in this quadrant prioritize getting things done _together_, with an emphasis on stuff like shared values and culture. In contrast with the Greens, they talk about teamwork more than technology. The verb associated with Yellow is _collaborate_.
+
+“Moving down, the lower left quadrant is colored Red. This one is internally oriented like Yellow, but now with an emphasis on being focused instead of flexible. For organizations or people in this quadrant, doing things right is more important than doing things first or together . There’s an emphasis on nailing down our procedures and processes, examining systems to make them more efficient, getting things under engineering control so they’re repeatable, predictable, and stable. Reds tend to talk about policy more than people, and efficiency more than experiments. The verb associated with Red is control .”
+
+“Finally,” Nell said, “We arrive at the lower right quadrant, Blue. Here organizations or people are focused like Red, but looking externally, like Green. The predominant value here is about doing things _fast_. In the Blue quadrant, what matters most is competing and winning. They’ll do a lot of stuff like identifying and understanding the market, pursuing the metrics of competition, aiming to thrill their customers and crush the competition. If Reds have their eyes on the rulebook, Blues have their eyes on the scoreboard. The main verb here is _compete_.”
+
+“We all have our own tendencies and preferences along these two axes, right? Keep in mind that each one is a spectrum, not a binary choice. We can care about being flexible and being focused, but we generally have to prioritize one over the other. That means most people will identify with one or two quadrants more than the others. And that is where the “competing” part of the framework comes in.”
+
+She flashed up another picture on the screen.
+
+
+
+“We often see antagonism and friction across the diagonals (although it can also exist across verticals). Greens value flexibility and external-orientation, so they are all about creativity and exploration. Greens are constantly asking ‘What have we not tried yet?’ They love trying out innovative new ideas and technologies.
+
+“Meanwhile, the Reds value being focused and internally-oriented, so they’re all about predictability and efficiency. They prioritize following the rules and sticking to well-established procedures. They ask questions like ‘How can we get things under control?’ You can imagine what those two groups tend to think of each other.
+
+“Similarly, Yellows prioritize harmony and inclusion, and are always asking questions like ‘How can we support each other?” They are less likely to ask questions Blues care most about, like ‘How can we outperform the competition?’ I guess it’s possible to ask both questions at the same time, but there’s only room for one ‘most important thing’ at a time, so we’re bound to prioritize one over the other.”
+
+Yvette smiled with chagrin, thinking of the earlier staff meeting. “Yeah, I see how conflict over priorities limits a team’s effectiveness and hampers productivity.”
+
+Nell smiled back and said, “Yep!” She continued, “The good news is, there doesn’t have to be so much friction. Once teams understand the different values, and what each one brings to the table, they can take strides towards leveraging the different strengths from each quadrant and appreciating what each one contributes.”
+
+Then Nell pulled up one final diagram. “These are questions that can help us understand both our own values and also those of others. Take a look at this Yvette. Which color do you think you are? Hint - it’s probably aligned with the question you find most appealing.”
+
+
+
+“I am sure I am yellow.” said Yvette. “Bright yellow! I really focus on collaboration and ensuring everyone is supported. The other questions are important to me too, but not as much as the yellow question. I see now that not everyone on the team shares that value, as much as it hurts to admit that.”
+
+“Yes,” replied Nell. “All the values have their place, and depending on the situation, some values will be more effective than others. In fact, we likely will need to shift from one dominant color to another several times over the life of a project… or the life of an organization. Failure to make these transitions is one of the big reasons organizations fail.”
+
+“Wow,” said Yvette. “This is a little scary but also super helpful!”
+
+Yvette paused and thought before saying, “So if I’ve prioritized Yellow as we built the team, maybe another color - or value - should be in the driver’s seat for the project for a bit? Like, once we’ve considered some options, maybe we should shift from being flexible and considering options to making firm decisions and being focused? Or once we’ve done the internal work of building the team, we might shift to being externally oriented and prioritize users or market research?”
+
+“Maybe,” said Nell. “I was hoping you’d ask questions like those, and I think the CVF will help you explore some answers.”
+
+“Thank you Nell!” Yvette exclaimed. “As always, you’ve given me a lot to think about.”
+
+Yvette and Nell said goodbye and Yvette sat at her desk for another 15 minutes, thinking about what to do next.
+
+Later that afternoon, Yvette, Roman, and Greg all received an email from their user rep.
+
+> As we discussed at last week’s review, we urgently require the new AI-powered healthcare data management system. Swift delivery is crucial for us to perform our jobs effectively and maintain a competitive edge in the fight for people’s health.
+>
+> Please prioritize this project and provide an updated / accelerated timeline for system deployment. I don’t care if you use old acquisition strategies or new ones. I don’t care if you bend the rules or even break them a little. I care about getting the job done. Our ability to win hinges on the timely implementation of this technology.
+>
+> I'm available to discuss any ways we can expedite the process.
+>
+> Barb
+
+“Hi Barb,” Yvette muttered to herself as she read the terse email. “I’m fine, thanks for asking.”
+
+Then, remembering her earlier conversation with Nell, she re-read Barb’s email and thought, “Hmm. ‘Competitive… fight… accelerated… win…’ ”
+
+“I think I know what color quadrant Barb falls in!” she thought. “Now, what do I do about it?”
+
+---
+
+### Questions for students to consider
+ 1. What would you do next if you were Yvette?
+ 2. Which color do you personally identify with? (Unsure? Try [this CVF assessment]( https://www.boomhogeronderwijs.nl/media/8/download_pdf_culture_assessment_workbook.pdf))
+ 3. Which colors do the various characters represent (Roman, Greg, Yvette, Barb)?
+ 4. Do you agree that Project RAINBO has primarily focused on Yellow values so far? What makes you think so?
+ 5. Should the project team prioritize a different value in the next phase of the effort? If so, which one, and why? What acquisition and contracting strategies would that point to?
+ 6. Should the type of technology being acquired influence the team’s primary values?
+ 7. How would you go about proposing and leading a transition from one color to another?
+ 8. How can the team represent a perspective that is not directly represented by any of the core members (i.e., Barb the user rep)?
+ 9. How can the program office build a blended values set that includes a balance of all four colors?
+
+### Guide for instructors
+We recommend reviewing some online resources about the Competing Values Framework, such as [this introductory whitepaper]( https://www.thercfgroup.com/files/resources/an_introduction_to_the_competing_values_framework_white_paper-pdf-28512.pdf) by Dr Kim Cameron or [this overview](https://denverleadership.org/wp-content/uploads/2016/01/Competing-Values-Framework.pdf).
+
+Each character in the case represents a different color / quadrant from the CVF.
+ - Yvette, the program manager, represents the Yellow value. Her main goal is to do the work together, and she prioritizes collaboration. The question she is most interested in exploring is “how can we support each other.” She talks a lot about teamwork and community. Notice how the friction surprises her - is it possible it’s been there all along, and she just didn’t see it?
+ - Roman, the contracting officer, represents the Red value. His main goal is to do the work right, and he prioritizes being careful and complying with policy. Roman wants everything to be predictable, scalable, and reliable. The question he is most interested in exploring is “How can we be more efficient?” He talks a lot about process and consistency. Notice how he prioritizes correctness and procedure.
+ - Greg, the chief engineer, represents the Green value. His main goal is to do new things, and he prioritizes originality. The question he is most interested in is “What have we not tried yet?” He talks a lot about technology and ideas. Notice how he moves to the next topic before addressing the previous one.
+ - Barb, the user rep, represents the Blue value. Her main goal is to do the work fast, and she prioritizes competition. The question she is most interested in exploring is “How can we outperform the rest?” She talks a lot about performance. Notice how she is explicitly open to bending the rules to get the results she wants.
+
+These four perspectives represent “competing values,” and so the initial challenge is to navigate the tension between them. Invite the students to consider which color they most identify with, as well as the relative benefits and risks associated with each set of values. For example, if the Yellow values are in the driver’s seat, the team will feel well supported but might be slow to make decisions or might arrive at a consensus that is not entirely correct. If the Red values are in the driver’s seat, the team will comply with regulations and do things right, but might miss opportunities to introduce new ideas and innovations.
+
+Invite students to discuss how they might create space in the project for each value to be included. The CVF shows that the greatest friction tends to occur between diagonal colors (which represent opposite positions on both axes). So Roman and Greg (as Red and Green) will have the most friction, as will Yvette and Barb (as Yellow and Blue). Discuss how to manage these friction points.
+
+One of the primary findings from the CVF is that the most effective organizations are the ones who successfully transition from having one color in the driver’s seat to another. In this case, the predominant color is Yellow at the start of the effort, as shown by Yvette’s observations about how well everyone gets along (and the lack of attention to certain questions about process and technology). Encourage students to point out where the different values show up.
+
+Invite students to discuss both which color/value should take the lead next, as well as how to make that shift. What types of conversations, meetings, and/or decisions would be most effective to lead the team through this sort of transition? What would they do next if they were Yvette? For example, might Yvette introduce the CVF to her team? Or ask Nell her mentor to come give a presentation?
+
+Finally, invite the class to discuss how various acquisition and contracting strategies align with each quadrant. What risks and benefits do they see, and which path do they recommend?
+ - With Green in the driver’s seat, the team is likely to adopt creative interpretations of the FAR and try out new authorities and flexibilities - such as the “Alternative Authorities” from the PTAI, even if the selected approach is new, risky, or unpredictable.
+ - With Red in the driver’s seat, they are more likely to follow previously established precedents and traditional methods, where outcomes are predictable and deemed to be safe, even if they take longer or are less innovative.
+ - With Blue in the driver’s seat, the team will prefer using whatever acquisition and contracting method gets them to the next milestone fastest - with relatively little concern over whether the approach is new… or whether the implementation is strictly correct.
+ - Finally, with Yellow in the driver’s seat, the team will likely seek a compromise approach, which may result in a sub-optimal strategy that sacrifices a certain amount of innovation or speed or predictability in order to secure buy-in from all parties. Reaching this consensus is likely to take more time, relative to the other three options.
diff --git a/tech-far-hub/content/resources/case-studies/case-study-challenge-small-agency-legacy-application-migration.mdx b/tech-far-hub/content/resources/case-studies/case-study-challenge-small-agency-legacy-application-migration.mdx
new file mode 100644
index 00000000..c0ce300b
--- /dev/null
+++ b/tech-far-hub/content/resources/case-studies/case-study-challenge-small-agency-legacy-application-migration.mdx
@@ -0,0 +1,281 @@
+---
+slug: case-study-challenge-small-agency-legacy-application-migration
+template: case-study
+page_type: case-study
+heading: Case Study Challenge - Small Agency Legacy Application Migration
+promo_description: This case study reflects an authentic scenario that Acquisitions professionals could experience when procuring digital services to migrate a legacy on-premise application.
+media_image:
+media_alt_text:
+is_featured: true
+nav_weight: 10
+---
+By Scott Simpson
+
+
+This case study was a finalist selected as part of the [Digital Acquisition Professional Program Case Study Challenge](https://www.challenge.gov/?challenge=ditap-case-study). To see the original case study, click [here](../../../../tech-far-hub/static/assets/files/small-agency-legacy-application-migration-ditap-case-study.pdf).
+
+
+> [!NOTE]
+> All people and situations are fictional. No real people are depicted in the scenarios below. All images are AI generated and do not intentionally mimic any specific person.
+
+## Background
+A small federal agency has a legacy on-premise application that is twenty plus years old. The application is used to interact with the American public in order to meet the agency’s primary mission. Due to its age and design, the application is difficult to navigate and currently requires a human staffed help desk to walk users through the process. Even with this assistance, the application has a high percentage of non-completion, greater than 75% abandonment. Approximately 1 million citizens attempt to use to the application each year.
+
+The annual operations and maintenance costs are continually growing and as a small agency it is eating up more and more of the available budget. After years of requests, the agency finally received enough funding to begin the modernization process. However, because of a five-month continuing resolution, the funding was only just received and it now must be obligated within seven months, before the end of the fiscal year. Some market research and discovery has been completed in anticipation of receiving funds, but neither is complete.
+
+The agency is looking for a cloud-based application that includes modern business intelligence processes. The new application should also better match the American public to the services offered by this federal agency. It must integrate with the finance system allowing for funds transfers to citizens.
+
+## Scenario 1 – Market Research
+
+### Personas
+
+| Photo | Name - Role | Description |
+| --- | --- | --- |
+|  | Reva – Product Owner: | Reva is a long-time agency employee who has worked for multiple offices and is very knowledgeable about all of the agency’s missions. She is an Agile enthusiast, with a strong preference for customer focused design. She is pushing hard for flexible solutions to both the technical and procurement challenges. Reva is very friendly and polite. She is a natural leader who listens to everyone’s ideas and tries to find common ground. |
+|  | Lars - PM/COR | Lars has been with the agency for about six months, but has 10+ years of experience with the Department of Defense. He is used to doing things “the DOD way” and is struggling to adapt to the smaller agency lifestyle. He is very risk averse, but open to new ideas that are practical and proven. Lars has a brusque demeanor that many people find off putting. He often interrupts people mid-sentence with information that is off topic or irrelevant. |
+|  | Anton - Chief Information Officer | Anton has floated back and forth between Government and industry for 25 years. He joined the agency about 18 months ago, but is still looking to make his mark. Rather than build a coalition of partners to implement his ideas, Anton usually just releases new policies or mandates change. This has not been received well by agency personnel, including CXO colleagues. |
+|  | Gabriella - Chief Procurement Officer | Gabriella is a GS-15 under the Chief Financial Officer. She has 20+ years of procurement experience with civilian agencies and zero knowledge of non-FAR authorities. She is extremely customer focused and has a strong desire to meet mission. Last year an internal audit found minimal errors in the Procurement Office, however, the report noted that the Office did not do enough to meet competition requirements. |
+
+### Situation
+Reva (Product Owner), Lars (PM/COR), and Anton (CIO) have been working together for months to create user stories to support the legacy system migration. Anton is meeting with the Gabriella (CPO) for the first time hoping to begin the solicitation preparation.
+| Speaker | Dialogue |
+| --- | --- |
+| Anton: | Gabby, Congress approved my funds – finally! I'm ready to move out on the on-prem application transition. |
+| Gabriella: | I appreciate all the work you've done in preparation for this; however, I just don't think the package is ready. You've got all these user stories, which I'm unfamiliar with, but I don't see a statement of work or a PWS. Since you said this was an IT contract there is a strong preference to use performance-based contracting. Have your PM check out FAR Part 37. |
+| Anton: | I've got funding that expires in 7 months. I can't go back and start all over again. What am I supposed to do? |
+| Gabriella: | Your office just has to document the market research and get this PR submitted by the end of next week. If it’s received after that then you're going to need to route a waiver for approval up to the Chief Financial Officer, which is way above my pay grade. I’m just a 15 doing my best. |
+
+Hearing the news, Reva quickly organizes a call with Lars and Anton to discuss their strategy.
+
+| Speaker | Dialogue |
+| --- | --- |
+| Lars: | I say we just recycle the SOW from last time and submit that. It got us this far. |
+| Reva: | That might be the fastest way, but I don’t think it’s the right way. If we just use the last SOW, our users are going to have the same old challenges. We should award a quick 8(a) contract now to perform more discovery and have them create the PWS or whatever it was Gabriella mentioned. |
+| Lars: | Reev, you’ve got no idea what you’re talking about. I’ve been working on this IGCE for months and I’m not going to start from scratch now.|
+| Reva: | No one is even talking about the IGCE, Lars … |
+| Anton: | Okay, let’s take it down a notch. Reva, I don’t think your plan is going to get our funds obligated by the end of the year. We have enough information to make some quick changes to the SOW from last time and get it done. If we don’t get this thing started soon, we’re not going to get my system done in time. By the way I've got a vendor I'd like you to talk with, it's someone I worked with at my last agency. I know we can't direct it to them but I want to make sure that they have a chance to compete for this. So, make it happen. |
+| Lars: | Great, more work to do. Are we ever going to talk about contract type? I’m going to need at least a few weeks to draft the determination and findings that supports a cost reimbursable contract type. |
+
+### Objective
+
+The program office must:
+ 1. perform Market Research, and
+ 2. draft a requirements document.
+
+You work with the Program Management Office (PMO) as a liaison between the program team and the procurement office (sort of like a procurement analyst). Provide advice for how the program office could perform their two objectives, identifying potential challenges they may experience and possible solutions.
+
+Review with Reva and Lars common agile principles that should be (or should have been) considered when developing a public facing application.
+
+### Potential Solutions
+
+#### Have an in-depth conversation with Reva and Lars together
+| Speaker | Dialogue |
+| --- | --- |
+| PMO Liaison: | Lars, I understand that you’re worried about the IGCE and a D&F for cost reimbursable contract type. Let’s put that off to the side for now and talk about it again later. It’s not that it’s not important, but we can make the decision on contract type after we perform some market research. Maybe it’s even a question that we might want to put into the RFI. What do you think about that? |
+
+> [!TIP]
+> This puts the concern into a “parking lot” for later.
+
+| Speaker | Dialogue |
+| --- | --- |
+| Lars: | Alright, whatever. If this thing isn’t awarded on time, it’s not my fault. |
+| PMO Liaison: | Let’s post a quick request for information to SAM and tell vendors that this is most likely going to be awarded this fiscal year. |
+
+> [!IMPORTANT]
+> What type of information do you ask for? Do you send a copy to the CIO’s vendor?
+
+| Speaker | Dialogue |
+| --- | --- |
+| PMO Liaison: | After we look through the RFI responses, we can hold one-on-ones with some of the vendors to ask follow-up questions in real time. |
+| Reva: | Is that allowed? |
+| PMO Liaison: | Oh yeah, it’s fine. OFPP, that is, the Office of Federal Procurement Policy, released this whole Myth Buster series on industry communication years ago. I’ll send you a copy. |
+| Lars: | Sounds like a waste of time. What would we even ask them? |
+| PMO Liaison: | Well, I put together some draft questions based on what we’ve talked about, but we can ask them other things too. |
+
+##### Potential Questions to ask:
+ - Whether discovery should be done before award or if it can be included as part of the overall contract.
+ - What the best type of statement of requirement is for this type of work (SOO, SOW, or PWS).
+ - Ask about potential evaluation methods for the solicitation phase.
+ - Ask about possible technology solutions to better match the public to services (including AI, etc.)
+
+> [!IMPORTANT]
+> Are there any others?
+
+| Speaker | Dialogue |
+| --- | --- |
+| Lars: | These are good questions. Do we have to talk with everyone? |
+| PMO Liaison: | Nope, just the ones you want to. Maybe five RFI vendors? |
+| Reva: | What about discovery? We’re not done yet. |
+| Lars: | What is your hangup with discovery?! |
+| PMO Liaison: | Discovery is actually something we do every day, we just don’t call it discovery. If you’ve ever use Netflix or Pandora, you’ve been part of a discovery session. Those two apps ask what you like and don’t like and then recommend new content based on your answers. |
+
+> [!IMPORTANT]
+> What other every-day examples could you use to describe discovery?
+
+| Speaker | Dialogue |
+| --- | --- |
+| Lars: | Oh my goodness. Have you watched Black Mirror?! It is so good! |
+| PMO Liaison: | I’ll have to check it out. But you know, Reva. Discovery doesn’t have to be done before you start. Most agile companies can incorporate discovery sessions into their sprint plans, it’s just dedicating time to user feedback and iterative experimentation. We should ask some of them during our one-on-ones. |
+| Reva: | Okay, but that doesn’t solve our problem about the SOW or PWS. I need to get that written in like 2 days or I have to go through this whole PR waiver process. |
+| PMO Liaison: | What if we used a statement of objectives? That’s a lot easier to put together and it actual works better for an agile procurement anyways. |
+
+> [!TIP]
+> Tell them more about an SOO.
+
+| Speaker | Dialogue |
+| --- | --- |
+| PMO Liaison: | In fact, if you want, we can write the SOO together. It will only take a couple of hours, tops. And then you’re done! |
+| Reva: | Okay, you’ve convinced me. Let’s go for it! |
+| Lars: | Where did you learn about all of this stuff? |
+
+##### Additional Questions
+ - What other information would you share with them?
+ - How might Anton (CIO) have prevented some of this from happening?
+ - What else could Gabrielle (CPO) do to help ensure timely award?
+
+##### Agile Overview
+
+| Speaker | Dialogue |
+| --- | --- |
+| PMO Liaison: | Before writing your requirements, you should spend some time gathering user stories from all of your stakeholder offices. |
+
+> [!TIP]
+> Tell them more about user stories.
+
+| Speaker | Dialogue |
+| --- | --- |
+| PMO Liaison: | You should also consider holding discovery sessions with public users, especially those ones that didn’t complete the interaction with application. It would be great to know why they exited the application. Another great best practice is to design with the end in mind. This would mean talking with offices like security, privacy, accessibility to ensure that all of their requirements (ATO, 508 compliance, US web design standards, etc.) were included from the beginning. It would also help to avoid any surprises later in the process. |
+
+> [!IMPORTANT]
+> What other agile best practices you could advise the team to consider regarding their overall migration?
+
+## Scenario 2 – Solicitation
+
+The Market Research Report and statement of requirements was submitted on time and the funding was obligated to the PR. Gabriella (CPO) has assigned a Contracting Officer and Attorney-Advisor. When Gabriella read over the statement of objectives, she had concerns about gathering citizen data and shared the document with the Chief Privacy Officer, who is now sending a representative to attend IPT meetings.
+
+The initial CIO has left the agency to join a venture capital firm and a new CIO was quickly appointed from industry.
+
+| Photo | Name - Role | Description |
+| --- | --- | --- |
+|  | Helena - CO: | Helena joined the agency last year but only just transferred to the office supporting IT requirements. She held a $5 million warrant at a previous agency, but procured mostly professional, non-IT services from GSA schedule. Helena feels a little unprepared since the team has been meeting for several months without her and is struggling to fit in with the others. As the CO, Helena is very unsure of herself and often relies on others to make decisions or tell her whether something is allowable. |
+|  | Maya - Attorney-Advisor| Maya (they/them) tries to attend most meetings, but is often not present. When asked about whether something is required or possible, they often demur until they see the question/document in writing. Upon providing legal advice, Maya rarely cites statutes or GAO decisions and instead makes vague statements about the legality or risk of something. Maya uses very complex language and often drops legal jargon and phrases that need explanation, taking up precious time during the meetings. |
+|  | Kim - NEW Chief Information Officer | Kim has joined the agency from industry and is looking to make her mark. She has the grand idea to merge several systems together into one larger one to operate as a central place of record. Kim has already discussed this with other CXOs and mission leaders, who are excited about upgrading their systems and want a lot of new functionality. |
+|  | Nate - Privacy Officer | Nate has worked in privacy about seven years. He started off in IT, but has a passion for data privacy, especially as it relates to emerging technology. |
+
+### Situation
+
+Reva, the Product Owner, is meeting with Helena, the CO, for the first time. Helena has forwarded the invitation to Maya, attorney-advisor, and Nate, privacy officer. Lars is out of the office on vacation.
+
+| Speaker | Dialogue |
+| --- | --- |
+| Helena: | I’m the Contracting Officer that’s been assigned to your PR, the one about building some kind of legacy fund. |
+| Reva: | What? No, it’s about modernizing a legacy application that is currently housed on-prem and migrating it to a cloud-based environment, preferably FedRAMP aisle 3 at least. |
+| Helena: | Oh, sorry. Maybe I got mixed up. So anyways. The package included draft evaluation factors, but that’s not normally something the program office handles. I got a sample from my Branch Chief and I’m going to use it instead. Is that alright? |
+| Reva: | Well, I’d like to see the final before it’s released. I really think that our technical evaluators need to see the offerors perform some coding and ask them questions about their work so that they can pick the right vendor. |
+| Maya: | Let me just jump in here and say absolutely not. According to FAR 15.306, it is not permitted to have discussions with offerors until a competitive range is established. If you’re going to ask questions of the vendors then we’re going to have to give them a complete list of all of their strengths and weaknesses. I don’t think I’m prepared to approve that. |
+| Helena: | Thanks, Reva. Okay, so asking questions are off the table. What about this – coding challenge thing?|
+| Maya: | I don’t think it’s a good idea. A few years ago, I had another team try to evaluate a coding challenge. However, the Git repository wasn’t setup correctly and none of the code was saved. The agency had to request that all offerors redo their entire coding challenge. That team was extremely lucky that they didn’t receive a protest, a protest which I firmly believe the agency would have lost. We might not be so lucky this time and there is zero case law out there right now about coding challenges. |
+| Reva: | Anyone else got any bad news they want to share? |
+| Nate: | I’m actually really curious to know whether any of your potential solutions will consider artificial intelligence? |
+| Reva: | Yeah, they might. A few of the vendors we talked with as part of our market research had new modules coming out that incorporated the latest in AI. |
+| Nate: | Not to be the bearer of bad news, but that’s going to pose a challenge. I’ve heard through the grapevine that there’s a new Executive Order coming out of the White House about AI. |
+| Reva: | Another one?! |
+| Nate: | Yeah, and it applies specifically to applications that interact with the American public. I don’t have a copy of the language yet, but it could be a game changer. The Chief Privacy Officer is suggesting a pause on all AI procurements until the EO is released so that we can ensure we’re in compliance. |
+| Reva: | How long is that going to take? |
+| Nate: | I dunno. |
+
+Kim, the new CIO, scheduled a meeting with Gabriella to find out the status of the legacy application transition.
+
+| Speaker | Dialogue |
+| --- | --- |
+| Kim: | Gabriella, thanks so much for meeting me. I know that it’s third quarter and you’re probably swamped, so I’ll get right to business. I’m worried that if our requirement for the legacy app transition isn’t awarded soon, the Administrator is going to sweep my funding and give it to mission folks, which is going to be bad for us. We’ve only got five months left in the year! |
+| Gabriella: | My team has looked over the PR that was submitted and it looks like they have everything they need. The Contracting Officer should be working it now and be able to award it before the end of the year. Have they sent you the milestone schedule yet? |
+| Kim: | That’s just it, when they talked earlier this week it was not good news. What I’m really wondering is if we can turn this into a sole-source to get it awarded as fast as possible. |
+| Gabriella: | I don’t think we’re quite there yet. Our competition numbers aren’t doing real well this year, I’ve already signed more LSJs than I’m comfortable with. How about this. I have an Acquisition Innovation Advocate on my team, they usually have a lot of great ideas. I’ll have them meet with you and your team as soon as possible to make sure this is on track to be awarded by end of FY. |
+
+### Objective
+
+The CPO has requested innovation coaching to support this procurement and ensure it is awarded on time. You are acting as the Acquisition Innovation Advocate and innovation coach.
+
+Advise the team about an acquisition strategy that will be approved by all stakeholders.
+
+### Potential Solutions
+
+As the AIA, you setup a meeting with Helena (CO):
+
+| Speaker | Dialogue |
+| --- | --- |
+| AIA: | This all has to be really confusing for you since you’re just joining the team. We should do some ice breakers at our next few meetings so that you get to know everyone! Let’s talk first about your role as the CO. FAR 1.102-5 says that as the CO, you should be the one to take the lead in encouraging business process innovations and ensuring business decisions are sound. Maya, our attorney, and Nate with Privacy, are just advisors to you. I’ve got a few resources that I think might help you streamline this procurement and get it awarded on time. The first one is the DHS Procurement Innovation Lab. They’ve got some trainings you can take and some literature you can read. You should also check out the Periodic Table of Acquisition Innovations, which most of us just call the PTAI. It’s got samples of how other agencies have used innovations and GAO cases that support them. Since you’re new to IT procurement, I don’t know if you’ve heard about the DITAP program yet. |
+
+> [!TIP]
+> Explain the program.
+
+| Speaker | Dialogue |
+| --- | --- |
+| AIA: | Our agency might be small, but we’ve got over a dozen COs that have been through the training. I’ll introduce you to a few and maybe they can help. |
+| Helena: | I heard that the CIO really wants me to sole source the award just to get it done. |
+| AIA: | Five months should be lots of time to award this contract. But, just in case, I’ll reach out to our industry liaison and talk to them about whether they know of a Small Business Innovation Research (SBIR) vendor we can make a quick award to. An SBIR Phase 3 isn’t considered a sole source, the competition was already done as part of Phase 1 and 2, so that should be okay with our CPO. But I’ll talk to her about it too. By the way, That coding challenge Reva suggested is a good idea. It might shave off a week or more from the evaluation time. |
+
+> [!TIP]
+> Tell her more about why.
+
+| Speaker | Dialogue |
+| --- | --- |
+| Helena: | Maya is never going to let me do a coding challenge. And even if she did, I’ve no idea how to run one! |
+| AIA: | First off, Maya’s is only offering advice. There are a few GAO cases about coding challenges. I’ll send them over for you to take a look. Second, maybe you don’t even need a coding challenge. What if you just had an oral presentation and asked the offerors how they would go about coding the application? I don’t think Reva and Lars have the resources to prepare for a coding challenge right now anyways. This would save everyone time, including the offerors. |
+| Helena: | I don’t think that’s going to meet the evaluators’ needs. Maya still won’t let them ask any questions. |
+| AIA: | Well, I’m not sure Maya’s right about that either. The GAO has consistently said that a critical part of discussions is allowing the offerors an opportunity to revise their earlier proposal. Plus, you might not even be in FAR Part 15.3. Maybe you’ll use the GSA Schedule to award this under 8.4 and you can use select best suited, then negotiate instead of discussions. |
+
+> [!TIP]
+> Tell them more about this.
+
+| Speaker | Dialogue |
+| --- | --- |
+| AIA: | And hey, if you still can’t convince Maya, then maybe you can use some static questions, ones that you’d ask every vendor. “Tell me about how you would use the agile principles to migrate a legacy on-prem app to the cloud?” It’ll give the evaluators some great insight. And you can ask them on the spot so offeror’s don’t have a chance to rehearse them. |
+| Helena: | I like that idea! |
+| AIA: | You could invite Maya to attend the oral presentations too. That way they see what’s going on. |
+| Helena: | Ha! Like Maya has time for that. |
+| AIA: | And remember too, if there’s a vendor out there that doesn’t agree with your approach, whether it’s a coding challenge or an oral presentation, they have to protest the solicitation, before proposals are submitted. |
+| Helena: | That’s a really good point. I’m feeling a lot better about this whole coding challenge thing. What about Nate’s concern with that new AI EO that’s coming out. |
+| AIA: | I know someone from the AIA Council who works over at the Office of Federal Procurement Policy. I’ll reach out and see what they know. But I wouldn’t worry about an EO that might or might not come down before you make an award. It might be another opportunity to use the select best suited, then negotiate approach. Before you go, let’s setup our next meeting so that it doesn’t get lost in the shuffle. How about meeting every two weeks for a quick check in? I usually meet with teams for just 15 minutes and we talk about accomplishments for the last two weeks, goals for the next two weeks, and if there are any challenges. |
+
+At the next meeting between Helena and the AIA:
+
+| Speaker | Dialogue |
+| --- | --- |
+| Helena: | I’ve been doing a ton of reading since we talked last week. Have you watched these PILCast videos on YouTube? They’re so great! Anyways, I wanted to run my acquisition strategy by you real quick before I route it for review. |
+| AIA: | Go for it! |
+| Helena: | So I’m thinking about a two-phased advisory down select. For Factor 1, Reva has some good corporate experience questions, like ability to demonstrate previous experience transitioning on-prem legacy application of similar size and conditions from to cloud. I think that I’ll advise about three offerors to proceed. If we get four, that’s okay too, but I don’t think we will. I’ll give them about 2 weeks to prepare for Phase 2, which is going to be just an oral presentation and price. |
+| AIA: | Are you going to give them the oral presentation topic beforehand? |
+| Helena: | No, they’re all going to be provided on the spot that morning with just a little bit of prep time. And I took your advice about select best suited, then negotiate, since I’m not in FAR Part 15. I’m going to include that for both technical, price, and clauses. So, if that EO comes down, which thanks to your friend at OFPP is unlikely, we can always talk with the vendor to include it. I’ll use the best value tradeoff to make my award. It should be done 2 months from now. Time to spare! |
+| AIA: | That sounds like a great approach! Great job, Helena! |
+| Helena: | I couldn’t have done it without you. |
+
+#### Additional Questions
+ - How would you address the new CIO’s idea about including additional systems within the migration?
+ - Is there any other advice you would give to the Contracting Officer or CPO?
+ - Is there any additional advice you would give the Program Office?
+
+## Learning Outcomes
+
+Learning objectives include applying the agile process, demonstrating knowledge of user centered design, sprints/backlogs and innovative procurement techniques, and recognizing the need for early engagement with stakeholders.
+
+The case study highlights the importance of communication among the stakeholders and users in order to develop an application that responds to the needs of all. Providing accessible digital services to the American public is a crucial challenge that the government is facing.
+
+Specific measurable outcomes include improved efficiency and stakeholder satisfaction, cost savings, and the ability to award a procurement on time.
+
+## Instructor Guidance
+
+There are many different ways to present this case study.
+ - Have different students read/act out roles (PO, PM, CO, CS, etc.) and then identify challenges/blockers and potential solutions.
+ - Have students read silently, then discuss in groups.
+ - Have students read just one section aloud, and then respond to just that one challenge.
+ - Have students read at home and prepare a “skit or scene” for how their challenge might be overcome.
+
+There are also different ways to focus on the overall challenges.
+ - Technical challenges.
+ - Agile challenges.
+ - Procurement challenges.
+ - Personal interaction challenges.
+ - Communication/collaboration challenges.
+
diff --git a/tech-far-hub/content/resources/case-studies/case-study-challenge-so-you-want-to-replace-a-legacy-system.mdx b/tech-far-hub/content/resources/case-studies/case-study-challenge-so-you-want-to-replace-a-legacy-system.mdx
new file mode 100644
index 00000000..84312d11
--- /dev/null
+++ b/tech-far-hub/content/resources/case-studies/case-study-challenge-so-you-want-to-replace-a-legacy-system.mdx
@@ -0,0 +1,261 @@
+---
+slug: case-study-challenge-so-you-want-to-replace-a-legacy-system
+template: case-study
+page_type: case-study
+heading: So, You Want to Replace a Legacy System…
+promo_description: This case study reflects an authentic scenario that Acquisitions professionals could experience when procuring digital services to replace an aging, custom-built legacy tool.
+media_image:
+media_alt_text:
+is_featured: true
+nav_weight: 10
+---
+By Jacob Akervik
+
+
+This case study was a finalist selected as part of the [Digital Acquisition Professional Program Case Study Challenge](https://www.challenge.gov/?challenge=ditap-case-study). To see the original case study, click [here](../../../../tech-far-hub/static/assets/files/so-you-want-to-replace-a-legacy-system-ditap-case-study.pdf).
+
+
+## Student Scenario
+### Your Role
+
+You work for a medium-sized Federal department. You are a certified COR and/or P/PM, and even though you have experience, this is not your only job function. In your Department there is not always a large difference between the Contracting Officer Representative (COR) and Program/Project Manager (P/PM) roles. You are not in the Chief Information Office (CIO).
+
+### What’s Happening
+
+A business unit within your office came to your team with needs for a new IT system (custom-built) or service (Commercial Off the Shelf (COTS) or Software as a Service (SaaS)) to replace an aging legacy tool. You are not a Subject Matter Expert (SME) in that area.
+
+The current tool was custom-built and has long been on an O&M (Operations and Maintenance) contract with no Development, Modernization, and Enhancement (DME) funding even though new needs have arisen since the tool was built several years ago. The current contract expires in six months. There is still one more six-month extension that could be exercised if leadership agrees, and your management needs to avoid any breaks in service. If there are any breaks in service, it will have critical impacts. The current provider is not a small business.
+
+Your initial market research shows there are several potential offerors, a mix of large and small businesses. Some are policy experts who pair with IT subcontractors. Others have COTS/SaaS solutions geared toward state and local government needs related to the relevant programs and funding, but they have not worked with the Federal government before.
+
+In this Department there’s no official centralized Project Management Office (PMO), so business units and P/PMs-CORs are expected to coordinate IT projects across the enterprise to include the business unit; the Acquisition/Procurement Office (APO); the Privacy Office (Privacy); and the aforementioned CIO, which includes the Cybersecurity Office (CyberSec); etc.
+
+### The Icing on the Cake
+
+Oh, and one final piece of information: your senior leadership wants Customer Experience (CX), Artificial Intelligence (AI), Cybersecurity (ATO, etc.), and Privacy (PIA, SORN, PII, etc.) addressed in all new IT systems and services plans, projects, and contracts.
+
+P.S. Plus they want costs reduced under any new contract.
+
+P.P.S. They also need to hit small business contracting targets this year.
+
+### General Student Instructions
+> [!CAUTION]
+> For all exercises, take care not to disclose any sensitive, secret, or non-public information.
+
+ - Unless your instructor provides different instructions, follow the exercise instructions.
+ - Your final task is to use the information from the front matter and exercises to write the body of a 1–2 page options and recommendations memo to your leadership.
+
+### Additional Notes from your Meetings
+
+| Leadership | CIO |
+| --- | --- |
+| Wants this completed ASAP, preferably by the end of next FY | Will be required to ask OCIO for Development, Modernization, and Enhancement (DME) funding if you want a new custom system, which will require asking for money through the two-year Capital Planning and Investment Control (CPIC) process |
+| Thinks we already spend too much money on the current solution and that a new solution can be both better and cheaper; is this even possible? | If your office is willing to bring Operations and Maintenance (O&M) money from your Salaries and Expenses (S&E) to the table for a COTS/SaaS solution using O&M only, the project may be able to be accomplished sooner but will have fewer customizations |
+| Wants to prioritize using a small, disadvantaged business provider | |
+| Your top senior leader is a consensus builder, and the team is split: half innovators (risk tolerant) and half bureaucrats (risk averse) | |
+| VERY focused on CX, AI, and DEI due to Executive Orders and risks | |
+
+| CyberSec | Business Unit |
+| --- | --- |
+| After procurement is complete, the Authority to Operate (ATO) will take four months if the solution is FedRAMP’d, six months if not | Is under a lot of pressure from leadership to get this done |
+| Needs to know who you are planning to assign as Information Systems Security Officer (ISSO) | Doesn’t like their current system, but is also hesitant to go through the process of moving to a new solution due to fear of lack of resources, time to learn and train, etc. |
+
+| Privacy | APO |
+| --- | --- |
+| Solution will contain Personally Identifiable Information (PII) | Not including the optional six-month extension, the time to complete a new acquisition will take nine months |
+| The Privacy Impact Assessment (PIA) and System of Records Notice (SORN) processes will take approximately six months to complete from the end of the acquisition process | Acquisitions must be completed by then end of August because there is an end of FY/beginning of FY contracting blackout for year-end activities from September through October |
+| Will any of this require a Paperwork Reduction Act (PRA) approval? | |
+
+| CX/AI | DEI |
+| --- | --- |
+| Find and read Executive Order 14058 | Accessibility (Section 508) is critical to any DEI and risk analyses for all new IT projects |
+| What does Artificial Intelligence actually entail in practice? | |
+
+## Exercise 1: Choose your system or service and begin to assess your options
+### Student Instructions:
+
+Per your instructor, as individuals or as a team, you will either be assigned or choose a real or imagined scenario in which you begin to identify the various components of feasibility for an IT project to solve the business needs outlined.
+
+For all options, assume and imagine your existing system is old, outdated, and only handles the basics compared to what a new solution could provide. The specifics are less important than the general idea that the new solution should (hopefully) be better and faster.
+#### Options to consider:
+ 1. **Customer Relationship Management (CRM)** for tracking service requests, status, resolution, information from partners, stakeholders, and customers.
+ 2. **Enterprise Resource Planning (ERP)** for Departmental and/or office/program assets such as budget, finance, funding, grants, HR, infrastructure, etc.
+ 3. **Content Management System (CMS)** which helps edit and publish one or more external (internet) and/or internal (intranet) websites with multiple web pages.
+ 4. **Science, Technology, Engineering, Mathematics (STEM)** software and/or hardware.
+ 5. **Choose your own general or specific business need** which has a potential IT system or service solution.
+
+Record your choice in a location and format you can easily access later.
+
+## Exercise 2: Use a search engine to find three examples of this type of solution
+*Example:* Find three popular solutions and/or solution providers. Can you also find at least one Federal government use example? E.g. Federal contract/contractor, FedRAMP, GWAC, etc.
+
+| # | Solution Example | Link/Source | In use by Federal government? |
+| --- | --- | --- | --- |
+| 1. | | | |
+| 2. | | | |
+| 3. | | | |
+
+
+## Exercise 3: Scope and Business Needs
+### Student Instructions:
+
+Assume the new solution will have a broader scope than the existing solution.
+
+Fill in a chart like the one below by beginning to brainstorm potential answers to the following questions:
+
+ - What’s are the potential or likely most important things these individuals or groups need or want out of a new solution?
+ - What are the key pieces of information or data to consider for the different audiences?
+ - What are the ways in which you might gather information about what each of these groups need or want out of a new solution?
+
+#### Business Needs
+| Audience| Primary Need(s)| Secondary Needs or Wants | Methods of Gathering Needs | Key Performance Indicators/ Target Demographics |
+| --- | --- | --- | --- | --- |
+| Senior Leadership | | | | |
+| Office/Program leadership | | | | |
+| Partners, stakeholders, customers | | | | |
+| End users | | | | |
+| General Subject Matter Experts | | | | |
+| Technologists (Tech SMEs), ex: IT, web, data, GIS, etc. | | | | |
+| Other audiences | | | | |
+
+## Exercise 4: Schedule, Cost, and Other Typical Variables
+### Student Instructions:
+
+As you begin to assess your options, answer the following questions about the various options compared to the current basic system:
+ 1. **Costs**: Will a new solution likely cost more, less, or the same?
+ 2. **Schedule**: How long will each option take to implement?
+ 3. **Budget**: If costs increase or Development, Modernization, and Enhancement (DME) funding is needed, where will this money be obtained and how long will it take?
+ 4. **Return on Investment**: Are there any ways in which ROI can be calculated? For example, how many Full Time Employees (FTE) does the current system replace?
+ 5. **Small/Disadvantaged Businesses**: Are there any 8(a) sole source options? If not, are there any GWAC solutions, like small businesses that resell the solution for a larger business?
+
+#### Options
+| Variables | Keep Current System| Upgrade Current System or New Custom System | Obtain New SaaS or COTS|
+| --- | --- | --- | --- |
+| Costs | Similar | Costs of DME and customization vs COTS/SaaS service and configuration | What will be lost without the ability to customize? |
+| Schedule | Any advantages to recommending keeping? | How long does it take to upgrade or build a new system? | How long |
+| Budget | Already budgeted for the next 12 months |DME requires justifications and time to obtain | O&M is faster but may not lead to as robust a solution |
+| ROI | Status quo | Does customization save money or cost money in the long term? | Does a leaner but more rapid solution lead to a better outcome? |
+| Small and Disadvantaged Business Options | Current provider not a small business | Can a small business handle what the larger business did? | Are there an adequate number of potential providers? |
+
+## Exercise 5: Risk, Innovation, and FedRAMP
+### Student Instructions
+
+Create a list of both positive and negative risks, along with the basic risk calculation, and answer the FedRAMP questions below.
+
+Contrary to popular belief, not all risks are negative. Positive risk is often ignored, and can often be defined as the same as, or similar to, innovation.
+
+From [FEMA.gov](https://emilms.fema.gov/is_0036a/groups/41.html#:~:text=Risk%20is%20the%20Impact%20rating,3%20x%205%20%3D%2015)
+
+> Risk is the Impact rating multiplied by Probability rating, with the resulting number as your Risk. Let’s say you live near a river and have experienced flooding in the past. You rated the Impact at 3 and the Probability at 5 so your Risk would be 15 (3 x 5 = 15). Go through your hazard list and multiply the Impact rating by the Probability rating.
+
+
+
+ - Positive Example: A new email communication solution will be able to help us reach thousands more partners, stakeholders, and customers, which will have a high impact on our engagement reach and numbers.
+ - Negative Example: The more our email distribution list grows, the greater our costs.
+
+| Variables | Keep Current System| Upgrade Current System or New Custom System | Obtain New SaaS or COTS|
+| Risk Description | Impact (1=Low, to 5=High) | Likeliness (1=Low, to 5=High) | Impact x Likeliness = Risk (1 - 25) | Positive or Negative Risk? |
+| | | | | |
+
+#### The Federal Risk and Authorization Management Program (FedRAMP®)
+ - Visit https://www.fedramp.gov/program-basics/. Go back to your original list from EXERCISE 2; are any of the examples you found FedRAMP authorized? https://marketplace.fedramp.gov/products
+ - Why might it be beneficial to consider FedRAMP authorized solutions?
+
+## Exercise 6: Artificial Intelligence
+### Student Instructions
+
+Explore the Federal AI use case inventory and either use the existing use cases; come up with your own; or a combination thereof. https://ai.gov/ai-use-cases/
+Fill in at least three AI use cases for your potential solution.
+
+| # | Use Case | Source | Description |
+| --- | -- | -- | -- |
+| 1. | | | |
+| 2. | | | |
+| 3. | | | |
+
+## Exercise 7: DEI or IDEA?
+
+While we often hear about the terms Diversity, Equity, and Inclusion (DEI), we don’t always include Accessibility in the discussion.
+
+As it relates to technology, Accessibility is often tied to Section 508: https://www.section508.gov/
+
+However, DEI, DEIA, IDEA, or whatever acronym we want to use, involves more in the technology realm than just ensuring that people who have visual or auditory impairments can utilize software or a website.
+
+### Student Instructions
+ - Review this article and report from the National Academies of Sciences, Engineering, and Medicine on **Advances in Facial Recognition Technology Have Outpaced Laws, Regulations; New Report Recommends Federal Government Take Action on Privacy, Equity, and Civil Liberties Concerns** https://www.nationalacademies.org/news/2024/01/advances-in-facial-recognition-technology-have-outpaced-laws-regulations-new-report-recommends-federal-government-take-action-on-privacy-equity-and-civil-liberties-concerns
+
+Answer the following questions:
+ - Which Section 508 considerations do potential solutions need to consider?
+ - What broader IDEA concerns might this or other new technology address or exacerbate?
+ - Do any of the potential solutions I’ve found have Voluntary Product Accessibility Templates (VPATs)? If so, where did you find them?
+
+## Final Exercise 8: Options and Recommendations Leadership Memo
+### Student Instructions
+
+Use the information from the prior exercises to construct a draft options and recommendation memo to your leadership. You should concentrate on the body of the memo.
+
+The total length of the memo will not be more than two pages, so the body of the memo should not take up more than 1.5 pages to allow space for the memo header. Consider the following:
+
+ - Should I place the top recommendation at the beginning or end of the memo?
+ - How should I order the other options?
+ - Should I include options that aren’t recommended?
+ - Which pieces of information from each EXERCISE are worth including for leadership, and which are worth saving for a discussion or presentation?
+ - Should any pieces of information, such as negative risks, be excluded?
+
+Draft memo body notes in a format similar to the following:
+```
+Top Recommendation:
+
+Options (ranked):
+
+Additional Recommendations:
+
+Top notes from each exercise:
+ 1.
+ 2.
+ 3.
+ 4.
+ 5.
+ 6.
+ 7.
+ 8.
+```
+
+## Select Additional Resources
+ - Federal Project Management: https://www.fai.gov/resources/toolkit
+ - Capital Planning and Investment Control (CPIC): https://www.cio.gov/policies-and-priorities/cpic/
+ - The Executive Budget Process Timeline: In Brief Updated February 23, 2024: https://crsreports.congress.gov/product/pdf/R/R47088
+ - Agency-specific Acquisition Regulations: https://www.acquisition.gov/content/regulations
+ - GAO What are the Biggest Challenges to Federal Cybersecurity? (High Risk Update June 2024): https://www.gao.gov/blog/what-are-biggest-challenges-federal-cybersecurity-high-risk-update
+ - Customer Experience:
+ - https://digital.gov/topics/customer-experience/
+ - https://www.performance.gov/cx/
+ - https://coe.gsa.gov/coe/customer-experience.html
+ - Artificial Intelligence:
+ - https://www.opm.gov/data/resources/ai-guidance/
+ - https://coe.gsa.gov/coe/ai-guide-for-government/introduction/
+ - https://www.cio.gov/tags/artificial-intelligence/
+ - Market Research https://www.gsa.gov/sell-to-government/step-1-learn-about-government-contracting/conduct-market-research
+ - Governmentwide Acquisition Contracts (GWACs): https://www.gsa.gov/technology/it-contract-vehicles-and-purchasing-programs/governmentwide-acquisition-contracts
+ - DEIA Executive Order 13985: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/06/25/executive-order-on-diversity-equity-inclusion-and-accessibility-in-the-federal-workforce/
+
+## Student Notes/Questions/Answers
+
+Please see page 11 of the [original case study](../../../../tech-far-hub/static/assets/files/so-you-want-to-replace-a-legacy-system-ditap-case-study.pdf) for a suggested notetaking format and resource.
+
+## Instructor Guidance
+
+> [!NOTE]
+> This instructor guidance section is included on a separate last page so it can be more easily excluded from the file or printout for the student.
+
+This case study is designed to allow for maximum flexibility and creativity for use across different individuals, teams, and groups in the Federal government.
+
+For each relatively short exercise, a brief set of student guidance is provided in each section. The goal is to make each exercise reasonably short while also capturing an important component of the broad base of knowledge needed by Federal government Digital Information Acquisition Technology Professionals (DITAPs).
+
+For anyone in Federal government, learning to write a quality options and recommendations memo for their boss or leadership is a key skill. The end goal of the exercises is to lead the students into that final exercise: writing the body of a memo to their leadership which gives their leadership options while also including a top recommendation. Students should be able to use pieces from each of the exercises preceding the final memo exercise to build their memo.
+
+### Instructor Notes/Questions
+
+Please see page 13 of the [original case study](../../../../tech-far-hub/static/assets/files/so-you-want-to-replace-a-legacy-system-ditap-case-study.pdf) for a suggested notetaking format and resource.
+
+
diff --git a/tech-far-hub/content/resources/case-studies/case-study-challenge-the-agile-shift-at-hhs.mdx b/tech-far-hub/content/resources/case-studies/case-study-challenge-the-agile-shift-at-hhs.mdx
new file mode 100644
index 00000000..d3c684da
--- /dev/null
+++ b/tech-far-hub/content/resources/case-studies/case-study-challenge-the-agile-shift-at-hhs.mdx
@@ -0,0 +1,230 @@
+---
+slug: case-study-challenge-the-agile-shift-at-hhs
+template: case-study
+page_type: case-study
+heading: The Agile Shift at the Department of Health and Human Services (HHS)
+promo_description: Health & Human Services (HHS) adopted Agile methodologies to improve acquisition efficiency, responsiveness, and effectiveness. This case study delves into the multifaceted challenges encountered during this transition.
+media_image:
+media_alt_text:
+is_featured: true
+nav_weight: 10
+---
+By Engineering Dynamics
+
+
+This case study was a finalist selected as part of the [Digital Acquisition Professional Program Case Study Challenge](https://www.challenge.gov/?challenge=ditap-case-study). To see the original case study, click [here](../../../../tech-far-hub/static/assets/files/the-agile-shift-at-hhs-ditap-case-study.pdf).
+
+
+## Summary
+HHS adopted Agile methodologies to improve acquisition efficiency, responsiveness, and effectiveness. This case study delves into the multifaceted challenges encountered during this transition, including migrating legacy data, navigating the complexities of bridge contracts amidst protests, and ensuring minimal downtime while transitioning to a system managed by a new vendor. Beyond the technical complexities, this narrative delves into the critical areas of conflict management, stakeholder engagement, and the delicate balance between adhering to Agile principles and navigating legal considerations. Through this lens, the case study sheds light on the nuanced strategies employed to foster collaboration, manage disputes, and align diverse stakeholder interests while navigating the legal frameworks that govern procurement and project management within the public sector.
+
+For additional insights and discussion questions, please consult the instructor's guide when the following occurs:
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+ ## [Section 1] Background
+
+In the heart of the nation's capital, the United States Department of Health and Human Services (HHS) embarked on an ambitious journey to revolutionize how clinical trial data was shared and utilized. In recent years, HHS utilized the traditional acquisition approach to deploy a Centralized Storage System (CSS), a secure platform for storing sensitive clinical trial information. This project, intended to streamline data sharing and improve accessibility for researchers nationwide, quickly became a textbook example of how acquisition can fail.
+The team meticulously planned the project, outlining a comprehensive scope and a detailed schedule spanning several years. Multiple Subject Matter Experts (SMEs) and senior management supported the initiative, while rigorous legal review and guidance from outside consultants ensured the project's thorough preparation for success. The project utilized the waterfall model, characterized by its linear, sequential approach. This methodology relies on comprehensive planning at the project's outset, with each phase (conception, initiation, analysis, design, construction, testing, implementation, and maintenance) completed before the next begins. This approach offers predictability and a clear structure, aligning with the government's need for accountability.
+Each project phase, from requirements gathering to implementation, was to be completed sequentially, with no overlap. However, as the project unfolded, several critical issues emerged:
+
+ - **Rigid Structure:** The waterfall method's linear structure proved its Achilles' heel. Halfway through the project, new technological advancements and changes in federal data protection regulations necessitated significant changes to the project's scope. However, the rigid structure of the waterfall approach made it exceedingly difficult and costly to incorporate these changes, leading to extensive delays.
+ - **Delayed Feedback:** Stakeholder feedback occurred only after the implementation phase. Gathering feedback revealed a stark misalignment between the system's functionalities and the users' current needs. Correcting these misalignments required a complete redesign, further escalating costs, and extending the timeline.
+ - **Cost Overruns:** Initially budgeted at several million dollars, the project's final cost ballooned to nearly quadruple the original estimate. The delays caused by the rigid project structure and the need to redo work to accommodate late-stage changes and feedback contributed significantly to the cost overruns.
+ - **Obsolete Technology:** The technology platform was outdated when the new system was ready for deployment. The rapid pace of technological advancements in data management and security meant that the system was already obsolete before it was fully operational.
+ - **Reduced Requirements:** Due to escalating costs and mounting pressure from management to deploy the system, the team was forced to release a stripped-down version that lacked essential functionalities such as search capabilities, collaboration, and user customization options, severely limiting its utility and effectiveness for end-users.
+ - **Data Rights Oversight:** A critical oversight occurred when the project team did not secure the necessary data rights for the clinical trial information. This lapse meant that HHS had limited control over how the data could be used and shared, restricting the system's ability to integrate with other services. The failure to acquire these rights stemmed from an assumption that existing agreements would suffice, a mistake that proved highly costly regarding operational flexibility and the high licensing fees required to obtain the rights post-deployment.
+ - **Cybersecurity Failure:** The system failed an independent cybersecurity audit. Outdated security protocols and inadequate data encryption practices, which had not been updated to meet current threats due to rushed deployment, caused the failure. The failed audit required immediate remediation to protect sensitive clinical trial data, incurring additional unexpected expenses and further eroding stakeholder confidence.
+
+The fallout from the project's shortcomings was immediate and significant. Major news outlets published critical analyses of the government's handling of clinical trial data, portraying the failures as symptomatic of broader inefficiencies in government procurement processes. This national attention led to a congressional investigation into handling sensitive data and the decision-making processes behind the project's issues. Although the inquiry found that federal procurement guidelines were followed, it placed HHS under intense scrutiny, sparking discussions on the need for modernization in acquisition and project management practices.
+
+The failed upgrade prompted HHS to reconsider its traditional waterfall acquisition method. Leaders recognized that this approach was ill-suited for the dynamic nature of technology and healthcare projects. The inflexibility of the waterfall model, along with delays in stakeholder feedback and frequent cost overruns, highlighted the necessity for a more adaptable methodology. This shift aimed to ensure the delivery of a system that met current needs and utilized up-to-date technology, acknowledging that traditional methods could no longer keep pace with rapid advancements in the field.
+
+HHS leadership, under the Deputy Secretary, made a pivotal decision to adopt Agile methodologies during the transition to a cloud-based system. Agile's flexibility allowed for continuous evaluation and adaptation, addressing changes in technology, regulations, and user feedback. This approach promised a user-centric development process, facilitating incremental delivery and regular feedback to align the project with actual user requirements while minimizing costly post-deployment modifications.
+
+Despite enthusiasm for Agile, concerns lingered due to previous failed implementations in other government entities. The Assistant Director recognized that Agile is transformative but not universally applicable. The methodology's emphasis on rapid iteration can clash with governmental constraints, leading to scope creep and unclear project direction. The transition to Agile required substantial training and cultural change within HHS to fully realize its benefits, necessitating a commitment to adapting Agile principles to the unique challenges of government work.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 2] Key Personas
+
+HHS leadership recognized the need for a project leader who could navigate the complexities of such a shift within the government framework. They chose Taylor Bennet as the project lead based on a proven track record of spearheading innovative projects and an ability to inspire cross-functional teams toward achieving common goals. Understanding that the success of the transformation hinged on more than just technical skills—it required a blend of expertise, adaptability, and a shared commitment to innovation and efficiency—Taylor was the ideal candidate to lead this charge.
+
+| **Taylor Bennet;** Deputy Director, Business Innovation Division, Advanced Research Projects Agency for Health (ARPA-H) |
+| --- |
+| - **Background:** Taylor is a scientist with charisma, possessing a rare blend of technical expertise and the ability to communicate complex ideas in an engaging, accessible way. This unique combination has propelled Taylor to the forefront of procurement modernization and efficiency, marking them as pivotal in government operations. A sharp eye for innovation and robust technical expertise, complemented by a friendly and jovial demeanor, marks Taylor's dynamic career. Combined with a genuine enthusiasm for Agile methodologies, Taylor can effectively motivate and rally teams around a mission with unwavering optimism. Despite not being a formal Agile expert, Taylor has invested years into dissecting and understanding how alternative principles can integrate within the rigid confines of government operations. This self-directed journey has endowed Taylor with a distinctive skill set that straddles the line between the conventional procurement world and the forward-thinking sphere of Agile methodologies. |
+| - **Project Role:** Taylor must navigate the complex government procurement landscape to secure the essential tools, technologies, and services needed for the Agile transformation. This role is pivotal in ensuring compliance with procurement regulations and aligning the procurement process with Agile principles. This alignment involves a proactive push for innovative requirements, cultivating partnerships with vendors who are not just aware of but wholly supportive of an Agile approach, and a commitment to making procurement processes more adaptable and responsive. Taylor has played a vital role in reimagining how procurement can act as a driving force for Agile transformation, a significant shift from traditional metrics. |
+| - **Challenges:** Despite a clear vision for how Agile methodologies can revolutionize project outcomes, Taylor faces frustration with senior leadership's limited grasp of Agile's core principles and their frequent skepticism towards its implementation, rooted in deviation from well-established processes. Worse, some leaders are overly enthusiastic, perceiving Agile as merely a means to accelerate work and achieve more with fewer resources, misunderstanding its emphasis on adaptability, team collaboration, and continuous improvement. Convincing senior leadership of the value of these approaches in a way that prioritizes flexibility and outcomes over rigid specifications has required a delicate balance of persuasion and demonstration. Each step forward has required Taylor to navigate organizational resistance to new ideas, leveraging a deep understanding of procurement and Agile principles to make a compelling case for change. |
+
+Taylor's choices for the core team were strategic, aiming to address the project's multifaceted challenges, from legal compliance to data integrity. This view led to the selection of Dr. Casey Morgan and Alex Johnson, each with a unique and critical skill set.
+
+Unparalleled expertise in clinical research and a well-earned reputation for meticulous attention to detail made Dr. Casey Morgan an easy choice as a SME. Taylor recognized that for the Agile project to succeed, it needed to be efficient and innovative and uphold the highest data integrity and reliability standards. Furthermore, the new system needed to be usable and valuable for the researchers who would use this system daily. Dr. Morgan's background in clinical trials, with complex data and stringent regulatory requirements, offered the project an invaluable, real-world perspective. Their demands for extremely high data integrity would ensure that the project's outcomes were innovative but also reliable and trustworthy. Furthermore, Dr. Morgan's skepticism towards Agile methodologies presented an opportunity. Taylor believed that winning over a skeptic through the tangible benefits and successes of the project would provide a powerful narrative to drive broader organizational change.
+
+With their deep understanding of the legal and regulatory landscapes governing HHS operations, Alex Johnson was the prudent selection as legal advisor. Agile methodologies, emphasizing flexibility and rapid iteration, presented potential legal challenges, particularly in a government context where compliance and documentation are paramount. Taylor knew that to implement Agile successfully, the project had to navigate these legal complexities, ensuring that every step, from procurement to data handling, was strictly compliant with government regulations. Alex's meticulous nature and legal acumen made them an essential asset to the team, providing the legal framework to innovate within the bounds of regulatory compliance.
+
+| **Dr. Casey Morgan;** Chief Researcher, Division of Clinical Research (DCR), National Institute of Allergy and Infectious Diseases (NIAID), National Institute of Health (NIH) |
+| --- |
+| - **Background:** Dr. Casey Morgan is a clinical researcher with over two decades of experience conducting and overseeing complex clinical trials. Known for meticulous attention to detail and deep knowledge of clinical data intricacies, Dr. Morgan has participated in numerous advisory panels and research committees. Despite their invaluable expertise, team members view Dr. Morgan as challenging, primarily due to a low tolerance for inefficiency, inaccuracies, and what they perceive as the 'cutting of corners' in clinical research processes. Dr. Morgan has a reputation for re-running the data for reviewed papers and sending scathing notes to any researcher foolish enough not to double-check results before submitting them for review. |
+| - **Project Role:** Dr. Morgan was brought on board to ensure that the clinical trial data system's design and functionality met the stringent requirements of frontline researchers. Dr. Morgan's role is to scrutinize every aspect of the system, from data integrity to user interface design, ensuring regulatory compliance and ensuring that it is genuinely helpful for researchers. |
+| - **Challenges:** Dr. Morgan's insistence on perfection and their skepticism towards the Agile methodology's iterative nature often puts them at odds with the project team. They are particularly concerned that the rapid pace of Agile sprints could lead to oversights in data security and integrity. Though sometimes perceived as overly harsh or obstructive, Dr. Morgan's critiques stem from a deep-seated commitment to patient safety and research efficacy. |
+
+| **Alex Johnson;** General Counsel, ARPA-H |
+| --- |
+| - **Background:** With an extensive background in government law, Alex Johnson is the epitome of diligence and commitment to legal precision in public sector operations. Their traditional approach to law, underscored by caution and thoroughness, is driven by an acute awareness of the potential legal pitfalls. |
+| - **Project Role:** Alex's role is vital in ensuring the project's strict adherence to legal and regulatory frameworks. This cautious stance, born out of professional necessity, aims to maintain the government's legal integrity, which is especially critical in the aftermath of the previous HHS disaster. Through meticulous legal guidance spanning contract negotiations to regulatory compliance, Alex ensures the project's operations fully align with legal standards. |
+| - **Challenges:** Positioned at the crossroads of innovation and legal compliance, Alex faces the daunting task of reconciling the project's ambitious goals with the immutable nature of legal constraints. The swift pace of technological change and the dynamic legal environment compounds the complexity of Alex's role, necessitating unwavering diligence and adaptability to keep the project within legal bounds while fostering innovation. Despite their integral role, Alex harbors deep-seated reservations about applying Agile methodology within government procurement, fearing it could exacerbate existing acquisition challenges within HHS. However, committed to the project's success, Alex is willing to navigate these uncharted waters, dedicating their expertise to ensure the Agile transformation proceeds without compromising legal standards. Despite feasibility concerns, this willingness to support the project underscores Alex's dedication to promoting legal integrity while cautiously exploring new methodologies. |
+
+In the first planning meeting, Taylor faced immediate resistance. Dr. Morgan started the meeting by questioning Agile's suitability for the high-stakes demands of their environment. At the same time, Alex shared similar concerns, wary of Agile's fit within the stringent regulatory framework of government projects. The atmosphere grew tense as Taylor presented a vision for a more active, responsive approach to project management. While discussing the disastrous previous software implementation, Dr. Morgan became enraged, stating, "It had set scientific progress back by a decade." Dr. Morgan demanded that any forthcoming solution meet the project's primary objectives and remedy the many problems after the last software release.
+
+Central to Dr. Morgan's apprehension was the fear that Agile's rapid cycles might dilute the depth and reliability of data analysis, jeopardizing the tool's utility for researchers; the primary focus is on ensuring that the tool is helpful to researchers and advances science. Alex was troubled by the potential legal repercussions of adopting such a flexible methodology, fearing it could lead to breaches in compliance, exposing the government to a spectrum of legal liabilities, including lawsuits and regulatory penalties. Taylor suggested a dual-track Agile approach designed to balance momentum with the stringent requirements of data integrity and legal compliance. However, this proposal only served to deepen the divide. Dr. Morgan doubted the possibility of adhering to rigorous data standards within the Agile framework's swift pace. Alex questioned the feasibility of maintaining comprehensive legal oversight throughout iterative development phases.
+
+The meeting concluded without a clear path forward, leaving Taylor to reflect on the precarious balance between driving innovation and adhering to the indispensable principles of integrity and compliance. This unresolved conflict highlighted the significant hurdle Taylor faced: to persuade a team deeply entrenched in conventional methodologies to adopt a novel approach, all while maneuvering through the intricate maze of government regulations and the paramount importance of maintaining data integrity.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 3] Vendor Selection
+Following the tumultuous initial planning meeting, Taylor shifted focus toward the crucial task of vendor selection, aiming to find a provider and a partner. Determined to steer the project to success, Taylor introduced a groundbreaking method for evaluating potential vendors, focusing on vendors' ability to deliver tangible, proven outcomes rather than just theoretical promises or the lowest bidder. Taylor sought adaptable, collaborative vendors with a track record of success in dynamic settings—critical traits for thriving in an Agile environment.
+
+Taylor prioritized practical, proven results, considering only vendors with a record of delivering concrete outcomes. The selection criteria highlighted these qualities, ensuring the chosen vendor could adapt to changing project needs while adhering to government standards. Taylor sought a partnership based on open communication, mutual trust, and a shared vision for the project's success, prioritizing vendors with a solid background in Agile methodologies. This strategy supported project requirements by selecting a vendor that could effectively apply Agile principles and navigate the complexities of government projects.
+
+However, this approach did not go unchallenged. Alex raised concerns about Taylor's departure from the established cost, schedule, and cost performance metrics. Alex, a staunch advocate for traditional evaluation methods, argued that these time-tested metrics provided a clear, quantifiable way to gauge a vendor's potential for success and were vital to spending the public's money with good stewardship. Alex was wary of Taylor's focus on outcomes, fearing it introduced subjective criteria into the selection process and could potentially overlook vendors who excelled in the conventional metrics but were less flashy in their results.
+
+The conflict between Taylor and Alex underscored a more profound division within the team. On one side, there was a push for innovation and a belief in the transformative potential of Agile methodologies. On the other, there was a call for caution and adherence to proven practices that had served the department well. This clash of ideologies highlighted the challenges of implementing change within an institution as complex and tradition-bound as HHS.
+
+After a meticulous evaluation process, Catalyst Consulting, under the leadership of Jamie Carter, emerged as the chosen vendor, distinguished by its exceptional track record of real-world performance and its adeptness at blending Agile methodologies with the rigorous demands of government projects. Their proposal demonstrated a profound understanding of the project's goals and a clear strategy for navigating the complexities of legal and regulatory compliance, making them the ideal partner for this ambitious transformation. A short-term contract was awarded to Catalyst Consulting to cover the planning phase, anticipating awarding a follow-on contract once the project requirements were clearly defined.
+
+| **Jamie Carter;** Catalyst Consulting, CEO |
+| --- |
+| - **Background:** As CEO of a small tech firm, Jamie Carter has focused on providing high-quality government technology solutions. Over a 15-year career, Jamie transformed a garage startup into a critical player in government technology solutions by prioritizing innovation that delivers real-world results. |
+| - **Project Role:** Jamie brings a hands-on approach to collaboration, ensuring the company is a strategic partner dedicated to the project's success. Jamie's deep dive into the project's objectives and challenges enables the delivery of technology solutions that are not only cutting-edge but also specifically aligned with facilitating the project's Agile transformation. |
+| - **Challenges:** Navigating a sector where technology rapidly changes, Jamie ensures their solutions remain innovative and immediately applicable, often involving pushing the envelope in tech advancements while ensuring they are practical, user-friendly, and adaptable to the project's evolving needs. Jamie strongly emphasizes delivering the latest advancements without falling into the trap of chasing new technologies at the expense of reliability and applicability. This balanced approach ensures that the solutions provided not only leverage cutting-edge technology but also maintain the highest standards of reliability and functionality. Central to Jamie's strategy is a commitment to excellence and a results-driven focus, aiming to meet and surpass project benchmarks and expectations. |
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 4] Stakeholder Alignment and User Satisfaction
+
+A month had passed since the initial standoff, and the atmosphere had subtly shifted. Though still carrying their reservations like armor, Dr. Morgan and Alex had begun to entertain the possibility of change. The memory of past failures and the looming threat of legal complications had not vanished, but there was a growing recognition between them that the status quo was not sustainable. This acknowledgment was not easy; it was born from discussions, reflections on Taylor's proposals, more than a few arguments, and a shared commitment to seeking a better outcome for their projects.
+
+Taylor noticed a change in tone during their meetings. Dr. Morgan, who had been skeptical, started asking more questions about how Agile methodologies could be tailored to ensure the integrity and depth of data analysis critical for their research. Alex, too, showed signs of a softening stance. While legal and regulatory risks were still front and center, these concerns began to engage more constructively, exploring harnessing Agile's flexibility within a compliance framework.
+
+They had not reached a consensus, but the willingness to explore Agile as a potential catalyst for much-needed change marked a significant shift. Taylor sensed an opportunity to build on this openness, demonstrating how Agile, emphasizing adaptability and continuous improvement, could address the technical challenges of their projects and the deeper issues of efficiency, responsiveness, and stakeholder satisfaction that had long plagued their efforts. This emerging willingness to step out of their comfort zones because they believed something needed to change was a small but crucial breakthrough. It was a testament to the power of dialogue, persistence, and the shared recognition that the path to innovation often requires navigating through skepticism and uncertainty.
+
+Taylor, determined to ensure the product met user needs, turned to Dr. Morgan for a solution. For Taylor, the essence of project success lies in meeting specifications while ensuring those specifications genuinely reflect the users' needs and expectations. In a complex environment with numerous stakeholders, Taylor recognizes the formidable challenge of pinpointing the proper requirements, especially when it involves navigating diverse needs and securing consensus among parties with varying priorities and perspectives. Dr. Morgan accepted the challenge and prepared to ensure the project's outcomes would better align with stakeholder expectations.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 5] Anticipate Risks and Challenges
+
+Taylor was keenly aware of the need to shift from a reactive to a proactive approach in project management, mainly when predicting challenges before a critical impact. Traditional methods often proved inadequate, addressing problems only after significantly affecting the project. This insight led Taylor to seek out innovative techniques to preemptively identify and mitigate potential issues, ensuring the project remained on track through strategic foresight rather than relying on reactive measures.
+
+As the discussion around Taylor's proposal for a proactive project management approach unfolded, Jamie, enthusiastic for cutting-edge solutions, introduced an ambitious idea: leveraging artificial intelligence (AI) models to enhance the project's predictive capabilities. With a background in technology and a keen interest in AI's potential, Jamie envisioned a system where AI could analyze vast amounts of data to identify potential issues long before they occurred.
+
+Alex, while intrigued by Jamie's proposal, expressed reservations about the implications of relying on AI, particularly concerning data privacy and the ethical use of AI. Alex also raised concerns about the Terms of Service (ToS) associated with AI technologies, mainly how any data entered could improve the model, potentially exposing sensitive governmental information and adding a layer of risk regarding confidentiality. This caution serves as a reminder of the need to balance technological advancement with legal and ethical considerations, ensuring the project remained compliant with regulations and respected data integrity. Dr. Morgan acknowledged the potential of AI to transform project management but also highlighted the importance of human oversight and the difficulty of checking results. Dr. Morgan pointed out that while AI could offer valuable insights, the complexity and nuance of the project required human judgment to interpret and apply these findings effectively and ensure the model was correct. As the team pondered Jamie's proposal, it became evident that any move towards incorporating AI would need to be carefully calibrated, ensuring that it enhanced the project's strategic planning and execution.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 6] Contracts Supporting Iterative Development, Part 1
+
+Taylor firmly believed that traditional government contracts were ill-suited to handle the demands of Agile project management. These contracts' static and inflexible nature starkly contrasted with the fluidity and adaptability required for Agile methodologies to thrive. To Taylor, it was clear that a significant change was necessary. The traditional approach to contracting, with its predefined requirements and fixed scopes, could not support iterative development, continuous improvement, and responsiveness to change. Adapting these contracts to support Agile's iterative development and changing requirements demands a shift in how projects are scoped, contracted, and managed. This flexibility creates contractual frameworks that adapt to changing requirements, shifting timelines, fluctuating costs, and other unknown variables inherent to the software development process.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 7] Agile Procurement Contracts
+
+Taylor's introduction of Agile Procurement Contracts (APCs) marked a significant shift towards project scope and requirements flexibility. By designing contracts prioritizing achieving outcomes over adhering to specific methods, Taylor enabled a more dynamic approach to project development, allowing for adjustments as projects evolve without sacrificing end goals. This strategy ensures that projects can adapt to changing needs while focusing on delivering tangible results. At the heart of APCs is the recognition that traditional, rigid timelines and fixed requirements often hinder the ability to respond to evolving project needs. Instead, APCs introduce flexible timelines, breaking projects down into shorter sprints. Each sprint is guided by its timeline and adaptable to the project's changing needs, ensuring that deliverables remain relevant and high-quality. This structure supports the development of Minimum Viable Products (MVPs), prioritizing getting functional, albeit basic, product versions into users' hands as quickly as possible. This approach facilitates early and continuous user feedback and enables iterative improvement, ensuring the final product meets user demands.
+
+Furthermore, APCs are designed to accommodate changing requirements, a staple of Agile project management. This flexibility ensures that adjustments can be seamlessly integrated into the scope and objectives as a project evolves, fostering an environment where contractual constraints do not stifle innovation. Regular review meetings and checkpoints are integral to this process, providing a forum for both parties to assess progress, address issues, and recalibrate objectives as necessary.
+
+Alex voiced severe concerns about this shift. Alex considered integrating Agile methodologies into government contracting unwise and a potential catalyst for legal and operational turmoil. The absence of fixed deliverables and the fluid nature of project requirements could lead to subjective interpretations of success, making it challenging to assess performance objectively. Alex was deeply concerned about the inevitability of scope creep, a common pitfall in Agile projects that could become exacerbated in a government contracting context. Without the strict boundaries of traditional contracts, projects could expand beyond their original scope, complicating project management and potentially leading to disputes over the initial agreement. Much of the apprehension stemmed from a deep-seated belief that Agile approaches' inherent flexibility and dynamism were fundamentally incompatible with government contracts' stringent, predefined structures. Alex foresaw many legal and compliance challenges from attempting to mesh Agile development's iterative, adaptable nature with the fixed expectations and rigid stipulations typical of traditional contracts, including breaches of contract. Alex's perspective highlighted a significant concern: that in the pursuit of adaptability and responsiveness, the project might inadvertently expose itself to significant legal vulnerabilities and operational risks, undermining the very objectives it sought to achieve by adopting Agile methodologies.
+
+Surprisingly, Dr. Morgan saw Agile contracts as a groundbreaking shift that could revolutionize government contracting. Years of experience have shown the value of adaptability and iterative processes, which are critically lacking in traditional government project management approaches. Dr. Morgan understood that the flexibility offered by Agile could be its greatest asset in responding to the dynamic needs of government projects. This belief is that the principles of Agile, when properly implemented, could significantly enhance these projects' responsiveness and success rates. Dr. Morgan was well aware of the potential challenges, such as scope creep and the difficulty of performance evaluation. However, their career had been defined by tackling such complexities head-on, armed with meticulous planning and clear communication. Dr. Morgan believed that by embracing Agile's iterative cycles and adaptability, government projects could become more responsive to change, ultimately leading to more successful outcomes and the advancement of science. Taylor was shocked to hear Dr. Morgan's perspective, particularly from someone with an extensive background in clinical research.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 8] Continuous Improvement
+
+Three months later, the tone of the conversation had notably evolved. Doubts persisted, yet they no longer overshadowed discussions. Instead, Dr. Morgan, Alex, and Taylor found themselves in a more productive dialogue, focusing on collaborative problem-solving rather than perceived impossibilities. The collective mindset shifted from questioning Agile methodologies' feasibility to exploring actionable solutions to overcome specific challenges, and the core question had transformed from "Can this be done?" to "How can we solve these problems?"
+
+Initially skeptical about Agile's capacity to support rigorous data analysis, Dr. Morgan now actively led efforts to adapt Agile practices to meet the project's rigorous standards. The team collaborated on ways to tailor sprint structures, allowing for deeper data analysis and ensuring that the agility of the methodology did not come at the expense of the project's scientific integrity. Alex's perspective also transformed. The legal and regulatory concerns that once seemed like roadblocks now seemed like solvable puzzles. Collaboratively, Taylor and Alex designed a compliance strategy aligned with Agile's iterative nature, ensuring that each project phase met legal requirements without hindering progress.
+
+Meetings were transformed into cooperative sessions, addressing every concern with a proactive search for solutions. Taylor steered these discussions, emphasizing Agile's core strengths to address the team's specific needs. Together, they delved into strategies for upholding data integrity, navigating regulatory landscapes, and managing stakeholder expectations within an Agile framework. This change in dialogue reflected a more profound transformation within the team. Doubts became springboards for exploration and ingenuity rather than obstacles. The team had transitioned from skepticism about Agile's applicability to actively figuring out how to make it work for their unique circumstances. This evolution from doubt to solution-oriented thinking marked a critical step forward in their journey towards adopting a more active, efficient approach to project management.
+
+At the latest meeting, Jamie stated that HHS's tendency towards stagnation, where teams stick to outdated practices rather than embracing new methodologies, is a significant risk. In Jamie's view, this stagnation contributes to inefficiencies, diminishes project quality, and hampers the ability to stay abreast of technological advancements. Jamie, Taylor, and Dr. Morgan agree on integrating solutions but disagree on the best solutions. All agree that team bandwidth is limited and that the right toolset needs to be selected.
+
+Taylor approaches the problem by advocating for a shift in mindset within government project teams, emphasizing the need for continuous learning and adaptation to new methodologies. Taylor believes in leveraging lessons learned from past projects to avoid repeating mistakes and to streamline processes for greater efficiency, while Jamie looks to technological solutions to address the issue. Jamie champions the integration of cutting-edge tools and platforms that can automate mundane tasks, facilitate better communication, and provide actionable insights through data analysis. Jamie proposes adopting cloud-based project management tools to enhance collaboration and agility, using data analytics to inform decision-making, and implementing AI to automate routine tasks, freeing team members to focus on more challenging issues.
+
+Dr. Morgan focuses on the importance of strategic planning and policy reform in tackling the problem. Dr. Morgan argues for developing policies that encourage innovation, support the adoption of agile methodologies, and create an environment of rewarding experimentation. Dr. Morgan emphasized creating a continuous learning and improvement culture within project teams, implementing regular retrospectives and feedback loops to capture lessons learned and integrate them into future project cycles.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 9] Trasition
+
+Jamie and Taylor are fully aware of the operational downtime risks associated with migrating to a new system managed by a different vendor, requiring a seamless transition through meticulous testing, training, and establishing robust support structures. Both are acutely aware of the inherent risks of data loss, corruption, and security breaches. Their collaborative effort is rooted in ensuring the integrity and security of data throughout the migration process. Their strategy emphasizes the importance of collaboration among the government agency, the outgoing vendor, and the incoming vendor to prepare all stakeholders for the change. Using an iterative testing phase, they aim to assess the new system's compatibility with existing workflows and data structures, identifying and resolving issues in a controlled environment before going live. This careful approach is pivotal in minimizing the risk of unexpected disruptions, ensuring the transition does not negatively impact service delivery, and reflecting their commitment to maintaining the integrity of the services provided.
+
+To mitigate the risks, Taylor focuses on meticulous planning and precise migration execution by conducting a comprehensive risk analysis to identify and address potential vulnerabilities preemptively. Taylor's methodical approach ensures that every aspect of the migration is scrutinized, from effectively translating data formats to implementing secure transfer protocols and safeguarding sensitive information against potential vulnerabilities.
+
+Meanwhile, Jamie brings a technical perspective, emphasizing the importance of minimizing downtime and ensuring operational continuity. Jamie explores innovative technical solutions to keep essential services running smoothly during the transition, fully aware that even minimal disruptions can have significant implications. Furthermore, Jamie focuses on robust stringent data protection regulations. These measures are crucial for protecting data during and after the migration, fortifying the new systems against potential threats.
+
+Alex is at the forefront of meticulously crafting all legal documents to support a significant project transition. Alex focuses on establishing a comprehensive legal framework that addresses current regulatory requirements and proactively anticipates potential challenges. Central to this strategy is developing robust contingency planning, which involves identifying previously encountered legal hurdles and creating detailed response strategies to mitigate risks. Alex's forward-thinking approach ensures that the project is not only legally compliant at every stage but also equipped to handle unforeseen legal obstacles, safeguarding the project's success and integrity.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 10] Bridge Contracts
+
+The project was progressing smoothly, meeting milestones on schedule and stakeholders expressing satisfaction. Under Taylor's guidance, initial testing on the new system went well, and data migration began. However, as the team geared up for the subsequent implementation phase, another vendor that had been in the running but ultimately not selected raised concerns about the fairness and transparency of the selection process. This vendor claimed the criteria used to evaluate proposals were not applied uniformly, and their bid, which they believed was competitively priced and technically superior, was unfairly dismissed.
+
+The vendor formally filed a contractual protest, triggering an automatic freeze on the project's progress per government procurement regulations. Unfortunately, this meant that until there was a resolution, the transition to the new vendor could not proceed. The implications were immediate and concerning. Delays threatened to derail the project timeline, incur additional costs and compromise the security enhancements needed.
+
+Alex, who had been through similar challenges in past projects, understood the gravity of the situation. The first step was to ensure operational continuity. Knowing that protests could lead to prolonged delays, Alex had wisely negotiated a bridge contract with the current IT service provider during the planning process. This foresight meant that the agency's operations would not be interrupted despite the freeze on the new contract. The bridge contract was a stopgap measure, allowing services to continue under the existing terms while addressing the protest. Alex convened a meeting with the legal, procurement, and operational teams to assess the situation. The immediate goal was to review the protestor's claims and prepare a comprehensive response. The response required a detailed examination of the procurement process documentation, ensuring that every step, from the call for proposals to the final selection, was conducted by government procurement regulations and was fully transparent.
+
+The team also began preparing for the possibility that the protest could lead to reevaluating the proposals or, worst case, a complete redo of the selection process. This preparation involved not just legal and procedural readiness but also maintaining open lines of communication with all stakeholders, including the chosen vendor and the protestor, to manage expectations and keep everyone informed of developments.
+
+After resolving the procurement protest and the government agency's selection process upheld as fair and compliant, the team focused on transitioning from the bridge contract to the original project plan. This resolution phase was critical, as it required coordination to ensure that the temporary measures put in place during the protest—namely, the bridge contract—were resolved without causing any disruption to services or delay to the project's resumed progress. Alex led a series of strategic meetings with the incumbent vendor under the bridge contract and the newly selected vendor to outline a straightforward, phased approach for handing over responsibilities. This approach included a detailed review of all work completed under the bridge contract, ensuring that any temporary solutions were adequately integrated into the long-term project plan or phased out in favor of the superior solutions offered by the new vendor. The resolution of the bridge contract was handled with as much care and strategic planning as its initiation, ensuring a seamless transition that maintained service continuity.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
+
+## [Section 11] Outcomes
+
+As the project concluded, a remarkable transformation unfolded within the team. Alex and Dr. Morgan, once cautious and skeptical, emerged as vocal advocates for the Agile methodology that they had doubted only months before. Their journey from skepticism to endorsement was not just a personal victory for them but a testament to the adaptability and resilience of the team under Taylor's guidance.
+
+Dr. Morgan, previously concerned about the potential compromise on data integrity and depth of analysis, had not only found Agile methodologies to be accommodating but beneficial. The iterative nature of Agile allowed for continuous refinement and deeper exploration of data, leading to previously unattainable insights under more rigid project management structures. Dr. Morgan's endorsement of Agile came from a genuine appreciation for how it enhanced their work's scientific rigor and innovation.
+
+Alex, too, had undergone a significant shift in perspective. Meticulous planning and a proactive approach to each project phase addressed initial reservations about legal and regulatory compliance within an Agile framework. Alex's transformation into an Agile advocate was rooted in a realization that flexibility did not equate to a lack of discipline or rigor. Instead, Agile provided a structured yet adaptable framework that could navigate the complexities of legal and regulatory requirements more effectively than traditional methods.
+
+Taylor, whose belief in the potential of Agile to revolutionize their project management approach had been unwavering, was vindicated. The success of the project and the conversion of the team's most skeptical members into champions of change underscored the effectiveness of Agile methodologies. Taylor's leadership and commitment to guiding the team through their initial doubts and towards a more agile, responsive way of working had paid off.
+
+The team's journey from doubt to advocacy was a professional transformation and a paradigm shift in how they approached challenges and managed projects. Alex and Dr. Morgan's newfound advocacy for Agile methodologies signaled a broader organizational change, paving the way for a continuous improvement, innovation, and adaptability culture. Taylor's role in this transformation proved that even the most deeply ingrained doubters can become powerful advocates for change with the right approach and mindset.
+
+The strategic application of Agile methodologies to address the inherent challenges in government project management yielded remarkable outcomes that significantly enhanced the overall efficiency and effectiveness of the project. The successful and secure data migration to the cloud-based system was a standout achievement. The team promptly identified and resolved potential issues by adopting an iterative approach to data migration, coupled with real-time monitoring and predictive analytics. This meticulous process ensured data integrity and security throughout the transition, facilitating a smooth and secure migration to the cloud-based system. The success of this migration laid the foundation for more agile and scalable operations, enabling the government to better serve its constituents through enhanced data accessibility and reliability.
+
+The maintenance of uninterrupted service delivery during contractual protests was another significant outcome. Anticipating potential legal challenges, Alex proactively negotiated bridge contracts and developed comprehensive risk management plans. This foresight and strategic planning ensured that services continued without disruption, even in the face of contractual disputes. By prioritizing the continuity of service, the team upheld its commitment to stakeholders and minimized the impact of legal challenges on project timelines and deliverables.
+
+The seamless transition to the new system with minimal operational impact underscored the effectiveness of Agile methodologies. Through collaborative workshops, cross-functional team structures, and dynamic resource allocation, the team ensured that all stakeholders were aligned and prepared for the transition. This collaborative approach, combined with the emphasis on continuous communication and stakeholder engagement, facilitated a smooth transition to the new system, ensuring that operational impacts were negligible and that the transition was barely perceptible to the end-users.
+
+The remarkable completion of the project under budget and ahead of schedule represents a rare and significant achievement in government project management. This success stems from the strategic application of Agile methodologies, which facilitated efficient resource utilization and enabled swift adaptation to emerging challenges. Proactive, iterative approaches allowed for continuous refinement and optimization of the project scope and resources, ensuring that expenditures were kept in check while accelerating progress. The project team demonstrated exceptional capability and commitment to delivering value and set a new benchmark for cost-efficiency and timeliness in government initiatives, showcasing the profound impact of Agile practices on overcoming traditional project constraints.
+
+The project witnessed improved cost-effectiveness and stakeholder satisfaction, highlighting the tangible benefits of integrating Agile methodologies into government project management. The iterative nature of Agile, combined with continuous feedback loops and the ability to adapt to changing requirements, resulted in more efficient use of resources and reduced wastage. This approach enhanced the project's cost-effectiveness and led to deliverables more closely aligned with stakeholder needs and expectations, significantly improving stakeholder satisfaction.
+
+## [Section 12] Lessons Learned:
+
+The successful completion of this project, marked by its under-budget and ahead-of-schedule delivery and high levels of stakeholder satisfaction, underscores several critical lessons learned. These insights are valuable for government projects and others seeking to implement Agile methodologies within complex, regulated environments.
+
+ - **Adaptive Requirements and Scope:** One of the primary lessons learned is the significance of maintaining adaptive requirements and scope. Flexibility in project requirements and the ability to adjust the scope in response to emerging insights and feedback are crucial for navigating the uncertainties inherent in complex projects. This adaptability allowed the project team to make informed decisions and modifications that aligned closely with evolving stakeholder needs and objectives, ultimately contributing to the project's success.
+ - **Adapting Agile Methodologies to Address Specific Challenges:** The project highlighted the necessity of tailoring Agile methodologies to meet the unique procurement and system transition challenges within the government context. By customizing Agile practices, the project team overcame specific hurdles related to vendor selection, contract negotiations, and the seamless integration of new systems. While Agile methodologies offer significant advantages, they are not universally applicable to every project scenario. Students learned to critically assess the appropriateness of Agile for different projects and how to adapt its core principles to better align with specific project requirements. This approach emphasized the importance of flexibility and the strategic customization of methodologies to achieve optimal project outcomes.
+ - **Early and Continuous Alignment with Vendors:** Early and continuous alignment with vendors was a critical factor in the project's success. Establishing open lines of communication and setting clear expectations from the outset fostered a collaborative environment that persisted throughout the project. Regular check-ins and feedback sessions ensured that discrepancies in expectations or deliverables were identified and addressed promptly, minimizing the risk of misalignment and project delays. This approach underscored the importance of viewing vendors as partners rather than service providers in achieving project goals.
+ - **Focus on Outcomes Rather Than Approaches:** The project underscored the value of focusing on desired outcomes rather than rigidly adhering to specific approaches. By prioritizing the achievement of project goals over the strict application of methodologies, the project team employed a mix of Agile practices that best suited the project's evolving needs. This outcomes-driven mindset encouraged innovation and flexibility, allowing the team to navigate challenges and seize opportunities.
+ - **Navigated Diverse Personalities:** The project highlighted the effectiveness of embracing diverse team dynamics and conflicting viewpoints to craft innovative approaches. Instead of allowing differences to hinder progress, the project team harnessed these varied perspectives to develop hybrid solutions that addressed the project's unique challenges. This approach not only facilitated successful outcomes but also underscored the value of flexibility and open-mindedness in achieving project goals, showcasing how a collaborative and adaptive mindset can turn potential conflicts into opportunities for innovation.
+
+> [!CAUTION]
+> Please pause at this point for discussion questions.
diff --git a/tech-far-hub/static/assets/files/navigating-stakeholder-and-decision-making-challenges-ditap-case-study.pdf b/tech-far-hub/static/assets/files/navigating-stakeholder-and-decision-making-challenges-ditap-case-study.pdf
new file mode 100644
index 00000000..5409d1f0
Binary files /dev/null and b/tech-far-hub/static/assets/files/navigating-stakeholder-and-decision-making-challenges-ditap-case-study.pdf differ
diff --git a/tech-far-hub/static/assets/files/rainbo-case-study.pdf b/tech-far-hub/static/assets/files/rainbo-case-study.pdf
new file mode 100644
index 00000000..f5ec8f6a
Binary files /dev/null and b/tech-far-hub/static/assets/files/rainbo-case-study.pdf differ
diff --git a/tech-far-hub/static/assets/files/small-agency-legacy-application-migration-ditap-case-study.pdf b/tech-far-hub/static/assets/files/small-agency-legacy-application-migration-ditap-case-study.pdf
new file mode 100644
index 00000000..95e6d4c9
Binary files /dev/null and b/tech-far-hub/static/assets/files/small-agency-legacy-application-migration-ditap-case-study.pdf differ
diff --git a/tech-far-hub/static/assets/files/so-you-want-to-replace-a-legacy-system-ditap-case-study.pdf b/tech-far-hub/static/assets/files/so-you-want-to-replace-a-legacy-system-ditap-case-study.pdf
new file mode 100644
index 00000000..26363f29
Binary files /dev/null and b/tech-far-hub/static/assets/files/so-you-want-to-replace-a-legacy-system-ditap-case-study.pdf differ
diff --git a/tech-far-hub/static/assets/files/the-agile-shift-at-hhs-ditap-case-study.pdf b/tech-far-hub/static/assets/files/the-agile-shift-at-hhs-ditap-case-study.pdf
new file mode 100644
index 00000000..afa9fe27
Binary files /dev/null and b/tech-far-hub/static/assets/files/the-agile-shift-at-hhs-ditap-case-study.pdf differ
diff --git a/tech-far-hub/static/assets/img/gao-cost-estimating-graphic.png b/tech-far-hub/static/assets/img/gao-cost-estimating-graphic.png
new file mode 100644
index 00000000..f3ac0ef0
Binary files /dev/null and b/tech-far-hub/static/assets/img/gao-cost-estimating-graphic.png differ
diff --git a/tech-far-hub/static/assets/img/navigating-stakeholder-and-decision-making-challenges_ditap-case-study.jpg b/tech-far-hub/static/assets/img/navigating-stakeholder-and-decision-making-challenges_ditap-case-study.jpg
new file mode 100644
index 00000000..3f6f68a5
Binary files /dev/null and b/tech-far-hub/static/assets/img/navigating-stakeholder-and-decision-making-challenges_ditap-case-study.jpg differ
diff --git a/tech-far-hub/static/assets/img/rainbo-case-study-cvf-2.jpg b/tech-far-hub/static/assets/img/rainbo-case-study-cvf-2.jpg
new file mode 100644
index 00000000..0cfd9618
Binary files /dev/null and b/tech-far-hub/static/assets/img/rainbo-case-study-cvf-2.jpg differ
diff --git a/tech-far-hub/static/assets/img/rainbo-case-study-cvf-3.jpg b/tech-far-hub/static/assets/img/rainbo-case-study-cvf-3.jpg
new file mode 100644
index 00000000..a46cdb95
Binary files /dev/null and b/tech-far-hub/static/assets/img/rainbo-case-study-cvf-3.jpg differ
diff --git a/tech-far-hub/static/assets/img/rainbo-case-study-cvf.jpg b/tech-far-hub/static/assets/img/rainbo-case-study-cvf.jpg
new file mode 100644
index 00000000..e7c592c9
Binary files /dev/null and b/tech-far-hub/static/assets/img/rainbo-case-study-cvf.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-anton.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-anton.jpg
new file mode 100644
index 00000000..885c3f96
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-anton.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-gabriella.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-gabriella.jpg
new file mode 100644
index 00000000..11f9a41d
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-gabriella.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-helena.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-helena.jpg
new file mode 100644
index 00000000..892ac2c0
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-helena.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-kim.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-kim.jpg
new file mode 100644
index 00000000..54334842
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-kim.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-lars.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-lars.jpg
new file mode 100644
index 00000000..69f94d16
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-lars.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-maya.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-maya.jpg
new file mode 100644
index 00000000..f313a187
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-maya.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-nate.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-nate.jpg
new file mode 100644
index 00000000..e978549c
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-nate.jpg differ
diff --git a/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-reva.jpg b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-reva.jpg
new file mode 100644
index 00000000..cda9c43c
Binary files /dev/null and b/tech-far-hub/static/assets/img/small-agency-legacy-application-migration-reva.jpg differ
diff --git a/tech-far-hub/static/assets/img/so-you-want-to-replace-a-legacy-system-fema.jpg b/tech-far-hub/static/assets/img/so-you-want-to-replace-a-legacy-system-fema.jpg
new file mode 100644
index 00000000..61f73f70
Binary files /dev/null and b/tech-far-hub/static/assets/img/so-you-want-to-replace-a-legacy-system-fema.jpg differ
diff --git a/tech-far-hub/static/assets/img/swot-analysis-graphic.png b/tech-far-hub/static/assets/img/swot-analysis-graphic.png
new file mode 100644
index 00000000..842e527f
Binary files /dev/null and b/tech-far-hub/static/assets/img/swot-analysis-graphic.png differ