Face the Future
The other reality you have to accept is that your automation project will never be finished. The test library should have the same useful life as the application under test, and undergo as great—if not greater—rates of change, which implies enhancement, maintenance, and support.
What this means is that you have to plan for the transfer of knowledge in order to maintain continuity over the coming years. If you use contractors, pair them with employees. Never have a single point of failure. Always back your key resources up with at least one understudy. Insist on adherence to processes and demand documentation. Treat your test library as a valuable investment that is worth protecting and preserving.
What this doesn't mean is that you should not demand and get results along the way. But measure progress by automated test cases executed, not by lines of code. I recently spoke to a test manager who realized that it was taking three days to update the script library for each new version of the application, yet the number of test cases that were automated could be executed manually in only two days. By measuring lines of code it looked like work was getting done, but a look at executed cases showed that work was being wasted.
Keep Your Vision
Always remember that automation is only a means to the real end. The goal is not to write the coolest test automation framework ever, or to experiment with new tools and techniques, or to endlessly tweak and refine scripts. The goal is to increase test coverage through improved productivity, thus reducing the risk and cost of failure.
Keep that vision, and maybe you can exorcise the ghosts of scripts past.