[ale] Save the FED your Money / I need Advice / The Zero Defe ct Methodo logy
Hogg, Russell E.
Russell.Hogg at opm.gov
Fri Apr 16 10:52:21 EDT 2004
I can tell you've worked in this situation. Your description is remarkably
accurate. The team here is probably far smaller than at the CDC so some of
those situations aren't quite as bad. For instance I almost certainly would
get no backlash from the company I work for saving contractor hours. This
is partly because the contract is so small that my status within it is one
of relative power, and partly because the company I work for has no more
upper level understanding technology than the Government it serves. RMCI is
a geology company that because of it's A8(sp) status (Let's not go there for
this discussion) got into technical services.
I'll add to what you stated that Government employees in this office have
only a "programmer" path for promotion.
So you guessed it, the people here basically have to take small extremely
simple software development tests to get their raises and promotions.
They study for weeks on end and in some cases have even been known to..
(deleted in the hopes of avoiding political flame war)
to pass these tests, and who can blame them.
The result is a huge number of people with the title programmer who in all
honesty couldn't tell you what an IF statement is. If someone were to do an
audit of this place and look at lines of code produced compared to number of
"programmers" they'd probably faint.
I agree with all the statements you made about Contractors. Contractors in
Government contracts are really a lot more like second class employees than
contractors in a real sense. The only positive thing is that if they don't
perform they can actually be sent packing. It's near impossible for the fed
to weed out the bad apples from it's crop.
I'll close by saying that most of the high level people I work with, GS-11s
and 12s,
Do herculean amounts of work trying to make up for the glut of people who do
nothing.
They manage these projects and are in many cases extremely overworked, which
is why nothing is at all organized.
Russ
____________________________________________
Russell.Hogg at OPM.gov
x2367
-----Original Message-----
From: Jeff Hubbs [mailto:hbbs at comcast.net]
Sent: Thursday, April 15, 2004 11:20 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] Save the FED your Money / I need Advice / The Zero Defect
Methodo logy
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
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale
-------------------------------
-- 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.
-------------------------------oi
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ale
mailing list