After having written up a lot of the requirements discussed here and
submitting them through a recognized user group, I received a number of
rejection notices with a reason of "not in plan". 

 

Could someone at IBM explain this reason a little further? I thought the
point of user requirements was to let IBM know what we wanted you to put
INTO the plan, not tell us that it's not in your plan. I mean, I know
you can't do everything, but that response is pretty useless - it tells
me nothing, and nothing gets done about the things we took the trouble
to document and write up through the formal process. 

 

I also got several responses (out of more than a dozen requirements) in
which that it was very clear that whoever responded didn't actually read
the requirement at all. This is even more frustrating, in that we've
pretty much wasted the time to document a problem and gotten nothing -
not even a good reason why you're not doing it - in return.

 

It makes the case for giving IBM requirements a lot harder if we get
responses like this. It really doesn't incline our management to help
you make things better if we don't know if you're even reading them, and
certainly not to do it on our own time and nickels. 

 

So, which is it, IBM folks? Do you want requirements, or not? If so, how
do we best phrase them to a) help you understand them, and b) help you
make the business case for doing them? 

 

-- db

 

Reply via email to