DYNAMIC PAGE -- HIGHEST POSSIBLE CLASSIFICATION IS
TOP SECRET // SI / TK // REL TO USA AUS CAN GBR NZL
(U//FOUO) Letter to the Editor : A Tool Developer's Perspective on
'Roadblocks to Change'
FROM: the editor
Unknown
Run Date: 01/25/2006
(U//FOUO) Here's one more reader comment on the topic of tool
development (prompted by the "Roadblocks to Change" article),
from the vantage point of a tool developer:
SERIES:
(U) Roadblocks to
Change
(U//FOUO) The January 10, 2006 article "Roadblocks to Change,"
was interesting to me only in that it restated many of the already
obvious cultural currents we tool developers already know too well.
As a tool developer, supporter, maintainer and marketer (for lack
of a better word) for a dozen years now, I have seen the resistance
to change and reluctance to adopt technology at every level of the
agency. Management is only one facet of the problem. Human
nature is the fundamental aspect to the challenge we face to
deliver new capabilities to the work force.
1. Study Points Out
'Roadblocks to
Change'
2. Letters to the Editor
: About 'Roadblocks
to Change'
3. Letter to the Editor :
More on Tool
Development
4. Letter to the Editor :
A Tool Developer's
Perspective on
'Roadblocks to
Change'
5. Letter to the Editor :
Getting Buy-In for
Tool Development
6. Letters to the Editor
: Still More on Tool
Development
(U//FOUO) Analysts have grown accustomed to, and are
exceptionally skilled at, taking comparatively inferior and/or
obsolete products and forcing them, despite the odds, to make
them perform incredible feats. As such, these end-users have
become developers in their own right and take pride in these
legacy systems which have outlived their usefulness in the face of
newer technology. Under these circumstances, the deck is stacked
against us as we venture out to them and offer promises of "a
better way to work." How could we possibly expect to receive
anything but skepticism and entrenchment as a response from
these analysts, when they not only have something in their hands
they believe works, but is also, to some degree, "resculpted" by
their own hands after their own specific needs?
(S//SI) Stating this problem is only climbing the mountain to the
summit to get a better view of the situation. Once on top of it, the
other half of the project is getting back down again and making
solutions that work and are adequately implemented. While it is
true that a sound and thorough requirements-elicitation phase is
essential to get the new product off the ground toward
development, this interaction with the customer must be an
ongoing communication throughout the design, development and
delivery of the new systems. This is something that is usually
lacking here, or at best, confined to an extreme minority of the
stakeholders.
(U//FOUO) My office develops tools for the needs of approximately
4000 community end users, but we tend to get input and feedback
from the same 15 - 20 individuals year after year. We need more
buy-in if we are truly to give the majority something that can be
readily accepted with satisfaction. Doing so will not only instill trust
in the tool-development process, but also speed up the delivery
and reduce costs. These are mainstays of the Software Engineering
discipline to which this agency has devoted a huge amount of time,
money and effort to promote. So far, even after 5 years of trying,
the culture hasn't changed much. But I remain hopeful and
optimistic that it can shift toward optimization.
--
(U) See also previous Letters to the Editor on this topic:
-- About "Roadblocks to Change"
-- More on Tool Development
"(U//FOUO) SIDtoday articles may not be republished or reposted outside NSANet
without the consent of S0121 (DL sid_comms)."
DYNAMIC PAGE -- HIGHEST POSSIBLE CLASSIFICATION IS
TOP SECRET // SI / TK // REL TO USA AUS CAN GBR NZL
DERIVED FROM: NSA/CSSM 1-52, DATED 08 JAN 2007 DECLASSIFY ON: 20320108