Would you ever build one on purpose?
Now I really love spreadsheets, they are so flexible and powerful. But would I ever design one or more into the core of a multi-million pound business?
I don’t think I would.
But a lot of companies have mission critical spreadsheets (it takes a while to admit to them …) – often these spreadsheets start as a good idea and become key to the business in a very short time. They must have something to offer then?
They can’t really be beat in terms of viewing and analysing data (I know I have tried!).
But as a source of data and data transformation well they are very good but anything can happen; from an incorrect cell lookup (oops it’s the purchase price and not the sale price I just quoted …) to some duff maths (how do you calculate net margin then?). And I’m assuming regular backups are taken, they are locked in a safe overnight and have secure logins … ?
So not so good at the security and robustness tests then maybe?
How about we compromise then – hold the data itself in a nice tough, secure, fast and flexible SQL Server database and allow the users to access this though an Excel spreadsheet?
Saves a lot of development work on analysis and reporting tools, you can sleep well too …
I got asked this a while back – it was difficult to answer without making a direct comparison.
I thought a bit then came up with this:
- Fully engaged with the business, part of the business
- Respected by the business
- Delivers apps and systems as needed and of the right calibre
- Positive attitude
- Cost conscious and business case focussed
There are loads of benchmarks out there for more tangible metrics, look at the BCS for some examples, but these don’t give you a flavour of the team and often don’t really work for smaller teams anyway. Rather like average goals per match or number of aces hit per game, useful stuff but it doesn’t paint the full picture.
Taking a business focus in the development team can pay big dividends.
Why get the dev teams involved too early?
Well I say you ought to for two reasons:
- They will be prepared if the project does run
- They can often make significant contributions to the project
Leaving it too late is what I call “chucking it over the fence” often onto an already over-loaded team. Not good.
The dev teams on their part also have to ensure they stay positive (or they won’t get invited again!) and understand things from the business perspective. Things such as “fluid”, “unknowns” and “can do”.
So … you’re in the same game but the team is not working well?
A well performing team can deliver up to 10 times than the same poorly performing, demotivated team (yes really, I’ve seen this first hand) .
Turn that into cost – and you can do that easily – then you’ll get why we spend a lot of time on this subject.
It’s easy to demotivate hard working performers – try telling Federer (for example) that his forehand isn’t fast enough … you get the idea (if you stay around long enough)!
It’s also easy to motivate hard working performers too … spot the difference …