, cricket (VPN 4:48 PM 62% Case Study 2: Attempt 1 Students, Read the following case study and examples of addressing the complicating factors that exists in this project in a two- page single space paper. Provide references where applicable. This paper needs to be written in 12-point New Times Roman. This assignment is due on 2/23/2020 at 10:00PM CST. VPN cricket 4:52 PM 61% E-Case Study Troubled Softwa... Case Study The Troubled Software Project Background PROJECT SEARCHLIGHT is a custom hardware and software acquisition for a Government Agency. The Agency has undertaken the acquisition to provide its employees a document search capability from their desktops and access to data that includes the Internet, web-based multimedia, and databases. The Agency further intends that the acquisition will provide an advanced virtual workspace for employees to collaborate in real time and to capture the knowledge created in that process. No new, multi-million dollar software development project ever goes smoothly in this Agency. New systems always have many unknowns. Costs at completion are almost always 50% over budget and deliver less than 100% of planned scope Project schedules are almost always 50%-100% late. PROJECT SEARCHLIGHT has endured cost overruns, schedule slips. and scope reduction since contract initiation A key source of program confusion has been the software development methodology selected by the Contractor and the subsequent Government oversight of those development efforts. The Government contracted SEARCHLIGHT as a Cost Plus/Award Fee effort. As part of their successful bid, the Contractor proposed to execute the development effort using an agile methodology." The term "agile" appears in the Project Management Plan (PMP) and in the Project Initiation Review (PIR) charts, as well as in its Preliminary Design Review (PDR) charts. Unfortunately, the Government team was unfamiliar with the agile methodology's principles and practices. The Contractor's PMP identified exactly how to manage a waterfall development project using Eamed Value Management System (EVMS) while constantly referring to the Contractor's agile development methodology. It does not appear that the Government COTR and program managers ever understood this. Thus, the Goverment insisted on waterfall processes and documents inside an agile time box. From June 2006 to December 2006, the Contractor produced, at Government direction, about 12,000 pages of documents. In addition, the program had convened seven control gates, PIR. System Requirements Review (SRR), Design Concept Review (DCR), PDR. Critical Design Review (CDR) 1.1. CDR 1.2 and PDR for 10C totaling 525 PowerPoint slides. What is Agile Development? To employ agile development as it is intended the development team rejects the concept of having to know everything in detail up front (requirements, design, etc.). The agile approach trades off detailed requirements definition for short, 2-3 week long development cycles (iterations), which are driven by direct customer interaction. Customers are given a "budget and get to select which requirements are the most important to work. The "budget" is an evolving, cumulative estimate of the development team's productivity--its ability to complete a given scope of work in a time box. Not all requirements are customer facing and so the development team also gets a budget to work items not visible to the customer such as system 1 cricket VPN 4:52 PM 61% E-Case Study Troubled Softwa... requirements (security, availability, reliability, etc.). Progress on the completion of requirements and growing number of incomplete requirements (Backlog) are tracked. Test Engineers are integrated into the development team. The Test Engineer develops automated test routines at the same time the developer creates the code-both working from the same requirements artifacts (use cases, user stories, requirements, etc.). If the code fails the test. the developer and the tester determine which is at fault. If you have multiple development teams another set of tests are run after the iteration to ensure that all the parts work together. At the end of the iteration you have two results: 1) working tested code and 2) a set of automated unit test cases used after every subsequent iteration to identify any unintentional changes. This agile approach clearly identifies project status. Since the team produces working code at the end of the iteration, everyone knows exactly where the project is. Agile adherents claim that with this approach you can stop at any iteration and you still have value for your expenditure. Perhaps more importantly, you can adapt to changing requirements at any time and either cut losses early or build on what has succeeded. Agile development is evolutionary, and it requires the project sponsors and the development team be comfortable with uncertain requirements in the early phases of development. Successful implementation of any agile development has two fundamental pre- requisites: the development team must have frequent, unimpeded communication with the end user community, and implementation starts with a general scope well in advance of the fully- defined requirements common to most traditional" Government acquisitions. Unfortunately for SEARCHLIGHT,the Government has insisted on known scope, known dates, and known costs since contract award. Many people incorrectly characterize agile as lacking process of being process-light. It is exactly the opposite. It requires a great deal of discipline and programmatic control. This control should not be confused with lots of documentation and control gates. The pace of development is rapid and unrelenting. The program has lots of changing information that must be kept synchronized. This information includes: an evolving requirements backlog. o evolving requirements (frequently across iterations), o test cases aligned with the requirements (frequently across iterations). defects end up on the requirements backlog (assigned to subsequent iterations) o training materials o status reporting by iteration The Current Situation The project has spent its entire budget but is still months away from IOC. Even worse, the Contractor and the Government team hold vastly divergent perspectives on the project's technical status. The Contractor holds routine weekly and monthly meetings with their government counterparts on the project. These meetings occur at several levels. There are: PM to PM, D/PM to D/PM, and peer to peer meetings. Nevertheless, there is insufficient information in the current cost reports to provide insight into program health. At the contract level, the program is under its planned bum rate. The Contractor provides monthly cost reports to the Government, but only is reporting planned versus actual costs (dollars and hours) at the contract level 2 cricket VPN 4:52 PM 61% E-Case Study Troubled Softwa... At a recent meeting, the PROJECT SEARCHLIGHT Program Manager briefed the program's status. The briefing reported a variant of EVMS was used to calculate the Cost Performance Index, CPI, of .38 and a Schedule Performance Index, SPI, of 33. The Contractor indicated that there is a lot of schedule pressure. The upcoming IOC isa hard deadline established by the Agency corporate board. They also indicated a date for FOC nine months after IOC. The Contractor appears to be confident that they can deliver 80% of the customer requirements at JOC. They think that some or most of the issues revolving around the requirements documents have been resolved. Requirements by Release Package 1200 1000 135 125 150 800 600 Number of Reqmts. 122 le Ort 4 Porta Port 2 Port1 400 350 117 200 331 216 0 Orginal loc Regis Competed Sunter Pel Total Perroning Feplened OC Tocalettater Ponts Peplen In concert with its in-house Federally Funded Rescarch and Development Center (FFRDC) advisors, "FFRDC A," the Government has frequently functioned as the program integrator. This is a completion-type contract. The Government went into the marketplace to purchase a solution. Having picked one, it decided to get involved in the details of the system implementation. In so doing, it has placed itself in a confusing situation. For example, the Government directed the use of a specific XML development environment against the repeated recommendations of the Contractor. Key scalability issues are now tied to this Government- directed vendor. To make matters even more interesting, the Government PM has frequently sent unaccompanied FFRDC personnel to engineering meetings with the Contractor. These FFRDC advisors have issued tasking and direction at these meetings. Moreover, on at least one occasion. Government personnel provided to the Contractor Program Manager a list of the Contractor team members to be removed from the contract. The Government Contracting Officer stopped this action and advised that it should not re-occur. The Contractor asserts that this activity had happened on two previous occasions. cricket VPN 4:52 PM 61% E-Case Study Troubled Softwa... These events have contributed to a Contractor-Goverment relationship that can be described as poisonous. It is unclear if any key stakeholder, on either side, has sufficient trust in their counterpart to enable the program to proceed. Additionally, there is a total absence of teamwork or cooperation between the Contractor and FFRDC A. The Contractor has indicated that there is no shared vision for the project It is clear that not everyone understands or agrees to a common definition of roles or responsibilities. For instance, both the Contractor and FFRDC A believe that they are the system integrator. This has caused communication problems in the past, and the Contractor indicated that they had to "lock down communications between FFRDC A personnel and Contractor developers. Apparently, the developers were being tasked" by several people (including FFRDC A) and the Contractor needed to get control of tasking, FFRDC A has stated that it believes the Contractor is trying to hide things from the Government. The Contractor agrees that a "gut check" would be a good thing at this point. They indicated that there were some things from PIR that did not occur and that there needed to be a baseline freeze and formal change process instituted. The Contractor is motivated and committed to bringing out this project successfully. They brief this project at their corporate headquarters every week The Government has engaged a second FFRDC, "FFRDC B." to develop a system architecture and provide systems engineering support to the program. Many critical project artifacts and processes do not even exist, while others are not being used effectively. Specifically the Contractor has recently provided an updated WBS, an organizational chart, and a project plan However, these artifacts only cover the Contractor's segment of the project (ie the Contractor's area of responsibility). There is currently no WBS down to the control account level, no project plan, no change management plan, no communications plan, no risk management plan and no documentation of the System Architecture. Both the Contractor and FFRDC A still believe that they are the systems integrator. With FFRDC B assuming responsibility for systems engineering and architecture tasks, they also now play a role in systems integration Communication continues to be a problem. There is a perception by some project team members that the Contractor is not forthcoming with information. The perception from the Contractor is that direct communication continues to result in inappropriate tasking outside of accepted project controls. Moreover, there does not appear to be a Risk Management process The common refrain heard in both Contractor and Government offices is. "We may not make IOC