Stop 'gathering' IT requirements

There's a post on Techrepublic titled, Project Managers: Stop "gathering" IT requirements.' It's an interesting read.

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The author, Paul Glen's, point is that, "project managers should negotiate requirements among the stakeholders." My comments on the article are as follows:

• In order to negotiate well, a project manager really has to understand the nature of the project and client ask. If the project manager doesn't understand the ask (e.g., isn't familiar with the business), a strong supporting cast is needed to keep everything real. Are you more confident when you know your project manager has lead projects similar to the one you are on or is very familiar with the industry?
  
• Requirement 'gathering' means collecting requirements, however, a business analyst is paid to understand them, derive meaning from them and then communicate the underlying business objectives. To me, this is the core competency of the role. The article does not really talk about this. You do not need a business analyst to order take.
  
• The following comment from the article seems a bit over the top, "We should think of a set of requirements as being like a multilateral treaty among a group of nations." I understand the need to have clear understanding and expectations, but this sounds like something people do when they don't trust each other.
  

I think, if anything, this accentuates the need to have a strong capable business analyst.