In the name of all that’s good in the world, please, please, please.
Our friend Stephen Few has been saying this for a while. It doesn’t seem like many of us are listening.
Pie charts are useful for one thing and one thing only: communicating that a series of numbers add up to 100%. That’s it.
Pie charts fail at everything else.
Generally we use pie charts to communicate a “part to whole” relationship. The problem is that they do a really bad job. That doesn’t seem to stop them from being ubiquitous; the fast food of the data visualisation world. They are tempting for a quick calorie hit, but ultimately lacking in nutrition.
The difficulty with pie charts starts not with the charts themselves, but with the limitations of human perception. The reality is that human beings are not very good at comparing the size of different areas. We are much better at comparing the size of different lines.
Look at these circles, imaginatively labelled “A” and “B”.
How much bigger is circle B than circle A? It’s more than 4 times bigger, but is it as much as 10 times bigger? We can tell that it’s bigger, but we do a poor job of saying by how much with any real confidence.
Now look at these two lines that we’ve called “C” and “D” (we’re nothing if not creative):
How much longer is line D than line C?
Most people find it easy to tell that line D is around 3 times as long as line C, but it is hard to say with confidence how many times larger circle B is than circle A.
How does this phenomenon play out when it comes to the humble pie chart?
Take a look at the following chart, showing visitors to this website from 4 different sources:
In this chart we can tell 3 things:
1. All parts add up to 100%
2. Organic Search accounted for the largest single share of traffic (somewhere just short of half of all visits)
3. Email marketing, Social media and Referrals were probably all about the same, but it’s hard to be sure and we certainly couldn’t tell with certainty which of those 3 is the largest, and which is the smallest.
So, in order to make this chart useful to readers, we have to give them additional guidance as to the relative size of the smaller parts, and tell them just how big the larger part is.
It’s hard to tell without labels, so we dutifully add the labels, and now the chart looks like this:
But when we stop to look at it, we realize that we have, in effect, created a circular table.
And worse than that, it’s a colour coded circular table. We have to look back and forward between the 3 smaller components in order to match the piece of pie to the label in the legend, and then, in our heads, try to rank them using the numbers. It’s not the hardest thing you’ll ever have to do in life, but you can probably think of more fun ways to pass your time. (Like doing this for example).
And that’s before we succumb to the temptation to add some “cool” 3D effects and perspective, thus making it truly impossible to make any meaningful visual comparison. Don’t even get me started on this mess:
Stephen Few suggests, and I whole-heartedly agree with him, that a more useful presentation looks like this:
I know, it’s not as “fancy” as that 3D exploding pie chart, but it actually communicates some useful information.
1. The items are placed in order for us; no effort is required to rank the components
2. The bar for each category is placed next to the label for that category, we don’t have to track back and forward to make sense of the chart
3. The chart takes advantage of the fact that humans are good at comparing lines – we can now see clearly the differences between the 3 smaller components
4. The data values are also presented in line with the bars, again making visual tracking much easier – no colour coding is required to relate the categories to the values
6. The chart still communicates that the numbers add up to 100%
So, let’s hear your arguments in defence of the pie chart; Stephen’s been saying this stuff for years, and pie charts don’t seem to be going anywhere.
We’re seeking a Marketing Operations Manager to co-ordinate all aspects of F1F9’s inbound marketing strategy.
This is an opportunity for the right candidate to bring their inbound marketing expertise into the financial services sector.
The role involves the initiation and development of content such as ebooks, toolkits, webinars, etc. from scratch to help us convert visitors into leads... and leads into customers.
The person we're looking for will have a demonstrated passion for inbound marketing, energy, enthusiasm and excellent communications skills. He or she will have the ability to work independently, and to collaborate with team members located across the globe.
Our ideal candidate will have experience managing email marketing campaigns and a comprehensive understanding of best email practices.
The Marketing Operations Manager will work closely with other UK based members of our Sales and Marketing team but will also co-ordinate with colleagues in other countries. We're more interested in experience and ideas than location.
We expect first interviews to be held in mid-July.
During May the F1F9 support team helped our 31 day course students, course alumni, online course customers and people preparing for upcoming classroom courses with a wide range of modelling queries and problems. We achieved our fastest responses so far, with 1 in 5 questions answered in less than 1 hour.
Our average response time was 12.7 hours, close to last month’s average (12.3 hours). More than half (54%) of questions were answered in under 8 hours, and we continue to attempt to answer all questions within one business day.
The satisfaction rating in May was 93% - less than the perfect score we're shooting for, but well above the industry benchmark of 87%. We didn’t have tutorials on certain topics that some of our online customers were hoping for, but we're currently developing lots of new content in the form of tutorials, e-books and blog posts and hope to keep all our customers happy with the resources that are coming up.
We are always glad to hear from fellow financial modellers, so do get in touch if you have any questions for us.
My experience of building models for many years is very much in line with what F1F9 have described in their recent ebook 10 Principles of Agile Financial Modelling.
The ‘traditional software development lifecycle’ can work for very small assignments (i.e. where the model build is no more than a few hours). The reality of most of the model builds I've been involved in is that financial modelling is really about much bigger projects, which last weeks, months, or even years.
In the book Kenny states that “the model is usually a testing environment for business hypotheses and these hypotheses evolve over time”. In my experience this is spot on. In addition I can think of a few examples where a spreadsheet solution was initially just meant to be a prototype on which a ‘proper’ software development would later be based – but the spreadsheet prototype then became the system itself.
“Long detailed specification documents don’t get read” is true in my experience too. On the few occasions in the past where this was attempted on projects I was involved in, it only got a very brief review, if at all, from the stakeholders required to sign it off. Only the results of a model itself, even if far from complete, prompted proper critical thinking about the business requirements of a model. Perhaps it should be noted that most people struggle to initially visualise a model and how to get started from a blank sheet of paper. A wordy specifications document usually does not help. But give the same people an example output sheet or template and they will be able to much better describe what they are looking for by reference to something tangible that they can already see.
However, we shouldn’t dismiss the value of written documentation relating to a financial model. It is normally considered good practice (and sometimes a requirement) to have a Record of Assumptions to accompany a financial model. Such a document is usually prepared at the end of a model build assignment and therefore may be viewed as not actually adding a great deal of value. From a model builder point of view ‘switching modes’ to write words, rather than numbers and formulae, can often be enlightening. I have experienced a number of times that the process of trying to articulate in plain English what (and why) particular formulae are doing what they are doing, has revealed that they were not quite doing exactly what was intended. But until that point everyone was confident that the formulae were accurate. It seems to me that writing words, rather than numbers and formulae, engages a different part of the brain.
From a model user point of view such documents have probably become like motor vehicle manuals – who reads up about using the radio in a new car before using it? Most people just press buttons and turn dials because certain fundamental functionality is simply expected to be there.
I have often been fortunate enough to have worked in a “split role”-type environment described. It has certainly worked very well when the circumstances permit.
Ongoing “face-to-face conversation” is essential. As much as key modelling assumptions may be written down and documented somewhere, it is dangerous to assume that a Chief Executive has read and remembered all footnotes from a document three weeks before. A 20-second conversation just before a major price negotiation meeting could have changed the finally agreed price by several £ million by reminding the CEO of a key assumption, even though that assumption was already stated on the face of the schedule he was working from.
After all, the model is only ever a means to an end; if it doesn't support better decision making, or a better negotiation outcome, then as modellers we haven't done our job.
Gavin is Head of Financial Modelling at John Laing plc.
Last week the FAST Standard Organisation announced the establishment of a International User Group for the FAST Standard.
Lots of our course Alumni and online training clients have asked how they can get involved in the future development of the Standard. At the same time the FSO has been looking for a mechanism to engage meaningfully with professional modellers who can input on the future development of the Standard. The User Group brings both of these requirements together.
According to Bert Verstaete, Co-ordinater of the User Group, the FSO is looking for individuals who:
1. Are active modelling professionals.
2. Have positive personal experience of FAST models, either in a build, user or reviewer capacity.
3. Can commit to remote participation in the group, and to making an active and positive contribution to the process.
If this is you, please apply to join the user group.
Judging by the feedback on our recent Agile Financial Modelling ebook, it seems lots of you have had similar experiences, and developed similar approaches.
One email in particular made me laugh and so I asked permission to share it:
"Dear Kenny,
I took a look at your financial modelling booklet.
Your comment relating to the ‘traditional life-cycle’ of building financial models made me smile. That is true as true can be.
It reminded me of my time at [INSERT NAME OF LARGE ACCOUNTING FIRM] and one particularly case where an Associate Director chap managed to burn a good part of the client's modelling budget (and time) in drafting a pretty comprehensive scoping document.
It was welcomed by client FD with: 'Where the @%*$ is the model or any draft of it? You can stick that damn document in your @%£$'.
That’s the spirit."
April was a busy month for our training support team, with a 45% increase in the number of questions from our online financial modelling training customers.
We were pleased that our average response time fell to 12.3 hours, down from 15.2 hours in March. More than 1 in 10 questions were responded to in under an hour, with more than half responded to in under 8 hours. Our target is to respond to all questions within one business day.
Overall we achieved a 94% satisfaction rating in April across all our online training support. This was down from March's 100% score due to some responses taking longer than clients expected due to time zone issues. Over the coming months we'll be setting up training support in other time zones which should help to address this.
Thanks to all our training clients for asking great questions - keep them coming!
Building financial models in an inherently difficult and complex task.
Although there is plenty of guidance about how to build financial models, including our own free introdutory financial modelling course, there has been lack of useful advice about how to function effectively as a team of modellers.
In financial modelling books and in-house "best practice financial modelling guides", the recommendation is generally to adopt a "lifecycle approach" to the management of model build: Specify, Design, Develop, Test, Deploy.
We found that applied to most financial modelling assignments this approach doesn't work.
Over time therefore, as a 40 person strong modelling team that has been in operation for more than 8 years, we developed our own methodology. We originally thought this was unique to us.
We recently found out that the software industry has faced similar problems. The traditional "lifecycle" or "waterfall" approach generally wasn't working for them either. In response, a new approach known as "Agile" has emerged. This is now being applied outside software developments, including manufacturing highly fuel efficient sports cars.
The principles of Agile do a very good job of describing the financial model build methodology we have developed at F1F9 and have come to rely on because, in short, it works.
We're delighted therefore to have published a short e-book setting out the 10 Principles of Agile Financial Modelling.
In this ebook, you'll learn:
-
why the traditional "lifecycle" or "waterfall" approach to project management doesn't work for financial modelling
-
how software developers have solved this problem using an approach called Agile
-
how an Agile development approach can work for financial modelling
Download the ebook using the link below and please share your experiences of what works, and what doesn't in the comments area.
Financial modelling is, or at least should be considered in terms of, a team sport - the talents of an individual modeller, no matter how fantastic, are nothing if they cannot work together within a collaborative team to achieve their goals.
Michael Jordan, legendary NBA basketball player said this about teamwork:
There are plenty of teams in every sport that have great players and win titles. Most of the time, those players aren't willing to sacrifice for the greater good of the team. The funny thing is, in the end, their unwillingness to sacrifice only makes individual goals more difficult to achieve. One thing I believe to the fullest is that if you think and achieve as a team, the individual accolades will take care of themselves. Talent wins games, but teamwork and intelligence win championships.
Take cricket players Shane Warne and Sachin Tendulkar. In their finest hour, the performances of their careers meant nothing because their team, as a whole, did not perform well.
In the past, financial modelling was a one-man show with everything depending on the "modelling guru" and it didn't seem to matter that no one else - least of all the client - could understand the model. With the evolution the FAST standard, a common language for collaborative modelling, this is no longer the case.
Model building can now be shared among the team, leading to parallel working and great efficiency.
Absence of team work can lead to problems, among them:
- Work is duplicated causing inefficiency
- Deadlines are missed
- Models are more error prone
Consider the equestrian. Although in the ring there is just one person competing for the ribbon, behind that person there is the horse, the horse’s handler, the trainer, even the saddle - there are many facets involved in making the equestrian a champion.
Similarly, in financial modelling, the collaboration of a cohesive team is essential to the completion of a successful model build.
On January 23rd Morten and I joined other members of the FAST Moderation Board from Deloitte, Mazars, and Rebel Group at FAST Standard Organisation events in Rotterdam and Brussels.
From our perspective it's interesting to see how the governance framework that has been put in place since the launch of the FAST Standard Organisation is enabling more and more companies to adopt the standard, knowing that they are not going to be "locked in" to one supplier for modelling and training services.
Together with a host of company executives, advisers, practitioners, academics and financiers from a wide variety of companies and organisations we had some great discussions about FAST.
Robert-Jan Bakker, Portfolio Manager from Pension Fund APG, discussed the benefits he's seen as a result of using FAST. He noted that as modelling is never a solitary activity and that because we work together, as teams, as partners, as companies, then standardisation has clear benefits.
Kees Horcher, co-founder of Rebel, commented that while Rebel are known for normally eschewing standards, in the case of modelling they have found that adopting FAST has allowed them to focus on driving innovation in the area of analysis. He described how the standard allows Rebel to "create modules which make it very simple to build a new model. We can build a new project finance model in a less than week, for example." He continued that "modelling speed is tremendously increased by using the standard".
This short video gives an overview of the event.