Gathering requirements or taking orders is an excellent question. Most organization believe that requirements are what they want to happen. If they state they need a report, they believe that is a requirement. Most IT organizations will not take the time to work with the customer to figure out what the requirement is. As a business user your motives are not to mess up IT and make their job harder, you are looking to solve a problem you have. If you were assured the problem would be solved with the new system but it was not, you tend to stop giving requirements and start giving required solution. Or if something you asked for doesn't work the way you need it and IT tells you that was your requirement, you stop giving requirements.
When a customer tells us he has a requirement for a report, we tell them it is not a requirement. A requirement is to have this particular information provided at this time. Then we can review the possible alternatives to meeting the customer requirement. Understanding what the customer's business need is time consuming and difficult at times, we would rather jump into coding the solution.
However, a larger more difficult problem is the communications between the business and IT. IT wants the business to talk in term of there processes and what the processes are accomplishing. They want them to detail every possible "requirement" for their activity. This is totally unrealistic no one can pre-define with today's tools all the requirements that have for a given function. The business deals with "things"; parts, people, purchase orders, invoices, events, etc. If you want to effectively talk with business talk about the things they care about. Then understand what they want to achieve. Forget technology, they don't (or shouldn't) care. Just solve their problems.
If they need customer information for a particular marketing program they want to initiate, how can you support this requirement? Expect change, if they don't get enough customer using the criteria they established -- of course they are going to change the requirement. It's not a plot against IT it's running the business. The operations of the business will always take precedence over the comfort of IT.
If the current IT methodologies or processes are not working to support business than we need to consider changing them. Create a common view or shared perspective with your business users, then work to giving them the tools they need. Forget the complaining about the poor requirements or the giving of orders, find ways to talk their language and help them operate the business.
Rating:
Gathering requirements or taking orders is an excellent question. Most organization believe that requirements are what they want to happen. If they state they need a report, they believe that is a requirement. Most IT organizations will not take the time to work with the customer to figure out what the requirement is. As a business user your motives are not to mess up IT and make their job harder, you are looking to solve a problem you have. If you were assured the problem would be solved with the new system but it was not, you tend to stop giving requirements and start giving required solution. Or if something you asked for doesn't work the way you need it and IT tells you that was your requirement, you stop giving requirements.
When a customer tells us he has a requirement for a report, we tell them it is not a requirement. A requirement is to have this particular information provided at this time. Then we can review the possible alternatives to meeting the customer requirement. Understanding what the customer's business need is time consuming and difficult at times, we would rather jump into coding the solution.
However, a larger more difficult problem is the communications between the business and IT. IT wants the business to talk in term of there processes and what the processes are accomplishing. They want them to detail every possible "requirement" for their activity. This is totally unrealistic no one can pre-define with today's tools all the requirements that have for a given function. The business deals with "things"; parts, people, purchase orders, invoices, events, etc. If you want to effectively talk with business talk about the things they care about. Then understand what they want to achieve. Forget technology, they don't (or shouldn't) care. Just solve their problems.
If they need customer information for a particular marketing program they want to initiate, how can you support this requirement? Expect change, if they don't get enough customer using the criteria they established -- of course they are going to change the requirement. It's not a plot against IT it's running the business. The operations of the business will always take precedence over the comfort of IT.
If the current IT methodologies or processes are not working to support business than we need to consider changing them. Create a common view or shared perspective with your business users, then work to giving them the tools they need. Forget the complaining about the poor requirements or the giving of orders, find ways to talk their language and help them operate the business.