I found this inspiring and “so-true” post by fprog of slashdot. The reason I loved it is that it’s so painfuly true, and exactly the kind of list I would prepare for myself or for anyone else before a new project / customer. Read, Learn and pass on!

Top 12 – Rules of thumb for project management

1. Triple the estimated time + 10%.
2. Add 2 weeks to that amount for a complete code review.
3. Any changes by the customer means “adding 2 weeks to the schedule”, even if it’s one line of code… why? because, it must pass documentation, Q.A., validation and be reviewed by the entire department, without accounting for “double bug”, bug induced by another bug and stuff like that or bugs that are in the core library and means retesting “everything”, “every module”, etc.
4. Any changes must be approved, reviewed and means adding delay (normally a big NO-NO) and therefore, 99% of the case thoses changes are left for future phases or abandonned by the client when they realise the implication. If not, it’s your objective to discourage them or force them to reconsider by any means. =P
5. Don’t give any feedback to the customer unless you must! If you do, downgrade any progress to minimum to reduce expectation and refrain the customer from adding new stuff to the TODO list.
6. Which means, each phase must be clear, consise, humble, realistic, feasible, with lots of buffer time for fixes, reviews and testing. Exagerating how complicated it is to a customer is always a good idea, because in the end, everything that seems easy is actually very difficult.
7. Do minimum documentation, UML to get started… They’ll get rewritten at least 30 times, before everyone in the group agrees after what 40 meetings?
8. Once the phase somehow works and the thing is somehow settle, start documenting it, so you don’t forget. It’s actually a very good way to detect logical mistakes, misbehaviors, bad coupling, bad cohesion, missing corner cases, bad design choices, usability problems, etc.
9. Best teamwork is small team of 3-5 senior people working toghether hand-in-hand, sometime helped by 1-2 junior, which can do much better than 120 junior who are completely clueless and never deliver on time…
10. For big projects split things up in component and/or phases that a small team of 3-5 people can do, keeping in mind of the big picture so its scales up, but ignoring any meaningless future details that don’t matter “right now”.
11. Rush the people to do it in “the simple 1/2 time delay”, keeping in pocket the “double time” remaining for any arising issue and reworking the core libraries, overhaulin the code, reviews, fixing bugs, etc. This means that if you are really late, you are actually late on your “buffer time”. If things goes well, then the project will be done before it’s expected, which will impress any client.
12. Finally, but not the least, there’s no such thing as a bug, it’s just a “small improvement”, a “new feature”, “code overhaulin”, “mispelled requirement” or a “security enhancement”. It keeps customer smiling, it’s less depressing for everyone and overall keeps the mood up on everyone face with a laugh or two!

And one more good one by chaboud:

I think that the most important thing to do when a project is on an insane schedule is realize that you aren’t super-human and pace yourself. If you don’t, and crunch hard nights or extra-long 50-hour sessions, you’ll spend the next few days with a fried brain and a complete inability to make use of your time.

If you’re normally a 9-5 guy, pull 10 hour days. If you’re normally longer, possibly consider working longer, but notice when you’ve started lagging because of fatigue.

Other things:

• Take walks. Get out, get blood flowing, and rest your eyes. Don’t stop to talk to people on your walks, because you’ll smoke hours talking about nothing (like postings on slashdot).
• If you’re angry, or burned out, take a day. You can spend entire weeks in a funk if you can’t get yourself out of it. It doesn’t help you, and it doesn’t help your team. If your boss can’t make sense of needing to pull away so you can be more effective, try and find another job.
• Be reasonable about moving targets. There’s no benefit to throwing a fit when your boss changes dates/requirements on you, but let him/her know what it’s going to cost in time or other features. Be quick about this. Don’t stew about it and let the feature-spec gel before you’re quick to pull the “we have to cut…” card.
• Big design up front: Don’t do something three times because you weren’t sure how you were going to do it in the first place.
• Less design up front: Don’t overdesign something because you’re so hung up on not doing it twice. You might have to code it twice, or three times. Get dirty in the code long before you’ve started sweating details that don’t matter. If you’re solid, this stuff will just flow out naturally.
• Learn to use copy and paste, along with other tricks to save yourself grunt-work time. It amazes me to no end how much time I see some programmers spend on writing code. On the same note, learn to type quickly. I’ve known some great programmers who were hunt-and-peck two-finger typists, and those are the same ones who generally pulled super all-nighters typing at 20 wpm.