Here's a popular motto: "Under Promise and Over Deliver!"
It's said with a level of enthusiasm that encourages lower expectations yet yields higher output. Yet I consider this a terrible motto in the world of software architecture. The client world will immediately see this as the norm rather than an once off event.
The following are my experiences on how to avoid these pitfalls.
Pitfall #1: Not getting Paid for Over Delivering
Let's start off with an example:
The remedy to this was that during step 4, you made the decision to implement an improvement, without the approval of the client. Now you are in the position that you cannot remove the additional improvements, or risk losing the loyalty with the client.
Pitfall #2: Deliver Early
Timelines are discusses and negotiated between you and the client. The final output is a schedule of delivery. You could flex your Agile muscles here and break this down into an iterative schedule. Bottom-line here is that time based expectations are set.
Then you delivery the requirements early. They are again elated with your progress. You are on cloud-nine! The next parts of the project are discussed. Seeing how fast you performed, they want to move up the timeline or adjust the number of items in your next delivery. What simply happened here is that they started thinking that you buffered the timeline, and they now want that buffer removed.
The quick way to avoid this might be to deliver items only on their scheduled release date. However, in the corporate mindset, this puts you at a slight disadvantage. You are not providing a differentiation by delivering on time. To stand out, if you finish early, let your clients know that, but state the fact clearly that this early deliver is not the benchmark for your other items. By clearly indicating that this was the exception, rather than the rule, you successfully set the tone that you did a good job without having them dictate your future releases.
Pitfall #3: Over Documentation
Documentation is the dread that all software developers fear. To date, every team I've worked with would prefer to build out complex features over writing documentation. Documentation is rarely something that comes naturally to any programmer.
What happens when you give the company large volumes of detailed documentation. Filing cabinets start serving their purpose. Documentation that goes beyond a simple user guide is often stored away for future reference for future developers. It is not meant for the general end user. If the company requires the detailed documentation, then ensure that it is part of the original project scope.
Pitfall #4: Re-factor Code
Unless you are brought in for the purpose of refactoring an existing codebase, don't do it. There is a tendency to constantly improve the code. This behind the scenes clean up may contribute to a faster application and potentially reduce the effort of future enhancements.
Unless you can bill properly for improving the codebase leading to faster performance, there doesn't seem to be a financial gain in doing it. The company who hired you to build the application, will not pay you more to fix it up. This should not be taken as an encouragement to write poor code, but rather an insight into how the corporate mentality does not place rewards on "non-tangible" improvements.
The Take Away
As always, set quantifiable expectations. Adding improvements without first discussing and adjusting necessary timelines result in difficulty in billing later on. Delivery early once, and you'll be delivering early alway, unless you communicate to the company that this is an exception. Write too much documentation that goes beyond the needs of a regular user, and it will live out it's life inside a filing cabinet. Finally, don't micro-optimize and refactor code if the incentive isn't set in advance.