 Thank you for coming So my session for good or for worse making happy client relationships first-hand experiences From supplying digital services From the past 25 or so years some heartfelt lessons that I that I got Some tips that you may be useful in your day-to-day operation the day-to-day Digital services, I'm going to be standing here because there's a recording and they want they want me in the in the picture apparently so So yeah, there's it isn't as much a method or structure that I'm going to present to you as much as it is Some first-hand experiences of the things that are learned and some tips that I might want to share with you today So my name is Emmerich Meiling For those of you who don't know me I'm with a digital agency called React online from Holland together with my business partner Jean-Paul. He's here today I'm a Drupal.org for 16 years and 10 months or so Yesterday I was formally instated as a board member of the Drupal Association and I'm also at the Drupal County Europe Advisory Committee. So hi. Good morning. Welcome. Please do come in. There's plenty of spaces across the room So In this session, there's five Topics that I'd like to cover in so how to do digital projects with inexperienced agile teams That's on both sides, but in particular on the side of Agencies and service providers which I'm from So how to deliver digital services within time and budget and some things that I'll learn from there Prevent from over-promising the trick there is not to make any promises But do deliver on commitments Delivering bad news, which is not always as bad as it sounds and negotiating negotiating contracts. There are not agile So Off onto the first topic how to do digital projects with inexperienced agile team So question to the group who of you work is with a digital service provider and ICT supplier who does Supplying digital services Websites platforms, right? Okay So who is who is using Drupal in their day-to-day operations and relying on an external party for For the website so a client as we call it. That's also a few right, okay So these things are for like very insightful for both sides of the table I'll be talking to digital service providers most of the time But I've been very interested to hear from you how you experience Working with digital service providers and the things that we learned and how we can learn from from you and vice versa So Those using Drupal feel free to stay. It's very interesting to hear the first step in getting the lack of experience Sometimes bad experience which often times have happens a lot as well is to take that head on now There's a concept a psychological concept called the fight or flight response as anyone heard of this the fight or flight response. Yeah, quite a few right, okay, so This is sort of a primal thing for people that ultimately under threats, right? When there's no other option people will fight or flee so Here's the definition The reaction starts in the brain and spreads through the body to make adjustments for the best defense or flight reaction Right, so I think a lot of this is going on in the world, right? Also in our day-to-day life sometimes how we do business and it runs through everything that we do When we allow it, right? It all depends on how you look at things Fear sometimes comes from an idea that you have. We had an amazing inspiring keynote about that yesterday, right? Or from bad experiences, which is also oftentimes the case. So Obviously fear kills the basis for trust or at least is quite a big impediment for it, right? So How do you overcome that? When you start working on a business relationship together on digital projects So I'm a sci-fi fan. I watch Star Trek from time to time No worries if you're not a Trekkie, it's just an analogy to illustrate the concept But this here is the Vulcan mind meld, right? The Vulcans from Star Trek It's a race and apparently that's something that only they can do The Vulcan mind meld is a touch technique that allows a Vulcan to merge a Vulcan's mind with the essence of another one's mind So in Star Trek, apparently Vulcans, they're not supposed to show their emotions Essentially, it lets other people see the world through through their eyes the way they Experience it their emotions their memories and so forth. Oftentimes the scenes is an emotional scene in the series Because in a very short moment a lot of knowledge and everything is sort of transferred from one mind to another And that this gave me the idea for an agile mind meld and doing an agile mind meld onboarding session with with each other with her clients or kickoff if you're not into Trekk and it's a well-prepared session that allows you to Take your client and let them see the world through your eyes Right. Tell them how the game is played Be very open about the caveats and the pitfalls and everything that you will encounter But it's because that it's going that is going to happen and I always invite Like the teammates the management team to that session, right? It takes it takes a bit of time But it's incredibly rewarding and refreshing to have them to have each other at the table early on And take them through how you see the world and how we will play the game together at the very start So we talk about How we do how we work you do agile how we do back look refinements how at certain points things may not Work out as we planned how maybe we need to let go of some of the scope The risks that are involved the good and the bad, right? So we're very open about that and I encourage you all to To take on a session like this and agile kickoff Together take the time two hours or so invite management and all and talk about these things About what will happen? So let's talk about ownership for a little bit. So In particular the part that's being played by the product owner, right? The concept of a product owner in agile often needs some explaining So in many cases, it's the project manager role, right on both sides so There's a question who who actually refers to When you talk to your clients, hey, I need I need the product owner I need you and your capacity as a product owner who refers to Your client as product owner, right? So that's just a few, right? So in so who refers to the client contact as project manager, right? So is there someone Someone of you who uses Drupal relies on an external digital service provider that has a product owner in house. Is there someone There's no hands, right? So okay, so we talk about this a lot about the importance of product ownership So there's different definitions. I like this one It's it's clear and simple but not always obvious and I highlight in particular the part About the person in particular that will make decisions involving time and money and This is crucial and this is this is from the sales deck by the way We also have it in our agile mind melt And we repeat this often and here's Kim Kim is product owner with one of our clients and This is what I do at the very start when we when we pitch or what we when we meet There hasn't been signed off anything. I take the previous slide I find a photo of the the person who's going to be in charge who's going to be our contact person and say This is the product owner with face and all and I again stress the fact that she's going to be taking decisions involving time and money And in quite a few cases, there's people Two one or two people that will sit up straight and say oh, but that's not her is going to be doing that That's me and That's the point where I'll say okay, then you will be our contact and product owner because I cannot go back and forth all the time and manage your Your team as much as I like to because that will take time away of making software, right? So it's very important that we have someone That has mandate and authority to make those decisions So at one point it will most certainly come to to a stage where we have to make decisions on doing things differently Let go of some scope There's also people that will Come in and say hey, but we promised or you guys said that you would deliver this or in the contract It says this so you need to add this as well, and I'm like No, that was Kim's well thought out decision So I always tell our clients you got to become very close friends with Kim Because if you want something done, she's the boss of the wallet. She manages the backlog She tells us what to do. So if blue suddenly needs to be green talk to Kim, right? So lessons learned Recognize and appreciate the fact that there's going to be doubt sometimes that's going to be changes Things will not go out as planned, but take the time to do that agile kickoff If you're not into track law kickoff onboarding session, whatever you want to call it And be very open and explain how you work So let them see the world through your eyes The good and the bad be open and honest Talk about agile values how the things are working the sessions or whatever project management method that you employ So without product ownership, there's a little chance to get with what you want, right? It's an essential role that we need to have so you must explain that So second how to deliver digital services within time and budget. Well, the trick is Make it so it fits the budget So that sounds easier. They're said and done, right? So how do we do it? It is one of the most repeated things that we have in our projects though We say it very often. So it's in our slide decks. It's in our proposals stressed in capitals It's it's repeated during the process Nobody wants a project that will run over budget, right? So the budget is always like this rock solid thing We can mold the scope, but the but the budget is what it is. Yes, we can go back and get more budget Yes, you can go to management and say, hey, we're going to add this or this But the budget is very fixed in our in our projects But there's always tension between the project and all the stuff that people want Because it's it's the opportunity to squeeze in as many things as possible and say, okay But then we also need this and then by the way, we talked about this. So I See a lot of proposals out there That we get also where Organizations are looking for a partnership as long as they get anything they need and want and that's everything about managing expectations. So There's often this quite long list of all the things and features that need to be in there And there's two things there first is you need to ask how can you be sure you need all these features? Right, did you do your due diligence? Did you talk to people? What where's the data? Where's the business goals or the other goals? That's Justify all these features, right? So why don't let you why don't you let us help you? Figure out what features you need and what's best because that's that's our passion. That's what we do best, right? So the second thing is that your client Contact person protocol and needs to learn to say no right, so That's that's hard thing. You need to help them and might not go right right away but The person must learn to make choices based on budget business goals and you must help help them discern what's most important and so Hanzer Knickerbuck Kniberg has a wonderful video and I encourage you strongly to watch this It's about 15 minutes. I used this a couple of times in work sessions in the past I show this to people sometimes I have about 40 seconds to show you. Oh We don't have the sounds, okay Okay, we don't have the sounds so The slides will be shared. I have the link, but I strongly encourage you to look up the video so to illustrate a didn't speak about as an agency in With various offices in the Europe and the US And it's it's a quite it's a bit forward, but there's two things that stand out We work for your customers. We may have to take their side at times Which was very appealing to me and it's like yes exactly this is this is The understanding that we were trying to get when working together and we're not suppliers right partnerships get the best result So let us work together on finding out what you need instead of supplying us this whole long list of features So lessons learned is work together to find What it is that you'll actually need so that's sometimes hard so We're so happy if we can find come to that stage Where there's a mutual understanding that yes We don't know yet what we need and we need you guys to help us figure that out in a way that fits the budget It's always that line comes always second Help them say no no doesn't mean no never I always tell tell them no not now So we always talk about no not now can be next month can be in the next increment if it needs to be in there We need to look for a way to get something else out because the budget is fixed, right? We're not suppliers partnerships gets gets the best results Prevent from over promising. There's only one way to do it. Don't make any promises That sounds like an easy escape right so We have contracts often times we're contract bound, but it doesn't mean you cannot have any commitment So I always tell our clients we are committed to delivering the best possible result in a way that fits the budget but we need to figure that out yet, so Estimating is hard Right, so when we have like Sort of an outline or a backlog or design then we need to say, okay, what will fit we need to estimate What will fit in the budget? So whether it's story points or t-shirt sizes or or the good old hours? Ultimately, that's what you need Estimates become fluid or they could become off Oftentimes, you know, they're wrong I'll admit to that so You can't have it all right, it's naive to think that there is a budget set that we've signed off on And you kept and we can all keep squeezing things in right? That's that's not possible. So Things change priority shift things may be added things that we have overlooked Things that our clients have overlooked. I often say well There's gonna be a few things that you haven't thought of that we might have now, but we cannot see our all ends, right? We cannot see everything so There's a lot of mantras from the from the previous slides Another important lesson is to do those estimates together right, so when it comes down to it when it comes down to actually sharing the marbles and Defining what can we do for the budget? Here's a photo of a project that I did for the port of Rotterdam It's like multi the global quite big project took us over a year to complete the entire scope And here's what we did at that time We had like all the tables in one room in one one long row With a black tape in the end and I printed out all the user stories from Yura at that day And we laid them out in a long row and we invited all these stakeholders and the product owner to come in And work out what could be done for the remainder of the budget and this was a very refreshing session Because they were actually making the case to one another as to why their Epic or stories needed to go first, right? So it also confronts your client or or in the stakeholders from whoever is from the business or Actually going to work or need all this stuff in to look your team in the eye and understand why seeing things are sometimes hard to build So they feel the pain of your of your creative staff or your development staff and they see ah, okay So that's why it takes three days to build this. Well, I thought it was like a couple of hours, right? They don't always get it the first time or right away But to look each other in the eye and see each other's pains and gains Actually creates this this this base for taking a hit for one another also the team Gets a feel as to why certain things are so important for your client. So Estimates black backlog refinement sprint refuse do as much of them as you can together actually all of them So the very key is trust learning each other and Yeah, so for the process to go smoother and and have a feel of why things are so important or feel as to why Things are hard to make those that was very refreshing. Obviously you can do this online from the tool or in a call, right, but This is what we did at the time So the lessons learned here is commitments are not promises, right estimates are not actuals and planning is guessing Yes, we're doing an estimate. We've we've worked a day to get this estimate out, but it's an estimate This it's not gonna be reality. It might be And sometimes it is sometimes actually it's even less, but it's an estimate not an actual I Can promise you that we will do our utmost best to get everything out Inside our estimate, right? So do the estimates together back look refinements and the sessions as much as possible Yeah, and people will will more easily want to work in common success when they understand each other's needs and pains Delivering bad news is not always as bad as it sounds But it's best served early and straight up, right? So at some point something will go different Your designer might be sick project manager might be out Some technical read there's a hundred reasons, right? So the agile manifesto says responding to change overfalling a plan Well, you know what? Mistakes will occur, right? Setbacks will occur. We all know it. It's part of life. So it's part of software development, too When there is a change of plans discuss it straight up early and often It's one of our mantras that we repeat a lot as well And sometimes our people are not happy with bad news, right? You can Bob Ross and all you want They won't take no for an answer Well, you know what? I won't take no for an answer, too So when people tell me no, we can do this like it's there's a technical thing. It's well, what can we do? So you must look for no, but what we can do is this I Repeat this a lot. So no, we can't do it. It takes more time. Okay, but what can we do? All right, so no, it's not good enough. I need to hear no, but what we can do is this So a few few weeks ago. We had some adjacent panels and it couldn't be Jason So we had them stacked and by the way, it was also better for accessibility We call the client right away say, hey, it's not gonna be like in the design But we're gonna do like this in your accessibility accessibility is better too problem-solved client happy that happens a lot, right? So if you put effort into it work to know but what we can do is this So when your client puts their foot down and say, oh, well, that's all all well and nice But you said at the start this and I need this I'm gonna repeat say, hey, this is what we've been saying from the start, right setbacks will occur Because why is it when we hit a snack I need to pay for it, right? This is what we're partners for So there's three questions daily And this is sticky on top in our sprint planning and we we ask them daily In the team in the daily stand-up is anything holding you back From achieving what's in the user story under design Is anything going to be different from what's specified in the user story or the design and is anything taking up more or less time than we Estimated if either one of those is a yes We need to break out and we need to contact the client product on our project manager early and often So that's what we do the sooner the less waste So lessons learned bad news best serve up served straight up Without hesitation or twisting around changes and setbacks will occur. It's a setback of life Don't take no for an answer look for no, but what we can do is this and Do that early and often? so We're going smooth and fast so Negotiating contracts that are not agile by the way, there's a Q&A at the end. I was I was planning on doing that just as we go along to Have some of the interaction going but the room is quite big. So You can put the questions in the app But it's fine to if you can remind them if you can remember them to have them come and I'll come with the mic Whatever you want or we'll see. Yeah Negotiating contracts that are not agile while contracts in most cases aren't agile, right? So there's there's a lot of at the start These RFPs and specification documents and and briefings that will say we're looking for a partnership So do we right but when it comes to the contracts, there is no partnership to be seen anywhere So we have a saying contracts can make a friend or an enemy good contracts make good friends Well, the Agile Manifesto is talking about customer collaboration Over contract negotiation, right? It doesn't mean we don't need contracts. We don't have contracts. Of course we do It just means that we also value a lot on the partnership Now this is me at Universal Studios a few years younger I'm a huge back-to-the-future fan sci-fi fan if you haven't noticed For those who aren't no worries This is a the car is a time machine at the Lorian plays a huge part in the films So why this picture a lot of stuff that happens in contracts are About things that happen or might happen in the future or how things may play out Right. So let me explain this I have three basic rules for contracts I will not commit contractually to something I cannot control Or risks that may be all on my side in the future Right things will not always go out as planned if I need to take all the risk That's outdated. I literally I literally say that So I will not work harder if if if I get a penalty penalized with money If if you need penalties or incentives, I want them to be mutual because that's what the partnership is about But to be honest, I don't believe in if you pay me more I walk harder because we will already work hard And there are so many hours in a day, right? We're also in the effort business. So ours Are not results, right? So we will be defining the result together I will commit to helping you yours though. So a few examples This is this is contract text. So I have to actually read this in any circumstance where deliverables will not be delivered in time in accordance with the preset agreement or is different from it Contractor is neglecting the terms and conditions and is liable for Consequences including financial consequences, right? This is this can be in a contract or an agreement. That's that comes with only happy documents And this is what I send back as I walk. I have a counter proposal to that So I will say that we first and immediately get together and try to solve before we are held liable in any way Because that's what a partnership is about Contractor will uphold the application. It is a good one To the latest standards laws and regulations and requirements as stated by the law and the latest version of our security Standards and technical policies. It should always be in accordance with the latest increment. Should it change? This is a back to the future moment for me Because I don't have a time machine how I cannot we can't know What the law will be in the future or what regulations or what changes you will make to your requirements, right? So This is what I counter. I Cannot accommodate the possible future requirements if they are to be met changes will be put forward Through the product backlog by the product owner provided. They are technically legally and otherwise feasible client absorbs all costs Risks and additional consequences just as with any act addition. This is a knockout for a further participation Well, I might you know if we negotiate and it becomes a little bit different I might change my mind anyway But I will put my foot down here because I will not commit To something that may be very risky to me in the future. I'd be very interested to hear from from you Who are relying on external? Parties and I might actually be on on the side of the table writing this how you would experience this so And how you cope with with with these contract negotiations on that? so There's lots more Examples but the lessons learned is don't commit to something you can't control it will work against you sooner or later You know in many cases, you know contracts will not come out of the drawer But in some cases they do and sometimes we need to be very strict about the agreements that we make, right? So if you need to take all the risk, that's not a partnership, right? I say to clients then well We have conversations about let's okay. Let's Amp the budget with 30% because you're moving all the risks to my side, but that's outdated and old-fashioned I literally say that setbacks will occur So are we doing this for good or for worse or not at all and? Contracts are always negotiable. So name your terms. I I've had legal People call me up and say hey, I saw your counter proposal to our agreement, but that's not how it works So definitely that's how it works. It's a negotiation, right? Don't let any anyone tell you otherwise You can always talk about these things Thank you for listening. Thank you for coming I'm gonna walk over there On the on the laptop, there's going to be if there are any questions test test yes, this works, so Let me see. I think I have to And I can also come to you if you have any question Right so so okay, so there's a question from from Lucas Lucas are you here? All right. Thank you for your question What do you do if the client cannot provide a product owner? So that's a good question, right? so But can you all can you all hear me? This is working? Yeah, okay, so Yeah, so what we do is we go through this process We go through the definition and we're like, okay So we understand that you don't have a product owner, but we need a person who's going to walk this journey with us almost on a daily basis you know if we are to make software and you you have only An afternoon every three weeks then we're not your party Right, it's not gonna work. It's a recipe for disaster So whether they call them product owner or not, but we need this person that fits this criteria Another option is for them to hire a product owner, which which happens Regularly, so that's what we do. Are there any other questions anyone? Feel free tough questions are also fine Yep, I'm coming to you. Hey good my questions around Contracts and you know it always does come up, you know, I am the main person at my organization that deals with all contracts and They're tricky and I wanted to know your opinion on more specificity in a contract or more vagueness in a contract Okay. Thank thanks John. So so you mean is Like make it more vague or more explicit or details to a contract Then you're gonna be held to every detail like bullet point by bullet point, right? So and I've had that happen and so when I write my contracts I write them slightly vague so that they can be interpreted in times of question, right? Rather than like you're putting on a login form more like Login will be part of their website, right? I mean sort of like if they catch you in a knit That's what I'm trying to say is like you don't want to write too much Yes, thank you. Yes, so I don't think there's like a silver bullet answer like a one size fits all But yes, so this is what we do sometimes and happens is where we Just like you say say hey, let's leave this a little generic And we if we can both agree on that that's perfect, right? Because let's make an MVP out of the contract and don't set anything all every detail in stone So yes, that's what we do sometimes as well. Thank you. I saw two hands So the question is about your success rate How many people do you think that you're talking to are wondering off because of your way to work with them? That's a good question To be honest, I have I have had one or two That said well, you know what if we have to spend a day a week with you. We're not going to do it We're not going to be able to do that. So That's so be it. Yeah, it's always tough, especially when you need to work There might always be some molding where you get together But ultimately yes, sometimes it happens, but it's not huge what it happens Thanks. I have a smaller company. We're only with six people and our products projects are not that big but How formal is your communication with the customer? For example, if they don't deliver what they are promising they would deliver Content or whatever and they don't deliver. Do you? call them and then Write a formal email to say this is what we discussed at the phone at the phone because Afterwards if there is a problem you have something you can fall back to or how do you do that? Yeah, so so thank you for that. So the mantra is early and often so whatever it happens We call them right away and that's quite informal. So hey, we're falling behind. We need this We can give you another day or two and we always write that down in confluence or in the in the user story So hey, this is this is what we agreed on 48 48 more hours, but we need to buy then right. So that's what we do Not like really a formal email, but we put everything in it last year. That's what we use right But this this is a good example of if if if there is a contract and a client that needs to have everything Written in stone like this, which sometimes happens. So hey, we need to have everything formal Right and I get penalty if I don't deliver in time. That's when I use the example Okay, so when you don't deliver in time, I'm gonna send you an extra invoice as well And they that's that's a weird concept oftentimes, but that's like that if we make a partnership out of of that That's the example that I use but it seldom comes to that. So anyway to answer your question Coming over We have few more minutes so how much project management and Meetings time do you include in your contracts? And do you name it as such or do you pour it pour it over the other points in there? question, thank you. Yes, so We explicitly have a line that says 2025 30% project management Or scrum That's what we call it And it depends on The relationship it depends on the situation It's differs from time to time sometimes that that goes up, right? You need more time together to work things out because That's a type of relationship the type of client But we explicitly put it in there saying about well 30% or something is overhead. That's what's needed. Yeah, it's a lot Yeah, that's Yes, yes Customers are looking for that and say hey, can we can we reduce that? Why do you need three people at the table? Because if I only have one right and to explain Details will fall away. They don't feel your pain. It's kind of ultimately sometimes cost-wise as much So yeah, but it's always a tension point Any other questions? Yes? I Got a question regarding your proposals So let's say you got an RFP and how deeply you describe these Conditions in your proposals. I mean for example the penalties So do you do describe that these are your? Basically idea of proposed idea of conditions So what you mean is do we put penalties explicitly in or leave them out So if you respond to an RFP do you describe these preferred conditions? Yes, so yes, so when we get like the conditions and agreement from the client and this stuff is in it I will count to that But yes, we also have our our agreement and conditions that obviously are well how we see a partnership and These are ideal to ours. So that's what we use and They it's like a mutual thing So if we do the same thing as what I like clients do and I don't want it that's not gonna work Right, so it needs to be mutual. So yes, we have an ideal Thing what we want Okay, so I think I'm going to release the room for the next one to set up Again, thank you very much for coming and your time and