If you search the internet for ESG (Environment, Social, and Governance) and responsible and sustainable investing, you’ll find there is a vast amount of information about it. And with so much information it can be quite difficult to distil. When it comes to putting a project together around a broad-ranging and fast-moving subject such as this, it can be tricky.

From a project management perspective, let’s look at some of the challenges you may encounter at the early stages of the project:

  • New and enhanced regulation is constantly emerging – in addition to the existing ESG regulation that has come into force, there is regulation that will become effective this year or next year, and some regulation still in the white paper stage. Understanding what is relevant and what you need to address now can be a minefield and will need your compliance team to work closely with the investment team to agree what is relevant for your business now (and needs addressing now) and what will need to be accounted for in the future
  • Service providers are developing new ESG-related data modules – this is making available a plethora of factors, scores, indices, and benchmarks that you can use for internal and external ESG reporting. But determining which, if any, are most appropriate to the business needs is a complex matter and needs some dedicated focus with plenty of lead time
  • Software developments bringing new and enhanced packages – new and existing system suppliers are introducing additional software functions and capability to monitor, model, and report ESG data. Similar to the point above, it is difficult to know exactly what is needed both internally and externally so perhaps don’t go for nirvana at the outset, rather start with the basics and build on that over time
  • IT Architects need to ensure the solutions are sustainable – the proposed business strategy and processes for ESG must not be built on rocky foundations, i.e. the underlying systems will need to support future developments. You should consider the end-to-end process, and build any necessary time and budget into the plan to accommodate, for example, new data linkages and system enhancements
  • Quantity and quality of data – there are many competing data providers in the market which can make selection difficult, particularly when you consider the cost and in-house ability to understand the data, understand how scores are determined, and ultimately what the data is telling you

What does this mean from a project perspective?

  • Difficulty in defining and finalising requirements
  • Difficulty in setting milestones
  • Hard to contain the scope of the project, output, and deliverables
  • There is a need for dedicated senior engagement & decision making
  • The initiatives will suck up business stakeholder resource and project resources

How do you overcome some of the uncertainty?

My overriding approach would be to say ‘be brave’. By that I mean not to aim for all singing, all dancing solutions at the outset, but that you draw a line under what you know and have today and work from that. In due course, once you have formalised the approach and embedded the minimum standards, then you can start looking at future enhancements.

If you consider ESG from a programme perspective, it makes it easier to break initiatives down into manageable chunks. Develop individual workstreams and run things in sequence as far as possible. Don’t try and do everything at once; have a delivery roadmap. And don’t be surprised if you have 5 or 6 significant projects or workstreams within the programme.

Here are a few questions to consider with the project team to help structure the programme of works:

  • What is it that the business needs to do as an absolute minimum to cover its activities e.g. from a TCFD or SFDS perspective?
  • What are the strategic targets the business aims to achieve e.g. PRI membership or Stewardship Code membership? If the business is going down this route, then a gap analysis is a good place to start
  • What are the internal policies, are they all written down and clearly defined e.g. for Voting and Engagements?
  • Do you have any areas where you have limited existing material or current policies are not as extensive as they are required to be? A lot of material may naturally focus on an equity perspective, however, it is important to demonstrate, as much as is practical, that you take ESG into account for all asset classes
  • What are the internal processes & practices, and are they all written down, clearly defined, and understood? Is everybody following them?
  • Do you understand and monitor your third-party service providers ESG practices? If not, what steps do you need to take to ensure you are provided with the relevant information and reports?
  • Are you able to demonstrate, through case studies and examples, how ESG principles have been put into practice?
  • Have you got all the necessary evidence for the reporting periods required? Is this presentable? Or do you need to build new monitoring and reporting capability (for both internal and external consumption)?
  • What is the business doing internally at an entity level, e.g. what actions are staff personally taking such as reducing their carbon footprints or using sustainable energy suppliers?

If you consider the challenges and have answers to these types of questions, that should allow you to start formulating a Terms of Reference from which the high-level plan can be defined.

One final message – There will undoubtedly be amendments as the project works through the finer detail (which should be through formal Change Control) and you should account for that in your planning.

We recently posted a link to a news article about the rate of IT project failures. There have been some very high profile, and some less high profile, IT project failures and outages in the past couple of years.

IT projects and programmes, large and small, are often both complex and complicated. Particularly when they involve the migration of data from existing systems to new systems. If you have worked on this type of project, then we aren’t telling you anything new.

We thought it might be useful to talk about why these projects can be difficult and how you might increase the likelihood of success.

The Challenges

The level of difficulty in these projects is driven by the:

  • Number of existing systems, the connectivity between systems, and external interfaces;
  • Functionality of the new system(s), any customisation, and the regulatory requirements;
  • Amount of data to be migrated, the structure of the data (clients, accounts, funds, stocks, etc.), and the data quality;
  • Number of system users, internal subject matter expertise, and internal project experience.

And that is only part of the delivery challenge. There will usually be an overlay of cost constraints, time constraints, and, sometimes, political constraints. It may be a multi-national project, it may span different divisions or businesses, and it can be across time zones. All of which increase the time, cost, and complexity.

Changes to any one of the things in the list above can, and will, affect everything else.

So, what can you do about it?

The core aspects of project management – governance, plans, risk logs, dependency tracking, etc. – are all important for a successful project but we would like to be more specific than that. These are our top tips based on experience:

  • Look before you leap. Everyone wants to get in to the action, but you must not skip detailed planning. We know it is laborious, uses lots of resources, and it can feel as if you are getting nowhere, but if you look at every component in detail you are much less likely to come a cropper later.
  • Mobilise properly. If you start the project with the wrong mix of skills and experience, it is difficult to recover, and you will lose both time and momentum. In your planning, make sure you understand who you need and when.
  • Map it out. Whether it is the system components, interfaces, or data migration, map it out. The more you understand about how everything is connected, the easier it will be to manage the project, keep it joined up, and assess the impact of any changes.
  • Never stop testing. It can be the easiest corner to cut, often backed by the implicit assumptions that “everything will be fine” or “we can fix it afterwards”. As recent press coverage shows, these assumptions are not necessarily correct. Test the functionality, interfaces, migrated data, systems access, volume, overnight processes, and everything else. You need to be confident.
  • Reconcile everything. It is one of the hardest things to do but it is critical. Reconcile your existing systems before your start, reconcile at every stage of the project, reconcile when you are testing migration, reconcile when you go live, reconcile across new systems and interfaces. Reconcile clients and accounts, reconcile financial amounts, reconcile static data. You need to know that everything is right.
  • Make good decisions. At each stage of the project making good decisions is key. Everyone will have worked hard to determine scope, timescales, and budgets. There may be good reason to change something but don’t do it without considering the evidence and expertise available to you. Quick decisions, sometimes forced by political pressure, almost always cause future problems.

This is a wide-ranging and multi-faceted subject to cover in a very short article. Every one of these projects have complexities and nuances that you could never conceive of at the outset but will be expected to manage when they arise, against a backdrop of time, cost and political pressure.

There is no magic solution but if you focus on detailing and mapping everything up front, making sure you test and reconcile everything as thoroughly as you can, and making open and honest decisions as you go through, you will increase your chances of success.

You can probably tell that we enjoy this stuff. If we can help, or you just want to pick our brains, feel free to get in touch.