5 tips for more strategic budgeting

With the end of the financial year looming as the next major fiscal date in many UK company's diaries, IT people everywhere will soon be embarking on the wishlist-to-business plan journey that is the budgeting process.

There is already a lot of good advice out there on how to estimate numbers and prioritise what makes the cut, and that can be a brutal process, so here's a few things I keep in mind to make sure I'm not being too short sighted:

1 - Know the cost of a customer. The rest of this list isn't in any particular order, but this is definitely number 1. Most good CIOs and CTOs I meet know what this disk array costs vs. that disk array and what these licenses cost vs. those licenses, but not that many know what a customer costs to acquire and convert or to reactivate if they drift away. The relevance? Knowing that means you can work out exactly how many frustrated customers you can lose because of that bug before its worth fixing, or that slow server before its worth upgrading. In this light, things that might otherwise not have made the cut become the no-brainers that they should be.

2 - Don't be influenced by trendy buzzwords. There is always a meme that vendors will be able to exploit because of our inability to apply common sense and logic to a pitch on whatever the currently fashionable thing is. SOA, virtualisation, and cloud computing come to mind whenever I recall ill thought through spending sprees. That's not the same as saying that these - or any of the other candidates in the same category - aren't good technologies with valid applications, just that any investment in them should be handled with the same pessimism and judgement of real business value as money spent anywhere else. Just adding 'cloud' onto the name of a product doesn't change it's fundamental ROI, so don't let these slip by you unchecked.

3 - Know the cost of scale. When sizing up a new project, give growth plans some weighting rather than just initial costs. Depending on the degree of speculation involved in your plan, taking cheaper entry options can sometimes bite you when you reach scalability limits.

4 - Wider consultation. A year is a long time and a budgeting exercise inevitably involves dusting off your crystal ball and trying to foresee everything that everyone is going to want in the coming 12 months. Good luck with that and, although it seems a little obvious, spending a bit more time with each area of the business trying to coax their plans and ideas out of them will at least expose the bigger ones up front.

5 - Increase priority on core things. Another one that sounds obvious but - through its limited practice - clearly isn't. In tougher economic times it is particularly important to give the most crucial things the most attention, and it can be mistake to favor too many might-lead-somewhere-might-not initiatives over those core basics upon which the business depends today. I think it is critical to set aside time and money for innovation and to take a punt on those less-certain ventures that our instincts tell us have that commercial je ne sais quoi but it needs to be proportionate to the main line. This is important when deciding what to drop in order to bring your wishlist and the available cash resources closer together - big but critical projects can be easy targets because they pull back more cost in a single swipe than a number of smaller but less meaningful items will.

The hidden wisdom of Kevin McCloud

I was lucky enough to get a copy of the Grand Designs Handbook for Christmas - it's a compendium of building projects from the channel 4 show (the book, not Christmas). The first few chapters have a lot of lessons learned and good practices picked up from 9 seasons worth of experience with, well, variously successful building projects.

Reading some of the advice, there is a lot that can be applied directly to software projects. There is a section on 'how to behave with your team' which is aimed at helping people keep their building sites productive - but the advice translates well to technical projects. Here's a couple of my favorites along with my join-the-dots:

"Don't give verbal instructions on site unless they've been agreed with your consultants and they're backed up in writing. If you just issue verbal instructions, you risk confusion and possible extra costs."

This is a top one for me - especially in the agile world where many interpret 'agile' as 'make it up as you go along' and then end up disappointed. I think maximizing interaction between delivery team and customer team is a good thing especially when both sides recognise the boundary between clarification and change in in-flight work.

"Do take time to prepare detailed written briefs setting out all your requirements for all your consultants. A good brief is an essential part of the design process."

One of the simplest formulas the govern all project delivery (hardhat or mousepad) is that the quality of what you get out with never exceed the quality of what you put in - yet this seems to escape so many of us so often. What you invest in clear instruction and regular contact with developers is a key variable in how happy you'll be with the results.

"Do allow your experts the freedom to do their jobs. Stand back from the project and enjoy your role as client; making decisions and hanging around, generally being a good egg and imbuing the world with optimism and excitement."

I don't exactly advocate stakeholders 'standing back' from a project, and I don't think that's what Kevin means either. Don't micromanage your delivery team and, as a customer, be sure to perceive the difference between decisions you should make (and don't let the team wait for those) and decisions the team should make (and let them use their skills and experience to make them).

"Don't listen to other people outside the professional team. You'll only end up getting very confused."

External feedback and extra ideas are good, but remember that an engineer knows his business best and don't fall into the trap of listening to someone else simply because you like their answers better. I consider myself relatively smart but even I'll say all sorts of wacky things when I don't have any skin in the game...

There are a couple of other sections with close analogies to technical projects - how to be a perfect customer and how to put a good brief together - which I think are 2 other critical ingredients to any successful engineering project (construction or software) but they'll keep for another post.