[ale] Save the FED your Money / I need Advice / The Zero Defect Methodo logy

[Jeff Hubbs]

I myself have been twice employed as a contractor to the Federal
Government and I worked for the Gov't for 12 years as a Fed doing IT, so
what you're alluding to is something that has been a bit of a focus area
for me for most of my career.  

I am not familiar with the "Zero Defect" school but I have read up quite
a bit on Extreme Programming (XP) and am currently reading a book called
"Agile Software Development Ecosystems."  I have had occasion to apply
some XP principles in both software development and even project
management and got a hint of the power of that approach.

Most of my recent experience has involved several different departments
of the CDC.  It may sound ironic coming from me now, but in my
observation, one of the biggest obstacles to successful and effective IT
implementations I've seen in Government is simply...contractors.  

The Federal Government is not supposed to have "personal services"
contractors, i.e., people who are treated just like employees, and you
tell them what to do and, if you like, how to do it.  No, contractors
are employed by a private company and they are supposed to carry out
what the statement of work in the contract says.  To have any hope of
success, extreme care must be taken with the statement of work.  Many
time, it's not, and even if it is, there seems to be no good way to
simply instruct the contractor to employ the expertise necessary to
successfully accomplish a stated goal.  

There are many different ways to structure a Gov't contract.  One way,
"cost plus award fee," means that the contractor's costs are reimbursed
by the Gov't *and* they get an agreed-upon amount of profit for
accomplishing certain tasks.  It shouldn't be too hard to see where the
land mine is in that arrangement.  First, the contractor can spend large
amounts of money, accomplish very little with it, and still laugh all
the way to the bank.  Second, the criteria for the award fee can be
vague and the Gov't may not have the expertise to evaluate the
contractor's work critically.  

Think about it:  if the Gov't had the expertise to evaluate contractors'
competence, they would have to be able to do what the contractors do, in
much the same way that figure skating judges generally have a long
history of figure skating and coaching figure skating.  Musicians are
the best judges of other musicians' chops.  Put another way, if Gov't
staff were fully able to judge IT contractors' performance, they
wouldn't need the contractors.  

IT generally isn't like, oh, building a fighter plane.  The Gov't can
produce detailed specifications for a fighter plane and pay contractors
to design and even build one for their evaluation against those
specifications.  Gov't IT projects are rarely that cut and dried and
there are also many more ways to do them than conventional
accomplishments like building planes.  Perhaps I should say that there
are many more ways to get similar results in IT.  If you ask a bunch of
different contractors to make a plane, you have a fair idea that they'll
all be pointy in the front and have wings sticking out of the sides.  If
planes were designed and developed as differently as all the different
ways you can make a Web app (e.g., Zope, LAMP, ASP, J2EE), one plane
would look like a Frisbee, another would look like a tube, and yet
another would have big wings that flapped.  

In my years as a Fed, I've seen contractors do things for which I'd fire
a subordinate for cause, but the individuals that did these things not
only suffered no repercussions but neither did their employers.  For
example, one guy tried to bolster some claim with some mathematical
formulas which, upon the slightest inspection, made no sense at all. 
I've seen people suggest rearrangements of shift schedules and claim a
hard dollar savings (for a program that gave out cash awards for such
suggestions) when there was none and I reviewed one that claimed a
savings associated with the use of some gigantic Xerox printer that
inexplicably failed to account for the six-figure cost of the printer
(my report actually featured a proper recalculation with a *negative*
cash award).  

Time and time again, I've seen contractors use deception, stealth,
intimidation, coercion, and obfuscation to preserve their continued
existence and get as much money as possible from the Government, and one
of the reasons I left the Government for private industry was that I had
had enough.  

To date, the best-run Gov't IT operations I've seen were managed and
operated by Feds while I worked for the US Air Force.  The one guy I
learned the most from about system administration (he was about halfway
to being a BOFH, though) was a Fed.  Things have changed since then, for
the worse.  This is not to say that there are not good individuals
employed as contractors; what's really sad is that sometimes those
individuals are caught in a dysfunctional situation.

Another dynamic I've seen is that a Gov't organization will immediately
turn to contractors to carry something out without even evaluating the
ability of the Feds in-house to carry out or directly manage the work. 
Speaking for myself, I came into Gov't work as an engineer and
programmer, never having managed anything more than a MS-DOS PC.  In
three years, I had learned to run a VAX in production.  In three more
years, I had learned how to analyze IT budgets and improve
cost-effectiveness.  Three years on, I explored the possibility of using
Windows NT instead of Win3.1 and Novell and established working
production NT operations two years ahead of our IT contractor.  Three
more years on, and I was working with Linux and figuring out how to
apply it to real-world situations.  By and large, Feds working in IT now
do not seem to have that kind of hands-on growth and first-person
comprehension.  

Another thing I've seen is that the IT honchos in some Gov't
organizations got that way only because they had the biggest 286 at home
at some critical juncture and they got made "the computer guy" by
default.  Such people have never written code or set up a machine that
dozens or hundreds of people will use at the same time.  They have
protracted backgrounds in human resources, finance, or logistics.  They
think 1, 3, and 5 are prime numbers (this was the first "crack in the
wall" that outed one guy who was supposed to be everyone's "computer
hero").  

Hopefully, your overseers are different and perhaps your company or at
least your team is different.  One endemic problem at CDC is that
whereas the IT operations within the various programs operate with a
certain degree of independence, somehow the programs have interpreted a
list of hardware and software products that the central IT organization
supports as being a list of products whose use is mandated to the
exclusion of all else.  Since this circumstance has resulted in Win2K as
being the server operating system software of choice, one ramification
has been that expectations throughout CDC seem to be pretty low across
the board.  

But, I digress.  A lot.

As for your situation, remember what I said about conditions that drive
low expectations.  Also consider that your own management may not take
kindly to suggestions that save the Taxpayer money at their own
company's expense.  Come up with a bright idea that enables you to have
only three contractors on staff instead of ten, and next thing you know,
the only way you'll be at the next Christmas party is if you're catering
it.  

- Jeff

On Thu, 2004-04-15 at 13:02, Hogg, Russell E. wrote:
> 
> Perhaps it's obvious from my email address, but I'm currently employed
> as Contractor for the Federal Government.
> I'm doing my piece here trying to get the way the Fed Gov does
> software systems to have some rhyme or reason.
> 
> Basically most of the horror stories you've all heard about the way
> things are done within the G is true.
> 
> There are a lot of folks working hard to change it though.  
> I've been here long enough now that people are starting to listen to
> me.  So I intend to use my influence.
> The release I'm currently working on is going to go live May 8th
> (https://www.mypay.dfas.mil).  
> Yes it's presently .NET and IIS but that's really not the issue.  
> The issue is how the projects are organized and run.
> 
> Shortly after go-live there will be a kick off meeting for our August
> release, I intend to go to that meeting armed.  
> Armed with DOC and ideas and suggestions for what ails us.
> 
> I'm hoping for some advice on selling concepts to non-technical
> people.  
> In particular the ZERO DEFECT METHODOLOGY.
> 
> I've had some discussions with several people on the list about this
> stuff though I don't remember if any of them were on-list.  Grant, I
> know you and I have had a conversation about these concepts back when
> we were employed together.
> 
> If any of you have good links to articles or discussions on this stuff
> (particularly with a non-technical slant)
> Please send them on.  If I can make a strong enough argument then we
> will start to move that way.  (slowly)
> If I can get this system to run like it should then I could probably
> save the American Tax payers thousands of dollars a week that are now
> spent with support because of ill-design and ill-implementation.  Not
> to mention stop carrying a pager 24 hours a day.  (I might make more
> ALE meetings)
> 
> Thanks,
> 
> Russ
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ____________________________________________
> Russell.Hogg at OPM.gov
> x2367
> 
> 
> 
> 
> -------------------------------
> -- Even though this E-Mail has been scanned and found clean of 
> -- known viruses, OPM can not guarantee this message is virus free.
> -------------------------------
> -- This message was automatically generated.
> -------------------------------mo
> 
> 
> ______________________________________________________________________
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale