First, please indulge me on the issue of "avoiding duplication" in this forum. Thanks for indicating in the other section that the duplicate of this post is a cross posting. However, most of us - at least most of us who regularly answer questions - read all the forum sections. Thus, please remove the other copy of this thread as soon as possible, in the hope that it doesn't live on.
Now, to your original issue.
Actually, while your problem is real, it can likely be avoided by some advance design. Get your engineers together - if you work in a distributed environment consider the EA function of providing a forum within each model - and think through the requirements for the work they will do. If you cannot identify (most if not all) the duplicate 'things' they will likely encounter, you probably haven't yet stated your problem clearly. This is a red flag that you should not yet drill down to the next level.
[Note: I've used "class" from here on; the logic applies to other elements, and to features.]
If you must move on without understanding the requirement, consider a paradigm where your engineers 'propose' new classes, and these are subject to review. Such classes will be placed in a shared package, with a temporary name. The class should be documented in sufficient detail to identify the reason why it was needed, as well as the function it must perform; these are different, if your engineers cannot distinguish them they should consider alternative designs. This temporary documentation does not have to meet corporate standards (that comes later), it needs only clarify why the class is being proposed.
The review can be done by a dedicated resource, some kind of quality circle, or whatever. It should not be done by a steering committee (at any level); this is a different function all together.
These 'proposed' classes will be subject to replacement, so until decisions are made the 'creators' must manage their use in such a way as to allow this to be done.
In some cases the review will show that the class is unique, and the class can be renamed to a meet your corporate standards. The documentation of the class will also be upgraded at this time. The original team need only take note of the new class name, EA should do pretty much all the rest. Later in the project other teams may adopt this class; if they need to extend the design that can be accomplished through normal methods and channels.
Sometimes the review will show a duplication, or expose where one is like to occur. Now the class definitions can be merged - one proposed class could be the 'winner' or all could be replaced with a new class, as befits the situation - to produce a clearly defined, named, and documented class. The decision, as well as the identity of the new class, will then be communicated to all the proposing teams. All 'owners' of the proposed classes must make appropriate adjustments to their designs at that time.
Resource budgets should be adjusted when classes are proposed, to allow for the overhead of review, and the overhead of rework.
This last point is important! Resources are required to do this, and there is a real effect on project cost, timeline, and quality. You will likely want to include this in the presentation you are making to your management, client, or whoever (or whatever) spurred you on when you were not yet ready to move to the next level of work.
HTH, David
