Back to the Estimate

The life of a technical architect is one filled with magic and wonder. We often wonder how to perform expected feats of magic. Forgiving such poor word play, there is one duty we are faced with in our day to day that demands such a skill. This is The Estimate. Being asked to estimate for a project can be like magically predicting the future. Often with a lack of information, people to consult and pressure from the business to come up with the magic number that turns a profit and doesn't send the client packing, it is easy to get it very wrong. Like Marty McFly in Back To the Future II, how do you avoid a dystopian future where you've been fired, your music career is wasted and your wife’s turned out to be a bit of a bloater? Since you probably don't have a flux capacitor, your next best option is to abide by Tech Rash’s top tips for project estimation.

A Rough Guide: Software Specification

Software Development can be like going on a holiday to somewhere new. You always run the risk of getting very little sun, potentially ending up in a grotty hotel or getting messed up by muggers and left groaning and penniless in a filthy, urine saturated alleyway. So how do we avoid this scenario and make this holiday the one where we meet up with our new found holiday friends, knock back a few nostalgic caipirinhas and congratulate each other on what a brilliant time we all had?

The Yellow Brick Build: A project methodology

Thunder! Thunder! Thund! Thu.n.de.? 

In the world of project management methodologies there is a limited set of models we as a delivery team are asked to subscribe to. And once we do, often is the case where the project becomes a never ending battle between the theory and the reality. The best proposition for describing projects came from my old boss.

To quote:

"F*ck 'agile' and 'waterfall' - the new labels for project management are as follows: 'car crash' (small projects), 'train wreck' (medium sized projects), and 'airplane disaster' (large-scale projects)"