Building Power Platform Applications for a Church with Haniel Croitoru, Protiviti

Welcome to the Amazing Applications podcast. This is the show for Microsoft, Power Platform and Dynamics 365 application creators who want to build amazing applications that everyone will love.

Hi, everyone, I'm Neil Benson, your host for the Amazing Applications podcast. My goal in this show is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power platform applications. Welcome to another episode of the show. You'll find show notes for this episode at Customery dot com slash zero two five.

My guest in this episode is Haniel Croitoru, Haniel is an associate director at Protiviti who lives in Toronto, Canada, and he's been a business applications MVP since 2017. Haniel shares a story about one of his power platform projects for a Protiviti not for profit client and shares the lessons learnt about multi-language deployments, implementation approach, executive sponsorship and change in user adoption. But just before we get into the interview with Haniel, I wanted to give a shout out to Pam Mannell, Pam is a customer engagement training consultant at CRM365 Solutions from Devon in the U.K., Pam recently took my online Scrum for Microsoft Business Applications training course and went on to achieve her professional Scrum Master level one certification with Scrum.org. Well done, Pam. You'll find show notes for this episode at Customery dot com slash zero two five. Oh, let's meet Haniel.

Ok, Haniel, welcome to The Amazing Application Show, it's great to have you with us.

Thank you, Neil. Glad to be here.

I'd love to have you on the show sharing your experience with the power platform and Dynamics 365. And I believe you've got a background in SharePoint, which is exciting as well. But just so our audience can get to know you a little bit better, can you tell us what you had for breakfast this morning?

Ah breakfast..Yeah. So typically I start my day with a cappuccino. It's an old old tradition I've had a machine that I got about 13 years ago from a wedding. And it's been serving myself and my wife pretty well since then. And I think almost no single day goes by without starting the day with a nice cappuccino.

Good. I'm a flat white kind of guy, so it's a little bit less foam than a cappuccino. But yeah, first thing in the morning, got to wake up and turn on the coffee machine for sure. And tell us about your first job. What was your first job after school?

First job so very, very far removed from anything, Microsoft or SharePoint. So I actually started my career after I did a master's degree in computer-assisted surgery, which is really a field where you apply computer science and robotics and electronics to solve medical and surgical problems. And so after I finished a masters degree in that field, I was working for a company here in Toronto, Canada, where we were developing software and hardware for image-guided surgery. So if you can imagine doing surgery through a camera, where you can superimpose your instruments on top of an X-ray or a CT scan and then look inside the body without actually having to cut the body open. So augmented reality is what it's called today. And 20 or so years ago when I was doing it, the term augmented reality didn't actually exist yet. So, wow, very cool. But that was yeah, that was my first real job.

And I saw that you've got several patents listed against your name as well. That's an amazing achievement.

Yeah. So through the tenure of about 10 years, developed some new approaches to actually doing surgery for mainly for orthopaedics, which was my area of expertise. And yeah. So so being able to achieve some millimetre accuracy on hip and knee replacements was something that was quite, quite novel at the time.

Uh Amazing. And tell us about your current job.

So right now, I'm an associate director working at Protiviti, which is a global consulting firm servicing twenty-five countries. We have over 70 different offices all across the globe. We do consulting in a number of areas. Technology consulting is actually one of the smaller ones. We do a lot of work in internal audit, financial accounting, security and compliance risk assessment, a lot of different areas in risk and finance.

 Ok, good stuff. I know you wanted to come onto the show to talk about one of the projects that you've deployed recently. That was the United Church. Can you tell us about that organisation?

Sure. So, yeah, we've been working with them for a number of years now. And one of the areas that we like is, as you mentioned, I started in SharePoint, but over the last few years I've been focussing very heavily in the power platform and automation and simplification of processes is something that is very, very near and dear to my heart. I always believe that you know, you should automate everything in life or as much as you can within reason. And so when we were working with the United Church, a lot of the processes at the time were manual and paper-driven. And they were going through a digital transformation whereby they were moving a lot of documents and even data that were stored on physical format into the cloud. So combination of SharePoint Online, Dynamics, and we took the opportunity at the same time to also automate a lot of their processes through online forms and workflows.

Okay. And what kind of size is the United Church in terms of number of users? I guess. But that's one way of measuring the size of a project or the size of an organisation.

So I believe there is about in the office, the core office, there were about 150 to 200 people. But then now the end-users who are really ministers and members at all the different locations, all the different churches and communities of faith, I believe you're looking at upwards of eight thousand people in.

Okay. Wow. it's a big organisation then. So they had some pretty old paper forms, I guess, collecting information about the congregation and those types of things, digitising all of that, so was the goal of the project was then to streamline the organisation and make things more efficient? Was it a cost-saving kind of project?

It was, yeah. It was a matter of cost-saving. It was a matter of just streamlining how they do things. Also reducing the amount of errors and really trying to sometimes reach out to some of these communities of faith that are very remote. And they do something by paper. By the time that it makes it into the main office, it might take some time. It can get lost. So doing it online is a lot faster and less error-prone.

What led them to choose the Microsoft platform? Were you part of that selection process as well, or that they made that choice? By the time you come in to deliver the services.

The choice was made. They were on Microsoft before. So they've been using Dynamics on Prem and they were using some other Microsoft products. But the actual decision to move to the Microsoft cloud, that was something that was the decision was made before I joined, I think about the people that were involved.

What kind of size of team did you have on your side? On their side? What kind of roles did people have and which of those do you think were the critical ones for the success of the project?

So I think our team was made up of about six to eight people, varying from the PM and the business analysts to having technical people involved in the configuration of the solution, building custom solutions, doing testing and validation, doing the business process development. So that's kind of from our side. That was a team size. From the client-side it varied because depending on certain areas that we were automating or working on, we would have members of the team anywhere from, let's say, two to five or six per department join in and be involved in all the discussions, the approach we wanted to take and then later on being involved in validating the solution and making sure that everything works as they were expecting it to.

Okay. What kind of project sponsorship did you get on the client-side? Was there a strong project sponsor in place?

Yes. Yeah, we had upper management involved in the project from the beginning.

 And you think that that's a critical thing or could you have delivered it without their support, you know, with some middle managers providing the requirements?

I believe that especially when you're going through such a big transformation, which requires a lot of change management and training, and often you'll find that organisations that are there are kind of the leaders and the laggers when it comes to adoption. So it's important to get the buy-in and the support of management to ensure that this kind of a transition goes smoothly.

Good. And I think about your side, was a project leader on your site who was driving the whole thing, or was it a collaborative effort where there's a number of people involved in making sure it all happened, driving the project? So initially it was driven by somebody else in my team. But then once I've joined, I was one of the key drivers of the project.

Ok, so you were the leading the project, inherited it from somebody else?

Yes.

Oh. How does it feel stepping into the middle of another project when you have a strong leader to hand it over to you, then it makes things a lot easier. Things are well organised. Communication is well defined. So it definitely makes things a lot easier.

 How long did the project last? Was it quite a quick project for you or was it stretched out over a number of years or months?

Overall, we've been working with them for a couple of years now. The last project that was on was for about almost a year.

Ok, so it's quite a long project. Yeah. And was it all deploying a single application or were you rolling out a number of applications, one after the other.

Yeah. And also, as I mentioned before, we have there are a number of solutions that were being deployed, including SharePoint Online. There was Dynamics 365, the power platform. Those are some of the key components and then we also had some azure workloads that were being leveraged for automation and for other areas.

Right. So so the technical architecture was on your side deciding which applications to use to solve the business problems or did the client come along and say, no, we need SharePoint for this or Dynamics for that?

 No, the the client entrusted us to let them know what would be best to solve their specific needs.

That always helps if you got that trust with your client. Yeah. Thinking about those applications, are there any particular features or capabilities that you deploy that you're really proud of that made a massive difference to their organisation?

Um, one of the biggest challenges that they had is because they are a bilingual organisation in Canada. Everything that you do that is either government or has a large number of users that are accessing information, you must have all the content in English and in French. And so providing solutions that are bilingual. While SharePoint has some capabilities, the power platform at the time didn't have any capabilities to do so. And so we've actually devised an architecture that made it very straightforward to actually build single apps that are bilingual and all the language would be defined kind of outside of the actual Power Apps.

And so during the load time, it would determine what language to users working in and based on that service to correct information onto the apps.

Ok, so as a church user, I can come in and say I want to speak French. I don't know if you're French, Canadian or Canadian, French or just French, Quebec, Quebec, Québecois. OK, so I select Quebec is my language and all the user interface elements are all updated to French. Or if I switch it to English then it would all switch to English.

Pretty much yeah it would default. So if your browser was set to French, it would, it would pick up on that and would say or either your browser or your Office 365 default language. If it was in French it would pick up on that and say OK, now all, all the content is going to appear in French automatically, so you wouldn't even have to set it.

That's pretty clever. You'll have to forgive me, but I haven't done a multilingual deployment since I lived in Europe a few years ago. But is that a standard capability in the power platform today?

It is not. And this is actually an architecture that I devised and I've given a number of talks about it at different events. You may see it referred to as Around the World in 60 Minutes, where I talk about the architecture, give some examples and the way that the architecture is built. It actually separates the content, which is the language from the actual app. And so in this particular case, all of the terms that were used on the apps were stored inside of SharePoint lists. And then if I wanted to add another language, I just basically add the new terms to the list. And every item would have a number of fields where one of them is the label itself, the value of it, and another one would be the language. So if I wanted to add another language, literally, I'd have had to do was just add the labels, define the language for the labels in SharePoint, and just refresh the app and select the language that's allowed to do. 

Really clever.

And so that's a feature that you've managed to extract from that client project and then reuse that in other deployments.

Yes, the architecture, the approach is something that was initially developed for that client. But the approach is very easily adaptable to other clients as well.

So that's, it can be pretty tough to do that when you're working in a large consultancy because, you know, you need some spare time to take the learnings from a client project and extract them out, make them more generic, perhaps make them reusable so that you can use them in other projects or maybe even package them up and put them on appsource so other people can access those. How do you manage to find the time to do that? Is that something that Protiviti does quite a lot of?

I think a lot of it comes down to self-discipline, right. So myself, there is no such thing as, OK, my work stops at five pm. I mean, if I wanted to continue to enhance my knowledge, I'm always reading something or trying out some new technologies or experimenting. So this is just one of those examples where I actually did research and came up with the approach first and then applied it to the client and then basically enhanced the approach a bit more. Wrote about it, like I said, gave a few presentations. But the knowledge, the IP is there. It's in my head and it's documented for others adaptivity. So if they wanted to implement the same approach, they could it wouldn't be taking anything from the client. It would just be implementing the same solution.

I love that idea of taking your knowledge, writing about it, presenting it, because that also clarifies it, refines it. You improve it in your head, it becomes better rather than just being stuck in your head and being reused on a future project that you happen to be staffed on. So I love that idea of sharing it. I think it makes the ideas stronger too.

 Absolutely. And actually what I find is often when working on projects and you're faced with challenges, that is often the best material for new articles and new presentations because I'm not a I'm a firm believer that if I want if I wanted to produce some content to be shared, I don't want to produce content that is already has been produced before because it kind of dilutes the value of what's already there. And, you know, when you search for some. You realise, OK, you're going to be hitting the same information over and over again.

So sometimes when I come across a certain challenge that hasn't really been solved before, that is typically when I will find myself writing about it or doing a video or giving a talk.

Think about the approach that your team used for this project. You know, it's no secret I'm a fan of an agile approach, taking things iteratively and incrementally. Was that your team's approach to this project or was it more of a plan based with the requirements specified upfront?

No, it was definitely a natural approach. I mean, I've worked with many clients over the years and being both a project management professional and a certified agile scrum master, a lot of clients will tell you from the beginning they know exactly what they want and they will document it and spend a lot of time writing documents. And I would say with confidence that 100 percent of the time what was built at the end if we build it exactly based on the specs, it is not what the client wants. They always want to do some changes or enhancements. So that's why I'm very much in favour of taking agile approaches where it makes sense. It doesn't always make sense, but in most cases, it does in software.

So think about requirements, specifications. Do you think they don't accurately reflect what was needed at the time, or is it just that the requirements have changed during the course of the project? Or were the requirements always wrong from the start?

It's not so much that they are wrong. I think what happens is, especially when you're looking at these kind of transformational solutions, users' knowledge is limited to what they know. So when you tell people about SharePoint a lot of times and their knowledge is limited about how they're going to say, yeah, it's a it's a cloud-based file share, it's a folder in the cloud, that's what they know SharePoint to be. And that and that is essentially limiting them. And if you were to say, OK, let's talk about your metadata, let's talk about content types and other things, you often kind of get a bit of a blank stare because they don't know what that is. They don't understand it. And so when you're asking them, let's talk about an information architecture, let's devise it, they don't really know what to say. They don't know how to think about it. And even though you spend a lot of time trying to explain it, while they may get it until they start using it and pivoting on how they think about data, they will not know exactly what it is that they want. So I've just gone through this kind of exercise with another client. We've spent a better part of about three to four months talking to every department, locking down the information architecture. And so far, now that we're doing the deployment, one hundred percent of the departments we're going through are making changes to the information architecture before we actually migrate because they're realising that, oh, now that they actually start seeing some of the data in a test environment, it's clicking in their head. It's like, OK, now I understand we need to do so.

I'm sure I asked a couple of agile practitioners this, but there's a phenomenon that says I can't express my requirements until I see something and then I can tell you what I want or don't want or don't like about what I've just seen. I'm sure there's a name for it.

I mean, sometimes you whether it's a proof of concept or just some demo, I wholeheartedly agree with that statement. Sometimes a lot of people are very visual. So if you try to conceptualise something to the users, they may not get it. But when you actually put something right in front of them, say, hey, here's what, what what you're going to be doing. Here's how I want you to think about it. It makes a lot more sense, you know, and I think, you know, people humans are visual in nature. So, for example, I don't know. I believe you come from the Dynamics background, not so much SharePoint. But if I try to explain metadata and content types and document libraries and security to somebody who doesn't understand the concepts and I try to talk in SharePoint terms, it can be quite overwhelming. Now, if I were to tell you, OK, imagine you're in your kitchen, your kitchen is your SharePoint site. Now I'm going to give you a coupon to your favourite supermarket, that coupon as a content type. It is something that you can see. It is something that you can hold in your hand and touch. That's the type of a document. And then you look at the information about it, the expiry date, the amount, the name of the store, those are all metadata feels right now. Take that coupon and stick it on your fridge. Your fridge is your document library.

Right? Right.

Take another example. Now you want to have something that's going to and the retention policy whereby when you talk about retention, the moment that the expiry hits on the coupon, you throw it away, it's useless. You don't need it anymore. Now, let's take another document. Let's take your Internet bill. You just received it in the mail. You're reading it, you know, opening up the letter, you reading it, and you're in your kitchen. Now, that's another content type. It's an invoice or it's a bill. It has different types of metadata. Maybe the amount, the due date, the service provider, and now you take that bill, you're not going to throw it away, you're going to put it in your drawer, which has a lock on it so your kids are not going to play around with it. So now you've got security and the retention may be what you have to keep it until the end of the year. You submit it to your accountant for tax purposes, then you throw it out. All of these concepts that are technical in nature, all of a sudden you're putting a very real-life scenario, like a spin on it, of something that people can actually relate to. You know, the kitchen, the fridge, the coupon, the you know, the Internet bill. And now they go they get an understanding of it.

I love that. That's amazing. I love the analogy you paint to help bring those technical concepts to life. I think we could all do a lot more of that in our projects, whether we're painting pictures like that verbally or prototyping either with low fidelity paper prototypes or high fidelity wireframes, I think we owe it to our users to bring those concepts to life. I love those illustrations. Great. Thinking about some of the challenges that you had during the project. What were the tough parts that your team faced or the client faced and how did you manage to work around those?

I would say change management and adoption is usually one of the biggest challenges as much as you want. You'd love to spend a lot of time with every single user that's not often achievable. And so trying to find the best possible medium to reach as many of your users and try to provide them with the necessary support that they require, I find that is one of the biggest challenges in this specific case of the project there was doing. Reaching the people in the office was easy because they're there and we were there. This was before covid. But then imagine the eight thousand or so users that are out in the field that can be in very, very rural areas of Canada that you would have to probably fly to or be on a train for a long time or a car that is not as easily achievable. Also, that if you look at the demographics so often, the people who would be, let's say, serving at a community of faith or assisting may be individuals who are less technically savvy and older, and then they start getting into challenges where maybe the screen text is a little bit too small and they just don't know how to use the technology.

They're still running on a, no joke, they're running on a three hundred baud modem. Well, and so we're trying to say, well, you can't really run SharePoint. You have this kind of a technology. So those were the main I would say the main challenges is it's mostly just the uptake and the adoption.

OK, so what kind of learning and user adoption strategy to put in place to try and help these people adopt your technology, offering different mediums, whether it's videos like little two minute videos on how to do something, documentation offering workshops and Hands-On workshops, offering drop-in sessions where they can do essentially like a few a free Q&A on anything they want to discuss and just really offering a lot of those and then also identifying champions in different regions or different offices. So if somebody has to ask a question, they can go to that champion first. So you're not going to have a small team of support staff inundated with a lot of simple questions.

So I love that idea of finding those local champions closer to where the users are, maybe a peer of the users? So somebody who's in their community or in the location, how do you find those people and bring them along? Do you share some project material with them earlier than the rest of the users get it? How do you get those people to trust you and devote their time to your project?

You need to empower them early on. So you need to really spend more time training them and providing them a lot of tools. If if they ask for some materials that, for example, may not be directly in scope, extra documentation or extra training. I personally like to go the extra mile for these individuals because what I find is that by spending an hour or two extra with them, it can save me dozens of hours later on if they don't have what they need to support their teams.

Ok, so that's a good takeaway for us, is to find those early adopters, the champions in our user community, support them with a little bit of extra love and that will hopefully make it smoother sailing for us and for all the other users later on in the project.

Absolutely.

Any other critical success factors that you think made this project particularly special or successful? Anything that stands out as a repeatable practise you'll take into your other projects?

I would say that just the amount of change that this organisation has undertaken in a fairly short time, changing almost all of their systems in one shot, I think that was quite exciting and also nerve-wracking at the same time, I would say that if I could take one big learning from this particular client is when possible try to maybe stagger some of the rollouts, because, again, if you're throwing a change at a user, it's one thing. But if you're telling them that everything that they do has to change now, it can cause a lot of stress for individuals who are not dealing well with change. And we have seen somewhere they were just a little bit flustered and they didn't know where to begin. Every time they would look at anything, it's like everything is new. It's almost like starting a whole new job.

 I was just chatting with a client yesterday about that exact same challenge. We're talking about the frequency of change. Should we plan for enhancements to our applications every couple of weeks? You know, at the end of every sprint, we deploy a new increment and enhancements, knowing our user application, or should we bundle them up and do it every quarter or half-year or every year? What have you found? Works really well as a pace of change for users, particularly in an organisation like United Church, where your users aren't full-time information workers sitting in front of a computer for 30 or 40 hours a week.

Yeah, so when it comes to especially when you're working in the cloud with Dynamics, with Microsoft 365, you often don't have the control to decide when changes are rolled out. You can join the first release programme for some users so they can get changes early on and they can see what's happening. But you really have to be ready to communicate changes that are coming and let users know that some changes, they just don't have a choice. They are the changes will be coming so often communicate through the Internet, through other mediums, and as I would say, as frequently as necessary, depending on the size of the change and the impact. And you should have some sort of a governance team in place who's on a regular basis reviewing what's coming down the pipe, understand the implications, determine if you need to provide extra training if you need to change some of the processes, documentations, whatever it might be, be ready, communicate early on, communicate frequently so that the change will be as smooth as possible.

Yeah, good advice. Thanks for that. Haniel, I really appreciate you sharing some of the learnings from your United Church project with us. If people want to keep in touch with you, follow you and discover some more of your content. What's the best way for them to do that?

 So you can follow me on either Twitter and LinkedIn. I'm not sure if you're going to be sharing the links anywhere.

Yeah, the links will be on the show notes for everybody to see. So I'll put those in the show notes for this episode.

Perfect. And also, if there's any questions about, you know, if somebody needs some help on some projects or some of those examples I was talking about I'll share my work email as well so that can reach me there.

Good stuff. Thanks, Haniel. I really appreciate your time today. Thank you.

Thanks again, Haniel. It was great to hear how he's designed a solution for multi-language, Power Apps user interfaces, his agile approach to building business applications and how he addresses change management and user adoption in his projects. Haniel is a well-known presenter on Power Platform topics. His presentation, Power Platform Governance Like a Rock Star, is a popular presentation at lots of community conferences. You can follow Haniel on Twitter at hcroitoru and on LinkedIn Haniel Croitoru or his blog at agile 0 three six five dot com. Of course, I'll put links to all of Haniel's socials in the show notes at Customery dot com slash zero two five. Thanks for listening to the show. I really appreciate you. Appreciate all the feedback. I get the reviews and the comments. Keep them coming. See you next time on the show. Until then, keep sprinting.