On Tuesday, 01/29/2008 at 03:24 EST, David Boyes <[EMAIL PROTECTED]> wrote: > 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.
For those wondering how IBM responds to requirements, we give one of these answers: - Available - Accepted - Recognized - Suggestion - Rejected Often a requirement's first stop is "Recognized". That is, we agree with the premise or the idea, and haven't made a decision about whether to do it or not. It's a kind of Limbo. If we decide we're not going to do it any time soon, but there's a chance, we'll make it a Suggestion. If we decide it's a bad idea or that we can't deliver it in the timeframe needed, we Reject it. If we are sufficiently smitten with the idea and intend to add it to the product, we'll Accept the requirement. Understand that number of Round Tuits in our posession is limited, though. When presented with a smorgasbord of delights that exceeds our gustatory capabilities, we prioritize: Which Good Idea shall we do? That means that there are a *lot* of Good Ideas that we don't do. And it goes without saying that IBM leverages its own requirements on the product. E.g. if we come out with a new processor, we have to add new support for it. Duh. What we don't like to do is leave a requirement in Recognized status forever. Do it, don't do it, but decide either way and move on. You know? Sometimes a requirement does not pass Go or collect $200 and is rejected or accepted outright. Of course, business needs change all the time, so a Rejection or Acceptance is no guarantee that it will never see the light of day or that it will be in release n+1. But remember that our response is a business response, not a technical one. It might be a great technical idea, but if doesn't match up with our strategic direction or investment portfolio, there's no sense in pretending that we're going to invest in it. > 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. If you or anyone else feels that a z/VM requirement you submitted wasn't properly understood or considered, contact me off-list and I will look into it. No one should feel marginalized by the process. Disclaimer: I doubt many people are satisfied by a rejection of their requirement. We intentionally don't give much information about why and the personalities of those who submit requirements seem to need a detailed reason. I appreciate that and can sympathize with it. But lawyers dictate these things. To Rob's point about user requirements: In the announcement materials you will see a list of User Requirements that we believe have been met by the new support. > 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? Yes, we want requirements. The best are those that do not describe new widgets, but that describe business problems that the submittor feels VM can help alleviate. If you think a square widget would work better than a round one, feel free to say so, but tell us why. And business problems are usually phrased in a way that says "I want to grow my virtual server farm by 15% every 6 months, as measured by billions of microthingies per fortnight, but there is no Golden Widget that allows me to frangle a self-supporting side-bender efficiently." I hope this helps. Alan Altmark z/VM Development IBM Endicott
