 Hello. Hi. Hi everyone. Thanks for coming today. My name is Will Huggins. I'm CEO and co-founder at Zutcher. I'm Hannah McDermott, Head of Delivery at Zutcher. Today we're going to be talking about building collaborative partnerships and handling conflict in digital projects which makes it sound like we're really experts at that but hopefully it's something we all experience so just share our experiences with you and hopefully you will find that helpful. The key thing I suppose is you never start a project with the intention of falling out with the client everything starts all rosy, everything's really optimistic and you're getting on and then there's usually a point sometimes it's gradual, sometimes it's quite sudden where what you're delivering starts to diverge a little bit from what the expectations of the client are. Whether that's in scope, timescale, quality, cost often then communication become a bit strange and guarded, trust starts to break down and then eventually confidence is lost and when confidence is lost it's very difficult to come back from that. You can come back from it and turning things around is hard but it isn't impossible honesty is usually the key that we find so when things really break down it's usually the situation that no one is completely right and no one is completely wrong and so being honest isn't about culpability or blame, it's just about acknowledging where things could be better or where you could make improvements but also pointing out where all parties, all members of the team could improve and being honest with yourself as well. Escalation is also important so bringing in stakeholders from both sides at a senior level to make pragmatic decisions and practical steps that can be taken to start to repair the relationship and get things back on track and focusing on tangible outcomes so sometimes small steps so what's going to be the next thing that hopefully helps to build confidence again and repair that relationship but as with all things prevention is better than cure so there's usually a few things that you can do along the way that will help to prevent the conflict arising but also help to address conflict when it does arise so it starts with winning the business basically I've certainly been in pitches often with Hannah where I get the look when I know I've said something that actually probably isn't a complete reflection of what we are able to deliver and so it always starts with that really when you start the pitch you're really focusing on winning the business not finishing or completing the project and so often some of the things that cause conflict are baked in at that point so the key thing I think again is honesty so be honest with the client about what's realistic when they start saying things they want this this that in that time scale for that cost so it's really important that they understand what's realistic but also be honest with yourself other things the compromises or the request that they're making something that is going to be worth it for you is it kind of the quality or the product that you want to be delivering so you're going into the project right from the start with both sets of eyes are open and be clear about assumptions and risk and that I think for clients can be a real selling point is point out where you see conflict arising where's the risk that things might break down or the areas of the project where you think there's going to be the key sensitivities and again I think clients will respect that but also see it as quite a reassuring and confidence building element of your approach and it is about managing expectations so this is one of my favourite ideas from the internet but it is about you know you can't have everything you can't have the best product in the fastest time for the lowest money and you know there's lots of permutations about how you manage the interplay between those three things but ultimately managing expectations and framing each project within its unique boundaries so you know some will have cost pressures but are probably more flexible on time etc so really managing the expectations of the client about where the pressures are for them and what you can deliver and what's realistic for the project outcome So after winning a new project the next step is onboarding I think from my point of view I always say that onboarding is basically the foundation of a successful project and in this phase we'd expect to set expectations form the team and establish if we've got any known risks so kind of kicking off on that point first step is building those new relationships so from our point of view we see ourselves as one team with our clients but that might be easier said than done to paraphrase the spice girls how do two teams become one I think this can seem really daunting but there are some really straight forward and easy ways to approach this at the start of a project some of the things we suggested here ice breakers something as simple as setting up a shared mirror board where the team pinpoint on a map where they want to go on holiday next and talk about it you know those kinds of things can help reduce the barriers to forming those important relationships that will be important later down the line in the project other things like shared communication tools setting up a slack project that both teams can talk openly on to kind of break down the formal communication that might normally happen at the beginning of a project in person meetings I know this can be difficult with COVID and also with remote working but where it's feasible I think it's really important to identify opportunities for that and also looking for any early collaborative opportunities so are there any technical investigations or workshops that we can have early on to try and overcome those kind of initial barriers after those kinds of activities the key thing would be to establish clear roles responsibilities this might seem very simple and very obvious but it's normally one of the things that can cause tensions relationships with clients where one of us has made an assumption about as deliverable from each other which then comes to blows later down the lines I think some of the important things to consider when you are mapping out your roles and responsibilities are do you know what the roles are that you need in order for your project to be at success if you don't then find out and agree it are there any key roles that are overlapping so for example do you have a designer on both sides in which case what are the practical realities of that what will each of those designers be doing in the project and also are there any roles that you feel have been under resourced or not filled at all so for example if a client has said that they want to rewrite all of their content and they have one content editor on their team that's something that you should be raising as a flag and discussing with them to mitigate rather than it becoming a blocker or an issue later down in the project I think alongside this make sure that you capture it I've seen many roles and responsibilities tables in spreadsheets that are hard to read that no one will ever look at again make sure it's easy to read captured in somewhere that's available to both teams so a shared wiki perhaps confluence that's what we would use and also make sure it's circulated and signed off so nothing is a surprise later down the line when you say oh this is your responsibility alongside forming the team and establishing those responsibilities I think it's really important that we have a shared plan again it might seem like an obvious part of kicking off a project but I think it can be easy to delay this when we feel like we don't have all of the known variables so what I would say is start with what you do know and create that skeleton and keep it simple some of the questions that are really important to ask at this stage are are there any known milestones again seems obvious but has there been an agreed go live date are there any other milestones that the team are working to again are there any unwritten milestones or are there any stakeholder expectations that have been perhaps discussed informally that we should be aware of so they don't trip us up later down the line again are there any internal work streams so are they dependent on us are we dependent on them are they going to affect the formation of the team and also again obvious but client team availability are there big chunks of annual leave coming up are there any other things that might affect their ability to work effectively on the project and then finally at the end of onboarding I'd suggest making sure you create a risk register now I know everyone will resist the urge to yawn when I talk about risk registers but I think it's important to remember that they are basically an extension of your initial plan and it's also an opportunity really early doors to discuss issues or concerns from both sides not just from the client side but also from our side and make sure that we're having those open and honest communication channels obviously the other impact of it is that if we discuss them and agree plans we can also avoid them derailing the project later later down the line and as I said here don't just document them make sure you have agreed a plan and dates for reviewing them so then at the end of onboarding we've moved into discovery and this is another really key phase for establishing a successful partnership with our clients the first part is really understanding the product vision if we don't have that shared understanding how can we possibly work together on the project and we will inevitably diverge at some point the first thing would be to ask the client what are their goals for the project what are their expectations what does good look like what does success look like for them now they might not always be able to answer that and I think we could do a whole session on the activities required to answer it but I think some of the key things to pull out would be stakeholder workshops user research and technical workshops to help really crystallise that vision so we both have that shared understanding and also suggest make sure you document what is discussed it's very easy to have sessions in the early stages of a project and feel like it's just an open communication lots of ideas flowing and then two months later everyone's forgotten exactly what they've talked about so make sure it's captured in the appropriate way in order to then deliver the vision we really need to have a well defined product backlog this again could be easier said than done particularly if the client has little to no experience of this this is something that we've come across time and time again so I think it's important here to consider some of the areas where you can support also some of the areas that you should leave to the client to make sure that we can successfully work on that backlog moving forward so some of the areas I pulled out as do's would be to use your best practice and use your experience to help them whether that's training and how to write user stories showing them examples from other clients use that experience to give them the springboard show them where there might be weak areas in their backlog and where you would suggest filling those out and where you think okay what about if what's the negative in this situation have you considered these other user roles etc things like that also make sure they sign off their backlog it can be very easy to assume that things are ready but don't make assumptions make sure that everything has been approved from them the internal stakeholders or whoever is involved in that process and also make sure the team from your side and their side are appropriately involved so whether that's your lead developers who are doing your estimates and your solutions or designers and UX team members that also need to be involved in those tickets on the don't side I would say make sure you don't take so responsibility I think it's very easy to take that role when the client is not able to necessarily create the backlog on their own but this can lead to problems where later in UAT for example they receive something for testing and they say this doesn't look anything like I was expecting but they weren't involved in writing the acceptance criteria in the first place which causes that tension also don't try and steam ahead or fill gaps in the backlog it won't save time we have done this in the past where we think let's just move forward and we'll fill those gaps as we go it doesn't work it doesn't actually save time and spending more time up front is important and as I said there on the last point don't forget to size or estimate in the way that you prefer to do so and make sure you append your technical solutions also so then once we finish discovery the next phase is delivery so I think it's important here to mention that from our experience we've found that working in an agile delivery approach has worked really well for us and for our clients particularly as they're very hands on through the process I would say though make sure that you don't think working agile means that you have to completely overhaul everything that you do and all the things that you do frameworks are there to support they're not there to dictate and ultimately there's a spectrum of how you can apply those frameworks use what works for you and for your business and for your clients you need to modify or amend those elements to make sure that they are doing what they need to do for your business as long as you're able to repeat them consistently with success and that's the key thing to remember so over the next few slides I'll talk a little bit about some activities that work for us some of those are framework specific and some of them are not so much first one is regular planning seems obvious it's baked into all project management methodologies but I think the key thing here is to flag don't let them become out of date it should be regular but also it should be with the team as a whole and that means team members from both sides this is an opportunity for everyone to reset review those risks that we talked about earlier on on boarding make sure we're allocating tasks appropriately and also rechecking their priorities are things still as important as they were when we first planned out the initial plan identify any dependencies so are there dependencies within our team but also with the client team for those potential pitfalls are there any deadlines within the sprint that we should be aware of potentially are there stakeholder demos are there other elements that we need to discuss with the client before we kick off the other part we can't miss when we talk about ways of working is daily stand ups daily scrums these are really important to be fully transparent with our clients we find that they're able to always have a view of how we are progressing but most importantly obviously to manage blockers so flagging them but also finding solutions for them one thing I would pull out is make sure to keep them short it's very easy for these to become unwieldy and therefore lose their effectiveness so if there are areas that need to be discussed pick those up in a separate call with the appropriate people to make sure your clients are not feeling like they're being dragged on to a 30 minute journey that they don't need to be I would say we normally discuss with clients at sprint planning we use scrum to discuss whether it's needed but I think it can be a really powerful and simple way of preventing confusion both in UAT but also in sign off so can we bring in stakeholders early on to visualise what the outcome will be which can be quite difficult for them during discovery make sure you agree the agenda and allow time for the team to prepare it remember to set the context before you start a demo it can be quite unusual for stakeholders in particular if they've never been involved in one and they might feel like they don't know where they're coming in so remember explain what you're demoing and what it's about and what the purpose of the call is and then last but not least the retrospectives this is the opportunity for the team to come together discuss what's working or isn't and what they need to adjust moving forward as regular as planning it's very easy to skip it and think I don't think there's really much to talk about everything seems okay but if you have then regularly you'll be surprised at how much might get discussed whether it's minor or major it means that we're addressing it on a regular basis rather than letting it fester I would say anticipate the discussion points can be really wide ranging whether that's technical ways of working or other and make sure that both sides feel comfortable to share feedback and that it doesn't become a one-way direction so whether that's from agency to client or normally client to agency if we're working as a team it should feel like a collaborative space and then the final point I would mention is make sure you don't leave your actions in your retro this is a common pitfall and for us we make sure we at the end of the session review prioritise and then for the ones we agree are the top priority put them into the sprint so they're there and we can't escape them and pretend that we forgot about them in the next one so yes so and then I suppose it would be remiss not to talk about the times when it does all just fail and all the steps you've tried to put in place haven't worked and so you make the decision often jointly sometimes not to go separate ways and so it's important to think about how you handle that ending of a relationship sometimes it is better to move on and so one of the things that I'd advise is to take all of the same disciplines that Hannah's just talked through into that off-boarding as you would do to any other project so approach it really systematically and try to do a really good job of it basically so define what you want to achieve out of the off-boarding both for both parties and then make sure that you deliver that really cleanly and I think one of the key things that I would say is don't burn bridges so often when a relationship ends because the two parties have found it really difficult to work together it doesn't necessarily mean that that's the total end sometimes the client might think we just need to find a partner that we can get on better with and then they go away and find that actually find of them as well as the partner and say we have seen clients come back so it's really important actually to approach these things pragmatically and do it in a way where you really you're not burning the relationships you're just accepting that this project or this part of the relationship has come to an end and so to summarise conflict does arise you know delivering web projects is not easy and there's usually multiple pressures on from both sides so there's lots of opportunities for conflict to arise resolving those conflicts isn't impossible and it's always worth giving it every possible shot trying to fix the issues through the things that I mentioned you know real honesty with yourself with the client building practical steps towards building that confidence back up that you can deliver but ultimately focus on each step of the way and ensure that the communication is transparent from right from new business through to onboarding into discovery and then through that agile process that Hannah talked about and then just you know be honest all the way through right to the potential end that if you can't resolve things then find the best way for you and for the client to move on I think we might have run out of time for the next question you mentioned the agile delivery and you mentioned also the stand-up the topic here was the relationship between us and the customer how you integrate the customer in such events of the agile process it's just you consider them as part of the team and then they participate like any member of the development team then yes so we would as a minimum have a product owner from the client side so they would be participating in that way and therefore they're baked into that process by default they have to really attend those ceremonies but sometimes they'll be more from the client side also Hannah said you know they would be a core part of the team so you know just like the developer or the UX designer or the scrum master the client would be expected to attend not you know not the whole client project team but at least the product owner