DYNAMIC PAGE -- HIGHEST POSSIBLE CLASSIFICATION IS
TOP SECRET // SI / TK // REL TO USA AUS CAN GBR NZL
(U) Letter to the Editor : Getting Buy-In for Tool Development
FROM: the editor
Unknown
Run Date: 01/27/2006
(U//FOUO) The topic of "roadblocks to change" and the related
matter of tool development have elicited quite a response from the
readership! So much so, I've bundled the comments together into
a series, to make it easier to follow. Here are two more reader
opinions:
(U//FOUO) The January 10, 2006 article "Roadblocks to Change"
has stimulated some much-needed dialogue and the comments
generated by this article have begun to illuminate this issue. The
most recent comments, by
[ part 4 of this series -editor ], have offered some of the dimensions that a future solution
will need to include.
(C) This is not a new issue area and has been with us for quite
some time. In the days of old A2 we regularly did mortal combat
with the development communities of A6 and later A7 (A6's
predecessor). We were so feisty about the issues surrounding
computer capability because the computer was an integral part of
our analytic production. Because of our high interest we initiated
efforts to find a better way of doing business rather than continue
to fight all the time. As a result of the work of
(now
retired) and
we started the journey into the use of
Integrated Computer Assisted Software Engineering (I-CASE).
What we found was that I-CASE used diagramming techniques that
as analysts we could read and determine whether our practices and
needs were captured. The developers on the other hand could see
other things in those same diagrams. Thus in effect we created a
language between the two communities and we also created direct
involvement between the analyst and the project.
(C) Unfortunately the computer science community of that era did
not find our approach that appealing (amongst other things it
advertised automatic code generation directly from requirements).
It also occurred about the time that A2 went from an Office of
1200 to a part of a consolidated office of Russia and were now only
300 to 400 people. Management's attention shifted from efficient
business to down-sizing.
(C) As a result of these experiences it has always surprised me that
the NSA approach to software engineering had a hard time
appreciating that if one did not directly involve the target-using
community for a new system, that program would encounter great
difficult with the delivery. For example, in July 2002 the delivery of
the new NSRP was greeted with great consternation from S2 for
this very reason. More recently, the delivery of voice tools
(NUCLEON, CREST et al) similarly met with great resistance. When
you are intending to change the work practices of a group of people
those very people need to be directly involved in how their work is
to be changed. If they are not directly involved, do not expect
them to welcome the change. It really is as simple as that. Of
SERIES:
(U) Roadblocks to
Change
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
course the techniques are key and management's direct
involvement are critical to success.
(C) This spring the Rebuilding Analysis Program Office will deliver
the first spiral of the first increment of the Integrated Analytic
Environment. From the time that the contract was awarded to the
Harris Corporation, there has been a RebA Roll-Out Strategy group.
The group is chaired by S2 and its aim is to assure the smooth and
effective delivery of the IAE. As a member of the Strategy Group,
S2 Analytic Technologies for the Enterprise (S202) has shared its
experiences with delivering the voice tools. This experience helped
with creating the Early Adopters Working Group which is
structured around specific work units representing each of the 12
product lines and include around 150 people. Through the judicious
use of the time of the early-adopters,
has assured that
the developers understand the work practices of the analysts and
that the analyst see the potential of new ways of doing business.
The group has also recorded their concerns as well.
(U//FOUO) Its too early to say that this is the solution, but clearly
the management and leaders of S2 have devoted a lot of energy to
make this a successful delivery. Certainly the using community is
involved. Management is as well and it faces some tall challenges
before April.
--
(U/FOUO) I have been reading the chain of replies to the recent
article "Roadblocks to Change" and would like to add a couple of
thoughts to the fray. Let me start by stating that I am an enduser, an analyst and a report writer. In my office there are those
that often resist adopting new tools because they feel that it is too
difficult and time-consuming to learn how to use them. In other
words, they are very comfortable with the status quo. However, I
believe that in the majority of cases, they resist because the
change provides no apparent benefit to them.
(U/FOUO) It seems to me that software (tool) developers are
constantly changing our tools because that's their job. Let's face it;
if you build a tool that works and there's no need to change or
improve it, pretty soon you're going to need a new job. In the
corporate or government world, and in our everyday lives, the
software we use is in a constant state of change whether we like it
or not. Simply checking the version number evidences this
(Version 8.4.72.1a (beta), for instance). I'm sure that there are
improvements made with each new version, but often, they are
transparent to the end-user or merely provide a "fix" to existing
problems. Rarely do I see real capabilities added and when I do,
there's usually a loss of some other capability. And all of this costs
money and resources, both of which are in short supply, I'm told.
(U/FOUO) Our office currently is "resisting change," although
there's not much we can do about it. They tell us that soon we will
transition from UNIX-based platforms to NT-based platforms. I
fully understand why this is happening. I agree that the Agency
needs to use a common computing environment. Unfortunately,
the tools that we are supposed to use on the new platform are, at
best, equal to what we have now, and at worst, completely
inadequate for the tasks we are performing. All of the other
considerations concerning new software tools are inconsequential if
the tools can't be used to do our jobs. Even the most secure and
stable database tool is useless if I can't quickly insert, modify, or
access my data.
(U/FOUO) I strongly believe that the only way an organization can
properly affect change is to get people to buy into it. People need
to truly understand the "why's" and "what's" and have a vested
interest in successful change. Change cannot be forced from the
top down and truly achieve the desired goal. This may seem
obvious, but the general perception is that this is still the way most
changes are made.
--
(U//FOUO) Editor's note: FYI, this thread has been picked up by at
least one blog .
"(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