FINANCE - FINTECH

Project management

Make sure you understand the big picture: Susanne Schartz’s lessons learned



Susanne Schartz says thorough planning and asking lots of detailed questions are key to good project management. Image credit: Eric Devillet (photo), Maison Moderne (illustration)

Susanne Schartz says thorough planning and asking lots of detailed questions are key to good project management. Image credit: Eric Devillet (photo), Maison Moderne (illustration)

Susanne Schartz shares a project management experience in this installment of “Lessons learned”, the Delano series where a financial executive shares what they learned from a particularly challenging experience during their career. The idea is to help both experienced peers and younger professionals if they encounter a similar situation at work.

Schartz is currently chief operating officer at Seqvoia, which provides software and data tools to financial firms. The experience shared in this interview occurred with a previous employer.

Aaron Grunwald: When did this experience happen, where were you working at the time and what was your role there?

Susanne SchartzSusanne Schartz: Some ten years ago, I worked at an asset management company. I had recently switched teams and was now in a new team. Where previously work was very much determined by daily operational routines, I now got to dig deeper in a different part of the business. The new surrounding had two sides, one focused on projects, the second on product. I belonged to the product side and what happened was that a major product project came along that needed to be managed. A project manager was allocated to the entire programme and I was asked to manage a sub-project on the product side. This included a new complex product launch, product mergers and operational integration across three global locations, and regulatory approvals.

What was the specific problem that you faced?

There were a few challenges. Firstly, I was new in the business unit and still unfamiliar to the product structure that was supposed to be launched.

Secondly, I had [previously] worked on projects before, defining requirements, reviewing specifications, testing deliveries, managing smaller business unit projects--so I was very familiar with the overall framework. Here I took on a role which was not part of my job description, which I had never done, which I had no formal training on and where the one person that had done this before was off sick--hence the need to put me to the test--and all of this on a large undertaking involving many stakeholders internal and external to the company.

How did you go about trying to solve the problem?

There was a mixture of approaches I took and also help I received. First of all, one of the senior leaders of the organisation sat down with me, giving me an overview content-wise how the product was going to work, where the differences were to a plain-vanilla product, which operational and contractual elements I needed to be aware of and consider within the planning.

Then it was a period of homework, crowdsourcing information. I sat with a colleague of mine who was knowledgeable on the regulatory framework on cross-border mergers. I sat down with the programme manager to learn about the overall context and any other moving items that might impact ‘my’ project. I sat down with the best business analyst in the world who was a planning hero, taking as much information as possible on MSProjects. Then I read what I could get on regulation, the project, the overall documentation. And then I created my project plan, with different streams--legal, client communication, operational setup, regulatory approval, merger activities--and interdependencies, all of this.

When you ask experts to contribute to a project plan, they will list a number of actions--sometimes not even very clearly. But some items seem so obvious, they will not tell you---despite the fact that they could be central to the work, or to a handover to another team. So throughout the entire project I spoke to the experts to understand the content of the project. What did they have to do, what did they need for their actions, why were they doing things. I also explicitly asked for risks, timings, the level of difficulty to perform operational actions, etc. So I worked my way into a real understanding of the work and the dependencies.

The good thing about this was that I actually expanded my knowledge considerably. At the same time, this also enabled me to assess what a change in any area meant to the project as a whole.

You said that “one of the senior leaders of the organisation sat down with me” to brief you. And I’m just wondering, how did that come about? Did you reach out to them? Or did they see that you were struggling, and they offered to help you?

They offered, because I kind of expressed my insecurity about the product, saying, this is not a normal fund.... I was new to the team, I was in operations before, but even there, [I had] more limited exposure to this type of product, definitely not to the more intricate workings that were necessary now.

So I wasn’t yet struggling. I was foreseeing some challenges in terms of the understanding that I thought I needed and definitely wanted. And that’s where he said, ‘well, I’m gonna sit down with you and explain’, and that was really, really helpful. It was one of the few moments in my career where somebody really kind of sat down and said ‘let’s really talk through this’ and explained.

How did you eventually resolve these issues?

Managing timelines became a major issue at some point in the project. The pressure I mentioned at the beginning meant that managers wanted to condense the project plan to fit the business ambition. But I had built a plan that I was confident in because I had considered regulatory review deadlines as they were guaranteed by the law. There was one conversation where the manager told me, ‘we have to do this earlier, we spoke to the regulators and they understand and will get back to us faster’. And I heard what he said, but simply thought that was not good planning to rely on a conversation and verbal agreement. This approval process had a lot of downstream dependencies--writing to clients, finalising contracts and operational agreements, setting up trading accounts. So I insisted on keeping the plan based on what I could rely on--the maximum timeline that regulators had to complete their review. I assured the manager that it would be easy to adapt the plan if approval came in earlier--simply setting some approval dates and the timeline for downstream actions would adapt automatically. But reliance on potential earlier action was wrong, because we were preparing client information including target dates. I managed to convince the manager, which was good, because all regulators came back with responses on the exact date they had to--not one day earlier!

Earlier you said some things were so ‘obvious’ that your colleague didn’t bother to explain them to you. So how did you find out about these ‘obvious’ things?

Yeah. In order to do the project plan, I really had to sit down with people anyway, saying, ‘well, what are you doing there? What are the main actions?’ And there it’s really questioning. So it’s questioning technique and a big grain of mistrust!

I think it always comes back to asking loads of questions and trying to understand, and I kind of wouldn’t give up until it makes sense in my mind.

So you really had to push for a lot of detail?

Yes and being ready to listen to the detail. You see, somebody says, ‘then we transfer the portfolio’, [be ready to say], ‘Well, what does that mean?’ And trying to really get the steps and then they explain something and say, okay, so ‘if I’m understanding this part, but I’m not understanding that part’. A lot of it also sometimes may be joining more detailed discussions, to pick up more of these dependencies, because, if you have big projects, what you need to do in the end is have a runbook of the actual events when you get going. So here’s the day when you do this really, physically, and, you have a timeline, number one to see, does it fit into 24 hours? Number two to say to those people who maybe have to sign something off at some point, or, have to be available all day, all night. We had the case, in the end, [when] we were sitting [there] all night. And we were still calling people at 11[pm]. You know, somebody in London called me back 11:30[pm] to know ‘can I have a drink now?’ ‘No, not yet!’

Looking back at the whole of the whole project, are you happy with the outcome?

Yes. I mean, the project ran to plan, except for these delays in the middle of the night, but, you know, there’s always delays on things like this. So I was also prepared for this, in a way, mentally, and I prepared everybody else that it might get late. But yes, it went pretty smoothly. I was happy to have insisted from the start that the timeline should be like this and could be shortened later on, if that became a reality.

But it didn’t, so...

Yeah, right! So I had good planning. You know, it’s what you plan for. I’m a big fan of planning realistically, rather than based on wish lists.

What advice would you give to someone who encounters a similar situation?

Don’t be afraid of challenges, measure them against what you do know already.

Work your way into understanding the larger picture--this makes you learn the most.

Be professional; keep the independence to make your own assessments.

Plan well and in detail--this gives you the flexibility to deal with the unforeseen by adapting a plan that you fully understand. To me, this is universal and not just on an experience involving an explicit planning.

Stand up and fight for what you believe in, based on good reasons and good reasoning.

This interview is part of the Delano finance newsletter. For the latest Luxembourg financial sector news, analysis and events, subscribe here.