Six most common failure points;

1.     Development Environment: Developer's machines are first configured by the developer, then the developer writes a solution to mimic those settings. You then install the solution in a clean environment where the developer has now access.  The developer will "fix" an issue, and you won't be able to duplicate the problem.

2.     SharePoint solutions are not safe:  The box administrator will install the solution (and feature) using a name and not a GUID.  This means there is no way to version solutions.  Now let's say a solution contained a DLL that was installed by some other solution, the last DLL will win.  IT also means that if the box admin removes the first solution, SharePoint will remove the DLL that both applications are using.  In a nut shell, even though we write code that is signed and safe - SharePoint doesn't adhere to this model when it comes to a solution.

3.     The human element:  There are numerous ways to deploy solutions.  You'll do best by simplifying the process and deploy the same way every single time.  Any documentation at all is a failure point.  Having to assign tasks to multiple individuals is a failure point.  Installation documentation should really come down to "run install" and not much else.  Operations folks are intelligent people, however their time is best suited to keeping the portal working and not understanding the nuances between installing this feature vs. another one.

4.     Rushing:  This is really the human element again.  A developer will make a very minor change (like the name of a web part) and say, "build it again.  I fixed a typo".  The PM is pushing to get into the test environment in an hour, so the tester asks, "all you changed was some text?".  The developer says "yes", so the green light is given but the install fails.  Why because the developer remembered to change the manifest to point to the new web part name, but he forgot to change it in the feature receiver, or whatever...  Could be a million things.  Simple changes can be more complicated then they look.

5.     Solution files are fragile:  A change in the code, or even to the structure of the web site can keep a solution from deploying properly. There is no developer tool showing what the solution is going to do.  The only thing developers can do is test it out. It can be very tough to know if the latest version of the solution is working or not, especially since developers rarely wipe their boxes clean in between each install.  It is really test's responsibility to verify that the solution works (In an upgrade situation, fresh install, or in the production environment as it is configured today).

6.     Multiple Web Front Ends (WFE):  Your environment hosted will contain multiple WFEs, it is not uncommon that the code or deployment process will fail when multiple WFEs are in a farm. Ensure you do at least one pass against a farm configuration with two WFEs