James Leal, an author on books about project management, states that “Delivering a project isn’t difficult. What’s difficult is delivering a project without first taking the time to plan properly”. In projects, it is tempting to rush right to the implementation, where you can actually start building the product that you want to produce. However, without proper planning things quickly fall apart. This and other mistakes that are commonly made during projects will be discussed in this article. In order to do so, I will use examples from a project for which over 170 million dollar was spent for software that was never taken into use: the Virtual Case File project.
The VCF Project
The final goal of the Virtual Case File project for the FBI was to replace the existing investigative software set, such as the Automated Case Support system, which was originally built for green-screen IBM terminals and was now emulated on regular desktop PCs. Moreover, it had to provide the FBI with the availability to “connect the dots” in cases – e.g. make links between the various filled reports, which was impossible with the legacy systems because they lacked a central, shared database between applications. However, the outcome of the project was a product consisting of over 700,000 lines of code that didn’t even begin to approach the functionality laid out in the requirements. By looking at the problems of VCF, we can learn about some common mistakes in projects – and how to avoid them.
1) Overly ambitious goals
At the start of the project, the objective was to come up with a web-based interface for the existing Automated Case Support system. However, in the light of the 9/11 attacks the goal was readjusted to a complete overhaul of the system. To make matters more complicated, the intention was to perform a flash cutover – fully replacing the existing system without a phase-in period. All of this had to happen from June 2001 to the end of 2003. Shockingly, the new system would be built from scratch: no existing software solutions would be used. This marks the first mistake of the project: setting overly ambitious goals.
When you set the objectives for a project, you should always keep an eye on the time (and sometimes budget) that is available. Larry Depew, the project manager of VCF, had no prior IT project management experience. This made it impossible for him to give a good estimate of the time required to complete the project. When you are making the planning for your project, get opinions from people who have worked on similar projects as much as possible so you are able to set reasonable deadlines.
Another thing that can be done to make goals more attainable is to look at what is already available on the market. For the VCF project a whole new e-mail-like system was developed, while the FBI already made use of Novell’s GroupWise, an off-the-shelf software package for electronic mail. When you are determining what has to be done for the project, keep in mind you can incorporate existing products and software libraries into your project – there is no sense reinventing the wheel if this doesn’t improve your project. In fact, the successor to the VCF project, project Sentinel, made extensive use of off-the-shelf software. By using existing solutions you can make an overly ambitious goal into a goal that is ambitious but within reach.
2) Unclear requirements
At the start of the realization phase of the project, it is good practice to have a clear statement of the intention of your project, and an overview of all the components and technologies that will be used to come up with this system. However, when starting VCF, no such blueprint was available: the FBI did not have a clear description of the workings of the current systems and the exact intention of the VCF project. As a result, it was impossible for the project members to “make coherent or consistent operational or technical decisions”, as stated in the report by the National Research Council on this project. In the contract for SAIC, the company in charge of the project, there were no formal criteria that could be used to accept or reject the delivered functionality.
To overcome this lack of clear requirements, at least a year was spent on gathering the required functionality for the system. Getting to a detailed requirements document meant meeting with experts in the field and employees at the FBI to meticulously record the existing and future processes used in the organization. These session resulted in a 800-plus pages description of the functionality of VCF. However, this document didn’t only contain a high-level explanation of the required functions of the program. Instead, the file dictated how every piece of functionality should be implemented. According to Matthew Patton, who was an employee of SAIC at the time, a requirements document should state that “we need an e-mail system that can do x…”, but instead stated implementation details such as “there will be a page with a button that says e-mail on it”.
At the start of a project, it is tempting to rush to the tinkering phase, in which you start to test different technologies in other to see which one fits your project best. However, in order to bring your project to a successful end it is better to start with a proper project initiation: define the requirements of the projects, divide the tasks and set the deadlines. In this way everyone goes into the project with a clear picture in mind of what the result of the project should be, and it becomes possible to check intermediate versions of your product against a set of norms that can be used to either approve of reject the delivered functionality.
3) Ignoring problems
Matthew Patton, who was working as a security engineer during his time on the VCF project, noted that the security of VCF could be greatly improved by implementing some of the existing security measures present at the FBI. However, when he presented his boss with these considerations, he was told to calm down and be a team player. Getting no support at his workplace, he turned to InfoSec News, a forum about information security.
In an email to this forum, he remarked that he wanted help getting in touch “with some heavy-hitting clued-in people over at the FBI”, who would “demand some real accountability from the contractors involved”. As it was “[The FBI] don’t know enough to even comment on a bad idea, let alone tear it apart.” He felt that the FBI didn’t want to “understand just how flawed the whole design is from the get-go”. Instead of taking these complaints into consideration, the FBI decided to fire Patton from the job. According to Sherry Higgins, who was in charge of overseeing the project for the FBI, Patton “… posted information that was not true and was sensitive”. Although Higgins sided with the FBI on Patton’s dismissal, she herself was also aware of the culture of ignoring the input of project members. She stated that “the culture within the FBI was, ‘We’re going to tell you how to do it.'”
From this we can learn that it is never wise to ignore problems with your project, or disregard the opinions of other people on your team. However critical their remarks may be, and however difficult it might be to fix the problem, you should listen to the problems that people working on the project bring to light. In this way, you are sure that you are not missing important aspects of the requirements, and everyone on the team becomes more motivated to achieve the goal, because what they say really matters.
4) Lack of communication
Closely related to ignoring problems is not communicating problems to the rest of the team. Sherry Higgins noted that “the feeling was, [SAIC] knew that they weren’t going to make it in December of ’03,” although this was never communicated to the FBI. When you have established the fact that there is a problem in your project, you should take care to communicate these worries to the rest of your team. Problems in projects rarely have the tendency to go away. On the contrary, the usually become more problematic as the project goes on. Therefore no-one should feel hesitant to communicate about issues they encounter.
Even though it was agreed that the software would be ready by the end of 2003 and it was apparent that it would not be ready by this time, the project could have been more successful by being more open about not being able to make the deadline. When issues are revealed timely, there is the possibility to ask for an extension of the deadline. Oftentimes, projects have a fixed deadline, which cannot be negotiated. In this case you can still make the project a success by eliminating some less important requirements of the project.
5) Lack of leadership
Even though all opinions of the members of the team should be taken serious, there should also be the possibility to take a stand on issues that pop up during the project. Failing to take a stand was clearly a problem during the VCF project, were agents from the FBI kept adding and adding requirements as the projected moved on. Instead of adding all this new required functionality to the product, someone should have stood up and said that the time to formulate requirements was over, and the focus should be on the implementation instead. Unfortunately, no-one who was working on the project showed the responsibility to do this. Zalmai Azmi, who was the CIO of the FBI in December 2003, observed that, in regards to the continuous expansion of the list of requirements, “there was no discipline to say enough is enough.”
In order to prevent problems like this, it is imperative to appoint a project leader, or chairman, right from the start. He or she can intervene when the progress of the project is jeopardized. However, this does not mean that all responsibility should fall on this leader. All project members should feel responsible for the advancement of the project, and should feel free to call impairments to the progress to the attention when necessary. Only in such a climate can you be sure that deadlines will be met.
Conclusion
In this article, you have seen five mistakes that are commonly made when working on a project basis, with examples from the Virtual Case File project for the FBI. Although each project is different, because each product calls for a different approach and each combination of team members asks for a different task division, each project can be brought to a good end when there is a clear goal that can be reached, the problems within the project are not ignored but communicated to the team in a timely fashion, and people feel responsible for calling impairments to the advancement of the project to the attention. Although this article covers some of the problems often encountered in projects, it is by no means comprehensive. Which problems in projects do you often come across?