SBInet, DHS Secure Border system

Just replace some of the names and you feel like your in the Middle East, where projects are known to be delayed, technology is always ahead of what was originally planned and the overall cost is several times higher then originally planned….

Important aspects of SBInet remain ambiguous and in a continued state of
flux, making it unclear and uncertain what technology capabilities will be
delivered, when and where they will be delivered, and how they will be
delivered. For example, the scope and timing of planned SBInet deployments and
capabilities have continued to change since the program began and, even now,
are unclear. Further, the program office does not have an approved integrated
master schedule to guide the execution of the program, and GAO’s assimilation
of available information indicates that the schedule has continued to change.
This schedule-related risk is exacerbated by the continuous change in and the
absence of a clear definition of the approach that is being used to define,
develop, acquire, test, and deploy SBInet. The absence of clarity and stability in these
key aspects of SBInet impairs
the ability of the Congress to oversee the program and hold DHS accountable for
program results, and it hampers DHS’s ability to measure program progress.

SBInet requirements
have not been effectively defined and managed. While the program office
recently issued guidance that defines key practices associated with effectively
developing and managing requirements, such as eliciting user needs and ensuring
that different levels of requirements and associated verification methods are
properly aligned with one another, the guidance was developed after several key
activities had been completed. In the absence of this guidance, the program has
not effectively performed key requirements definition and management practices.
For example, it has not ensured that different levels of requirements are
properly aligned, as evidenced by GAO’s analysis of a random probability sample
of component requirements showing that a large percentage of them could not be
traced to higher-level system and operational requirements. Also, some of SBInet’s operational
requirements, which are the basis for all lower-level requirements, were found
by an independent DHS review to be unaffordable and unverifiable, thus casting
doubt on the quality of lower-level requirements that are derived from them. As
a result, the risk of SBInet not
meeting mission needs and performing as intended is increased, as are the
chances of expensive and time-consuming system rework.

SBInet testing
has not been effectively managed. For example, the program office has not
tested the individual system components to be deployed to the initial
deployment locations, even though the contractor initiated integration testing
of these components with other system components and subsystems in June 2008.
Further, while a test management strategy was drafted in May 2008, it has not
been finalized and approved, and it does not contain, among other things, a
clear definition of testing roles and responsibilities; a high-level master
schedule of SBInet test
activities; or sufficient detail to effectively guide project-specific test
planning, such as milestones and metrics for specific project testing. Without
a structured and disciplined approach to testing, the risk that SBInet will not satisfy user
needs and operational requirements, thus requiring system rework, is increased.

Seriously, long term, highly technological projects always risky to manage. In a way, I admire those that can manage a project with hundreds and thousands of dependencies, external controls, budget constrains and eventually deliver a solution. I am sure that under the proper guidance, this said system will become the cornerstone of the border control system.

]]> http://securitypie.com/you-dont-build-a-fence-this-way/feed/ 0