Security authorizations: expired packages cut by more than half
Early in my IT career I inherited a compliance tracking system I didn't build and didn't understand. Before changing it, I learned how it worked, asked the people stuck in it, and found where it actually broke.
The problem
After retraining from pharmacy technician into IT, I joined the Wing Information Assurance office at Vandenberg Air Force Base. Every system on base needed an approved System Security Authorization Agreement (SSAA) to stay on the Air Force network. Our office tracked those packages for 4 groups and 49 tenant units.
A large share of the packages were expired. The Access database that tracked them was built by someone who had already left. I had no database experience.
Baseline
4 groups and 49 tenant units, about 5,500 network users
262 SSAA packages reviewed in my first six months
A large share of packages expired
A tracking database with no measures for where packages stalled, and outdated terminology
What was actually happening
On site visits, units told me the packages were hard to complete. The documentation requirements weren't clear, so packages sat unfinished or came back for rework. The delay wasn't a lack of effort. It was unclear requirements and no visibility into where packages stalled.
Where it broke
Two places. The submission itself, where units were guessing at what the certifier needed. And the tracking, where the database couldn't show us the bottlenecks.
The change
The tempting fix was to scrap the old database and start over. I didn't understand it well enough to do that yet. So I learned it first.
Reviewed returned packages to find the most common rejection reasons and where timelines stalled
Took a self-paced database course, then copied the old database and took it apart to see how it was built
Consolidated 52 overlapping packages
Built a standard SSAA template that spelled out what the certifier and Designated Approval Authority actually needed
Held short walk-through sessions for the units completing packages
Rebuilt the database with measures for bottlenecks and updated terminology
Result
Expired packages: down more than 50% (documented in my 2005 performance report, tied to the package consolidations)
Package completion time: down 40% with the new template (documented in my 2006 performance report)
These figures come from my performance reports, not a formal time study.
What I learned
Don't replace a broken system first. Learn how it works, ask the people stuck in it, and find where it actually breaks. The database wasn't the root problem. Unclear requirements were. The database just couldn't show it.
Method
Find the most common reason work comes back, standardize the input, then measure where it stalls. In EASIER terms: Ask what happens now, Spot where it breaks, Improve the way, then Review what changed. See all six process guides.
Related free tools
The Process Improvement Toolkit includes the 5 Whys and Pareto templates for finding your most common rejection reasons, plus a PDCA tracker to measure the fix. No email required.
