www.greg-wright.co.uk

Here's a very brief summary of what works for me. Take it or leave it:

1. Have a methodology

No methodology implies no path to success. Methodologies are processes and processes are useful in social activities because problems become the fault of the process, and not of the people. It takes discipline and practice to keep to the process.

2. (Almost) The last thing you do is program

This is the failing of most projects. Unless your methodology is to develop software early hold your nerve and don't develop too soon.

3. Think it through first

Think the project through clearly. Many of the pitfalls you would otherwise fall into can be worked out in your head. Design now or face expensive disaster later.

4. Estimate

Break the project into steps that are as small as possible. Use these little steps for timescale and cost estimation. Never rely on a programmer's opinion of how long it will take. (If you do apply a fudge factor of at least 100%.)

5. Communicate

Make sure you communicate the design clearly to your team. Everyone must know precisely what they have to do. How do you know if you communicate clearly? Get the person you are communicating with to repeat your requirements back to you.

6. Test

Use test-driven development. Write the tests first and use Continuous-Integration to watch the development flow and estimate how far through the project you are. TDD will allow you to refactor, if you have to without introducing too many new bugs into the project. Don't write application code until the tests are ready.

7. Evaluate and Reflect

What went well, what could be improved. How close were we to spending and time estimates? How can we improve these next time?