Defining requirements for complex Power Platform apps with Hamish Sheild

Hamish Sheild: [00:00:00] And I was like, how am I going to get these requirements out in a way that I understand them, my employee understands them and the customer as well? 

Neil Benson: Welcome to Amazing Applications, episode 120. I'm Neil Benson from Customery. Thanks for downloading another episode. It's a cracker with Hamish Sheild from AppRising in New Zealand. Hamish describes his five-step method, called Solution Mapping Framework, in which he takes design thinking principles and applies them to the discovery phase of our projects to help us create that initial product backlog so that we are creating the maximum possible value by creating the right application that solves the most difficult problems in our customer's business processes.

You can find links to Hamish's framework and lots more in the show notes at https://amazingapps.show/120. 

Hamish recently participated in my Winning Agile Projects masterclass, where I help Microsoft partners qualify, pitch, propose, estimate, and contract agile Dynamics 365 and Power Platform projects. It's a five week program with five to 10 sales, pre-sales or delivery consultants. And I'll be running more masterclasses for Asia, US and European time zones later in the year. Find out more and apply at https://customery.com/winning. 

 Let's meet Hamish shield and find out all about his Solution Mapping Framework. 

Neil Benson: Hamish, welcome to Amazing Applications. It's great to finally have you on the podcast. You're a guest I've wanted to bring him [00:02:00] on for such a long time. It's great to finally have you on the show. 

Hamish Sheild: Thanks, Neil. Thanks for having me. It's um, I'll be able to listen to of the podcasts and so great to on the show and, and, uh, participate.

Neil Benson: I wonder if you could take a moment just to introduce yourself for the Amazing Apps audience and let us know are, where you're from and all about your history with business applications. 

Hamish Sheild: Sure. Thank you. Yeah. So my name is Hamish Sheild. I'm based in Auckland, New Zealand, and I have a small consultancy company called AppRising and we specialize in, in the Power Platform, uh, mostly around helping organizations build their own apps and automation on the Power Platform. So, you know, helping them with the strategy, the governance, you know, CoE toolkit and, uh, also, uh, I guess design processes and how to, um, I used to do that hard stuff upfront in terms of designing an app, before you go away and build it. So making sure you get the right licensing, requirements, and that the right components, um, all put together. Uh, yeah. 

And so in terms of my personal life, um, Uh, I've got two young kids. So I guess between that and work, everything's very busy, loves to go kite surfing. And, um, 

Neil Benson: Oh, cool. 

Hamish Sheild: get a little bit of a downtime, but that's not very often with these two kids and a full-time job. Yeah.

Neil Benson: And for our audience's benefit, let us know what you had for breakfast this morning. 

Hamish Sheild: For breakfast, uh, morning it was museli with, um, coconut yogurt, cause I'm dairy free and, and some blueberries, which is pretty standard for me. And some coffee. Of course. Always coffee. Yep.

Neil Benson: Nice and healthy. I really miss my muesli. I'm staying with my parents-in-law on while my house is being restored and I'm just on Weetbix because it's so much easier than 

Hamish Sheild: Oh. 

Neil Benson: mixing own muesli in their house. So yeah, miss it. And tell us, out of the portfolio what's your Microsoft application?

Hamish Sheild: Yeah, this is a quite interesting question. Um, [00:04:00] at the moment I'm really into, and I don't know if it's an application, but it's within Outlook and I use Outlook on the Web, um, and you can change it to a view called Board View. And it's basic. It's incredible. Also what you've got is a calendar and then you can stick other kind of widgets on it. So I've got a calendar. I've got my to-do I use Microsoft To Do so I've got my to do list. got my flagged emails and a flagged to come back to later. Um, I've got some time zones, you know, like we always, we're working with the guys and, um, you know, I guess in Seattle and stuff, right. So reviewing 

Neil Benson: Yeah. 

Hamish Sheild: is.

I got that up there. So it's, uh, and notes and all sorts of things. It's a board where you've got is a widget, so you can drag around and it is kind of like my homepage for the day. It's pretty cool 

Neil Benson: Well, I'll check that out, yeah.

I have experimented with a new app recently called Motion. And it's a productivity app that plugs into your calendar. And what it does is it finds a time in between meetings and takes your to do items, prioritizes those, and puts them onto your calendar. 

Hamish Sheild: Well, 

Neil Benson: you'd ever need to shift a meeting, it'll reorganize your to-do items, based on the priority. And then it will, AI algorithms will run over your history to figure out how much you can really get done compared how much you think you can get done and, you know, fill up your time with all those things on your backlog of tasks that don't necessarily have a scheduled time on them. It looks really cool.

So I'll have to experiment with that. Let you know how that goes.

Hamish Sheild: And it's very cool. Yeah. 

Neil Benson: Uh, so Outlook Board I'll have to check that out as well. 

Hamish Sheild: it out yet, man. It's it's the calendar. And then you just, at the top, we've got view. You can view different versions of calendars and then it's, it's a board. 

Neil Benson: There you go. 

Hamish Sheild: I was playing around and it's pretty cool.

Neil Benson: Awesome. 

I was really fortunate to join one of your training sessions recently, where you were introducing us to your Solution Mapping Framework. After that it was just dying to have you onto the podcast, cause I thought what you were teaching people and the framework you put together, uh, was really pretty innovative.

You borrowed techniques from a few different places. And I think, um, a, there's a few of us in the community, [00:06:00] maybe you and me and Dani who, who aren't just teaching people how to build applications from a technical point of view. But it's how we build applications as teams, as collaborators you know, I love people at the leading edge of that sharing their knowledge. And I thought that session was awesome. So I've dragged you on here to maybe share that with our podcast audience as well. Can you tell us about your Solution Mapping Framework?

Hamish Sheild: Yeah, you. So I guess that's the smallest thing that just comes out of necessity, right? In terms of, you know, a head, I mean, I've, it's something I've kind of bundled together. Lots of learnings. Um, I guess across my career and some training I've done and it's kind of a bit of bias around design thinking as well.

A lot of elements of that, but essentially, um, couple of years ago, I started working with a client who. Had an old access database. Um, and they wanted to turn that into App, right. To modernize it. And basically. Probably 20 years between been like one guy, he was he's about 80 now. So he's, you have a risk factor, but he'd been building it for, for 20 years and just adding on stuff as they went.

And, um, this client, uh, basically got whatever they asked for. He just added onto the thing. So you can imagine that 20 years of just this guy tinkering with his ex started bias was the complaint medicine. So. Uh, I remember sitting in a phone call, um, and, uh, with a, with a client and he was sharing the screen and show me what the app does.

And I was just freaking out in terms of like, how am I going to turn how I want to take this monolithic app and put it into Power Apps, but not make it as clunky and as hard and difficult to use as it was in Access. Um, and so, and then also at the time I had a, um, uh, an employee working with me as well, and we were going to do this together.

And I was like, how am I going to get these requirements out in a way that I understand them, my employee understands them and the customer as well? And, I guess it's just [00:08:00] so overwhelming and there's so many requirements, right? So I had to have this way of drilling down into it and starting at a high level and an easing my way into it.

And so this is where this is going to solution mapping framework came from where. Um, yeah, I guess these step-by-steps that I go through to simplify the whole process of gathering requirements. Yeah.

Neil Benson: Right. So you can't, you can't, you have to extract the schema and, uh, recreate it in Dataverse? That's not gonna cut it. 

Hamish Sheild: Yeah. I thought I saw that, um, they've released the, you know, the, whatever the upgrade path recently, but I don't, I mean, it was such a mess. There's no way I would've upgraded like that. So we started from scratch. 

Neil Benson: There's going to be a lot of Access databases that are like that. They've got a long history. No great design behind them. 

Hamish Sheild: Yeah. 

Neil Benson: having a method that extracts the table structure and imports in into Dataverse is not going to get you too far. 

Hamish Sheild: No, no, especially. Yeah, especially when people don't design it and they're not made it, we headed off a full data remodel as part of it as well. It was just, it was a nightmare, but.

Neil Benson: So you've said that your, um, so we should mapping framework as suitable for complex projects or complex applications. How do you define complex? Is there a certain size? Is it the number of users? Is it the number of tables? What factors make up a complex project? 

Hamish Sheild: Yeah, very good question. Um, and so I think complexity for, for me, it's not really around, um, I mean, yes, I complex project as, you know, maybe have a complex data model and heaps of tables and a lot of data, and that does make it complex. But I think it more from like a, a person's perspective in terms of do in a and someone who's trying to design a solution, um, how familiar am I with the customer's business processes and how complex are those and how to unpack those? Is kind of how I would describe complex. And so I think, you know, when I did that training session, Uh, a while back, I talked about, you know, coming from a Dynamics background when you're putting together Dynamic [00:10:00] Sales or Customer Service, you kind of know those processes, right? And so I call that not complex at all, cause cause personally I know them quite well, when you come into, um, you know, a completely new business in a, in a new business process and you don't know what's going on, I would consider that complex. So it's kind of depending on the person themselves and your experience and your background as well, I think. Yeah. So when I'm talking about using this framework for complex, uh, solutions, I guess complexity, in terms of trying to distill these requirements down to something that's understandable.

Neil Benson: I wrapped up a $50 million project deploying Dynamics 365 Customer Service it had about a hundred project team. That was fairly complex. So I think, yeah, it's a point of view, right? How many processes are there? How many users are in different sets of requirements are involved and they might have data. And lots of things make it a complex project. 

Hamish Sheild: Yeah. 

Neil Benson: Do you prefer those or do you prefer simple projects? Would you rather get in and out in a couple of weeks? Do you love getting your teeth stuck into big, complicated applications? 

Hamish Sheild: Yeah, I think I'm not a fan of like big monolithic kind of projects that go on forever. Um, this one here, um, it wasn't complex in terms of, it's only got a handful of users, uh, not a lot of data, but in terms of like the business processes the data model it was extremely complex. And, um, you know, for them, you know, things on, um, the key things for like, you know, very complex data model, they wanted to better visualize everything. That data integrity was very important to them. And so to have visibility of these data of data across a multiple tables and joining all that together, um, is kind of, you know, pretty fun in model driven apps, right. So we did a lot of embedded canvas apps. So I quite like. Um, his is short, sharp engagements, and we chunk this down into manageable chunks, right? So every couple of months we rolled out a new feature for them. [00:12:00] Um, just to make that kind of monolithic project a bit more manageable.

Neil Benson: So tell me about the steps in the solution 

Hamish Sheild: Okay. 

Neil Benson: mapping framework from memory of that training session you ran, there was or six steps. do those. 

Hamish Sheild: Yeah. So, um, there's five steps. And so basically kind of starts off with like call it interview and observation. So it's kind of, if you go to the design thinking, our way of doing things, this is kind of like you're, you're empathizing. So, um, typically that involves what I recommend. Well, when you're gathering requirements, you can often sit in a room and discuss them with your stakeholders.

Or what I prefer is you go out and you observe them doing their work on their site, or them using their current Access database application and how they use it. And you find that you'll pick up more, um, You'll put your pick up a lot more than you would when you just ask some questions.

And if you ask someone to describe their process, because they're so ingrained in it, and they know a day to day, they're not going to tell you every single little step, but if you see them do it, you'll, you'll pick up a lot more. So that's the first one. 

And the second one, um, I kind of start drilling down into more details, uh, customer journey maps, sure people will be familiar with.

Then I kind of go from there to swim lane process diagrams. Going a bit deeper using, um, those swimlane process diagrams to put together a product backlog and then user stories. And they, all those kind of five steps all of work together. I mean, you go from one to the other and you kind of gradually get lower and lower until you've got a backlog of user stories.

We requirements, which is the kind of the, the end goal, right. Is to have that their backlog of requirements.

Neil Benson: Well, that's the starting point uh, for, the development teams to swoop in. And, uh, so building features, right? 

Hamish Sheild: Exactly. Yeah. Yeah. So this has its, it has its place in a project, right. It's kind of the start of it all.

Neil Benson: I love that idea. I haven't done it enough and that's getting out the users are working seeing them in action in their day jobs. Who's doing that [00:14:00] observation. I did get a chance a couple of years ago to visit, for one of the superannuation firms here in Australia was just visit in their contact centers.

I remember asking one of the call center representatives, if a click to dial feature would be useful, you know, just here, there's a customer's phone number and you need to give them a call back, click on the number. And that would pass it through to the phone and start to call the customer. She said, nah, I don't think so.

We just type it in. Second phone call she made, she got the wrong number. Your example, if I recall, was you were visiting a construction site where they were pouring foundations or something, so that's a bit more exciting than visiting a contact centre. 

Hamish Sheild: Oh, does he have, for sure, like quite a lot, those ones where, I guess for me, I quite like those Power Apps. When you're making, say a canvas that's, you know, for a phone or whatever to be used out on site, you know, there was an engineering firm and then, you know, um, Done things, uh, an app for, uh, for, um, avocado orchard.

I've looked at apps for, you know, manufacturing, someone in a, a manufacturing site and they've got to scan different barcodes and stuff cause they're mixing chemicals together. So those, those are always really interesting to get outside and see how they actually do it. Um, and those sorts of ones you do pick up, I think a lot more about how they do that and what their processes are and what they find annoying compared to, if you sit in an office with them and just had a chat.

Neil Benson: Maybe I'm scarred from my first experience is way back a CRM 3.0, we built a, a mole clinic screening application. So they took a photograph of your skin and any suspicious looking moles, they would take our very high resolution, bright light, and to determine whether it might be cancerous. We built the application and then UAT that the nurse that I showed the application to ask me to strip down to my underwear.

So that was a really good way to see the application in use. But yeah, I'll have to think that since then. Uh, so after. Uh, solution observations. You're making lots of notes. [00:16:00] You're observing people in their, in their work. Then you're building these journey maps. Can you describe a journey map? Cause I sometimes see journey maps and they look a lot like a process diagram.

W what's the difference in your mind? 

Hamish Sheild: Yeah. I think it's journey map is a pretty loose term, right. This is a lot of different flavors out there. Um, I think in terms of the difference between that in a process diagram is that like a journey map probably has more of that kind of human elements to it. So the way I've do, um, journey maps, do you have a process along the top of these are some steps you needed to go through and then you write less down or what are the actions, what are the person doing and the steps, then you consider other going the extra things around. I mean, that, cause that would be kind of what your business process diagram is, right. But then what you consider the of journey as what are the things they're interacting with? So they're interacting with some systems or other people or a spreadsheet or whatever then you consider what are the pain points.

So, so, and, and this step of the process, when they're doing these actions, when they're interacting with these things, What is really painful for them? And then the last kind of, um, row of, uh, journey map is, the opportunities. So based on those pain points, what are the opportunities we have to make their lives better with a Power Platform solution, right? And so that's kind of that's yeah. The difference between that and a business process diagrams a lot more to it, and you're thinking it from more from that kind of human element.

Neil Benson: And so those opportunities for making life better, would those then feed into a business case that would be your list of advantages or things that you're going to offer, and that maybe have some kind of return on investment in them as well? 

Hamish Sheild: Yeah. So typically as part of this I guess what I shared in this training was what we kind of did this as a workshop, right? And have people putting down their ideas on this journey map and ideas of what the opportunities are. And then part of that has kind of prioritizing those. So what's going to provide the most value to the business.

And a lot of times those opportunities become like your features for your, your app [00:18:00] going forward. So this is kind of leading down into like, uh, our backlog.

Neil Benson: Yeah, Okay. and from there it's then you have , you call them swim lane process models, where I guess it's just a business process diagram, you have clear illustration of who's doing what, how the systems responding to people's actions, that kind of thing.

Hamish Sheild: Yeah, I guess the way that I do, and I guess business process diagrams again, is another one where people have a whole different ways of doing it, right. But I like to have a very well defined between but if you've got to have people, as you know, some of us, you have a process diagram, it's just systems listed and not the people involved.

So I kind of listed both and it's kind of two sections. One is people on the top and there may be multiple people involved and they all have their own roles and they will have their own swim lane. And then below there the systems as well, and they have a swim laneeach. Typically I can I map out like that.

Kind of hard to describe over a podcast.

Neil Benson: Yeah, Um, well, you have got a great blog article and we'll include a link to that in the show notes, for those who are visually oriented it's in there. 

What kind of level of detail do you go into? A lot of business processes there might be a decision that somebody needs to make, and it could be four or five outcomes in different segments of customer or different sizes of, of applications something you need to evaluate. And are you going to illustrate all those different options on this business process flow? Or you can just kind of try and keep it at a relatively high level? What level of detail do you think is appropriate there?

Hamish Sheild: Yeah, and this this is a such a hard question. And, and even, you know, talking with clients at the moment around, business process diagrams, how detailed do you get? I mean, I want you to do that for a while, yeah, I guess you'd get a sense for it. I kind of start off with don't, don't be too, you know, don't be too detailed and I think just enough information because at the end of the day, what you want to do is to use these diagrams that I built as part of this, um, process mapping is to communicate back to the client or your stakeholders, you [00:20:00] know, what the solution is in subsequent kind of communication tool, right? If you have too much detail that they're going to glaze and not pay attention. If it's not enough, they're not going to understand that. So that's such a hard balance, but I 

Neil Benson: Um, 

Hamish Sheild: it's the way I look at this as these diagrams aren't like, you don't just draw the diagram once and then leave it as the design. It's you keep, you know, re-iterate on it and you keep changing and modifying as you go. And even in, through when you're building the apps will always come back and re-touch-up those diagrams to kind of show, you know, current state or as, you know, as built.

Neil Benson: I was going to ask you business process analysts quite often like to do that: as is, and to be different sets of process diagrams showing the current state and the future state. Do you think that's useful? I've always preferred to focus just on the future state... 

Hamish Sheild: Yup. 

Neil Benson: This is where we're going to. Unless you're the organization who's already made the investment in today's processes and mapping those out, I wouldn't do it just for the sake of the future and designing a new application around run the future state processes. Have you found a lot of value in doing both? 

Hamish Sheild: Yeah. Sometimes. I mean, I'm probably with you. I definitely you're more focused on the future state. And I think this is where in this kind of mapping process, I've got the, the journey map is as really like I said, the higher level business process documented, but I that's kind of at current state. So it's, what are their current pain points and what are the opportunities to move forward?

And then when I do the business process diagrams, it's always future-focused. But sometimes the current state does help. If, if your processes are really, really complex and it's really hard to understand, I think sometimes doing a current state does help kind of educate people to moving forward.

But typically I try avoid if, if, if, you know, you don't need them. 

Neil Benson: And so after the business processes have been laid out, customers agree that yes, that's, that's how crazy our current world is. And it's always crazier than they thought it was, in my [00:22:00] experience. Whenever they discover they might have rework or waiting that's going on or approvals that need to get made, why things always take longer than expected. So they've, they've learned all of that and you're then translating some of those requirements, you talked about the opportunities and pain points earlier, now you're ready to start writing some user stories. 

So the same question applies. What level of detail is appropriate for our user story at this stage? Are you going kind of feature level? Are you going to split them down into smaller stories later, or are you writing quite small implementable stories straight off the bat? 

Hamish Sheild: Yeah. So this is kind of where, this is what I guess, well, I call it the solution mapping process or framework, right? Because this is where I was and I was struggling a lot. And I see other people struggling with this, as well as how detailed do you go with your user stories in terms of writing them out?

And so what I've found is if you can kind of get the level of detail, right, for your business process diagram, the next kind of side, my rule of thumb is each step in your business process diagram is a user story. And then usually a business process will either be like a feature or an epic in your backlog. And so this is my way, getting my head around. Okay, here's my end-to-end business process. And then it's got 20 steps. I'm going to have 20 user stories. And there may be one feature. And then I might have another business process for another feature and roughly works out like that. 

And I think that's over the years, I think, yeah, seems to be about, I feel familiar. It feels about right. In terms of giving and having enough detail for the developers that they can go ahead and, you know, and do their, their bits.

Neil Benson: I love those kinds of things that you build up with experience that, it's not a rule, you can't say there's 20 steps, there must be 20 user stories. Life's not that simple. But it's a good heuristic to use once you've built up some experience and you've got a few opportunities to see this in practice. You go well, yeah, okay. So there's 20 steps in a business process that could be 10 to 30 user stories, that kind of range, but 20 user stories is probably fair starting point. 

I've seen lot of user [00:24:00] stories where there's a nice description, there's a few acceptance criteria, but then there's pages and pages of test cases and scenarios and all sorts of things attached. And it becomes like a 10 page requirements specification, which just gives me the shivers because those things are now hard to change, and hard to update, and hard to split, and hard to combine them. It makes us a lot less agile than just keeping it nice and short and sharp. How much detail do you like to see in your user stories? 

Hamish Sheild: Yeah. I'm not, I guess I'm not a user story expert. But I F for me, I guess I got a couple of bug bears with user stories, right. And one is who don't write it as a proper user story, you know, as the, as want so that. It just drives me crazy. And the amount of time people live. 

Yeah. 

Neil Benson: a stickler for that. 

Hamish Sheild: And the people I leave out the, so that, you know, the reason why as a requirement just yeah, that's, um, bugbear of mine and then, yeah. And then not writing acceptance criteria, I think, you know, the key things that doesn't have to be a lot of detail, but these just have a well-written user story and at least some sort of acceptance criteria, right. And, and I don't think we need to have heaps of documentation. And we link those user stories back to that process diagrams and that kind of really forms the bulk of the documentation that I do.

Neil Benson: Here's something that I've done to focus on that value part. Is instead of as a I can so that, flip around and go, "So that we can pour concrete foundations accurately every time, I can follow a checklist." 

Hamish Sheild: That's pretty cool.

Neil Benson: So that puts the value upfront. And then I don't write the persona where they, whatever they, you know, as a user role, I use a tag for that because I quite often find there's might be more than one type of user who would appreciate that feature.

And so I just look in the tags and go, oh, this is for a concrete foreperson and this is for a site manager, whatever roles are. And there might be a couple. Um, [00:26:00] 

Hamish Sheild: Yeah, that makes a lot of sense. Yeah. I'm working with a client at the moment and going through this, can I use this story process and, um, they're yeah, sometimes they've got as art and in about five different roles listed and yeah, we have thought about using tags as well, just to make it easier. Yeah. Good tip...

Neil Benson: What's next? Do you typically then just build a quick prototype and off you go, or are you doing estimation on the back of this and where does this fit into a sales process where a potential customer might be evaluating you and other Microsoft partners?

Hamish Sheild: Yeah. Yeah. Good. All good questions. so I mean, typically this is kind of, like I said, that. Overweight or I guess if you're waterfall, that's kind of it, their requirements gathering stage efforts, you know, agile, it's kind of to help form that back log. So I think this is like good consulting work and quite good, you know, strategic work, right. And so I, I just need to give you paid for this sort of exercise. And, but then at the back of it, right, you would come up with some estimates. And so, because you've kind of built up this backlog and you've got some user stories you can estimate off of that. I think, you know, just having, doing your course recently on the Winning agile projects, some good tips in there around how to take a backlog and put some estimations together.

So, um, I think. This process, there will kind of dovetail into, into some of that. If you're at that stage of having to, to estimate for your clients

Neil Benson: I could great framework, Hamish. You've got a great blog article on it to back it up. What's next? How can people find out more about it? 

Hamish Sheild: Yeah. So definitely go to the blog article I did as you know, I ran a couple of sessions live, I didn't record anything. I'm planning on recording once I get a little bit of time. Cause it's something I want to, I want to share with people, right? And I think people, some of the feedback I've got is that they can read the blog, and they've come to the one hour training session, it's still, there's, there's quite a lot in there. And so, um, I quite like to kind of break it down and show people kind of step by step, but, um, yeah, people [00:28:00] could go jump onto the blog and then they want to follow me on LinkedIn or whatever. And, um, uh, hopefully announced some sort of recording at some stage.

Neil Benson: Great. So I'll direct people towards that. It's AppRising dot co dot nz. 

Hamish Sheild: NZ, yes. 

Neil Benson: Okay. good to be a link to the actual article in the show notes for anybody wants to check that out. 

I just want to switch gear a moment. You mentioned right at the top of the show about centers of excellence, and I am a complete novice when excellence. I'm quite often the first Power Platform Dynamics 365 project team a customer has ever encountered. And they're planning lots more. So they're thinking about a center of excellence, but I've departed by the time that those kinds of things are being considered. What is a center of excellence? And how can customers go about creating one?

And what type of customers suit a centre of excellence? 

Hamish Sheild: Yeah, good question. So, the way I define a centre of excellence is I guess, a group of people and tools and processes to help manage your Power Platform. I'm doing quite a bit of work in this space at the moment. Cause I guess we're around enabling people to build things on the Power Platform, but you bet, Hey, got to have a nice stable, secure manage, you know, manageable platform on underneath.

And I think as we know, if you have you let the Power Platform go unmanaged, you can have apps for all and technical debt and stuff everywhere. Right. And so a centre of excellence is a lot around managing that and making sure things are compliant and safe and secure, and that's kind of the Iceland on the governance side and then on the nurture side to it as well.

So how do you educate your, your makers who, you know, typically, you know, people have makers in the business who aren't technical, don't have a technical background. Um, and so they're not going to do things right all the time. And so you've got to help them, give them some guidelines, teach them what, you know, what is, what are these practices, that sort of thing.

So that's what a centre of excellence is about. And so I help, I guess, organizations kind of define what that kind of, what [00:30:00] that looks like, how do they resource it? Uh, and then there's obviously a bunch of tools in terms of the, the Microsoft CoE Starter Kit. Um, which is awesome by the way. It's, there's just so much in there, but they're also going to gives me a job because it's, um, yeah, cause it's so much to it. 

Neil Benson: It's not a double-click install? 

Hamish Sheild: No, it's to the part, like what sort of organizations is that for? I guess in terms of the, the toolkit probably larger organizations, right?

There's quite a lot of maintenance to, you know. It gets a new release every month. Which is awesome. So that's, every month it's getting updates and bug fixes and everything, but that's quite a lot of maintenance in terms of, you got to take the solution from GitHub and put it back into your environment and regression testing and stuff. There's quite a lot behind all of that. So it's usually those kind of large organizations have got, you know, hundreds or thousands of users, multiple environments, that sort of thing. 

Neil Benson: Do you have have a big community of citizen... I'm not sure I like this word... citizen developers building applications, or if you just had several IT groups or professional developers in different business units, departments, building applications. Is it useful even for professional developers as well work in organizations that have a center of excellence? 

Hamish Sheild: No, it's very much, I think, uh, Microsoft are pushing that kind of fusion dev team, right. In terms of your, I call it citizen devs or makers or whatever, and then your pro devs as well. So centres of excellence is very much around bringing all those together. And so part of, I guess, defining how centres of excellence work as there's different models for a centralized sort of unit where you have your pro devs on a centralized team and they get, you kind of do work for the business units, or sometimes you see where you have business units and they'll have a pro dev in each business unit and they help the people in those business units make their applications.

So there's different models for that. And Microsoft's got quite a lot of documentation, um, around that and guidance as part of the CoE kind of offering. 

Neil Benson: It sounds fascinating. I'd love to get [00:32:00] into some of that. Sounds good. 

Is there anything else I should've asked you about that I haven't covered Hamish?

Hamish Sheild: I don't think so. Yeah. I think if you've done a great job interviewing today,

Neil Benson: Thank you very much. 

Where can people find you? Have you got any community events coming up that you're presenting at and people can get in touch and sync up. 

Hamish Sheild: Yeah. I help co organize the Auckland user group. So this is the Dynamics 365 and Power Platform user group here in Auckland. So we run a once a month and it's on, on, Meet-up. I haven't actually got any other things planned coming up, but, um, if you want to reach out, uh, LinkedIn is always the best, best channel for me.

I'm usually pretty, pretty active on there.

Neil Benson: Great. Okay. Well, we'll make sure we include a link to your LinkedIn profile.

Well, Hamish, thank you so much for joining us on Amazing Applications. We learned lots about your solution mapping framework, centers of excellence and lots more besides. Really appreciate your time. 

Hamish Sheild: Uh, thanks, Neil. Thanks so much for having me on and getting me to talk about my process mapping framework. I'm looking forward to sharing with other people. So if people want to have a look, um, you know, have a check it out on the blog. 

Neil Benson: Great stuff. Thanks, Hamish. 

Hamish Sheild: All right, thanks so much, Neil. 

Chike Eduputa: Thanks so much for listening to the amazing apps podcast you can join the show's mailing list at https://AmazingApps.Show you'll Get a personalized welcome video from yours truly and a notification when there's a new episode available there are also shortcuts So you can follow the show on all major podcast players and you can follow amazing apps show on Twitter LinkedIn YouTube Instagram and Facebook You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an amazing apps t-shirt visit https://Amazing.Apps.Show Thanks again for listening I really appreciate you Until next time take care and keep sprinting[00:34:00]