Disclaimer

BEFORE YOU START: Please note that although I currently volunteer for both the Stroke Association and Age UK, the views expressed in this blog are strictly my own. I am not a spokesperson for either (or, indeed, for any) organisation. I am based in the UK and the blog therefore has a UK bias - I've tried to use the Glossary to explain any terms which might be ambiguous, but if you think there is anything I've missed, please message me.

Sunday, 2 June 2019

Costing Projects

Oftentimes in my career, I've been asked to produce project plans. I have a few simple rules I worked by, but they were not rocket science and I usually just ground them out.

By grinding them out, it was basically sitting down and working out, as best I could, all the different little tasks which went into the whole project, and, as best I could guess, the duration of each task. From there, just basically adding up the numbers together. The end goal was to be able to say how many man-years of effort would be required. I let other people juggle with the number of people involved, and, frankly, a lot of the time it really was no more than juggling!

A lot of tasks were repeated across the board. For example, every task finished with a unit test, so "unit test" was always a sub-task. A unit test is simply testing the part in isolation. But again, unless you realised this and took account of it, you wouldn't allocate enough time for it.

I had a basic rule that a task would take a minimum of half a day. Sometimes a task might be a single change to a single line of code, so a half-day was overkill. But over the course of the project, it averaged itself out. Conversely, if I costed a task at more than a fortnight, I knew I needed to break that task down into smaller parts to get a better idea. Overall, there were normally the same feelings on each project - when you first worked out the numbers, you, and other people, would say "crikey, will it really take that long???" because the number you calculated would always exceed your gut feel. But at the end of a project, I was generally happy with my initial estimates, although requirements invariably changed during the course of the project, par for the course.  After all, because the duration of an entire project was just the sum of these small tasks, for each task if would have been very difficult to miscalculate by all that much. So, unless you hadn't thought of all the tasks... Project Managers would often be not happy at the end result, but that was their problem - ultimately tweaking the numbers at this point would just have been wishful thinking - they'd have the math right there in front of them, so it'd take a degree of bravery (foolhardiness) to ignore it in favour of their gut. But some of them did, and they invariably got burned. If my advice had been wrong I'd have been concerned, but if they'd chosen to ignore my advice and subsequently got it wrong, that was their problem.

In my last few years, I met another guy who claimed he could estimate the cost of projects without grinding things out as I did. Quite funny, really, I'd regularly meet people in my career who could do things more efficiently than I could. For some reason, I survived despite being so inefficient. This guy just used his gut feeling. The difference, as always, is the working out - the documentation. My detail would be used as the basis of the plan that would span the entire project, the final number that I produced was just the headline. I was fortunate, I suppose, because I encountered this behaviour early on in my career and developed coping strategies - the guy, often parachuted in, who tells you. ever so nicely, that what you've been doing is crap, so you just had to cover your backside.

No comments:

Post a Comment