Six challenges of enterprise Dynamics 365 projects with Andrew Bibby and Dani Kahil

Neil Benson: [00:00:00] 

Hi, I'm Neil Benson from Customery and you're listening to the Amazing Applications podcast where we help you build amazing, agile Dynamics 365 and Power Platform applications. I've got another amazing interview by Dani Kahil for you in this episode. It's number 116. This time, Dani is chatting with Andrew Bibby.

Dani has been a guest a couple of times on the show and he was the host on episodes 109 on 112. He's an independent consultant and an online trainer specializing in requirements analysis and solution envisioning. Andrew Bibby is one of the founders of Proximo 3, a Microsoft partner based in the UK. And they are both Microsoft MVPs for business applications. 

Today, you'll get to hear them discussing a pivotal project in Andrew's career in which he shares his advice on the approach, on managing requirements, coordinating multiple teams, and how to ensure the successful adoption of your new business application.

You'll find show notes with a transcript and links to Andrew and Dani's resources at amazingapps.show/116.

Just before we get started, I'd like to congratulate several Customery Academy students who recently completed my Scrum from Microsoft Business Applications course and achieved their Professional Scrum Master certification with Scrum.org. They're Max Zakarov from Empired and then from IBM were Jared Reynolds, Abe Potten, and Anna Pienaar. Congratulations, and thanks for being part of the Customery Academy.[00:02:00] 

Dani Kahil: All right. Good morning. Good evening. How are you, Andrew? 

Andrew Bibby: I'm good. Thank you, Dani thanks for having me on. 

Dani Kahil: Oh, you're welcome. Thank you for making the time. I know we are in different time zones, so it's a little bit challenging sometimes to find the right time to discuss things, but thank you for making the time.

Andrew, before we get started, would you mind giving a quick intro about yourself to our audience? 

Andrew Bibby: Sure. Yeah, no problem. So my name is Andrew Bibby. I'm a founder of a company in the UK. We've founded a new company last year, Proximo 3 with some other Microsoft MVPs in the business application space.

I've been working with Dynamics 365 and Power Platform for 15 years. It's just gone 15 years. And that's all I do. And all the projects that I've worked on have been about that. So, been through lots of different scenarios and learn a lot along the way as well. And actually that helps me and helps us in Proximo deliver the services that we deliver today, which is more around advisory work on projects and bringing all that experience to projects where they don't necessarily have a lot experience people on, on the project. So that's where we come in. 

Dani Kahil: Wow. Amazing. So you started a year ago you said?

Andrew Bibby: Proximo 3? Yeah. Yeah. It's a, we started in February. We've just done our first year anniversary. That's that's good. It's going really well. It's been different because I was an independent consultant before that, and we were all independent.

And we've come together and it's been a learning curve. I'm not going to lie around things like, you know, doing sales, pre-sales and things that I haven't necessarily got got into before. So it's not just about doing the job anymore. It's about actually running a business as well. But it's been very interesting and varied, and I'm never doing the same thing every day, you know, each day is something different. [00:04:00] More different projects or different roles or training, or like I say, pre-sales or project work. So yeah, I'm loving it actually. 

Dani Kahil: Wow, amazing. I've seen a lot of, you know, posts and kind of events that you guys are running. So it looks very interesting. 

Andrew Bibby: Oh, thank you. 

Dani Kahil: So Andrew, you here to discuss one of your project that you had in the past. So effectively the format that I would like to explore a bit with you is, you know, pick a, a project that you had in the past that where you have actually learned a lot from it and kind of go a little bit more into the details of that project, right? So we'll have a conversation about, you know, how the product went and then drill down to the challenges and the lessons learned from that project, right? So what kind of project did you pick for us today? 

Andrew Bibby: So I'm going to go for one of the biggest projects I've worked on. And I actually worked on that project for three years. Maybe a bit more actually, but it was a big multi-phase, multi workstream project, business transformation project for a financial services company in the UK. And it probably the reason I chose it is because I generally work on smaller projects, enterprise projects, but generally smaller.

But this was one of the most fun projects I've worked on, to be honest, even though it's very difficult as well. It had lots of challenges. But I work with some of the best people I've worked with in my career. And I learned a lot from them. And yeah, it's kind of one of those really formative projects to work on, you know, learned a lot, but across different areas. And also, you know, obviously I was able to fulfill my role as well. And I thought I did a good job of that too. So yeah, it was very rewarding from that perspective. 

Dani Kahil: So what role did you play on that project, Andrew? 

Andrew Bibby: So I was I was working with the end client as an advisor because they've not done a Dynamics 365 project [00:06:00] before, or worked with Power Platform and they had they had to go through a partner selection process. They just felt out of that depth, you know, uncomfortable with, with the information that they needed to know. And so they brought me in, because I'd been working with partners for the previous 10 years or so. And yeah, it was the first project I'd done actually on the customer side. I'd been working with partners previously. And so that was an interesting switch. They had an implementation partner there. They had two actually, I'm trying to think maybe it was three. But yeah, so you know how these big projects go sometimes. And yeah, I was, I was basically in between the customer and the partner to try and grease the wheels, try and make the customer went of what the partner needed.

And, you know, the, the in particular we'll come onto, you know, talking about requirements and you know, the information that the partner needed. But also vice versa, what the customer should expect from a partner and also to be a quality assurance that actually they were getting a good, good service from that partner as well.

So, yeah. It came at the right time in my career where I had enough experience of a few different areas where I could fulfil that role. But yeah, not without its challenges, but it also, like I say, very rewarding. 

Dani Kahil: Already the, the, the structure of the team, like, treat two or three partners already and you in the middle, I can see already, you know, the challenges coming, coming with such a role. Can you also advise, so when did you join? At which part of the project that you joined the beginning? 

Andrew Bibby: Yeah. Luckily I was a good question because sometimes you get brought into a project halfway through and it's kind of difficult, you know, to, to have a good impact. So yeah, I actually started the, they were very, the people that the end customer were very aware that they needed help early on. And I came in just after they'd started a proof of concept phase. This is [00:08:00] going to be a big project, multimillion pound project. And so what they wanted to do is at the start is run a six week proof of concept and bring a team together to prove the technology, the ways of working. They've not done an agile project before.

We'll come in and talk about project methodology, but so there was lots of things that they wanted to see if they could work in a certain way and whether their technology, whether Dynamics was suitable a suitable platform, whether they could customize. In the way that they needed, whether they could work quickly, you know, all these things were very new to them.

So they ran a six week pilot, proof of concept, and they came in at about week two, I think. Yeah. So we we went through that. It was very successful. We had a very close knit team, even though it was probably 20 people. And yeah, went through the process. And that was the, also the, the next phase for the project to actually get the go ahead.

Yes, we can work this way. And also this is kind of budgets that we're looking at and it helps the partner estimate the work that was involved and and also for the, the end customer as well for them to understand the work involved. So yeah, I came in at that point and then I worked all the way through proof of concept and then into the different phases of the product all the way through go live, actually, which didn't happen. It was about two years, two and a half years. So you have nice big projects. And yeah, and then I did some work afterwards with the customer to help upskill their teams internally so that they could maintain the project after the partner you know, gone off into the sunset. So yeah, it was the whole, all the way. Yeah. That's every stage which was great. 

Dani Kahil: Yeah. That's great, actually. I found the most rewarding project I had in my career, the ones where indeed I could step in at the right time and kind of go through the whole project and almost, you know, also deliver the project and kind of [00:10:00] transition it.

So in term of technologies and applications, can you give us a quick tour? What, what is it about? 

Andrew Bibby: So, they were introducing the end customer, wanted to replace an existing system that they had for managing customers and also managing their sales pipeline. So very typical kind of CRM project.

And they also had a number of on-premise systems for things like policy administration and quoting, and so financial services, lots of legacy systems involved. And so yeah, Dynamics 365 Sales was the platform of choice and also Customer Service was in there as well. And customize that to build out a fairly extensive data model ended up being something like a hundred custom tables and to support their sales process. 

So just take a step back. What they were trying to achieve was was to they did some analysis of their sales process and they realized the people, the advisors that worked for the company, worked in different ways and there was a lot of administration involved and a lot of generating documents and, and they calculate that the average time to take a customer, one of their customers from initial discussions through to selling a product was about 13 hours, 12 or 13 hours. And what they wanted to do is obviously reduce that time spent because they realized that a lot of that time was spent on administration. And, you know, like I say, creating quotes and documents and things like that.

And if they could reduce that and automate some of that, then obviously, better customer experience. And also more time for these highly skilled individuals to talk to customers, you know, so a real benefit there for both the customers and for the, the business, cause they could see more people and therefore sell more products, you know? So it's a, quite an easy justification [00:12:00] for the project. 

They were aiming for basically having the amount of time taken to get one of their customers from the initial discussion all the way through to selling product. Higher profit, more people to see everything else, you know?

So yeah, it Dynamics 365 in the cloud. I mean, which all of the projects I've worked on in the last five or six years have been in the cloud, but with integration to on-premise systems and so a fair amount of integration involved and all of that legacy estate and also some infrastructure built out in Azure, as well. Azure Functions and Logic Apps and also data storage in Azure as well.

 I guess fairly typical for a larger side project these days, you know, there's Dynamics or there's Dataverse and there's some Power Platform components, and then there's some Azure stuff and there's probably some on-premise stuff in there as well. So, you know, the solution architecture was not atypical.

Dani Kahil: Thank you. Yeah. Nice. So you were mentioning agile at the beginning. So how did the journey go? Was the, was it new for them or had they experienced in agile before, or?

Andrew Bibby: I think this was quite a learning curve for the organization and for the people working on the project as well. So yeah, that was like I mentioned, it was part of the original proof of concept can they work agile? Can they make decisions quickly enough as a business to work agile? And when you're doing a proof of concept, that is, fairly ambitious in its scope, actually, there was a lot of, you know, a lot of stuff in, in the POC. But you had some very empowered people on the product that could make decisions and that didn't need to keep referring back to other, you know, more senior people. So they were very entrusted to to make the right decisions, which is absolutely what you need.

And so proof of concept worked well. [00:14:00] When it scaled out to from 20 people you know, six weeks, eight weeks worth of work to over a hundred people at some points of the project and multiple work streams. I think there was six work streams across like data migration, integration functional build, business analysis. You know, lots of different work streams going on.

And that didn't scale in an agile way. They tried to work. They try to run the project like that, and they kept hitting mainly the issue was that the business couldn't make decisions quickly enough. And so as a mindset of the organization is very used to long projects, but also lots of analysis upfront, lots of design upfront. But that wasn't flexible enough for how they wanted to work on this project. 

So after some back and forth, and you've probably experienced yourself, some attempts to work agile and then it kind of stalls. And then you have a reset. All right, so what are we going to do? 

Came up with this approach which was more a mix of waterfall and agile. You know, how it is. Which is kind of trying to take the best bits of agile and also some security from doing lots of design upfront and lots of analysis upfront to scope the project effectively resource the project. But then once you've been through that fairly long-winded process of analysis and design, actually running the build and test as agile sprints. 

So yeah, this stick go back and forth for awhile. I wouldn't say it was overly successful. And actually one of the pieces of advice we had very early on which was a little bit, benefit of hindsight, you know, it seemed like, you know, is that if you choosing a project methodology, [00:16:00] go waterfall or go agile. Pick a horse. There's benefits and there's pitfalls to each one, don't try and do both.

And that actually is exactly how it turned out. Doing both was problematic as well because yeah, there was lots of stop start and it becomes a schedule problem then of getting the right people at the right point. You've got lots of dependencies between work streams and they have to start at the right time and finish at the right time, you know?

And so project management, I was going to say nightmare, but it was actually just very difficult to manage from a project management point of view. And I think there were three or four project managers on, on the project attempting to do that. And with the best will in the world, even with some very, very good people it becomes very, very difficult. 

So I would say where I have seen the benefits on Dynamics and Power Platform projects is, is to work in an agile way because the toolset helps you do that. That you can build things quickly. There's not a lot of coding and development anymore. 

But you need people that are experienced in working that way, that can make decisions quickly, that are empowered to make those decisions. You need really good requirements and a process to refine those requirements. So there's lots of things that you need to put in place in order to be able to work in that way. But when I've worked on projects that really have those things, they really hit the hit the road. What's the expression?

Dani Kahil: Hit the ground?

Andrew Bibby: Hit the ground running, not the road. Hit the ground running and are very productive and they can deliver. And application life cycle management is also part of that as well. So there's lots of setup work you need to do, but if you do all that, as I'm sure you've experienced, you can be very successful in working that way.

And so, yeah, that's my preference of a way of working now. Waterfall feels very long-winded. But yeah, not all organizations are geared up [00:18:00] for working that quickly. 

Dani Kahil: Yeah. And agile. Yeah. It's a bit of it. As you said, a bit of a learning curve, I think where I've worked with many companies that try to adapt agile, but it's still. Agile requires a bit of experience as well.

I mean, you know, doing some trainings will help you, but it's really on the ground doing an agile project that I found even myself, that I find myself learning the most right. After one project done in agile then the next one, I kind of understood the concept way better than after just, you know, learning theory.

So I guess that's the challenge for a lot of organization. I guess also product owners. Being a product owner, I've seen multiple times, it's a first for, for a lot of product owners that work with, so they don't really know the best practice. They don't really know what works. What's not. They don't have that experience.

Andrew Bibby: So, yeah. Yeah. Completely agree. And actually something that I've learned on working on agile projects for probably eight or nine years, is that the scrum master, or whoever's leading those teams, they need to be good. If they don't have experience, and they're just done the training course and they're having a go or if they're not proactive enough, if they're not confident enough, then that has a major impact on the productivity of those teams. They're a linchpin. 

So, you know, like you have the product owner and then scrum master has been, they're working in tandem, they're driving things forward. And if you don't have that, and that happened on this project as well. They went through several different scrum masters and a lot of them were not all that experienced.

And you could really tell. You know, with the productivity of the teams that you need to kind of work together as it's, everybody's a cog in the machine, and once they're all working together, you really can be very productive. But if there's something not quite right,[00:20:00] you're grinding the gears together and things start slowing down.

So, yeah. Scrum master, I think that's one of the most vital roles on, on that that team. 

Dani Kahil: Yeah. Yeah, totally agree. So you're talking about requirements as well. Can you explain what was so how was it done in the process, how was your collaboration with the business analyst who was actually doing requirements gathering and analysis?

Andrew Bibby: Yeah. Yeah. So fairly big project, as only as I said. So there was a team of business analysts looking at the different work streams and different areas of the business to do, to do the analysis. So there was six or seven or eight different times. 

From the client, right? Not the partner? 

No, no, actually no partners don't in my experience, they don't really do business analysis very well. Dynamics partners anyway. They're very much more focused on like functional consultants.

But yes. Yeah, the, the, the, the. Brought in a team business analyst, both from the existing business and also contract business analysts which, you know, had some ups and downs, I would say. But they used one of the most important things I think about this project, and one of the things that I learned, is to have a single tool set for managing the requirements all the way through development testing and into production. 

This was Azure DevOps they used and I've really sort of grown to love Azure DevOps. I don't like the name because it makes it sound like a developer tool. And just for kind of building stuff, maybe testing it, but actually does a really good job once it's set up correctly all the way across the life cycle.

Requirements were managed in user stories in Azure DevOps. And something that they really struggled with was it took a while to actually learn to use DevOps properly and set it up properly. And also have everybody up to the right level of knowledge to able to write user stories correctly. The right level of detail for them to be managed [00:22:00] in a consistent way. 

But something that really was problematic is traceability of those requirements all the way through development life cycle. And when you use one tool, you have that traceability, if you're doing it from the start. So you put your user stories into DevOps and you, you have developer tasks, maybe, against those user stories. You have test cases against the user stories. You have releases against user stories. And then you're into production and you can trace the whole thing through. And so, you know, what you initially wanted to develop and functionality you wanted to build is now in production because otherwise, how can you tell?

And a number of times on the project, you've run into this issue of trying to keep track of what's been done and how much there was left to do, because they weren't using the tools properly. They weren't using DevOps properly. There's lots of spreadsheets, and then trying to retrospectively connect development to user stories, testing to user stories.

And so that was a real administration headache. And if you're not doing it from the start, it just causes more pain later on, when you actually do need to prove what you've done and how much it's cost and how far through you are and how much there is left to do. 

So yeah, that was a really big learn that I'm doing in one tool set, whether it's DevOps or something else is just pays dividends all the way through the project life cycle. Not doing it is painful and expensive. So yeah, on bigger projects, absolutely. I'd say you'd need to use some kind of tooling like that. But on bigger projects. 

Dani Kahil: Yeah. I'm a big fan of Azure DevOps as well. So totally agree with you. I worked a bit on JIRA as well for the clients, but yeah, most of our clients use DevOps. 

Andrew Bibby: I've actually worked with JIRA recently. I've worked a few times over my career, but on a project I just finished, they were using JIRA for requirements and, defect [00:24:00] management basically. Yeah. And it was pretty good. I was quite impressed with how far it's come. So yeah. I'm not so negative about JIRA anymore. 

Dani Kahil: Yeah. Yeah. 

Andrew Bibby: Dev Ops just, it seems to tick all the boxes and that's why I think it is poorly named because it does so much more than just manage code and development tasks and tests, you know? So yeah big fan. 

Dani Kahil: So you were talking about user story. How did you manage to make sure that the dev team understood the user story? Did you use some kind of template to run the user stories?

Andrew Bibby: Yeah. So I'm not going to claim credit for this, but actually there was a a really good business analyst, named Jack, who I'm still friends with, who was responsible for doing a lot of the setup work in Azure DevOps and making sure that the customizations that needed to be done to sort of track statuses and those different custom fields that we needed he did all that set up. And that as part of that, we had fairly customized work item templates to make sure you're capturing everything correctly. 

But I would say that I've worked on another big project, actually straight after this where they really suffered was there was a disconnect between the detail in the user stories and what the developers needed. It wasn't so bad on the project that I'm mainly talking about because the developers were altogether. One big team. We sat together. We had lunch together, you know, we spent every day of the week together, which is, you know, the luxury of having an entire floor dedicated to this project in a building. 

 I'd say that's more difficult maybe in these days with virtual working, hybrid working. And that's something that I've seen with other projects. But absolutely it's fundamental that the developers or the functional consultants understand everything they need to from that user story to go and build it. And where I've seen that cause [00:26:00] problems is, you know, the customer who is maybe not very experienced in writing user stories or their business analysts, not very experienced in working that way. And they also don't know that developers need in terms of the level of detail for them to write a bunch of user stories that look okay from a business perspective, cause they are user stories. But then get passed on to the development team. Development team kind of has a go at building what they think the person meant when they wrote the story. And then when you're in sprint, there's lots of turnover of, ah, that's not quite right, and that's not what I meant. I missed that from the user story and development and requirements changing in sprint, which is terrible for productivity. 

And that's exactly the experience that I had was that sprints would just not achieve anything like the productivity and the story points that they were projected, because there was so much requirements churn during the sprint and you need to get all that stuff done before sprint. And there's, there's a number of issues there. 

Having the understanding, like an acceptance process where a lead developer or lead functional consultant is reviewing the stories before they go into sprint. To really poke around the edges because they know what they need. And for them to accept those stories into the sprint and say, yeah, these are ready to go for us. And that really cuts down the amount of questions. You can't avoid it completely, but the number of questions and the changes to requirements, which is another productivity killer in a changing requirements mid-sprint. Don't do it! Just stop doing that!

But that requires education on, on the customer's part for them to understand the level of detail they need. And also from the development team or the functional team for them to know, to ask them for them to have this process of accepting stories and saying, yes, they are ready for us to work on because they've got all of these different things worked out.

That was a, quite a big learning curve and [00:28:00] actually, I learned more on this, on this financial services project around that and around the importance of the quality of your requirements. And they've actually, that has carried forward for me on every project I've worked on since. If you don't have enough information in the requirements, you're going to trip up in development, testing, and all the way into production, because things will be delivered into production that are not what you need because the requirement wasn't correct in the first place. 

And particularly around testing. A tester can only base their testing on the user story. All right. You know, in an ideal world, they would have other people to talk to, but unless it's written down in a user story, how does a test and know what they need to test?

And so, yeah, this is another, another focus area. If it's not described in user story in the requirement, the test is not going to test it. It's going to go into production with holes, with functional gaps, no quality issues. I really pushed this when I, when I do training on solution architecture course is the importance of getting requirements up to the good level. Because if you don't, you've just got problems the whole way long, as I'm sure you've experienced. 

Dani Kahil: And when you say, so requirements up to a good level, do you have tools you use or, or key parameters use? 

Andrew Bibby: Yeah. I think I, I mentioned actually I was, I was training the Power Platform solution architect course a couple of weeks ago, and there's a really good set of parameters. That is in that course. And this is on Microsoft Learn, as well, I think it's seven different quality sort of characteristics of a user story. I'm trying to remember them now, but it's things like: Is the user story unambiguous in its language? Does it overlap with other user stories? In which case, you know, that's a bad thing because [00:30:00] there could be conflicts between the story or the functionality that's being built for, for each of those user stories. Yeah, I really recommend that people actually look at the Microsoft Learn content for the solution architecture exam and also your blog, which is excellent on these sorts of subjects for some really strong, quiet area for when you're assessing uses stories to say, are they ready? Have they got enough information and often, and this is really important, often customers are not keen to spend the amount of time required to get the user stories up to that level because they just want to get on with it and get stuff built. It's agile and we can change it as we go. And, you know, all of that kind of myth that you get. 

It does require a really serious investment upfront and for customers to understand that it's garbage in garbage out. Yeah. It's high quality in high quality out, and that's what you're aiming for, but that's an education process with the customer as well. I think that's quite often underestimated. 

Dani Kahil: Yeah. What I, what I used on my project, then it's again, a learning experience. And depending on the project is kind of introducing a definition of ready for the user story, right? Doesn't have to be followed for every single story, but it's a couple of, of rules that we use on user stories: Did we have a conversation about the user stories. The user story might be 'I want to capture a date for the case because there's dark', even if he seems to be very small, just had a quick chat with your team to make sure everyone on the team. Yeah. Yeah. Having that conversation, acceptance criteria written a specific format. So I like the given. The given scenario. So it's couple of scenarios that you can document in the, in the acceptance criteria. Making sure the also so that we have an idea of the estimates and, and why is to make sure that everyone on the team, like the dev team, the functionals, the BA sit down together and go through the [00:32:00] exercise of reviewing the acceptance criteria. Because now they need to put a number. So it's not really, the number is it's for planning purposes, of course, but it's mostly to make sure that everyone reads to the story and make sure they understand it and come up with a number. And if you have too big of a disparity in numbers, you know, you have something that isn't clear, probably. So a couple of those, and of course testing asking the test team to write test scenario based on the acceptance criteria, if they can't like, like you said, then you're probably missing. Yeah. Perfect. Yeah. 

Andrew Bibby: So actually on this project, we did you mentioned there on the estimation, we did planning poker, which is I felt, I thought it was a very useful exercise where you have to help everybody understand what is what the aim of a user story is, to review the acceptance criteria together. And if you have those large disparities in estimate, as you said, to talk that through, so you understand why you have those big differences, maybe this, maybe that raises something that other people haven't thought of. Or maybe it's someone being overly concerned about a piece of work in its complexity. So yeah, I think that is a very useful exercise. Again, it takes time, but you've got to invest in. 

I would also say that estimating is very important from a a customer perspective and also, you know, for the partner to plan their work, obviously, and, and for them to put tasks against that estimate that help them plan their sprints as they go forward. So the estimation, that should get better as you go through the project. People get more accurate with their estimates. Estimate is notoriously difficult and lots of a variety of estimates. But what that helps on the customer side is for them tohave an idea of the cost, the budgets that they need, the the monthly [00:34:00] spend that they need to anticipate. Because that's something that I find with agile quite a lot is that customers don't like it because they don't know how much it's going to cost. And it's a bit of a myth, but in doing that estimation process, yeah, I do think it's useful from a planning perspective, but also for that visibility of cost for our customer.

Dani Kahil: Yup. Perfect. So we discussed a few challenges that you had during this project. Any other challenges that were kind of...

Andrew Bibby: Sort of leap out is that like I said, I work with some of the best people I've worked with in my career on that project. From a perspective of, of them being very experienced, very intelligent, very proactive coming up with innovative solutions really a great team of people.

However, it was still a problem project. You know, a lot of it was to do with project management. Not that I'm blaming the project managers, cause it was a very complex project, but an area that was a particular problem was the work streams that were happening and they had different backlogs they're working through. So there was a data migration work stream and integration data model work stream, functional bill and all, each of those teams could work independently. The problems came when they weren't talking to each other enough. And the problems got bigger as the project went on. 

For example, changes were made to the data model to satisfy user stories or functional requirements, but those weren't passed on to the data migration team. And so they didn't know that they had these other fields that they needed to find values for. Or vice versa, integration. The interfaces weren't very well defined, but once they were defined, okay, what does that impact on the user experience? And also the data migration as well? 

And all these things kept coming up over and over again, but there was a lot to do with the teams not communicating effectively about the changes that were [00:36:00] happening and with the best will in the world. You can say you have to talk to each other and they'll go, yes, we will. And then they don't and they forget, and these little things that get missed that add up to bigger problems. 

 Same goes for the business, right? Because on a big project requirements will change as you go through the project and you can ask the business people, if you're changing a process, please come and tell us because that may impact the project that we're working on. And they'll go, yes, we definitely will. And then everyone will forget about that and they'll find out when you deliver something. That's not right, because we changed that process six months ago, you know, which is the problem with, with doing lots of design upfront. But yeah, I think the role of a solution architect on a project like that is to sit across those work streams and have the overall visibility across the work streams.

And I think that may be an area that was just too difficult to do. Or there just weren't the lines of communication there and the experience there, maybe with those architects. So, yeah, tricky one. But I would say that came up to bite people over and over again, that communication issue. But yeah, definitely a learn for me on future projects that you need to have this, these sorts of processes in place, even if it feels quite heavy weight to have people meeting every day or, you know, a few times a week to just talk about what's happening across the work streams. It's a difficult challenge I think, to try and get the balance right of communication. 

Dani Kahil: Yep. So lesson learned from this one would be, if I understand correctly, having those processes for people to kind of exchange the information having an architect sitting in between you were saying as well.

Andrew Bibby: Yeah. I think depending on the size of your projects, a solution architect across the whole project is great. But it could be that the project is too big, in which case, you know, a number of architects sitting, sitting across separate work streams that also [00:38:00] roll up to an overall architect. Yeah, is useful.

Another difficulty is trying to document changes. You can use dev ops for example, to say, document a data model change, and then you can use maybe, I don't know, tagging things like that to try and notify other workstreams what's going on and where they should pick it up, but you know, this is where the tools kind of, I've not found a great way of, of working with the tool set to enable that kind of communication.

And you really can't beat just sitting down with people and drawing things on a board to get your, your, your points of view. So yeah, I'd be happy to learn how you can do that better, but trying to track changes that impact other work streams is very difficult. 

Dani Kahil: Yeah. Yeah. Totally agree. Totally agree with you. The bigger the team, the more, the more complexity it is, right? The more interaction are needed between people and then all those interaction are complex. 

Andrew Bibby: It becomes very time-consuming as well. And there's lots of information you need to be putting into DevOps into something just in case you needed it, you know?

And it becomes a real overhead on the project that is normally not well understood. 

Dani Kahil: Yeah. Totally agree. All right. We covered a few challenges. I want to make sure that we, before we wrap up that we cover a few of the, what went well.

Andrew Bibby: The project itself was over budget and over time. And one of the big issues I think for that project being seen as successful is that they went live when the project wasn't ready with hindsight. It wasn't ready. And that was a lot to do with budget. And the financial penalty of not going live, you know, because things get put on hold because they're waiting for this new system or waiting for this new solution.

Users not being ready. Change management side. There was an aspect of change management on the project where [00:40:00] training and planning for impacted users was done to an extent, but it was nowhere near enough. 

With hindsight again, what went well? I would say that, like I mentioned, there the best bunch of people I've worked with, but also one of the best teams I've worked with and the people that were leading those teams and overall leading the project did a really good job of getting people to work together and overcome problems. Even on a difficult project. I've come out of that project with friends for life because we got to know each other and and got to know our strengths and weaknesses. And when you could lean on somebody and when you can ask for help. 

And I think the people side of a project is very much underestimated and having people that have probably been thrown together. You know, even from the partner side, those people have probably never worked together. This might be ahead of that, particularly with bigger partners and lots of people on the customer side, who'd been drawn from different areas of the business. Again, probably hadn't worked together and to have those people gel in a, in a team that could work and be productive together that opened my eyes as to how important that was and that sort of that's, again, something that I try and bring into projects as I, as I go along now, is that the importance of building relationships and knowing who to ask for help, when to ask for help? Yeah, I think it's not so much the technology that is so important to me these days, because you know, you can get pretty much anybody to build things. 

Yeah, it's more the people side people side of change as they call it. Which is much more interesting to me. And also I think much more important than, than the technology it's understanding how you impact people with what you do on a project, but also getting people on the project to work together effectively in this. I've, I'm always learning on that side. That's not something that comes naturally to me, I don't think. And I learned a lot from the project about how, [00:42:00] how you can do that. 

Dani Kahil: Amazing. Cause you are also, I know your, your interest in change management and your expertise in that area. 

Andrew Bibby: Yeah. 

Dani Kahil: Did you manage to, so how was it done on that project that you managed to learn something to help them? 

Andrew Bibby: This is actually I worked on that project just as I was getting more interested in change management because I'd work with partners, like I say, 10 years or so before that, and I worked on a number of different projects that I thought went really well. And then, you know, you, they go live and you'd go back and visit the customer again. And nobody's using the system or it's going to go where there's problems. 

And I can never really work out why that happened until you start to look at change management until you start to understand. It's in building a project, which is typically what partners are very focused on. They're building stuff and they're testing and putting into production. What happens before that in terms of getting people ready to receive the changes that you're bringing and also after you go live and they get this new system, which they've been told is going to be so great for, you know, supporting users and really understanding the effort that you need to go to get the return on investment that you originally wanted. It's the reinforcement of training. It's support. It's understanding how people learn in different ways. And I think that's much more interesting. It's much more interesting to me now. 

And I've done certification, which is a company called Prosci, a change management methodology that they've worked on for over 20 years. And I, that, to me, just when I took that training course on Prosci, it just spoke to me like this is where, where have you been all my life? And it was just so much common sense, but distilled into a methodology with steps with you know, at this stage in a project, you should be doing this and here's some templates to help you. [00:44:00] Go through that process with users and with impacted people within the organization. And the next stage, this is what you do. And it was a structured, it's a structured methodology. It's built up from thousands of projects and thousands of people over the past 20 odd years. 

So I'd entirely recommend anybody that wants to understand change management: Prosci is great. There are other methodologies out there. Their training is great and it was a really good experience for me, but I really recommend any project of any significant size has an element of change management. You are six times more likely, six times more likely, to have a successful project, if you use good change management than if you're doing poor change management or no change management. If you don't know what change management is, you're probably not doing it very well on, on your project. And so you have a much, much less of a chance of having a successful project. 

Ultimately, that's what everybody wants. Everyone wants to work on successful projects that everybody loves, but change management is absolutely fundamental to really understanding how people are impacted by what you're doing and helping them through that. And it's also something that's very much underestimated in terms of the time and therefore the budget required to get people ready for this.

Yeah, partners in particular, like I say, can be very focused on just building to requirements. And actually customers are really interested in getting the requirements and getting to the end, you know, training people. There's all this other stuff, which is around getting people ready, helping them. That's where you see the return on investment. If you're spending a million pounds or a million dollars on a project, why wouldn't you spend another 10% of that to make sure that you get the return on investment that you need. Sort of thing. So yeah, I'm, I'm a huge proponent of change management. 

Dani Kahil: Thank you. Thank you, Andrew. That was a [00:46:00] great conversation. Anything else that you want to add?

Andrew Bibby: I always try, like, this is a kind of principle for life. I mean, in any experience that you have, good or bad, try and learn something from it. And that's the same goes for projects. You're going to work on projects that you don't like working on. And you're going to work on projects that are good and they're fun and they go, well, hopefully. Every time you work on a project that you can reflect back on that and look at 'Why was it like that?', ' Why did those things go wrong?' Or 'Why did they go right?' You know, hopefully and then try and bring those things into your future projects. Be the change you want to see is I guess what I'm saying. It's within everybody's power to do something that makes their life more enjoyable or makes their job more enjoyable. So...

Dani Kahil: Yeah, absolutely. Absolutely. Thank you. It's a great piece of advice. So either you win or you learn, right. In some way. If you adopt that philosophy, it's easier to kind of reflect on the bad experiences and push yourself through, you know, sometimes a bit less fun project because it happens that you said, right. Thank you, Andrew. That was a great conversation. Thank you for sharing that with us. I would see each other around, I hope. 

Andrew Bibby: Yeah. Hopefully, well, hopefully we'll meet up in real life. See each other in, in Microsoft sometime. Thank you for having me. And I think that one of the things about that project in particular is being able to talk about it. It's not just cathartic like therapy for me, but I learned a lot from it and I hope if I can pass them on, then those other people can learn from that and not have to go through some of those experiences where I had that learning. So, yeah. And I think that's, that's what our community is all about as well as learning from each other. Thank you. I appreciate it. 

Neil Benson: Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. [00:48:00] 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!