A topic that attracts much discussion in technology circles – and one of the early questions that we, as vendors, are often posed by prospective clients – is: ‘Which development methodology do you follow?’ The two most popular approaches – ‘Waterfall’ and ‘Agile’ – are well-known, mature practices.
Waterfall follows a linear approach to software development. With waterfall, the vendor will analyse, design, build and test before delivering the entire system. Some firms believe that waterfall is old fashioned, flawed and presents too much risk, in that the asset manager might not discover that the software is not fit-for-purpose until it has reached the end of the process.
On the other hand, agile is an iterative, team-based approach to development. With agile, a vendor will create ring-fenced ‘packets’ of software at a time, then pass that functionality through to deployment. Rather than producing tasks and schedules, all time is organised into phases called ‘sprints’. Deliverables are prioritised in terms of value to business as determined by the customer.
In my opinion, one area where the agile methodology often comes undone is that people can abuse what ‘agile’ really means. Developers think that their work can be more rapid because they no longer need to do any analysis or design; they can just concentrate on building solutions. In these circumstances this approach often fails because there are no clearly written requirements. Agile is therefore not always the perfect solution either; more often than not, when vendors say they are adopting the agile method they are actually cherry-picking the elements of functionality that they like and ignoring the elements that they don’t like.
I personally don’t see why any asset manager, in normal circumstances, would sign up to an agile-based client reporting project – but it obviously happens. To me, agile is like leaving your cheque book on the table. It suggests that the vendor will try a number of different approaches, and if one of them works, they will move on to the next phase of development. The arrangement is totally in the vendor’s interests. It is far more advantageous for a client to be in a situation whereby it can see upfront what is going to happen and when (and as far as possible, how it is going to happen).
Of course, agile development has its place. In situations where the client has many uncertainties within the project and a large number of deferred decision points, then agile development makes perfect sense. It may be a ten-step project where the vendor will not know what step nine will be until it reaches step seven. The vendor will therefore develop the design up to step seven and then re-evaluate.
A good example of this deferred decision-making scenario within client reporting is where there is another major IT project (such as the deployment of a new data management system) looming on the horizon. We often see that, in addition to fragmented processes, many asset managers are having to cope with multiple data venues (for example, where there is a data repository for client reports, another repository for fund factsheets and a further one for pitchbooks). It means endless checking and rechecking of data.
Data management projects typically involve multiple stakeholders and multiple end-points. In this situation with many scenarios (and with the client not knowing how many of these will impact the reporting project), taking steps one to seven and then re-evaluating steps eight, nine and ten when the vendor reaches that point is logical.
With most client reporting projects, however, the vendor knows every step from one to ten. It is very rare to get that far down the road without knowing what the end-point will be, in my experience. In the dual-project circumstance, most asset managers will maintain a clear separation between the two projects. The client reporting project can commence, utilising the various, disjointed data silos at its disposal to solve today’s problem. When the data management project finishes or reaches a point where it is accessible, the asset manager can then allow the reporting team to swing its data sources (for example, sources of market data) over to the new, streamlined configuration. In this way, asset managers can commence their client reporting project immediately; they don’t have to wait three years for their data management initiative to be complete.
If your reporting vendor is set on an agile development pathway, first make sure that they can justify this approach. It might be substantiated, or it might be the short road to anarchy.
By Abbey Shasore, CEO of Factbook
@FactbookCompany
Read more Insights