WEBVTT
00:00:00.740 --> 00:00:06.894
Welcome everyone to another episode of Dynamics Corner, the podcast where we dive deep into all things Microsoft Dynamics.
00:00:06.894 --> 00:00:17.853
Whether you're a seasoned expert or just starting your journey into the world of Dynamics 365, this is your place to gain insights, learn new tricks and how to manage communication.
00:00:17.853 --> 00:00:19.225
I'm your co-host, chris.
00:00:20.100 --> 00:00:20.821
And this is Brad.
00:00:20.821 --> 00:00:24.525
This episode was recorded on September 18, 2024.
00:00:24.525 --> 00:00:24.865
And this is Brad.
00:00:24.865 --> 00:00:27.109
This episode was recorded on September 18th 2024.
00:00:27.109 --> 00:00:27.469
Chris, chris, chris.
00:00:27.469 --> 00:00:33.137
Another great episode, but before we jump into it, you have a different background.
00:00:34.700 --> 00:00:35.402
I'm a different background.
00:00:35.402 --> 00:00:44.005
I am in the city of Las Vegas at the Power Platform Conference First time and I'm excited.
00:00:44.926 --> 00:00:48.872
Power Platform Conference 2024 in Las Vegas.
00:00:48.872 --> 00:00:54.741
Yes, you're very fortunate to be there.
00:00:54.741 --> 00:00:55.304
I'm a little jealous.
00:00:55.304 --> 00:00:59.195
I wish I was there, not for the gambling and the food opportunities, that, but to learn knowledge about Power Platform.
00:00:59.195 --> 00:01:00.521
It's such a powerful tool.
00:01:00.521 --> 00:01:15.141
But while you're over there in Las Vegas, we still keep the podcast running and today we had the opportunity to continue our discussion about effective management, leadership and also the human factor of an implementation With us.
00:01:15.141 --> 00:01:34.834
Today we had the opportunity to speak with Christian L.
00:01:34.834 --> 00:01:35.736
Welcome back.
00:01:36.415 --> 00:01:37.137
Hi, hey Christian.
00:01:38.257 --> 00:01:38.837
How are you doing?
00:01:39.361 --> 00:01:39.822
I'm fine.
00:01:39.822 --> 00:01:49.192
Thank you, last days of summer here, yeah, and I tried to have some summer vibes back then before the autumn is coming.
00:01:49.519 --> 00:01:51.046
I'd like the summer vibe shirt.
00:01:51.046 --> 00:01:53.920
I think it's working Last days of summer.
00:01:53.920 --> 00:02:01.653
I hear that a lot from the conversations because now it's towards the end of September and I guess it cools off in most places.
00:02:01.653 --> 00:02:04.504
To me, I think it still feels like summer outside.
00:02:04.504 --> 00:02:08.312
I think it's 85 and sunny right now.
00:02:08.800 --> 00:02:10.485
You get summer all year long man.
00:02:11.707 --> 00:02:13.271
I know that's part of the reason.
00:02:13.271 --> 00:02:19.986
Well, we get summer when most people have winter and then we just have blazing scorching flames.
00:02:19.986 --> 00:02:24.286
When people have summer, yeah, you have to hibernate.
00:02:24.286 --> 00:02:25.907
So it's the opposite.
00:02:25.907 --> 00:02:27.704
It's the north.
00:02:27.704 --> 00:02:43.229
You stay indoors for the winter for the most part, and then you venture out for spring, summer and fall when it's nice, because it's too cold, and then down here you just don't go outside from May until September because you'll disintegrate from the heat.
00:02:43.229 --> 00:02:47.387
So welcome back.
00:02:47.387 --> 00:02:50.866
Christian Enjoyed the conversation last time when we talked about leadership.
00:02:50.866 --> 00:03:20.336
We do talk with a lot of members of the community about the technical aspects, the functional aspects of implementations or of Business Central, but, as we talked about last time, what's often overlooked is the management of the individuals working on those implementations, whether it be on the customer user perspective, or from the partner or whomever is helping someone implement the Business Central application.
00:03:20.919 --> 00:03:21.701
What is the word?
00:03:21.701 --> 00:03:22.724
Is it customers?
00:03:22.724 --> 00:03:23.425
Is it user?
00:03:23.425 --> 00:03:25.953
What do we call somebody who uses Business Central?
00:03:26.461 --> 00:03:27.844
Who uses Business Central?
00:03:27.844 --> 00:03:37.734
I think it's the user, but from the partner side we speak of the customer because it's the business term.
00:03:37.734 --> 00:03:43.362
Lately I thought if we should more aim for users.
00:03:43.362 --> 00:03:45.844
Lately I thought if we should more aim for users.
00:03:45.844 --> 00:03:51.750
I like the principle Dave Farley has on his Continuous Delivery podcast.
00:03:51.750 --> 00:03:58.917
He says that we deliver software faster to the hands of the users.
00:03:58.917 --> 00:04:04.401
Working software faster to the hands of the users.
00:04:04.421 --> 00:04:14.254
Since I was during my roles from the beginning I started with Navision and NAV a consultant who trained users.
00:04:14.254 --> 00:04:20.093
I have the direct experience as how it feels for users to learn a new software and something like that.
00:04:20.093 --> 00:04:31.834
And I think being a consultant in the first roles shapes your perception throughout the projects for the upcoming years.
00:04:31.834 --> 00:04:47.704
For that, when you are a developer who gets the requirements, makes some coding and delivers an app and the consultant is the one who has feedback to the users, that's another perspective.
00:04:47.704 --> 00:05:05.326
Since we are a small company and we started with a very small team back then, most of our developers were also consultants, so you always had the direct contact to the feedback of the users and how they feel and something like that.
00:05:06.160 --> 00:05:21.949
And I did a lot of training sessions, even standard, in NAV or Business Central and train someone brings me to step into the user's shoes.
00:05:21.949 --> 00:05:44.208
How does it feel having to train a new system, doing my daily tasks slowly, 10 times slower as it is required, and something like that, and, from this perspective, creating, as a trainer, a safe space for the users to learn something new?
00:05:44.208 --> 00:05:50.795
So we speak about customers, because that's the business side we want to provide.
00:05:50.795 --> 00:06:05.848
But when it comes to how do I design my software, how do I bring the software to a real value, I think of the users, of the user role.
00:06:08.163 --> 00:06:09.007
No users are important.
00:06:09.180 --> 00:06:14.930
You mentioned a couple points and I wanted to follow up on some of the points that you had made.
00:06:14.930 --> 00:06:19.750
Back when you first started, developers were consultants.
00:06:19.750 --> 00:06:27.944
So developers understood the application, in essence to work with the customers, to understand the requirements and then to be able to develop a solution.
00:06:27.944 --> 00:06:45.793
I like that model because I feel, in order to deliver a better app for a customer and extension, if someone can understand the application and ensure they understand the requirements, it results in a better deliverable.
00:06:45.793 --> 00:06:49.043
And this is KB.
00:06:49.084 --> 00:06:58.625
And I did a session at Days of Knowledge America this past weekend or week, I don't know, it seems to be a blur to me these days, but that's what we talked about, is you know?
00:06:58.625 --> 00:07:04.007
The question was are you an AL developer or are you a business central developer to talk about some of the importance?
00:07:04.007 --> 00:07:20.331
So that's what it was like, and that's how I was brought into this space as well was when you had to basically fill all roles Project, manage, develop, consult, even do some sales.
00:07:20.331 --> 00:07:23.644
I guess you could say have you noticed a change now?
00:07:23.644 --> 00:07:33.047
Has it been a radical shift or a large shift where most developers are more just taking requirements and working with them?
00:07:33.047 --> 00:07:38.721
Not to deviate too much from what I wanted to talk to you about but as you break up the topic.
00:07:38.742 --> 00:07:39.706
I have some questions on that.
00:07:41.060 --> 00:07:47.834
I think the shift began more than a decade ago when the projects grew larger.
00:07:47.834 --> 00:08:00.673
You have to split up the tasks and the responsibilities because otherwise it's just too big for being a one-man show.
00:08:00.673 --> 00:08:06.720
On NAV, I know some of the freelancers are still doing that for customers.
00:08:06.720 --> 00:08:24.185
But when we have the big shifts from a major version to another, or from NAV to BC or from CIL to AL, most of them need the help of a partner with a larger team with specified roles.
00:08:24.185 --> 00:08:28.603
A partner with a larger team with specified roles.
00:08:28.783 --> 00:08:32.892
And I think it's also a differentiation between projects and product development.
00:08:32.892 --> 00:08:48.407
I think for product development it is better to split the responsibilities even more and the roles even more and the tasks even more, because you can more streamline the whole development process and the feedback process and everything.
00:08:48.407 --> 00:09:17.091
Sometimes I see developers who are not that engaged with customers, but then we focus on get the requirements right and talk about the requirements in that way that the customer feedback is in the requirements, so the developer doesn't need to ping pong with the product owner or something like that.
00:09:17.091 --> 00:09:19.067
That is what we focus on.
00:09:19.067 --> 00:09:29.904
We don't focus on every developer has to be in the meetings, because it drains them out and it's cost them time, but we lay more focus on.
00:09:29.904 --> 00:09:33.653
Are the requirements right that they can do their work independently?
00:09:33.953 --> 00:09:36.922
yes, but I did have a question for christian.
00:09:36.942 --> 00:09:56.994
You had mentioned, um, you know, focusing some of your developers, or at least prioritizing their time, not to be in a meeting all the time, or if they're not required a meeting, then they shouldn't show up in a meeting and more focused on the solution.
00:09:58.821 --> 00:11:12.009
You know we've had several conversations now with Brad and many others where any time that you put together a solution or, you know, putting a product together or extension for a client, you typically have to have a I think you mentioned product manager or a functional consultant along with a developer, so that they can both have a full understanding of what the solution is going to look like, versus just throwing a developer in front of a client and says, listen to what they're saying, and that could be detrimental of putting together a solution, because some developers may not think about all the functionalities and they just want to develop a solution background and or experience as a functional that knows the business process and then develop.
00:11:12.009 --> 00:11:12.750
Those are awesome resources.
00:11:12.750 --> 00:11:15.115
Or pairing a developer with a functional consultant.
00:11:15.115 --> 00:11:29.241
I think it's becoming more and more important, um, you know to to have that in your, in your staff yeah, and what we do at cdm is we also train new developers in functional aspects.
00:11:30.104 --> 00:11:43.225
So they also learning the the application side up front, not in every detail, but they go through the regular training curriculum also on the functional side and on the development side.
00:11:43.225 --> 00:11:50.432
As I was, I learned most of my experience during the project.
00:11:50.432 --> 00:11:50.951
That's right.
00:11:50.951 --> 00:12:15.951
But they have the background and in the first project they go there with an experienced functional consultant or project manager who does this bird eye view of okay, how does this requirement the customer has fit into standard functions and is it really a need to do a customization or not?
00:12:19.542 --> 00:12:29.708
That's where it's important, as I had mentioned, to have a business central developer versus just an AL developer, because they can catch, and it's also important when they're developing a solution to put it together.
00:12:30.200 --> 00:12:52.712
But to take it back to leadership and management for a point, in the last discussion that we had with you a few months ago it seems like a few months ago, or maybe a few weeks ago, I don't even know at this point we talked about the different management phases or processes or steps for managing a team, and I wanted to take that a little bit further.
00:12:52.712 --> 00:13:04.792
I appreciated the conversation because we were talking more so from the partner point of view, or if you're developing an ISP application or an app-for-app source.
00:13:04.792 --> 00:13:18.131
What we started talking about earlier in this conversation was customer or user implementations working with a partner, and I have some questions around the management and adoption of that.
00:13:18.131 --> 00:13:34.609
Is there a way to manage a team that's co-joined between a user base and a partner, and how can you manage a team or lead a team for a successful implementation when you have two groups of people?
00:13:35.221 --> 00:13:41.349
You need to have another additional level of awareness.
00:13:41.349 --> 00:14:00.072
I would say for that, because as the external partner you are not in a role that you have a direct influence on how the customer or user is organizing their project.
00:14:00.072 --> 00:14:27.052
So when you experience that there are they are struggling with that, it helps to see if they are in survival mode or not and can provide some additional workshops or discussions on project manager level or on on leadership level on the customer side to address those topics.
00:14:27.052 --> 00:14:48.216
In my project manager experience back then I didn't take this step as much as I wanted to because I felt this hidden barrier between us as a partner and the customer organization.
00:14:48.216 --> 00:14:57.591
So we are just the partner who gets some wishes and some requirements.
00:14:57.751 --> 00:15:00.755
That is seen as someone who delivers.
00:15:00.755 --> 00:15:03.870
We are just a truck driver for their solution to bring it to them.
00:15:03.870 --> 00:15:07.442
Who delivers.
00:15:07.442 --> 00:15:11.086
We're just a truck driver for their solution to bring it to them.
00:15:11.086 --> 00:15:16.455
We have not the order to also manage their organization and what is going wrong there and something like that.
00:15:16.455 --> 00:15:27.455
But it impacts the project so much If the customer is in a survival mode or not and they are not aware of these modes.
00:15:27.455 --> 00:15:38.049
They are not familiar with building up a team, like we are for every project, so they even don't see it.
00:15:39.522 --> 00:15:50.133
Yes, every time I hear you say survival mode, I get a slight chuckle, because sometimes I feel like I'm always in survival mode when it comes to it.
00:15:51.004 --> 00:16:06.076
You did you hit another key point where a user going through an implementation is not always in the space or have the opportunity to develop a team for an implementation.
00:16:06.076 --> 00:16:23.131
I think with Business Central it targets so many different types of customers because it's that versatile of an application that it can handle small businesses and it can handle the medium-sized businesses and a lot of people don't talk about it, but it can even handle larger-sized businesses.
00:16:23.131 --> 00:16:41.561
So depending upon the size of the organization is going to be how big of a team that they can have to work with the implementation, which I think is a challenge and, like I think you had mentioned, with them being in survival mode with it, it may be because they also have work to do, as I call it Right.
00:16:41.561 --> 00:16:42.767
So it's it's.
00:16:42.767 --> 00:16:47.589
The business must still move forward as they're going through an implementation.
00:16:48.903 --> 00:17:05.251
And from our experiences also lately, the big projects my colleagues did the best projects were those where the project managers were able to work full-time on the project.
00:17:05.251 --> 00:17:09.808
That were the best cases.
00:17:09.808 --> 00:17:16.359
They prepared all the requirements, they prepared the test cases, they did the testing, they were the key users.
00:17:16.359 --> 00:17:25.355
They knew what other key users they can approach to have good feedback about the solution early on and something like that.
00:17:25.355 --> 00:17:30.266
But many customers are not in this role.
00:17:30.266 --> 00:17:37.020
Mainly the guys from the IT departments are nearly in this role.
00:17:37.602 --> 00:18:14.666
If you have a project manager who is mainly in charge for finance management or purchase or something like that, and because of this they are purchasing a solution from us as a partner, struggle the most with this because they see us as a partner, more like any other vendor who is just delivering goods to their loading dock, who is just delivering goods to the loading dock and when it's there it will be checked and they receive the invoice and they say, okay, we did receive the goods and we will pay them.
00:18:14.666 --> 00:18:32.846
But that is more like acting in daily business than doing an ERP implementation project and most of the partners don't have the time to send their people on a five-day project management training or something like that.
00:18:32.846 --> 00:18:47.559
And even if they do, having the experience to really do a project takes much, much more time and there is no repetition right takes much, much more time and there is no repetition right.
00:18:47.559 --> 00:18:53.123
Most of them are doing an upgrade project or even an implementation project two or three times in their career.
00:18:56.066 --> 00:18:57.567
Yes, I could see there's a challenge.
00:18:57.567 --> 00:19:04.872
So, from a partner point of view, how can you lead or manage that project?
00:19:04.872 --> 00:19:18.741
In those types of situations, is there anything that a partner can do, or someone leading the project from the consulting point of view, even if they're not a partner, to help with that management process of their team?
00:19:25.404 --> 00:19:30.871
I think the best approach to bring this to the table is doing it in a section we call risk management during the steering meetings.
00:19:30.871 --> 00:19:43.338
But to be able to do this you have to manage how you can build trust on the customer side that you can talk to those topics.
00:19:43.338 --> 00:20:04.537
I had some of those situations back in the large projects but it needs, again, very much experience to address it right, not to upset the customer and to open them up to look at those issues.
00:20:04.537 --> 00:20:12.444
But it comes down to yes, it is about risk management for the company.
00:20:12.444 --> 00:20:22.157
So you look for how is the correlation to risking them going out of business if we do not address this?
00:20:24.326 --> 00:20:29.625
And the importance of all of this for a successful implementation.
00:20:29.625 --> 00:20:37.858
I have conversations and I try not to go off, but we're going down a certain road with the risk.
00:20:37.858 --> 00:20:46.881
I try not to go off, but we're going down a certain road with the risk, and a lot of the conversations I hear about an implementation sometimes make them sound like they're a daunting task or a big task.
00:20:46.881 --> 00:20:54.855
I mean they are a big task because, in essence, someone's changing the core of their business.
00:20:54.855 --> 00:20:57.335
What's the function of the business?
00:20:57.335 --> 00:21:00.366
To manage all of their business processes to continue to be successful.
00:21:00.366 --> 00:21:18.865
But it doesn't always have to be complicated, it doesn't always have to be what I call difficult, but with that it also requires some preparation, which sometimes sounds like a lot of work, because we all talk about this and it's not just this conversation we're having.
00:21:19.326 --> 00:21:36.647
It's I've been having more and more business type conversations versus the technical and the functional conversations, and I'm starting to hear phrasing that if I were a business owner, I may sometimes be afraid to go through an implementation because I hear, as you had mentioned, risk management.
00:21:36.647 --> 00:21:42.739
I hear project management and my staff will need to learn a new system.
00:21:42.739 --> 00:21:48.998
My staff will also have to go through and test the new system, but I still need to perform my function.
00:21:48.998 --> 00:21:59.258
It does sound complicated, but as we go through this process and working with them with leadership, how can we tone that down and also explain to them?
00:21:59.258 --> 00:22:10.106
Yes, there are risks, but there's risks that, with anything that you're doing and it doesn't have to be so big, in essence I don't know if.
00:22:10.126 --> 00:22:11.050
I'm phrasing it properly.
00:22:11.526 --> 00:22:12.830
I think there's always going to be risk.
00:22:12.830 --> 00:22:33.513
I think, maybe finding ways for people to understand that there'll always be risk but you can do a lot of things in terms of preparation as a leader or if you're leading a project or even managing a team, that if you take the time it will minimize those risks.
00:22:33.513 --> 00:22:37.866
Not necessarily, you know, sometimes you can't, you just can't remove risk.
00:22:37.866 --> 00:22:39.148
There's just unknown risk.
00:22:39.148 --> 00:22:46.519
But you can certainly minimize and even prevent some of those things that would creep up.
00:22:46.519 --> 00:22:53.178
So I think the conversation still needs to happen, even though it could sound scary.
00:22:53.178 --> 00:23:12.973
But if you don't have that conversation ahead of time, then it's certainly going to be more difficult and the risk would be more amplified if you're not having this conversation and, of course, investing the time to do it.
00:23:12.973 --> 00:23:16.015
It sounds tedious, but it's a must.
00:23:16.704 --> 00:23:24.875
Yeah, it's more like something you can train on a project management or leadership course.
00:23:24.875 --> 00:23:32.934
That is more some skills that you can follow, and it's easier to get up the skills.
00:23:32.934 --> 00:23:38.277
The hard part is how will you address it?
00:23:38.277 --> 00:23:40.255
Who will you address it?
00:23:40.255 --> 00:23:41.284
Who will you address it to?
00:23:41.284 --> 00:23:50.480
Sometimes the complex part is not that you have to have a risk management list.
00:23:50.480 --> 00:23:57.679
The complex part is who in the organization of the customer will be best to be addressed.
00:23:57.679 --> 00:24:04.029
This and this could be a person who's not in leadership, who is not even in the project management role.
00:24:04.029 --> 00:24:32.036
But it could make sense because you feel that the person there's someone maybe in the purchase department who has a connection to the project manager that the project manager will listen to what he is saying and it's more likely that you can bring your points to the table when you first talk to this guy in purchase.
00:24:32.036 --> 00:24:36.431
That is the complex thing and you have to try out.
00:24:36.431 --> 00:24:41.933
You don't know in advance if this goes well or if this fires back.
00:24:42.904 --> 00:24:44.752
And that is a really complex part.
00:24:44.752 --> 00:24:46.571
You don't know how they react.
00:24:46.571 --> 00:25:03.596
You have to test a little bit who is the best I can approach, and for this I take some thinking tools from my future leadership training, together with Elastic Leadership and traditional project management.
00:25:03.596 --> 00:25:13.432
And that is do I have a problem of knowledge when knowledge is there but not for the person?
00:25:13.432 --> 00:25:15.696
Okay, how can we do it?
00:25:15.696 --> 00:25:21.718
How can we show them the documentation or book some training or something like that?
00:25:21.718 --> 00:25:25.270
Or is there no knowledge?
00:25:25.270 --> 00:25:28.178
Nobody knows how to address this in this company.
00:25:28.178 --> 00:25:31.310
So then the question is who can I ask?
00:25:31.310 --> 00:25:34.678
Who has an idea about how to approach this?
00:25:34.678 --> 00:25:40.096
And that is the point where I now can shift a little bit more.
00:25:40.096 --> 00:25:49.997
Then I can decide okay, this problem I can address with training and it's got a high possibility that this problem is solved.
00:25:50.644 --> 00:26:13.404
But there are other problems, even larger, for customers in such projects where nobody knows how to do it in their organization, and then me, as a partner project manager, knowing of these things, can guide the customer organization a little bit in this direction.
00:26:13.404 --> 00:26:20.058
So when you have this kind of problem, do you have someone who you are talking to?
00:26:20.058 --> 00:26:24.171
Because you know, when you talk to this guy.
00:26:24.171 --> 00:26:27.699
He has some idea sparking.
00:26:27.699 --> 00:26:32.175
It's a starting point where it opens up or something like that.
00:26:32.175 --> 00:26:35.275
Okay, go to him or her, or something like that.
00:26:36.346 --> 00:26:40.471
We had that in a big project Many departments.
00:26:40.471 --> 00:27:12.614
I trained with a new NAV version back then and during the lunch break they're all sitting in the same bistro and eating and one of the guys in a particular sales department talks about how he is configuring with the personalization mode, his role center and his pages and something like that, so that this is a good fit for his work, and he has ten colleagues in his department who are nearly doing the same.
00:27:12.614 --> 00:27:20.491
So after the lunch break I approached the project manager, the customer side, and said did you listen to him?
00:27:20.491 --> 00:27:29.645
Maybe he is a good key user, Maybe you should talk to him.
00:27:29.645 --> 00:27:38.699
Building up the role center for the profile for this department and having this feeling who is good for approaching him a certain problem?
00:27:43.373 --> 00:27:59.086
is a big part of project management, that that's a leadership skills, skill that you must have, um, because you do have to gauge the audience and figure out you know who who knows something and you sometimes you have to get it out of them.
00:27:59.086 --> 00:28:01.532
Sometimes you have per person in the room.
00:28:01.532 --> 00:28:08.896
That's the most quiet person, but in many cases they're probably the most knowledgeable and they're just taking it all in.
00:28:08.896 --> 00:28:12.351
So you have to get that person involved.
00:28:12.351 --> 00:28:21.732
You know to speak up and share, because, yeah, you're right, you know there's going to be somebody within that group that knows something.
00:28:21.732 --> 00:28:26.721
Maybe they're just afraid to speak up and and so you have to get it out of them.
00:28:26.721 --> 00:28:29.679
And, like you said, you know, you listen and you heard someone.
00:28:29.679 --> 00:28:35.750
That's like you know what that person has, some ideas, um, you know just from listening to what they're saying.
00:28:36.491 --> 00:28:54.659
And how to approach this, because often if you encourage a person like this in an official meeting to speak up, they stay quiet Because the culture in this organization is shaped in a way.
00:28:54.659 --> 00:29:22.647
We cannot say this in an official meeting, so you can try to approach them informally in the coffee kitchen or somewhere else and try to leverage this knowledge that is there so you can in some way, as a partner project, shape this environment for those people to speak up, but diving into.
00:29:22.647 --> 00:29:26.917
Okay, we have a workshop here or a training class or something like this.
00:29:26.917 --> 00:29:31.632
You offer to me a good solution, please present.
00:29:31.712 --> 00:29:35.058
It is sometimes very risky.
00:29:35.058 --> 00:29:44.500
Very risky because nobody can directly influence the culture of any organization.
00:29:44.500 --> 00:29:50.034
We, as a partner project manager, are even less able to do that.
00:29:50.034 --> 00:29:59.093
So you have to find to play the way and open spaces on the backstage of the project to do this.
00:29:59.093 --> 00:30:20.958
You have also to play the front stage in the official meetings, steering meetings and something like that, and you have to play on the backstage because if you are not getting these people to speak up, you don't get on the project early, on these problems early, and the risk that you get all the bunch of problems in the go-live is very high.
00:30:22.787 --> 00:30:23.730
Yeah, you made a good point.
00:30:23.730 --> 00:30:33.472
Yeah, sorry, brad, you made a good point that as a partner, it is very difficult as a partner to help encourage that right.
00:30:33.472 --> 00:30:46.340
You have to have a really good partnership with their internal project manager or even their executives or sponsor the project where they also have to encourage that right.
00:30:46.340 --> 00:30:55.278
That's their culture they'll have to live with every day Because once you're done with the project you may slowly go away, come in and go for other future projects.
00:30:55.278 --> 00:31:01.838
But it's really their responsibility as an organization to encourage that.
00:31:01.838 --> 00:31:21.676
And if you start a project and that's not encouraged, where someone speaks up and puts them down right away, then they clamp up and don't want to share anymore because now they were put in a spot, you know, and I don't want to share now, so that that could be detrimental.
00:31:21.676 --> 00:31:22.298
That's risky.
00:31:22.298 --> 00:31:33.771
You're right, christian, you can't just put someone out there and said, hey, calling them out, it's, it's a big risk as well yeah, when you, when you are not aware how is the culture at this organization.
00:31:34.333 --> 00:31:39.089
So my advice would be try to get a picture.
00:31:39.089 --> 00:31:42.076
How is the culture here in this organization at the customer side.
00:31:42.076 --> 00:31:46.277
You have to play in swing with this culture.
00:31:46.277 --> 00:31:53.999
That is a very better approach than just saying, okay, we are open here, just speak up.
00:31:53.999 --> 00:32:01.578
It won't have any negative consequences when you're not knowing what is the culture playing here.
00:32:03.405 --> 00:32:19.337
It is important to identify who in the room, as we're calling it, which I'm going to talk about in a moment knows the true process, the true requirement or what needs to be done in a project right from a leadership point of view.
00:32:19.337 --> 00:32:31.438
Requirement or what needs to be done in a project right from a leadership point of view, and we're talking about being able to talk to this individual or group of individuals, or however you do it, in an unofficial manner to try to organize or bring to service the team.
00:32:31.438 --> 00:32:46.617
But now we're in 2024, and I know how we talked about just how the roles have changed through a project over the years, where a developer early on in the conversation would be responsible for also doing some consulting.
00:32:46.617 --> 00:32:51.154
Now, in 2024, a lot of things are done remotely.
00:32:51.154 --> 00:32:56.236
So how do we impact leadership?
00:32:56.805 --> 00:33:07.507
And I loved the conversation on elastic leadership that we had and I encourage everyone to go back and listen to it and learn about it, and we can continue that conversation forever.
00:33:07.507 --> 00:33:21.612
But now, from a leadership point of view, let's take into consideration even going back to that elastic leadership model, where you no longer have everybody in an office together, where you no longer have everybody in an office together, even for implementation.
00:33:21.612 --> 00:33:24.134
Sometimes you can do them fully remote.
00:33:24.134 --> 00:33:29.377
I've had conversations and discussions with many on should you ever go on site?
00:33:29.377 --> 00:33:34.821
Do you need to go on site and meet the customer in person or the user in person?
00:33:34.821 --> 00:33:57.773
But now, from the management point of view, all of these things that we're talking about, all the modes and the elastic leadership management or even the layers that we have through an implementation how does working remotely impact that and how can you address the differences between in-person management versus remote management or even hybrid management?
00:34:00.116 --> 00:34:10.619
I think you can do it full remotely, but you have to set up more meetings just for those topics.
00:34:10.619 --> 00:34:24.452
You cannot just cramp it in the regular status meetings or something like that, or just doing a remote kickoff workshop or something like that and hoping that these problems can also be solved there.
00:34:24.452 --> 00:34:45.454
In my perception, experienced project managers are also doing good project management work remotely, because most of our project management work is remotely, even if we have very local customers here in northern Germany.
00:34:45.454 --> 00:35:02.985
What we try is to be before the kickoff workshop or after the kickoff workshop with our team at least a day on site just to get to know each other.
00:35:02.985 --> 00:35:08.978
But I think it's done in a third of the projects.
00:35:08.978 --> 00:35:13.025
Most kickoffs are held remotely or something like that.
00:35:14.648 --> 00:35:24.059
What helps is having a good project structure, but it doesn't put the risk completely down.
00:35:24.059 --> 00:35:36.976
So what you can do is being aware of this and offer some of these meetings just to talk about how are we doing in communication?
00:35:36.976 --> 00:35:43.664
Are there some blockers in the communication or something like that.
00:35:43.664 --> 00:36:10.974
And when you approach these topics, not play it to the personal level of the people, because every organization has a cultural behavior or something like that to personalize right away Like, okay, I know this guy.