The FBI’s VCF (Virtual Case File) project was kicked off as an automated, online mechanism for handling all the typical paper based forms currently in use for routine case reports. They needed a system that would allow sharing and cross referencing of virtually all the information they gather on a daily basis. They needed this system online yesterday so it is safe to say that timing trumped anything else in the decision making process. The project was launched into execution by an 800 page requirements document that spent a lot of time defining items like where buttons should go (the how) and far less emphasis on the details of what the system should do for the end users.

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. Another discovery as the complete system underwent testing was that features that were not required were implemented, while features that were required were not implemented, leaving a total of 400 system level deficiencies.

When it came time to find reasons for failure of this project there were 3 learnings that stood tall: poorly defined requirements, unrealistic schedules lacking required detail and the lack of a detailed plan to cover the hardware (computers and network gear) requirements and purchases. The requirement of needing the system online as fast as possible grew into a “we need to shoot from the hip” attitude. The team had actually planned to do a changeover from the old system (ACS) to this new system (VCF) in a weekend, and there was no fallback plan if there were any serious issues. There was also a failure to negotiate features vs. timing vs. cost with the vendors as the requirements evolved over the years. Reuse of existing code was also thrown out the door by one of the FBI’s key vendors, one might assume due to the “cost plus” nature of their relationship.

The VCF project was killed in April of this year after over 4 years of effort, 700K lines of unusable code and an expenditure of $170M The need for this system still exists and the FBI now plans to implement it using “off the shelf” software with an estimated implementation time of about 4 years.

What is to be taken away from this painful example of a doomed project? There are some classic examples of what most of know should never be done on a project, yet I am sure we have faced a time when we had to buckle to the pressure and cut corners in the interest of schedule. Did that decision work out well for your project? Or did you just end up feeling like things were under control in the near term, while farther down the road there was a surprise simmering that blew the production release date out of the water.

The VCF project was doomed before the 800 page requirements document was completed. Yes, 800 Pages of information that did not meet the requirements of a requirements document. Did any end user, or review it? This document should have been taken to the end users for review, buy-in and updating. It does take time to do this and definitely messes with a “shoot from the hip” mindset. Without this critical step how could they you have been sure the end product would be something that meets, or even comes near the end users requirements? The alternative is a lot of wasted time creating something that will need to be reworked again and again, or a project that is put to rest as a killed project. A key take away for us should be confirmation of the need to spend time on your requirements and review them in detail with those that are the customers of the finished product. If requirements are done well you will find minimal trips back to rework a design for “features”.

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. It does create some temporary relief in the early stages but it is a false sense of project security. The schedule planning process must be at a nuts and bolts level of detail and have room for pushback and negotiation. A second major take away: Build a detailed plan and stand up and hold your own on what the plan says can be done with the resources that are currently at your disposal.

Is planning a waste of time or is planning your only guarantee that you will meet an agreed timeline? You probably agree that planning is a necessity. If I start questioning the level of detail that is necessary in your planning I am confident this is where the opinions will begin to diverge. Looking at the VCF project above: they had a plan, they had requirements, they had resources, they had visibility and yet they failed miserably. Why? They did not have the necessary detail in their plan to be able to generate a solid schedule. Items were left off the list. They could not afford the time to do justice to the planning and it cost them the project! Not allowing enough time to plan is a dangerous corner to cut when attempting guarantee that a project stays on track.

I have been labeled a planning fanatic. So be it. I leave nothing to assumption and I ask a lot of questions when building a plan for a project. Questions like “are all the devices you need in your schematic available, characterized and have models behind them”? If they are not, they must be added as part of the plan for this project. Another good question would be “Is the parasitic extraction and back annotation tools your planning to use ready in the process you are using and does it cover all your devices and will it correctly annotate your spice netlists”? If it is not in place, to the required level of functionality, you must plan the steps that will have it developed to the necessary level for this project. Another good question for a mixed signal design is “How are you going to simulate the top level design and is everything you need in place to perform the necessary level of validation”? If there is tool flow development necessary to validate the design at the top, make sure to include it in your plan.

When embarking on the planning phase of your next project keep the necessary support functions in mind in addition to the specific tasks. Support items include the tools, capability improvements, design flow(s), best practices, reviews and any project assumptions. These are the area’s that can easily fall off the radar screen when you’re planning the project. If support items are not covered in your detailed project plan there is a sizable risk that they will come up and “surprise” you by quietly eating away at your schedule.

If you have any specific questions that you would like to see answered here please send me an email and I will address them anonymously, unless you indicate differently. I would also like to hear about potential topics for this newsletter.

email: jeff@jorvigconsulting.com

phone: 480-895-0478

web: http://jorvigconsulting.com