Wow Jerrry... that's some vent.
I do agree with you though. I do think that the process could be more
streamlined.
I went through my Tivoli Rep once and must admit that I'm still wondering if
he actually
submitted anything to anyone. I haven't heard a thing. No, not even
"Mr King, thanks for your input. Get stuffed, Tivoli Development".
What I would personally like to be made generally available is this "list of
requirements" along with
their associate priority for implementation and an expected release date. I
realise that this list could
be quite dynamic. Some things taking longer than expected and other
requirements pushing existing
requirements further down the priority list, but at least you would get a
feel for what the future is.
At least one would know if Tivoli/IBM were aware of the problem/requirement
and how important they
think it is.
-----Original Message-----
From: JerryLawson [SMTP:jlawson AT THEHARTFORD DOT COM]
Sent: Friday, November 19, 1999 8:12 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Wanted: A working requirements process
Date: November 19, 1999 Time: 9:21 AM
From: Jerry Lawson
The Hartford Insurance Group
(860) 547-2960 jlawson AT thehartford DOT com
----------------------------------------------------------------------------
-
-
One of my biggest gripes with the whole *SM product set of late is
One of my biggest gripes with the whole *SM product set of late is
that the
things that we need often do not seem to get considered when new
versions
come out. Now to be fair, some of them do get in, but often the
ones that
are near and dear to our hearts seem to either be missed, or they
show up in
ways that we never expected. This was never more apparent than at
the
Symposium this fall, when we were presented with all of the new
features in
TSM 3.7. Then, in the last session, we were presented with a set of
features
that were all very well received by the attendees, many of them
coming from
requests that go back to V1 of the product (the features, not the
attendees!). The problem was that all of these features were not
even in the
development plan for the next release!
In poking a bit deeper, Tivoli will admit that there is a
requirements
process, but that you must either go to a SHARE meeting, or submit
the
requirements to your Tivoli representative. I would like to suggest
that
this process is flawed from the beginning, and needs to be replaced.
Why do
I say this?
1. SHARE is a great organization, but using it (or its sister
organizations
outside of the United States) has a major flaw. These organizations
are IBM
user groups, and primarily mainframe based. So if you are an *SM
customer,
and you don't have a mainframe, you may not even know about Share.
Or even
if you do have some IBM big iron, but you run ADSM on Sun or HP or
NT or
AS/400, you still may not know about SHARE, or if you do, you may
not be able
to attend.
2. Even if you do know about Share, if you can't attend, then
submitting
requirements is difficult at best. Yes, you can mail them in, but
when they
are discussed and voted on, there will be no one to speak to the
requirement.
And if any questions come up, your requirement is likely to be
deferred
until a clarification can be obtained. This may mean that a group
of people
will rewrite it as they "think" you meant, or they will send it
back, and you
can resubmit for the next meeting in 6 months.
3. Yes, you can submit requirements to your local Tivoli rep, and
they are
glad to handle it for you. Sounds great. But the problem is that
if both
you and I submit the same requirement, we can't see each others
submission.
Of course, we will word the submissions differently, and so the
interpretation as to whether they are duplicates or not is left to
the
developers. You think this is a small point? There are several
thousand
requirements against our favorite backup product as we speak (I have
forgotten the approximate number, but trust me, it is substantial.)
I would
submit that if these requirements were truly unique, and there were
indeed
thousands of requirements against the product, then it either
wouldn't work,
or it would be so hideously implemented that no one could use the
product.
Both of these statements are by definition, false.
4. One more point with submission through your Tivoli Rep - there
does not
seem to be any response process. How are you supposed to find out
about the
acceptance of your requirement by the development staff?
What we really need is a system that allows us as customers to
submit
requirements in a manner that is easy to use, provides for a dialog
between
customers and development, and does not have a bias towards any one
area or
platform. We should be able to see if anyone has filed a similar
requirement, and if they have, add a "me too" to it. And the
process should
also be interactive in that Tivoli should be able (required?) to
respond back
with a status on the requirement - not a minute by minute standing
of where
the requirement is, but rather an overall response to the request
that gives
us some idea of where it stands. This would use a set of standard
responses
that would tell us if the request was to be included in the next
release,
would be considered at the next review, would require some major
redesign,
would not be included in our lifetimes, etc.
In my dealings with IBM requirements in the past, a major issue has
been the
control of requirements. Once submitted, IBM became very
proprietary with
them, and did not want them shared in an open forum. This is
understandable,
I believe, but can also be overcome with security and registration.
I think it is time that Tivoli revisited this whole issue of
requirements,
and did a little "out of the box" thinking in doing the redesign.
Those of
us who have been on this list for a couple of years probably
remember the
ADSM-R list, with its intent to foster a discussion of requirements.
This
was an excellent beginning, but it died quickly when it was
discovered that
it was one sided - IBM did not officially recognize it, and thus the
discussions that were held were by definition fruitless. The
requirements
that were discussed never made it back to development from the list.
With the *SM products, (and with many other Tivoli products), the
old models
of soliciting input and feedback simply don't fit anymore. The
audience of
customers is too diverse to make the old methods of any value - they
simply
do not reflect a significant number of customers to make them of any
value.
Ironically, Tivoli the company is all about the new world - the
internet,
eBusiness, and how to manage the brave new world. Doesn't it make
sense that
a company like this would solicit important feedback from their
customers
using the same environment that they are trying to promote? Does
anyone else
feel the same as I do - that no one is listening?
----------------------------------------------------------------------------
-
-
Jerry
Jerry
|
