In my six months at Push, I had not been burned on a project until now — well this is more of left feeling slightly charred than completely incinerated. I was also awarded a couple days off to recover from missed weekends and fried nerves.

It all started from a rushed quote, and snowballed from there. I was forced to to turn around a quote in an afternoon. Without any time for a thorough analysis, I could only do a light breakdown on the various pieces and come up with ball park quote based on number of days. Unfortunately, management had half my number in mind.

When an ambitious developer quotes time, they usually under estimate by a couple days and a good Project Manager should buffer that time, not cut it in half.

And, if they do, the scope must also be reduced or…well… one must suffer the consequences of dealing with an very angry development mob working all hours and weekends working furiously to get it done — free dinners are a nice perk but only go so far.

Again, to any developer looking to work at Push, crunch time is common in our industry and this experience was certainly not that bad since it hadn’t happened to me in awhile so perhaps I was due to keep my stripes. Our dev team is usually very pro-active when in terms of process, planning, and balancing work/life — just not this time.

At our weekly software and soup sessions at Pho Pasteur, I complained about our rushed quote to fellow colleague and coder Tim Spurway [ architect of the Firewater Framework ] who explained the concept of “risk spike” analysis to me.

A risk spike can be mapped to the difficulty level of adding new features especially on the impact of working with legacy code, so that in order to properly measure that risk, you need to work with the code and run tests before you can even begin to quote time.

In my case, I was working with a code base and framework developed by another agency. Tim suggested that before I should have given my quote, I should have worked with the code for at least a couple days if not a week. I could only salt my soup with my tears.

Anyways, the project is finished now and my original quote is my smoking gun. I ended up working that amount of time compressed into overtime and weekends. I have used it to invite management into a formal discussion about producing a document — a stronger contract — that could better protect both groups and make the client happy; the end goal being to always under promise, and over-deliver

This meeting is happening next week, and I’ll try to post an update. I’ll leave you with of my favourite bullets points pulled from this extreme programming wish list.

P4. Make frequent small releases. Having a running system with reduced, but incrementally growing functionality, is a base for quick feedback from client side. Such an approach minimizes costs of radical changes in the project because new needs and requirements might be taken into account in the nearest increments.

P6. The project is divided into iterations.

D3. Create spike solutions to reduce risk. A spike solution is a small, informal experiment with your idea how to solve a problem.

C8. No overtime.

This is also a good blog post on evualuting risk