How do you define when a development project is actually “done”?
This post is ridiculously in the favor of a client, but I think more developers need to think in favor of their clients and stop thinking arguing features on a technical level. If all developers had a little more business sense, I strongly believe that both the developer and client would walk away happier each time.
Task Level Completion
Whether your a freelancer on a project or a part of a team, you should be using some sort of project management system to hold yourself accountable and to measure your time, success, and failures on various projects. The more granular you can make the information on this level, the better data your collecting to be able to defend your invoices, measure your abilities, and help predict future projects.
Start with Unit Tests
One of the biggest complaints by clients is when you’ve walked away from the project and something breaks. Try to be proactive rather than reactive by building with Test Driven Development patterns:
- Do assertions and make sure that all functions are receiving, processing and returning as expected.
- Write scenario tests which have to pass and consistently pass to be deemed stable.
- Test at different levels: from a task to a full user scenario.
Success Criteria for Tasks
If you’ve outlined your task deeply enough, the success criteria should simply be meeting the description of the task and any subtasks both in functionality, aesthetics, and code cleanup. Ultimately the client only cares about whether or not it works and how it looks, but you should care about the quality of the code and the ease of another developer to come in and adopt.
Milestone or Story Completion
I’ve never liked the word “story” in project management, but I want to differentiate it from a commonly used “scenario” in the TDD world. When it comes to user stories, these are the tasks that string together to create a story or milestone. Success criteria for this level should first required that you’ve met the success criteria at a task level and then additional scenario testing that is both automated and manual to assert that the functionality looks and behaves as the client described. Upon your internal approval, you should also review this level of completion with the client to catch any issues or refinements. I often make this process a part of my contracts so that the client is signing off on specific phases rather than the project as a whole.
Project Launch or Phase Release Completion
Before you ever launch a project into a live environment you should go through every story and test again. You should then make backups of your work both in dev and production environments and store in an external location. Then, schedule a time with the client that will cause little disruption to their business and will also allow you ample (and stress free) time to push into production. Upon successful launch, you should load test, make sure your unit tests and scenarios still pass, and setup some kind of automated reports so that you are alerted before anyone of failures. Finally, wrap it up and communicate with your client. The exit phase should be as long as the intro phase, and you shouldn’t be in a rush to dismiss or wrap up the project. If you need to collect an invoice first, do so, but stick around and be available for a short time to help maintain and tweak your application.