Succeeding With Pega®: Speed, Funding, And Expertise With Ian Johnston

It is quite fascinating that we always fight to keep our digital transformations from becoming overly huge implementations. It is advisable to stick to iterative approaches, but it seems most people find it hard to do so. Alexandre Nevski explores this issue with Ian Johnston of AI4Process. Together, they explore how overcoming the challenges related to funding and people expertise can lead to better digital transformative movements. Ian also shares valuable strategies for building a strong team and how to equip everyone with the right skills that will spell success for your projects.

Pega® is a trademark of Pegasystems Inc. Please visit https://www.pega.com to learn more.

—

Succeeding With Pega®: Speed, Funding, And Expertise With Ian Johnston

Introduction

My guest is Ian Johnston. Isn’t it fascinating how we always fight to keep our digital transformations from becoming these huge, big-bang implementations? Why is it so difficult to stick to an iterative approach? With Ian, we explore these dynamics and discuss two related aspects, funding and the expertise of those involved. With over 30 years of experience in digital transformation, Ian’s insights are invaluable. He started his career in the city of London, implementing financial dealing rooms and wholesale banking systems.

In 1994, he joined Pega and has been involved in many successful projects in finance and other industries. In 2019, he co-founded ai4process with Amit Agrawal to help clients get the best out of their digital transformation. They brought together many experts in Pega and other tools to provide resources and best practices to clients. Are you ready for deep insights, practical advice, and a great attitude? Here’s my conversation with Ian Johnston. Ian, welcome.

Hi, Alex.

It’s an immense pleasure to have you on the show. I’m interviewing a lot of Pega experts for this first season, but you’re by far the one that has been involved with this technology the longest, isn’t it? I was wondering maybe for the readers, if could you share how you got into Pega, I think 30 years ago now. Also, what made you stay in that ecosystem all this time?

I started life in banking in the city, in trading systems and banking systems, and then I did a project for, HP, the company I was working for at the time, had this workflow system, which I thought was cool, where you could build and control a process and the user interface. About that time I was headhunted by a guy who was working on behalf of Pego trying to build up the Pego team in the UK. I had already had an interest in Workflow. He was a company that was starting in the UK, looking for people like me. Sounded like a really interesting subject to get into.

The technology that was already on your radar is something that you’d like to get more experience with and five years ago, you co-founded a company called ai4process. Could you tell us a bit more about what led you to create your company? What was the vision and how much progress you’ve made since then?

I left Pega in 2018, essentially to do something different. I was at a stage where I wanted to do something else, and move on, which I did, I left and then I knew I was going to do something, but I was looking for an opportunity. Amit Agrawal, my business partner, came along and he’s very persuasive and asked me to come along and form ai4process.

What we wanted to do is we wanted to incorporate best practices into Pega implementations, basically to use our skills and to bring on other Pega experts to help people implement Pega and subsequently other tools as well in the BPM workflow environment, implement them. We knew how to make Pega work, and how to make projects work within a Pega environment.

We wanted to do that in the best way, using best practices, using the best people. We figured that the best way to do that was to create our own company and do it that way. Amit has experience with Pega and with other companies in the Pega ecosystem running Pega practices. It was an ideal combination between the two of us.

Yes, indeed, and are you happy with the progress?

Yes, we’ve been growing. We had a little pandemic in the middle of the last five years to trip us up, but things have been going very well. We’ve got a good, long list of clients that we’re currently helping on their journey with various BPM tools, but mostly in the Pega environment at the moment.

Icebreaker Questions

Before we transition to the next segment, I wanted to ask a bit of an unusual question, but for the readers, Ian and I go way back. I was lucky to meet him 17 years ago, and I’ve always been inspired not only by Ian’s technical depth but by the attitude you have at work. I don’t think I’ve ever seen you stressed or angry. I wanted to ask you, where did you get that superpower?

Superpower? I guess I know, I suppose some of it you’re born with, and some of you have the influence of the people around you, but I don’t tend to get flapped by certain situations. I guess what you see on the outside is not necessarily what’s going on on the inside, but I think keeping cool and taking a step back and looking at problems or situations, be they communication issues or whatever is always good to do.

Iterative Approaches: Keeping it cool and taking a step back are always a good thing to do when looking at problematic situations.

We’re not going to get a silver bullet done today to you.

Not that I know of.

Echoes Of Innovation

It would be great to have in your journey that would illustrate how an iterative approach, one that avoids big banks can benefit digital transformation leaders. Let’s say we are in some insurance company and they do have some systems in place, but mostly they’re core ERP type of systems. From a business perspective, what objectives should be prioritized?

It depends on what they already have in terms of systems. The things that BPM systems are very good at are orchestrating, and coordinating between different actors within the organization, between customers and customer service, and this thing. It’s going to depend on the level of automation that’s already there, the level of manual processes that are currently there, and the control.

Typically if you go into an insurance company, they may have a lot of different systems that may do a lot of stuff on spreadsheets, checklists on spreadsheets, and things like that. Interdepartmental communication may not be great. If you have a customer talking to one department, they can’t see what’s going on in all the other departments, for instance. Having a centralized system where you’re able to record transactions and work between departments and be able to view across customers or clients or whatever.

If we were to put ourselves then, they’re considering, they see an opportunity, and they want this transparency but then what could happen to derail their attempts to do a smaller implementation at first to do an iterative approach? What kind of arguments are sometimes in your experience made to recommend, “Let’s do more.” “Let’s do everything.” Where is that coming from usually?

There’s a budget aspect that drives it. Who’s going to pay for it and the people who are paying for it or the business units that are paying for it want to see everything done? They want everything for their money, et cetera. There’s that going on for starters, which is a problem. Anybody, when they look at automating part of their organization is going to want everything as well.

They’re not going to be satisfied with something small. There are probably lots of other reasons as well, why that doesn’t happen but you see it in so many places. They try to boil the ocean. They want absolutely everything. What starts as an iterative, agile project to deliver sprints worth of production functionality turns into a huge waterfall project because everybody decides they can’t live without everything on day one.

What happens is that nothing happens. It’s the personnel. All of these things are all about the people. You need the right people with the right vision in the business. You need the right people to manage and govern what’s going on and then you need the right people to perform the implementations for you. You need to have high-caliber people who understand the technology and who also understand the business. That’s key to being able to understand both of those things to get the best out of the implementation.

How does that work at a personal level? It’s rare to have a business leader who has done agile, for example, projects before, they might not have that much experience with that. On the technical side, you were talking about the art of the possible. I guess you’re referring to a more technical skill set, but how do they understand what the business objectives would be?

I think some of that has to come from within the business, but then some of that can also be provided through third parties, the software implementer, or the SI. They can provide that, but they’re not going to be able to provide everything to the business. In any software sale where you’re selling a software application to a business, you need a good buyer as well as a good seller. Buyer needs to know what they’re buying and how they’re going to get the best benefit out of it.

Not every buyer is what I would term a good buyer. Some projects are doomed to fail because the buyer doesn’t know what they want or what they’re buying. Therefore, very difficult for anybody to be able to succeed in that environment. If you get a good buyer and a good team and you’ve got a good seller who understands what they’re implementing and selling, then make it a success.

Blueprints Of Innovation

Let’s say in our hypothetical, example, the buyer is struggling a little bit this midway through our story. They might be described as you just said, maybe not the best of buyers. They’re a little bit confused about this approach. What can our hero, our digital transformation leader do to guide them, to get them back on track?

That’s exactly what they’d have to do. Again, you’re relying on the experience and the knowledge of the implementation party, if we’re going in. One of the things that ai4process tries to do is to put in high caliber people into our projects to be able to help guide the client to be able to get the best out of us and get the best out of the software.

Yes, it is teamwork between all of you and everybody’s contributing, but if you do have a lot of experience in this, you can provide that advice and guidance or governance. One of the things that we do, which is pretty important is to go in and set up a center of excellence within an organization to be able to help that governance design out of the possible, how do you coordinate, how do you do reuse and all of that good stuff across the organization. That is providing some of that but you do need some experience on the customer side as well. Help is available.

It sounded like you were talking more about a partnership, not only providing implementation services because you were saying that you need sometimes to be part of governance, to guide the directions. Is it fair to describe that as a partnership?

Absolutely. That’s exactly what it is. The partnership may be between multiple partners as well because it’s never as simple as two companies, a business, and many companies in a lot of cases.

Is that hypothetical story that we just told, is that actual? Does that happen in reality?

Yes, it does. I’ve seen both ends of the scale many times, from the waterfall, which never actually gets there, to the iterative where everybody’s seeing new stuff coming in and things improving weekly basis.

Innovator’s Playbook

I think that’s very encouraging for our readers. Like this story, please like and subscribe. It will help us share it with a wider audience. For the last segment. We want to share practical advice with digital transformation leaders that an iterative approach, the shape, what is maybe the first thing you’re going to do, and the first quick wins depend on the funding. Can you maybe expand and elaborate on that a bit?

If it’s a small business and it has a single business unit, then much easier. It’s clearer. It’s a single business, one particular business unit, one source of funds, implement one system. Fine. You know what’s going to fund it. You know where the benefits are going to be but if it’s a large organization with 10 different business units, then where do you get the funding from? Is there a central budget for IT for transformation that you can use?

If so, how does that get funded? Typically, particular business units will make more money than others. Therefore, do they pay more? You might have one part of the business that is a lot more complex but makes much smaller margins. How do you disperse the costs across the organization? You may be fighting separate finance departments in a business unit and the budget for the whole organization’s IT possibly won’t run to the money you need to do a transformation across the whole organization. That’s where the difficulty lies.

Is there a structured approach depending on the funding in place, and how you approach the technological project? Or is it the other way around? Do you figure out what you want to do from a business vision perspective, and then you try and find the right funding?

I guess it’s all got to be driven by cost-benefit, hasn’t it? It’s difficult to do it any other way. The benefit has to be demonstrated to each part of the business. For them to want to fund that transformation for their part of the business, they need to be able to see how they’re going to benefit and it comes back down to let’s do something on a small budget to start with that we can roll out to the main businesses and then see some progress, have paid a small amount of money and got some new functionality for that money, some new transformation.

It’s all about being able to demonstrate that they’re not just pouring money into a central bucket, which after three to five years, they’re going to get a new system that’s going to do everything they want. And typically what happens is everything changes during that period. The leaders change, the businesses change, everything changes.

Now you’re left with something which is never going to be finished and businesses paid a lot of money for. It does come down to looking at the cost-benefit in each business and having a central decision-making process to work out what you’re going to do first in terms of prioritizing what you’re going to build.

I think you do need to have the ability, it depends on how much control you’ve got in your business of the purse strings across the business because if you don’t have any control, it’s going to be very difficult for you to justify building something that every part of the business benefits from, but one part of the business is paying the most for because they make the most money.

If you don’t have control over your business, it will be difficult for you to justify building something that everyone could benefit from.

I think there’s a balance there between the benefit of each business unit, wider business, and what’s going to benefit everybody. It’s almost like you need a little bit of socialism within your business to make sure that everybody benefits rather than just the people who shout the loudest and make the most money.

Yes, because you’re potentially looking at benefits further down the line. Sometimes short-term investment is only part of the full picture. I like the metaphor of the tree for an organization where business units are the branches or the leaves or whatever, but they have a trunk that they have in common and those are the shared services of which information technology is often for once.

Some organizations are like huge trees, with one big trunk and a few branches up top and nothing else, and then some other organizations are more like bushes where there are almost no shared services because I don’t know the way that the organization came into being through merger and acquisition, so maybe just the strategy of their organization.

It sounds like coming back to the funding, you want to take into account the shape of the organization. Based on that shape, which part of the organization is going to see the most benefit? Those are the ones that you would, by default, approach but then let’s get back to what we were saying about longer-term investments and creating assets that are going to be a a public good in the organization. How do you fund those?

Rather than each party or business building their own by themselves, you’re building it once and everybody’s benefiting from it, getting that economy of scale. I think it’s being able to put that into a short time scale again so that everybody’s benefiting within a short period rather than a long protracted global transformation program.

I think that’s the key to being able to show that it’s not only are they going to get something which is best in class, best practice but it’s going to cost them less money and they’re going to get things more quickly. They’re going to be able to get improvements more quickly, and better functionality, and they’re going to be able to benefit from innovation in other parts of the business.

Some organizations solve this quite complicated challenge by simply having, information technology, IT, take care of all the projects from their budgets. Is that a good idea in your opinion?

I think we’re always going to be moving towards it being business-driven rather than IT-driven. The tail shouldn’t wag the dog. The IT department should be able to guide the business, telling them what the art of the possible is, and what the best practices and innovations are, but at the end of the day, it’s got to be business-driven.

I guess I agree with that because I have seen so many IT departments hijack those initiatives and from a business perspective, in those cases where they are not paying for it, there is no business case as such. There is just a replacement program for one tech by another or something like that, or just the acquisition of a new tech. It does seem like it has lost its meaning. There’s no clarity about why this is being done other than internal IT purposes. What other practical advice should we give to our readers?

One of the things I feel most passionate about is the people side. With the increased sophistication of BPM and workflow platforms, do need the right caliber of people to be able to create business applications within businesses. You can’t throw an army of people against a problem to solve it in any short space of time.

It needs a smaller number of higher caliber people, people who understand the business that they’re going to work in and they understand the technology, be it Pega or anything else, they know exactly what it’s capable of. I think a smaller number of people can be a lot more productive when they know exactly what they’re doing, as opposed to having a larger number of more junior resources on projects such as these. There is an issue there, which is how do I bring on new people? How do I train them? Where do these experienced people come from? There isn’t an infinite pool of these.

I’m sure every leader would prefer to have fewer reports or fewer people to manage and be more productive, but it’s not always possible. What can you do?

I’ve always described a diamond shape to the project team that’s working on an implementation. Rather than the pyramid where you have your experienced people and your leaders at the top and a small number and then you have a large number of your army of your more junior people at the bottom who are doing the actual work.

I think it’s more of a diamond shape is what you should have. You have your leadership team and then you have a larger number of senior consultants in the middle and then a smaller number of more junior people that you’ve got that you’re bringing up and training and who are gaining experience. You’re always going to need that because you’re going to need fill from the bottom up.

As people move away, leave the project, or move up in the diamond, you’re going to have to fill from the bottom. Having a diamond shape rather than a pyramid, I think, is key. What you tend to find is that in more traditional projects, the more senior you get, then the less you do in terms of actually building things, and designing things.

That should be the other way around. I think you need experienced people and you need to change the mindset that moving up in terms of seniority should mean that you still do that work but you do it at a much faster or more efficient level than you would have done. You need to adopt A-scales for instance. There’s a thought that if you want to move up the pay scale, then you have to move up into management.

The more you move up in terms of seniority does not mean you get less work to do. You must only learn how to do it at a much faster or more efficient level than before.

I think actually what you need to be doing is giving a different route, which is more the principal consultant route. You have very skilled people doing the work as opposed to just moving up into management positions. In terms of backfilling underneath, then you do need a small number of people who are coming on training and not draining the resources out of the more senior people.

If you have a large number of junior resources on your project and a small number of experienced people, the juniors will drain a lot of resources from the experienced people, take away from the critical path of the project, and also create work that may need redoing or has a lot of issues, whatever, which then causes the project more.

Another benefit for the junior people themselves when there are fewer of them is that they move through the gain experience much more quickly.

They get more attention. One of the things we do after processes, is we have a lot of skilled people, but we also train as well. In training, we build teams for our clients, who will ultimately become employees of our clients, but also for ourselves. What you need to do is put these trainees or the guys who are just coming up through training onto projects with more experienced people, but a small number of them, not a large number of them. Spread them across your projects so they can gain the benefit of working with the senior people. By putting many of them on, you’re not training the resources out of the cycles of your senior employees.

To select the smaller number of people, what should they look at?

They’d look at the supplier, obviously in the reputation of that supplier. Then I think you’ve got to look at the individuals if you don’t know the supplier and you don’t trust them and the people that come on. Then obviously you’re going to need to look at the individuals, look at their experience and CVs.

Is it about technical skills or are there other aspects to consider?

It’s all around. It’s about the technical skills, certainly about the communication skills and the understanding of the business as well. One of the things that we do when we train people up to go and work within a particular business is that we teach them not only about the technology, we’d look at their soft skills and they may need some help there.

We’d also look at training them in the business that they’re going to work in. When they go into the business, then they can hit the ground running as quickly as possible because they understand a bit about the business, a bit about the big picture not just the small piece of work that they’re tasked with doing, that they can start to make informed decisions themselves as well as part of the learning process.

Train your team in a way that they understand a bit about the big picture, not just the small piece of work they are tasked with doing. This way, they can make informed decisions themselves.

I think it’s also part of the respect we show our clients because it can be jarring for them to have sometimes technical experts join to whom they have to explain the very basics of their industry. I think nothing technically wrong with it. At the human level, there is something about it, isn’t there?

A lot of businesses aren’t that complex at the end of the day when you look at what they do, but many people who are working on projects would not necessarily understand because they’ve never looked at it. They’ve never had the opportunity or been given the opportunity or been taught what the business is, how it works, what it does, and how it benefits their customers.

Following on from this topic, is there any book or media recommendation that you would give to our readers?

When I started working in banks early on in my career, there was a fantastic book called How the City Works, which goes into all aspects of finance and how books within the City of London. My recommendations, and it’s still valid now. It all still works in the same way it ever did largely. Technology has moved on somewhat, but the basics of banking and finance are, as far as I know, fairly similar, or if not the same.

That’s great if you were going into a telco company or insurance company to do some research and find a book or an online blog about the basics and how it all works. Fantastic thing to do and gives you so much credibility if you’re talking to business users, requirements gathering sessions, or whatever as part of the project, maybe something like that.

Episode Wrap-Up

Credibility is really important in our profession. That wraps up the first part of my conversation with Ian. I hope you found his insights into the iterative approach, federating funding models, and the importance of people in digital transformation as valuable as I did but there is more. Ian’s vast experience provided us with so much great content that we’ve decided to dedicate a second entire episode for a deep dive into the world of artificial intelligence. We’ll be exploring the latest use cases, understanding the risks, and discussing the capabilities of Pega’s process and generative AI. Be sure to tune in to the next episode for this special continuation. You won’t want to miss it. Until then, peace.

Important Links

• Ian Johnston – LinkedIn
• ai4process
• How the City Works

About Ian Johnston

Ian started his career in the City of London implementing financial dealing room systems and wholesale banking systems. He then joined Pegasystems in 1994 and worked on many workflow and BPM implementations across financial and other industries. In 2019 Ian co-founded ai4process together with Amit Agrawal to help clients get the best from their digital transformation. They have brought together many experts in Pega and other tools to help them grow the business and provide resources and best practice to their clients.