Estimates

Estimating the time it will take to code something is not easy, it takes experience and also the opinion of more than 1 person. I worked on a project once and I had to code a piece of work that was estimated by someone else - at 10 days. It took about 60 days in reality. Although I was new to the technology, it was still severely underestimated.

How best to avoid such situations? Ensure that you don't just rely on 1 person's opinion. Track a persons' opinion, so over time you know that person A tends to overestimate or person B tends to underestimate. Of course if it was a group exercise (which estimating should be) then this is less relevant.

Agile does this with various methods, but the main thing is that estimates are a team effort not relying on 1 person and that estimate accuracy is tracked and the feedback from that is fed back into the estimation process. In fact this is just common sense.

Amazingly, more often than not this does not happen.

Requirements

I was on a project once where the requirements gathering phase was completely missed out. Instead, departments just wrote down raw requirements on a Sharepoint list, however ambiguous, and that was it. There was no analysis, to nail down requirements and non-functional requirements into formal user stories, priority, for sprint 0 [agile] or a formal functional specification / technical specification [waterfall], use cases etc. We was just expected to create a system from that, to a deadline (don't know how that date was arrived at) obviously incredibly difficult. A lone tester was brought on to the team late on and its just started to dawn on the team and the manager that its going to be impossible to test without use cases or documentation on how the system is supposed to work. This wasn't the only thing that wasn't right but let's just stick to the topic of requirements. Looking back now I should have raised this earlier on but even I joined at a far too late stage, and realized far too late, and I just got down to trying to do what I was told, trying to fit in with the team, on the piece of work in an incredibly difficult subject.

It's amazing but true.

Lesson 1: Fully understanding and capturing as much requirements as possible in documentation (in whatever form) is essential - and getting them 'signed off' from the business.

Lesson 2 (to self): Always believe that process is important, and trust your experience, and don't get overwhelmed by the organisation to think at the start 'oh it must be ok because this is how its done here'. If it looks like a duck and quacks like a duck - its a duck.