"You don't learn to walk by following rules. You learn by doing, and by falling over."
—Richard Branson
Many large technology projects in the asset management industry are, at best, a limited success. If a project outsider was to compare what was achieved against the objectives set, the two measures are often at polar opposites. What invariably happens is the project scope, deliverables or team structure alter to varying degrees. Budget gets blown out of the water and far less is accomplished than expected. Some people may lose their jobs as a result of the project meandering, other staff are moved to one side and new team members are brought in.
Technology projects often start with great expectations. In time, those expectations change (usually in a downward spiral) until at the conclusion the imperative is just to get the project over the line. Once it’s over the line, the internal PR machine kicks in and tells the firm what a great success it has been.
As aforementioned, one of the key problems is that the team is very rarely composed of the same members at the project’s conclusion as at the outset. By the end, almost all of the early knowledge accrued has dissipated. To make matters worse, the team that finishes the project has such a vested interest in promoting its 'success' that they will always review it in the most glowing terms, then move onto the next project with the same attitude that emerged from the previous one.
All too often, projects commence with a lack of focus on the operational issues involved. Project charters can be full of ill-defined 'future speak' and very little clarity. Equally, if there is no detailed target operating model to strive for, it is not uncommon for many existing processes (often built and designed around legacy systems and resources) to be simply rebuilt with the new technology, as opposed to fully utilising new functions and reviewing operational processes to ensure that they are fit for current and future needs. Unless these issues are acknowledged, it is highly likely that the next programme will make similar errors.
The other reality that is rarely acknowledged is that with the scale and impact of these projects, it is nigh on impossible to avoid making mistakes. In almost every case there will also be changes in scope and requirements as the project progresses. Once this is accepted, it is critical to create a culture where errors can be discussed at an early stage and not hidden. Lessons can be learned, the project re-calibrated and the end delivery ultimately improved as a consequence.
The problem is that large, global asset management firms are always highly political environments. People are reluctant to take responsibility for miscalculations; in fact, they are far more likely to play the 'blame game'. The truth is that project failure (and equally its success) is rarely down to a limited number of individuals; it is more often than not the effect of the corporate culture. Technology projects are a team game and all involved must accept some collective responsibility for the positives and negatives that emerge.
Large transformational programmes need regular, open and honest reviews, with no fear of reprisals. Programmes also need to have a postmortem and lessons learned should be actively sought and implemented.
Whilst I understand the need to promote a positive outlook toward the new technological environment once it is implemented, and to ensure any lingering negativity is removed, this should be balanced and honest. How often do firms consult the end-users of the systems implemented and actually ask them about the new user experience before, during and after the project? If the consumers (both internal and external) are not experiencing any material difference, then one has to question whether the project was a success.
Unless you undertake an honest review of a project and make meaningful changes as a result of that evaluation, then the same blunders will be made all over again. To quote the Irish playwright George Bernard Shaw: “Success does not consist in never making mistakes but in never making the same one a second time.”
Comments