Specification gathering is one of the main reasons why IT project fail.
What is spec gathering?
One or more people from IT, could be a Project Manager, a Business Analyst or even a programmer, meet with the customers to gather requirements for a particular project.
In the meeting or meetings, the customer relays what the product is supposed to do.
Their job is to think through all the different scenarios that could arise.
Which means simulating different possible flows of data and following their paths to the end.
And it's ITs job to ask questions.
What happens when this occurs? How should we handle the exceptions? What if they happens for this reason, what should the application do?
However, for one reason or another, not blaming either side, all possible scenarios are not hashed out sufficiently.
And because not all info is gathered, chances are, some type of scenario will happen in the program which has not been accounted for.
And sometimes these are caught in the Quality Assurance phase of the project.
Chances are, QA teams have gone to the wayside and the customer becomes responsible for testing.
And they are always slammed for time and do very little if any testing.
And so the program goes live and downstream, days, weeks or months later, the problem is exposed and becomes a giant problem with high exposure and several departments are brought together to assign blame and scramble for a solution.
Which means the IT person gathers the information of what should occur when something happens, that which was not discussed prior, and the IT team fixes everything.
So the bottom line is to gather specs, up front!
You must got through the monotonous pain of disucssing every possible scenario as soon as possible.
I would say this is the top reason for failed projects.
Coding is usually the easy part.
And there you have it!