In an earlier post I'd lamented about the problems in managing requirements, this post probably reads as a prequel to that one. What are the real problems when it comes to requirements analysis?
Meryl K. Evans of the lockergnome identifies 5 specific issues:
- Customers Don’t Know What They Want
- Requirements Change During the Project
- Timeline Trouble
- Communication Gaps
- Customer Organization Politics
Who tells the customer that he is wrong? The answer is embedded in another question. Do you even know that the customer is wrong? And when you say customer, who are you referring to?
As always the "two sides to a story" paradigm holds here. Business knows business. Technology speaks technology. Some of the requirements are never ever seen by the business user who is detailing his requirements - these are system requirements, file transfer protocols, security measures, compliance issues, hardware sizing, upstream applications, downstream applications. Showing mock-up screens and having walk-throughs and spewing tomes of documentation will get you a business buy-in, however beneath and beyond the snazzy drill-down reports and ease-of-use-navigation and pretty and a pie user interface lie the incompatible data formats, tucked-away-in-binary information , firewall issues, port problems, network latency, hardware scaling and application performance issues.
Ask any developer - can 'this' be done? and he will tell you... it 'caaaaaannn' be done, buuuuuuuut.... The length of the 'can' and the drag of the 'but', translate loosely to: Sure you 'm0&@#', I'm an engineer and this is code and I can get it done. However, do you realize the number of lines of re-coding and hours re-testing effort it takes to have that silly nice-looking jazzy useless piece of junk information on the screen? And, do you even begin to fathom the performance impact this is going to have on the downstream applications that use the data feeds from this system, and the weekend batch is going to take at least a couple of hours more? As you swivel nervously in his cubicle, waiting for him to say some thing more.. he ends the mystery abruptly by saying: No.
Can we involve the IT during the functional phase of requirements, ideally yes. Do they have to sit in everyone of the meetings? Probably not. However, before you go in for the final grand sign off from the 'business', make sure you have a tacit approval from the development. Goes a long way in avoiding surprises later.
I've noticed in several instances that accommodating requirements changes from the IT are more time consuming and project impacting than those from the business. Business can be 'made to understand'; whereas, IT issues are more immediate, critical and non-negotiable. Hey, if a particular entry violates the primary key, then you can't really do anything to code around can you? If the security policy will not allow users have then lower their browser security settings, you can't have the fancy browser based copy-paste functionality can ya?
This issue is compounded when multiple mini-clients exist within the client organization. And if there exist political friction between the client's teams.. ouch .. you are sitting on a live mine.
Time solves everything. Except when it's solving time related issues. Study the requirements and share the time-line with the customer. If you don't have any room for over-runs and slippages, fine - but, tell the client that you are running a tight schedule. This might help him, help you prioritize. If a project has even a minor chance of slipping time lines, then the chances are it will. and the earlier you the tell the client, the better it is.
