Provide a benefit to (end) users!
This is the ultimate project goal. Do not let any short sighted manager fool you into behaving as software was only about money. Yes: „If they don’t pay you, don’t solve their problem“. But, if they pay you, give them something they benefit from and do not just formally fulfill the contract.
Fight for small, manageable projects!
Use common sense to make sure that the project is feasible given budget, time, personnel and technical constraints. Split large projects into smaller, manageable ones.
Each producing something useful and run by a separate feature team.
Adapted from Death March, The Complete Software Developer’s Guide to Surviving „Mission Impossible“ Projects, Edward Yourdon.
Be agile and have a plan!
I do not promote any puristic plan-driven (waterfall) or agile approaches. We need elements from both. We do not need hyped new methods every 5 years. We must accept that creating Software is complex and hard work (and fun!).
Life is like a waterfall – sometimes it goes up, sometimes it goes down.
Use common sense, have passion for your work and maintain a shared vision in your team. Tailor your development process model to the needs of your specific project. Plan and create intermediate artifacts (like requirement and specification documents) as needed. Be agile and embrace change – because reality will not adhere to your plans and you want to be able to show more than paper, in case you run out of time, money or management support during your project.
Create a broad, lean, stable, extensible and executable(!) architecture.
See Is Design Dead?
In many customer/supplier constellations one must first create a “complete” specification to win a contract for the project .
The following overview from the Rational Unified Process nicely depicts working in different disciplines in parallel (from project start on) and shows the transition phase into production. For 25+ years I and my teams have often successfully worked in parallel in all disciplines producing the project artifacts in parallel. If we were forced to formally follow a strict waterfall, we found a way to cheat – sometimes by producing dummy documents.
From The Rational Unified Process: An Introduction, Philippe Kruchten.
I do highly recommend reading this small booklet, regardless of the process model you are using.