Virtual Case File

A Report on VIRTUAL CASE FILE Failure

Submitted by: Tage Nobin Roll No- 20070653 B.Tech (V Sem) Dept. of Computer Engineering Dr. Baba Saheb Ambedkar Tech. University

VIRTUAL CASE FILE

“THE MOST HIGHLY PUBLICIZED SOFTWARE FAILURE IN HISTORY"

INTRODUCTION •

What is Virtual Case File? As the name stands for, the term Virtual Case File means a system in which all the information and data’s would be in virtual term i.e. the they would be stored and available from computers; no more mental challenging paper works and ease of exchanging notes and remarks about all related cases. The project Virtual Case File that the FBI went for was supposed to automate FBI’s paper-based work environment empower agents and officers to access, view, edit, store, and replicate case files online anywhere where there is an internet or wireless access. It would allow agents and intelligence analysts to share vital investigative information, and replace the obsolete Automated Case Support (ACS) system. This revolution would have improved productivity, increase morale, reduce waste, and most importantly, let agents be agents, not file managers and computer technicians. In short, Virtual Case File was thought to revolutionize the way FBI worked and accessed information.

ORIGIN Facing a big problem in dealing with the running Automated Case Support system the FBI hauled for a total change in its IT department. The FBI finally decided the plan and in September 2000, the FBI announced the "Trilogy" program, intended to modernize the bureau's outdated IT infrastructure. The project was originally scheduled to take three years and cost $380 million and asked. In September 2000, Congress approved $379.8 million over three years for what was then called the FBI Information Technology Upgrade Project. Eventually divided into three parts, the program became known as Trilogy. 1. Purchasing modern desktop computers, printers, fax machine and all other related devices for all FBI offices. 2. Developing secure high-performance WAN and LAN networks, and modernizing the FBI's suite of investigative software applications. The Transportation Network Component would provide secure local area and wide area networks, allowing agents to share information with their supervisors and each other.

3. The User Applications Component, which would ultimately become the VCF, staked out the most ambitious goals. First, it was to make the five most heavily used investigative applications—the Automated Case Support system, Intel Plus, the Criminal Law Enforcement Application, the Integrated Intelligence Information Application, and the Telephone Application—accessible via a point-and-click Web interface. Next, it would rebuild the FBI's intranet. Finally, it was supposed to identify a way to replace the FBI's 40-odd investigative software applications, including ACS.

The first two goals of Trilogy were generally successful, despite cost overruns. Replacing the Bureau's Automated Case Support (ACS) software system proved difficult. It had been developed in-house by the bureau and was used to manage all documents relating to cases being investigated by the FBI, enabling agents to search and analyze evidence between different cases. ACS was considered by 2000 a legacy system, made up of many separate stovepipe applications that were difficult and cumbersome to use. ACS was built on top of many obsolete 1970s-era software tools, including the programming language Natural, the ADABAS database management system, and IBM 3270 green screen terminals. Some IT analysts believed that ACS was already obsolete when it was first deployed in 1995.

LAUNCH Bob E. Dies, then the bureau's assistant director of information resources and head of the Trilogy project, prepared initial plans in 2000 for a replacement to ACS and several other outdated software applications. In June 2001, a cost-plus contract for the software aspects of the project was awarded to Science Applications International Corporation (SAIC), and the network aspects were contracted to DynCorp. Dies was the first of five people who would eventually be in charge of the project.

THE FAILURE Unluckily for the FBI, its antiquated IT systems were in the spotlight following the September 11, 2001, terrorist attacks, when counter- terrorism became the top priority. After terrorists crashed jetliners into the World Trade Center and the Pentagon, the FBI, were being criticized for not "connecting the dots” in time to prevent the attacks. Critics challenged that they (FBI) did not have the software necessary to connect any new dots that might come along. And won't for years to come. As a result, the call for intelligence management became the topic of utmost importance. In January 2002, the FBI requested an additional $70 million to accelerate Trilogy; Congress went further, approving $78 million. DynCorp committed to delivering its two components by July 2002. SAIC agreed to deliver the initial version of the VCF in December 2003 instead of June 2004. On 13 December 2003, SAIC delivered the VCF to the FBI, only to have it declared DOA. Under Zalmai Azmi's (then CIO) direction, the FBI rejected SAIC's delivery of the VCF. The bureau found 17 "functional deficiencies" it wanted SAIC to fix before the system was deployed. As an April 2005 report from a U.S. House of Representatives committee pointed out, there were big deficiencies and small ones. E.g.: One of the big ones was not providing the ability to search for individuals by specialty and job title. Among the small ones was a button on the graphical user interface that was labeled "State" that should have read "State/Province/Territory." SAIC argued that at least some of these deficiencies were changes in requirements. While SAIC fixed bugs, Azmi, with the help of Depew's team, created investigation scenarios that would take different cases from opening to closing and tested them on the VCF. Those tests revealed an additional 400 deficiencies. SAIC finally offered to take one more year to make all the changes the FBI wanted at the cost of an additional $56 million, Azmi rejected the proposal. The software was intended to be little more than a web front-end to the existing ACS data.

Countdown to Catastrophe • • • •

September 2000- FBI IT Upgrade Project, later called Trilogy, funded for US $379.8 million. September 2001- Robert S. Mueller III replaces Louis J. Freeh as FBI director a week before the terrorist attacks of 9/11. October 2001- Robert J. Chiaradio advises Mueller on software he dubs the Virtual Case File and brings Larry Depew aboard. January 2002- FBI receives an additional $78 million to accelerate Trilogy.

• • • • • • • • • • • • •

February 2002- Joint Application Development planning sessions begin; Sherry Higgins hired. August 2002- Matthew Patton hired by SAIC as security engineer. November 2002SAIC and FBI agree on baseline requirements; Patton leaves SAIC. December 2002- FBI receives another $123.2 million to complete Trilogy. September 2003- GAO reports that FBI needs enterprise architecture. December 2003- Zalmai Azmi becomes acting CIO; SAIC delivers VCF. March 2004- Arbitrator finds that of 59 problems, 19 were FBI changes to requirements and 40 were SAIC errors. June 2004- FBI asks SAIC to develop Initial Operating Capability (IOC) for $16.4 Million; FBI contracts Aerospace Corp. to evaluate the VCF. January 2005- Field trials of IOC begin; Aerospace Corp. delivers its report. February 2005- Final Office of the Inspector General's report on Trilogy comes out; Senate hearing, 3 February. April 2005- FBI officially kills the Virtual Case File. May 2005- Mueller announces a new software project called Sentinel. December 2005- Contract for phase one of Sentinel to be awarded.

Why the VCF was so important? The FBI has many divisions. Each division had its own IT budget and systems. And because divisions had the freedom and money to develop their own software, the FBI now has 40 to 50 different investigative databases and applications, many duplicating the functions and information found in others. Last year, in an effort to centralize IT operations and eliminate needless redundancies, the FBI's chief information officer, who reports to the director, took charge of all its IT budgets and system. Agents investigate everything from counterterrorism leads to bankruptcy fraud, online child pornography rings to corrupt public officials, and art thefts to

kidnappings. They interview witnesses, develop informants, conduct surveillance, hunt for clues, and collaborate with local law enforcement to find and arrest criminals. Agents document every step and methodically build case files. They spend a tremendous amount of time processing paperwork, faxing and FedEx-ing standardized memo and requisition forms through the approval chain—up to the squad supervisor and eventually to the special agent in charge.

REASONS FOR FAILURE In a devastating 81-page audit, released in 2005, Glenn A. Fine, the U.S. Department of Justice's inspector general described various factors that contributed to the VCF's failure. Among them: poorly defined and slowly evolving design requirements; overly ambitious schedules; and the lack of a plan to guide hardware purchases, network deployments, and software development for the bureau. The whole picture paints a picture of an enterprise IT project that fell into the most basic traps of software development, from poor planning to bad communication. The project demonstrated a systematic failure of software engineering practices: •

Lack of a strong blueprint from the outset led to poor architectural decisions.

•

A competent and a permanent team leader’s absence were felt. Several officers and managers were transferred and changed during the term of the project leading to confusion and clash of ego.

•

No time bound was assigned. The schedule was another area where this project lacked the necessary depth. The pressure was on for getting it done in a time frame window that was defined from the top. There was obviously no room for negotiation of the bottom up details, or at least it was not an environment that was conducive to schedule negotiation. In this type of environment you get a schedule that appears to meet the top down window and everyone is happy, for a while. Then things get behind, blame gets assigned and reassigned, and the team is generally viewed as not being up to the challenge. This type of project planning never generates any winners in the end

•

Repeated changes in specification.

•

Repeated turnover of management, which contributed to the specification problem.

•

Micromanagement of software developers.

•

The inclusion of many FBI Personnel who had little or no formal training in computer science as managers and even engineers on the project.

•

Scope creep as the requirements were continually added to the system even as it was falling behind schedule.

•

Codes bloat due to changing specifications and scope creep. At one point it was estimated the software had over 700,000 lines of code. As the system pieces came on line for testing, the feedback from the FBI to its vendors was that it was not operating as needed and the vendors were inundated with change requests. As the changes mounted, the frenzy to get them fixed mounted, which resulted in inconsistencies at the interfaces of various software modules. This in turn created another set of changes to get the interfaces aligned.

•

Addition of more people and resources to the project as it was falling behind, which made it later still (Brooks' law).

•

Planned use of a flash cutover deployment, which made it difficult to adopt the system until it was perfected.

•

As usual, there were wiser heads inside and outside the project whose warnings were ignored. One of the best examples is Matthew Patton. The VCF had Matthew Patton, a security expert who was taken on by the VCF Contractor, SAIC in 2002 and left after a few months. From the start, Matthew had some serious reservations about the project, which he raised with his supervisor but to no effect. In frustration, he posted an article regarding his reservations about the project on a web discussion board in October 2002. The immediate result of Matthew's action was that he was taken off the project and left SAIC shortly thereafter.

•

weak information technology investment management practices at the FBI,

•

weaknesses in the way contractors were retained and overseen,

•

Inadequate resolution of issues that warned of problems in Trilogy's development.

•

There was no plan B. All that FBI wanted to do was replace their existing software system; the consequences and plans were never given a thought.

IMPLICATIONS The bureau faced a great deal of criticism following the failure of the VCF program. While the bureau claimed in testimony to Congress that the program lost $104 million in taxpayer money, some analysts believes the true figure is at least twice as high. In addition, the bureau continues to use the woefully antiquated ACS system, which many analysts feel is hampering the bureau's new counter-terrorism mission. In March 2005, the bureau announced it is beginning a new, more ambitious software project codenamed Sentinel to replace ACS, expected to be completed by 2009. This time around the bureau will be able to use lessons learned from the

successful New York Police Department Real time crime center project as a template for its own design.

SOLUTIONS As the automation life is beginning to take place, more and more the need of software is being seen in action. The increasing development of software witnesses many debacles also. According to a recent study, as many as 80-90% of IT projects run over budget or are terminated prematurely. And even those that reach some sort of completion often fall far short of meeting user expectations and business performance goals. The Standish Group reports that around 30% of IT projects will be cancelled. Around 52% of projects will cost 189% of their original estimates. Only 16% are completed on-time and on-budget. In larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. There are many real time failure cases of software, and the numbers of such cases are moving positive. Any kind of software that is being developed, needs some basic and core techniques which can’t be replaced and are indispensable. The failure of high profiled Virtual Case File software project shed light to some major details. There are some steps and solutions that a software development should take to avoid such failures. •

Any software that needs to be developed needs a clear cut blue print. An accurate outline of the project on which you can base your implementation plan and monitor project progress. As to what are the client’s needs and what they expect from the software. This in turn makes the developer more focused during the whole process development.

•

All the needs should be foretold. If requirements are done well you will find minimal trips back to rework a design for features. Constant change of plans and requirements make the software development lame.

•

A permanent team leader or manager with good technical knowledge and upmost experience would do surely do justice for the development of software.

•

Time plays a very important role in any kind of software development especially in major project such as the VCF. A deadline makes the team work harder and stay focused. But the deadline should not be so near that software is develop in hurry. Proper analysis of any kind of risk involved in failure must be studied. No one likes discussing project risks. It is human nature to think positive, nothing will go wrong. Sometimes success or failure is

•

determined by how well prepared a project team is when disaster occurs. If the project team or organization is not prepared, the project may stop unexpectedly until a new plan can be executed. •

A sound communication between the various teams of the software development is very essential. Without a good communication, there is a very good chance of confusion and misunderstanding evolving in the process.

•

The most critical area in implementation is that delicate transition between the way it was done before, and the way it will be done on the new system. This process needs to be fully understood and properly controlled with full involvement of both business and IT personnel, not just IT alone. For maximum understanding and exchange of ideas in this transition there must be a large area of commonality of understanding and terminology between how the business sees and defines its processes, and how the IT sees and defines the processes.

•

Adequate software testing. Without documented business procedures, there is no clear basis for testing the system and no way of gauging the benefits of implementation. Even the most sophisticated software testing methodologies and tools require a detailed definition of what is expected of the software to be given before their sophistication can be fully exploited. Without process definition this is not possible to provide.

•

A good resource should be made available. Organizations usually don’t have all the resources to manage every aspect of their development projects, therefore optimum use of the available resource should be done. Not recognizing your company’s resource limitations can be a software development project’s undoing.

•

Last but not the least, software or say the final output needs a thorough review. A good review always paves way for the complete and good software.

Developing software has always been a herculean task with lots of out-of-track works. But with all the new automation technology we have now and new ones that are being constantly developed, there is very good chance that developing codes for software will be automated with zero percent of error. All we need to do is to manage ourselves for management.