Secure Buildings Access Control (1993)

Something Seems "Fishy"

I should have realized at the start that this project smelt a bit "fishy". I had been hired by a past colleague manager for a 6 month contract to "just wrap up this major project to sign-off acceptance". The warning sign was that the original development team had resigned 'en mass'.

But times were tough, the clients were prestigious and I was up for a challenge. The project - "Building Security and Access Control" at the Australian Federal Parliament House (the security pass office operated by the Australian Federal Police), and the Department of Defense Security Office (so at least we didn't have the prospect of the clients going bankrupt on us).

My colleague took over the project management, I was the general technical "dog's body", tester, implementer, trainer and day-to-day client liaison, and we got one developer back to do code fixes.

The purpose of this blog is not to describe the whole project, but just to high-light some interesting, even humorous, aspects of the projects and lessons to learned.

Be Very Careful of System Parameters with a Sensitive Human Aspect

One aspect of the implementation at DoD, was interfacing to an "intelligent" revolving door. These doors had two special security features. There was an air-volume displacement measure to detect if two people tried to go through the door together. The other was a sonic detector of flat surfaces to detect people exiting with boxes etc.  These detectors were connected to a recorded voice warning enunciater. 

The first warning that we had of the need to tweek the parameters was when one of the more 'robust' ladies of the DoD tried to enter - the door went into reverse to back her out, announcing "One at a time please!" Oops!

Next we had an Admiral try to exit wearing his (flat top) hat. Oops! (Staff, including Admirals, had to be reminded that protocol barring wearing of hats indoors, included inside the exit doors).

The Most Difficult Part of Government Contracts is Getting Paid

The major problem of both projects was the lack of any robust, agreed set of Acceptance Criteria. And government departments are especially sticklers for not paying a cent until satisfactory acceptance has been signed-off. This is a real trap for small technology companies, as this was, who seem to think that all they need to do is to develop a good technical solution.

One thing I have learned over the years is that "Acceptance" is NOT "Testing" and that "User Acceptance Testing" is a misnomer.  

The Acceptance "Demonstration" must be specified with a well defined set of inputs which will produce the expected, documented outputs. "Dry runs" of "Acceptance" must be run before-hand error-free before attempting the sign-off demonstration to the customer. The acceptance criteria must NOT allow unfettered trial-and-error usage. There must be no unexpected errors. Demonstration to the customer for acceptance sign-off is not the time to be still discovering bugs. After acceptance, there will be a warranty period in which bugs uncovered by the customer during normal use, can be fixed.

If a "big bang" acceptance sign-off is of concern to the customer, then negotiate the contract with staged payments with the majority paid on primary "acceptance", and the balance after some defined settling-in period - define incident/problem severity levels and acceptance of settling-in defined along the lines of "2 weeks with no 'Severity 1' errors, and no more than 2 'Severity 2' errors per week" (as an example).

Getting Burned

Did we finally get paid? Not in my time there. Four months in, my pay cheques stopped coming. I stuck it out to the end of my term, but soon after, the company filed for bankruptcy and I lost out 2 months salary and a month's travel and accommodation expenses. Just before the end, two more clients had been signed up for the system. That part of the business was the only section to survive, sold off at 10 cents in the dollar and the administrators were chasing payment of the above contracts.