I used to sit next to the CS(Customer Service) team for sometime and I heard them instructing certain steps to customers to redeem campaign codes the second time. The dev team had put some extended efforts to exactly prevent this sort of scenario, these campaign codes were not to be redeemed twice. Why this sort of disconnect?
In small organisations without any sort of processes, most of the requirements usually come on the fly, they are briefly discussed through mails, the dev team gets into action, once they are done and testing is through, it gets pushed to production. Then starts the barrage of mails asking, How do we prevent fraud? I need these reports for the board, how do I get them? CS does not even know this feature is live, how did that happen? I need an admin panel to do so and so, why is it not there already? How well is this feature performing, how do I check that? Are we measuring so and so? etc etc.
I am not saying this is always the case, but most of the time this is how it plays out. Why does this happen? Usually there is some sort of disconnect between the various teams as everyone is busy doing their own shit due to lack of time/resources and abundance of problems to solve. Also, there is this constant pressure to throw things out as soon as possible in the name of existential threat/out pacing competition that details not in your face tend to be over looked. For example, a dev may not really think about an admin panel as during development he/she can play around with the database or some config file and get around the problem that an admin panel solves for a non technical person.
How do we fix this? The simplest and the least resistance way to fix this is a project management tool. I have expounded on this before, but let us look at it again in light of this problem. Avoid discussing features over email and do this through a project management tool so that everyone involved has a 360 degree view of the problem. Also, have a template for each task with sub tasks, for example each task can have the following sub tasks(not an exhaustive list and in no particular order):
1. Admin panel.
2. CS briefing.
3. Executive reports.
4. Code review.
5. Testing scenarios.
6. Analytic requirements.
I am sure you can add to this list based on your domain but the bottom line is have a template with the obvious listed out. How this helps is, when we have things on our face, we tend to actively think about them. Also, the unintended side effect of this is self documentation for coming generations and preventing blame game later on :). How many times have we heard this typical conversation, one guy says “I had told you this, why was this not done?” The other retorts, “We never discussed this, what crap are you talking man”(Exaggerated for dramatic effect).
Other ways of solving this problem is what big organisations do, having a strict spec review and sign off process, holding regular meetings where all the stake holders are present. I prefer a much more informal process of self documentation and processes which give you the feel of lack of it, your mileage may vary.