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 that the
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
|
