A bit of research via the Internet and some business analysis textbooks and you arrive at the conclusion there are five common problems encountered with requirements gathering.

So far so good. Unfortunately there is no agreement on what those ‘five’ actually are.

I have come across these:

  • Customers don’t (really) know what they want
  • Requirements change during the course of the project
  • Customers have unreasonable timelines
  • Communication gaps exist between customers, engineers and project managers
  • The development team doesn’t understand the politics of the customer’s organisation

And these:

  • Teams speak a different language
  • Pushing for Development to start
  • Delaying the documentation – We will document along the way
  • Keeping requirements Feasible and Relevant
  • Inadequate Review, Feedback, Closure

And many more.

Everything above is correct of course – these are all perfectly valid. But I have written previously on these pages about a trend in recent years for the technology team to be approached even without any detailed requirements at all. “Make it work” is the “requirement” – such as it is – and technology are expected not just to deliver a solution but to create requirements themselves, on behalf of the customer. I personally don’t have an issue with technology operating like this, though I have encountered people over the years that would throw their hands up in absolute horror. Even more discomfort is in store for those who (wrongly) seem to view technology merely as a ‘supplier’ of solutions – much like the people supplying the coffee machines or photocopiers…. Another topic for another time perhaps.

« »