European Spreadsheet Risk Group 2010

We had another excellent Eusprig Conference last week – congrats to the organisers.

Lots of interesting discussions both within the sessions and outside, and of course in the pub.

Some highlights:

Sumwise is a new spreadsheet-alike product that allows more structured models, runs in the browser locally or remotely. It looked really good, I can see a whole class of problems that it fixes very elegantly.

EASA presented on their tech for publishing spreadsheets to web servers for browser based usage scenarios. Having built a few of these Excel-runners myself (I still have the scars) I appreciate what’s involved. I liked the way it would work with any spreadsheet and is not as picky as Excel Services (2007 anyway, 2010 is more accommodating).

ClusterSeven were talking about new value they are discovering for clients by tracking cell changes over time. They are able to build up not just validation trends, but also business, pricing, economic etc trends. I suspect converting all that unstructured tat scattered across the average spreadsheet forest into mineable information is more valuable, and a better sales story than the hunt for ‘potential’ errors, or mischief.

Dean Buckner from the FSA described their current views on data risk, and it close relation spreadsheet risk/end user apps. I always enjoy the clarity with which Dean explains what the FSA care about and how those things should be addressed. For example sometimes just a written policy is fine, for other areas the FSA want clear practical evidence.

There was some interest in trying to create a generally agreed set of best practices, with caveats as required. I’m not sure if this is something Eusprig will officially endorse/sanction, but I think its something they must if they want to maintain credibility. You can’t spend 10 years saying ‘what about the spreadsheets?’, and then offer nothing to help.

I was disappointed to miss some of the academic papers which ran on a different track. I am not a fan of the Eusprig 2 track approach. I don’t think there are enough people interested in this area to divide further, and I think the current conf length (1.5 days)  could be extended by 3 hours to allow the academic stuff, perhaps on the Friday afternoon.

So instead of hearing the evidence of how names can impair less experienced users we had a half hour slot about why a certain modelling company use names extensively. This was a little long on hyperbole and a little short on fact/evidence for me. And it unfortunately failed to address all the real world scenarios that make many experienced commercial devs wary of names in the real world.

My favourite (repeatable) quote of the event was actually just after
Ralph Baxter the CEO of clusterseven was explaining some of their new features/use cases to me as we ascended some lift in the tube system. As we got the street level some bloke turned round and said….
Drum roll please…
“Ralph thats the best elevator pitch I have ever heard”
That bloke turned out to be Mel Glass from EASA, we all then spent the next hour discussing the harsh reality of corporate spreadsheet use. (And some of the opportunities around at the moment)

One of the people pushing for some generally approved spreadsheet techniques was Morten Siersted from F1F9. Of course we will never all agree about the minutiae (note the interminable named ranges debate). But it has to be better to have reviewed a well thought out approach and decide where you will adopt and where you won’t and the supporting reasons.
FAST is one of these well thought out approaches, and its free/open source, non commercial etc etc. And unlike some of the others, Fast stands on its own. there are no chargaeble tools required to implement or test it.

Its here.

I’m not sure where the best place is to discuss it, but I do think we should discuss it. I’ll maybe do a more in depth post in the next week and we can discuss it there, or if FAST put up a discussion blog post that would be even better.

I’m not sure which is the most contentious, climate change or spreadsheet modelling/developer standards?

We’ll see I guess.

Did you go to Eusprig? what did you think?



ps I managed to use the é and the è on my Swiss keyboard today.

7 Responses to “European Spreadsheet Risk Group 2010”

  1. Mike Staunton Says:

    Generally accepted best practice for speadsheets with caveats seems, to me, still too ambitious

    The trouble is that such standards (and remember accountants and regulators are well used to standards but ones that typically are backed by law) is that they seek to be absolute – whereas I think it is better to make standards relative

    How about following all the standards if you have fewer than 1,000 hours spreadsheeting experience but allowing those with more than 10,000 hours to have some opt outs

    Surely standards should take into account the problem that the spreadsheet is trying to address – is there already a known solution that is being replicated (match the known answers – who cares about requiring standards); again, maybe the problem is given to two independent modellers to solve (again, if the answers agree – why worry)

    Again, how important (in $$$$) is the problem

    I’ve just illustrated three important factors to set the ball rolling

  2. Harlan Grove Says:

    Whether or not to have spreadsheet standards depends on whether or not one classifies spreadsheet modeling as a form of programming. If so, how to accommodate end-user (i.e., undisciplined/nonstandard) spreadsheets? If not, then what exactly is spreadsheet development? Automated calculator usage with a wee bit of database stuff tossed in?

    If I had a say, I’d approach it from the standard engineering perspective. Where are failures most common? When are failures most damaging? Are there demographic correlations between classes of developers and types or errors? [That last one: are business people with substantial subject knowledge but little formal programming training or experience, programmers familiar with other development environments but new to spreadsheet development, or old codgers resting on laurels they earned yesteryear the source of the most serious errors?]

    And again this is a big/small issue. I doubt there are many big organizations left which use spreadsheets for any sort of after-the-fact financial reporting, and anything going into a prospectus is now vetted by battalions of lawyers, so short-term planning and forecasting and individual deal pricing/costing are probably the only potentially big ticket uses left for spreadsheets. As long as these aren’t bet-the-company deals, they don’t trigger regulatory scrutiny. So I doubt large organizations would much care any longer whether there were spreadsheet best practices or not.

    BTW, any one else still have copies of PWC’s spreadsheet best practices which they had posted to the web maybe 10 years ago but had pulled by 5 years ago, probably out of fear of liability law suits (someone followed the letter of the practices but nevertheless screwed up magnificently and lost boat loads of $$$$). Actually that leads to another engineering truism: no matter how well designed or implemented, EVERYTHING fails at some point. The problem with standards is that it makes the standards setters subject to law suit when the inevitable failures occur.

  3. Mike Staunton Says:


    Can’t track down the PwC article for you – but here’s a dire example from down under (

    To build on your ideas I’d be think about a scoring system (say from 0-100) that could be used to take account for size of organisation, importance of problem, difficulty of problem, other approaches, spreadsheet style, experience of modeller

    that would also take away the false belief that such a scoring system would prevent all future disasters – all that the scoring system would be saying is that a higher score means that disaster is less likely than with a lower score

  4. Charles Williams Says:

    You can get the PwC article from here

  5. Harlan Grove Says:

    Thanks, Charles. I should get more familiar with that EUSPRIG provides.

    Simon’s article was the first I’d heard of the FAST, and I’ve been reading through it. Shame it mixes good sense with some strong biases and poorly contrived examples backing up those biases. The emphatic recommendation of the INDEX function without discussion of how to come up with the indices is problematic at best.

  6. Darren Miller Says:

    Hi Simon,

    Good to meet you at the EuSpRIG conference last month – and thanks for mentioning and complimenting Sumwise. As I mentioned at the conference, we are looking for some early adopters to help us test usability before we set Sumwise loose via the interweb. If you know anyone who fits the bill, please point them our way (

    Cheers, and good luck with the move.


  7. Bill Benson Says:

    Sounds like a *lot* of fun. My financial goal for 2011 is to become sharp enough at Excel to warrant raising my billing rate *just enough* to allow me to afford a week in London next year again, I would have liked this EuSpRIG conference in addition to Simon’s and Charles’ conference earlier the same week. Cheers to everyone, the ones I met and the ones I missed.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: