Agile Practices for IFAs
You may have heard words like "agile" and "lean" used from time to time in the realms of manufacturing or software engineering, but these terms are seldom heard in the financial advice industry. Granted, the world of financial planning is different from that of engineering, but there are nevertheless some agile principles and methodologies that financial services firms can take advantage of.
To begin with, it may help to understand a little bit about what "agile" means and how it came into being.
What are Agile Methodologies?
Back in the early days of corporate computing, it was only the biggest companies that had the budget to invest in information technology and there were very few professional programmers around. Software had been developed in academia but nobody outside of that realm really knew how to engineer software to fulfil the needs of a customer. Likewise, nobody in the corporate world really understood what computers could and could not feasibly do to help their business or make their staff more productive.
As a result, corporate bosses in charge of investing in IT felt the need to be very prescriptive. The functional specification of the planned software had to be detailed, designed up-front and signed off by the board at the outset. This would then flow down to the programmers who would build the software exactly to the specification, test its conformance to those requirements and return it to the customer.
This was all fine in theory and, indeed, also in practice, but only if the up-front functional specification was exactly right and completely comprehensive. However, for the vast majority of non-trivial IT projects, this was not the case.
It soon became apparent that corporate bosses didn't know everything in advance and were rarely able to foresee the complexities of the tasks at hand. They were often unaware of the working practices adopted by those at the proverbial coal face and often prescribed software that was a hindrance rather than a help to the staff. There was also no process for handling changes in requirements once the specification had been submitted, and any modifications were expensive and error-prone to change, often resulting in increased costs and long delays.
Around the turn of the century, software engineers decided they'd had enough of repeating the failures of the past decades and chose to come up with a new way of working. A commitment to better working practices and a set of principles that were geared around producing quality software for the customer and forsaking everything that got in the way of doing that: the Agile Manifesto was born.
This paved the way for several new software engineering methodologies that aimed to deliver this manifesto, accepting the truth that requirements may change and embracing regular feedback from the customer. This agility gave clients a competitive advantage over those who were still working with detailed functional specifications up-front, and as people began to realise the benefits the popularity of agile software engineering grew.
Today, it is nigh-on impossible to find a job in software development that does not subscribe to agile engineering practices.
What Does This Have to Do with Financial Services?
As much as the Agile Manifesto and its set of guiding principles are geared around IT projects, many of the ideas that underpin them are applicable to any working environment that involves people and processes.
At PowerPlanner, we apply many of them ourselves when designing our processes. Here's a handful of examples where any financial planning practice can benefit from embracing agility.
1. Minimising Waste
One of the principles behind the Agile Manifesto is to maximise the amount of work not done. In other words, keep things simple and only do the work that needs doing.
This requires an understanding of the work involved in the end-to-end financial advice process. It can be helpful to map out this process visually (e.g., using cards on a board or a flow chart) and then identify where potential efficiency gains can be made.
Very often, the quick wins are around limiting data redundancy and avoiding re-keying information. Do you really need to scan everything you receive from a provider or can you limit it to the documents that add value? Is it possible to reduce the number of databases, systems or spreadsheets that you need to enter data into? Can the data be shared between them? If you can answer affirmatively to any of these questions then you'll start to reduce waste in the process.
It's also useful to consider when you do things rather than just what is being done. A key concept in software engineering is the notion of fast failure. In other words, it's better to catch errors as soon as possible rather than waiting until runtime and reacting to a system crash. This helps improve the efficiency of the process and also has the obvious benefit of avoiding disappointed customers!
Applied to financial services, this could mean looking through information as it's received to verify that everything is there. If the administrator notices something's missing, the case immediately gets put on hold and you go back to the provider.
It sounds simple, but this rarely happens in practice, and often it's only when the case is on the paraplanner's desk a few months later that it's noticed key information is missing. Going back to the provider at this late stage leads to indefinite delays, which can cause panic if the client meeting is booked and the adviser needs the report quickly. Adopting a fail-fast approach means the paraplanner can have confidence that all required information is on file and the adviser can confidently manage clients' expectations.
2. Paying off Technical Debt
Software teams sometimes have to take shortcuts to meet deadlines which later need more robust solutions implementing. The result is called technical debt. If not "repaid" - that is, if the robust solutions are not implemented later and the shortcuts are left in place - it can result in a code base that is hard to fix and maintain.
In financial services, the equivalent might be rushing a client through without a proper fact find or risk profiling questionnaire. If you're lucky and the assumptions made in doing this are right, then you may find the advice is suitable, but if not then you might have to redo quotes, projections, suitability reports etc. and the cost mounts up. Worse, if this work just gets forgotten about and there's a file review, the regulator will not be impressed!
Shortcuts do have to be taken sometimes, hopefully very rarely, and if they are taken it's a good idea to "pay off" the resultant "debt" as soon as possible.
3. Convention over Configuration
Favouring convention over configuration leads to a clearer and more widely-understood process. In financial services, the term "configuration" is arguably less appropriate than it is in software engineering but the point is still valid.
Essentially, the idea is to establish a consistent and well-understood approach that all staff members can follow, but one that is flexible enough to allow adjustments to be made in special cases.
An example would be around the interpretation of information. At PowerPlanner, we treat the details submitted through our secure paraplanning portal as sovereign. If there's a contradiction, these details are taken as correct and supersede anything else. If the details are missing from the portal, we look at the fact find first, then meeting notes, then, if that information is still missing, we'll use a sensible default or go back to seek clarification.
This convention means everyone knows where information is taken from and how to resolve conflicts, so it's much faster to write reports and review them. Of course, in certain circumstances, this can be overridden and data can be taken from a different source, as long as it's clear to everyone that a different source is being used.
4. Have a Definition of "Done"
Describing work as "done" is a common assertion but does everyone in the team know what this really means? Defining "done" empowers team members to own a task and do it to a good standard. Others picking up subsequent tasks can have confidence in the quality of the work and the whole team performs better and functions more efficiently as a whole.
This can be applied to multiple aspects of the financial advice process. Take data gathering, for example. To one administrator, just posting off the LOA may be their interpretation of having "done" this task, but another may view this as posting the LOA along with an information request letter, as well as following up with an email and subsequent phone calls to manage the process until all the required details have been received.
Both administrators would say they have done the data gathering, but their actions are clearly very different. By defining what "done" looks like, there is a consistent and high-quality approach to data gathering across the whole administration team.
5. Retrospective Reflections
A key principle of agile teams is that they are given the opportunity to challenge the way they're working to seek improvement. Team members should feel empowered to try new things, bring new ideas to the group and offer constructive criticism of things that are not working.
The major challenge with this is personalities. It's crucial that each team member understands and respects each other's capacity for dealing with criticism, confidence in expressing views and sensitivities. Similarly, pride can get in the way of progress if you're not careful, so team members shouldn't take things personally and have to keep in mind the key objective of improving as a team.
Summary
These are just a few examples of how agile methodologies can be applied to financial services, and the principles laid out in the Agile Manifesto can inspire positive change in other ways as well. It's worth reading the whole set of principles and thinking about how they can be applied to your financial planning process.