Interview with Avril Tuohy, Project Director, HSBC

Delivering a BPM Solution in the Financial Services Industry can be fraught with challenges. What are your major challenges?

Getting people to understand the problem. One can waste a lot of time trying to communicate a need that may be very obvious to you but unless the sponsor can actually see the pain it is unlikely that they will take the project forward. In general it's about linking the pain they are feeling together with a possible solution in a coherent way.

What drives you in your role?

Delivering to multiple levels in the organisation. You know you are winning when the senior managers get what they want and the business users delivering the results on the ground also like working with the system. It's not always possible to please everyone but it is a good goal.

So what makes a good team?

Make sure that the team is big enough for the job; don't use a maintenance team for an implementation project. A proper range of skills is vital, as is the ability to work with each other. A well structured team should be equipped to manage risk which means not being too optimistic.

What do you mean by "well structured" team?

It has to be fit for purpose. For instance if the team grows out of difficulties with the current solution then it may not possess the right skills to implement. It pays to re-think the team structure prior to starting a project rather than using a support team to implement a new package. Get the right mix; make sure that the team has business input including process people and technical staff. An understanding of the process is vital to a successful implementation so the training of your staff needs to be matched by familiarisation with the business process.

When implementing or maintaining a BPM system, what are you priorities?

Stability, performance and functionality. In that order.

How do you go about achieving your performance goals?

Performance testing is vital. You must take the time to test how the users are actually going to use the system and not how you think they should use the system. Performance testing often tests only the intended use rather than the actual use. Beware regulatory issues these are really difficult to plan for and test.

Are there any principles that you apply in the pursuit of the priorities for your BPM solution?

Early adoption of new technology comes with risk; make sure that the organisation has the appetite for this before leaping in. If you are not sure then hold back. Once you have made the decision then commit to it and show a degree of tenacity. Don’t attempt a modification of any significance in the first year after implementation. Focus on stability and performance. Let the system bed in.

Ensure that the interests of all stakeholders have been considered before committing to a decision. This is the only way they will come with you.

You say that is important to consider the interests of all stakeholders when making decisions. Who are your key stakeholders and how do you manage them?

The key stakeholders are the User Community and IT. It’s been my experience that a user community, who use a combination of spreadsheets and information from the ledger, don’t always understand the advantages or the complexity of a BPM solution. Work with them to discuss the nature of the business process change and what this will actually mean to them.

Include IT at every step of the way; if they are not on board at the start of the project it gets progressively more difficult during delivery. Makes sure they are in agreement before you start.

Tell us more about how you approach business process change.

Make sure that the business is prepared for the change to the process and understands the complexity of moving to a new process. The older and more established the existing solution the more integrated it will be within the business, informally as well as formally. Worry about what you can’t see, keep asking questions and track down the informal uses of the old system.

Question how defined the process actually is. Get a proper understanding of how much of this process the organisation understands as compared to the little piece that individuals may understand. If it's not defined, take the time to get it defined.

Understanding the top level structure is easy; always look underneath at how it's made up as this will be where the real work lies. Worry about the quality of the underlying data and ensure that the business really understand how much work is involved in reconciling data on a new system.

Any advice on upgrades?

Too many assumptions are made particularly when moving to a new product from the same vendor. The technology is moving very fast and 5 years is a long time. The result is that what looks like an upgrade is in fact a complete re-implementation.

These products are built for a new generation of business problems and they handle things in completely different ways. They are no longer a general accounting tool, they are very specialised. The business needs have changed too and in the rush to meet these needs what works well can be forgotten when focusing on what needs fixing.

How can the risk of moving to a new product be mitigated?

It is all down to initial analysis. For example, if the existing solutions are highly distributed then it's likely that everyone will be using them slightly differently. This needs to be taken into account.

What is the most important lesson that you have learnt in your role as a Project Director?

I have learned not to attempt monolithic projects with every last requirement being delivered in one giant delivery. Prioritise the requirements, break the project up, demonstrate value step by step but keep your eye focused on the eventual goal. Start small. Stay flexible.

Other Interviews

Emap - Jimmy Weir

Friends Provident - Richard Thomas

First Choice Holidays plc - Jason De Mullich