 Hey, hi there, everyone. Thanks a lot for coming along to the presentation here today. Project Manager War Stories and Tales from the Trenches. As we all know, project managers are a very important part of getting any project out. They're sort of crucial to the success of any particular project. They really act as the linchpins of a web project because they've got to connect various parties, such as the product owners, the stakeholders, as well as members on their own team, such as developers and solution architects and designers. They've got to be great at mediation, communication, basically juggling the balls and keeping the whole show on the road. They've also got to take responsibility for the delivery of the project. And that means being responsible for the success for the client. The project has actually got to be delivered and the client basically be happy with what they've received. Also, their employer has got to see the project as a success in terms of financial things. And the team as well should have enjoyed working on the project as well. How do they navigate all of these competing claims? It really does come down to experience. It's not just a matter of book knowledge. A lot of it is about being in the trenches and having been there and done that and taking the lessons learned and applying it for the next job. So here we are today. We've got six project managers that have been we've found from various Drupal web shops in Australia and New Zealand. When I was putting this talk on, I basically emailed out to everyone I knew. And six intrepid project managers have stepped up to share their hard-won knowledge with you. So what we're going to see is six lightning talks, five minutes each from each of the project managers. And then we're going to have some question answers at the end. So I encourage you to ask all the curly questions you like of them once they're finished. These are the people we've got. We've got Mara Malani. She's the owner of Marameo Designs. We've got Andrew Bogue, who's the general manager of Catalyst. Peter Molding, who is a consultant. We've got Ahmed Darby, who is a client service manager from Technocrat. Lucas Hodge, the owner from Media Insights. And Daniel Richardson, client service manager from previous Next. So basically these guys are all going to serve up a bit of an assortment of little tips and tricks and all that hard-won knowledge. So I'll get off the stage and I'll introduce Mara now to take care of proceedings. Hi, guys. My name is Mara Malani, and I'm the owner of Marameo Design. We help small to medium businesses to create, develop, and grow their digital online presence. We've been working with Drupal for about five years, and it's been an amazing ride so far. What I'm going to do today is I'm just going to speak about a bit of the quoting process that comes into a project. And I'm not sure about you guys, but every time I have to quote for a project, I feel a little bit of a combination of a 007, a mind reader, and a counselor at the same time. And it's also quite crazy and insane the amount of time and effort that usually is unpaid that goes into quoting all the time. So what I'm going to be doing is just trying to focus on minimizing this effort without pulling just a number out of a hat. I'm just going to share our approach on quoting, and it's by no means like a magic recipe. But that's what we do and it's working for us. So what we do is that we have just a simple Google spreadsheet. And so we just completely break down the project in user stories, as you do. And we assign a difficulty of one to five for every user stories. There is a really simple calculation going on here where depending on how many hours we think it's going to take to complete the user story, we're going to have a low range and a high range. So it goes from about 0.8 to 0.2 depending on the difficulties. So something like, for example, creating a content type, it would be difficulty one. Something, for example, like functionality that requires a module that we never used before and perhaps has a very big issue queues with bugs in it, it would be a difficulty five. That, of course, gives us an estimate range and we add project management on top of it and it's all good. Now, you can also find this quoting spreadsheet in www.marmadedon.com slash quoting. See if you want to grab it and have a look at it, feel free. So at the end of the day, the quoting exercise, I consider it to be a trusting exercise with the client. Most times when you quote on a project, the clients come from a referral or come from a website lead, which means that they don't really know you. And sending something like that through, it really sets the base for a transparent approach and relationship that you're going to set with your clients. And in our case, this works pretty well and we don't really have any issue with that. Sometimes it happens that they just say, we need a fixed price, we can't go on a flexible quote. What we do is we really try to educate them and explain that a flexible quote most times is actually cheaper at the end for them. But if you really, really need a fixed quote, what we do is just we get the higher end of the estimate and we add a 15% on top, which is the risk factor for us. Of course, there are things that you can do to minimize that risk. And the first one, it would be to start with the right strategy from the beginning, especially ask keeps of questions and do a lot of research, but more than anything, I think it's more like getting to understand what requirement hasn't been asked in that project because a lot of the time it's not what the client asked you to do, it's what they don't ask you to do, that you really need to try to find out in order not to get in trouble later. Prototyping is something that I found really, really important. A lot of people say, oh yeah, but it's take time and time is money, really is not. You can even do something very simple like a sketch and a piece of paper and the visual, the visual delivery that you do to the client, it really helps for them to understand that you really got what they want and it gets out of the way a lot of problems later. So it really saves you money at the end. And agile development, of course, keep really short sprints and reviews all the time, it really helps generally to minimize the risk during the actual project. Now this is by no mean again like a recipe, a magic recipe, and I really like to know how you guys do it and just to share this kind of conversation with you because I'm quite interested in this specific topic. Thank you very much. Hello, hello. My name's Andrew Bogue. I'm the Managing Director of Catalyst IT here in Australia. Over the years, I've sort of had a number of roles in the Drupal space from once upon a time, a long time ago, being a developer to being a account manager to even solution architecture and also general project management. And that's where I sort of come from in this particular talk is some thoughts around how to, you know, some thoughts that I hope will be useful in order to deliver, you know, have a successful outcome and that sort of component of project management, which has, as Murray well said, project managers do a whole lot of things, but I think ultimately they're about a successful outcome for the client and for yourself. So one of the important things with, you know, project management in this sort of scenario of Drupal is this whole idea of really getting Drupal, right? So we're an organisation that we don't only do Drupal development, we also do other things, we're all about open source software, but there are times when, you know, we will actually assess a project as to whether or not Drupal is the best fit and, you know, you need to understand what Drupal is good at and where it's gonna make your life harder or it might not be ideal. One of the examples recently is we looked at Drupal for a project and it wasn't actually, we weren't actually doing any content management, so there wasn't really much content and, you know, Drupal is a content management system and, yes, we could have used a lot of the bits of Drupal to solve some problems, but it started making the idea of using a framework a little bit more appealing, right? So you wanna be able to understand what Drupal is good at and how it's gonna make your life easier and where it is a useful instrument in your toolbox. And that's the thing that, if you sort of use it for the wrong thing, then or you use it for something that might, there might be a better way of doing it, then, you know, that isn't necessarily the best start for a project. So another thing that we think is really important is sort of the structure around a project, right? Now, obviously it depends on the size of a project, as to whether or not you have all these people available to you, but they each have a really important role and the project management should keep them all on the same page, but, you know, you need account management, you need someone making sure that the process is going according to plan and that the client is broadly happy and that the client is up to date with what's going on and the client is aware of which decisions are pending and, you know, what we might need from then. You need technical leadership. It really does show, once things start getting a bit tricky, if there isn't the right flavor of technical leadership, technical leadership also allows you to keep people on the same track technically conceivably because there's always more than one way of doing things from a technical point of view, even with Drupal that, you know, tries to standardize a lot of these things, there's always more than one way, there's always a number of, you know, there's always someone wants to do it this way and someone wants to do it this way and, you know, technical leadership at the very least means someone gets to make a decision and, you know, that decision is based on their experience and they see it as a net game for the project and they realize that, you know, we have to make a call here and that's what I'm gonna do. You know, Drupal developers, you need good Drupal developers, they're worth their weight in gold and if you have them on a project, that can be the difference between something taking one week and something taking six weeks. You know, DevOps, as it gets thrown around, operation support, depending on the nature of the project, it really is good to have someone who understands about how to set things, you know, how to architect things well. That's very relevant if you're doing something that involves some systems integration conceivably or, you know, you have some particular requirements around high availability or these sorts of things. You know, using junior devs is a great thing, it's good for the community, it's good for your company, it's good for the universe, but making sure that that mentoring process is done properly and that you're supporting them and developing and not just throwing them in the deep end and then watching them drown and then saying, well, that didn't work very well, you know, that you've got to invest in them and that needs to be part of your, if you've got the capacity for it, that needs to be done well and we've actually learned a lot about how to not do it and we're getting better. And, you know, obviously part of the team structure of a successful Drupal outcome is a client who also gets Drupal and he also understands what it brings and he also understands what you should do with that and what you shouldn't do and how you need to work with it. And, you know, one of the challenges is clients who want admin access on a Drupal site who just shouldn't have it because they just shouldn't have it because they don't understand that someone can click around and really break everything and then they want to complain that it's someone else's fault, you know, and it's this whole, but they sort of say it's my site and I go, well, yeah, it is, but you don't understand how to use these things, you know, so it's an interesting one and you really want the, you know, putting access control in place can be painful and, you know, sometimes causes many problems as it solves, but they need to get it, right? They need to understand that their Drupal brings certain things to the table. Another thing that we've, there is an ongoing challenge is this whole idea in the Drupal world of when to build and when to use and when to extend, you know? There are certainly, I've heard some criticism out there in the market actually from some people who, some clients who said that there are, you know, there are Drupal sort of developers out there whose idea of, you know, developing is just to download modules from drupal.org and install them, right? Now, that's a really, that's one of the pluses of Drupal is that you've got so much you can use it, you know, that someone else has contributed and that's a great thing, but you do also sometimes want to write code. You do want to write your own module and you do want to extend an existing module and you want to be able to make those decisions. You know, you want to maybe standardize a particular module as opposed to use two different ones. You know, these are things that, if you get them wrong, you earn technical debt or you get a solution that, you know, isn't necessarily what you want it to. And that's an ongoing discussion. I mean, the use of features, for example, how you use features in your deployment processes and in your code control and sometimes they're a bit of a pain, but you know, obviously they have real uses. Certainly, you need to be able, in my mind, you know, you need to be able to write modules. You know, you need to be able to do smart things with the tool sets that Drupal provides you with the APIs. That's what Drupal was built for. It was built to be extended, right? So, getting that right is a core part of a successful Drupal outcome. You know, the big picture as well, as much as many Drupal projects are really like a build and deliver, you know, you can and should be thinking about what's in the future. You know, you don't want to just deliver and run away because, you know, a great source of work for us is always our existing clients. You know, we don't want just transactional relationships with our clients. We want to do a piece of work and then another piece of work, right? You know, that's the easiest way to get more work is from people who already know you and who like you and understand you. And that's why you sort of, to some degree, need to be thinking about, you know, the tightness of your solution, the maintainability of your solution, you know, the dirty word of upgrades and all these sorts of things. But, you know, trying to really factor in as much as is feasible in the solution that you're delivering a great example there is if you're really going to be handing this over to your client to manage and run and potentially work on, then have a think about what they're going to need to be able to do that well. It's no good to say, well, you know, we did it, here's the version control, here's a two-page document, you know, you don't want to pass anymore so you can handle it, right? Like there are other things you can do such as mandated communication periods and you can build this into the project. Mandated communication exchange workshops, potentially a couple of events together where they're going to make some changes and this is going to go all the way through to a release cycle and things like that, which is going to increase the level of comfort in that particular case. So, you know, if you can, it is about, it's a long game as well as it's a short game and this going well, you get more work, which is another successful thing for everyone. That's us. That's us. No, that's not it. Well, what can I say this morning I was totally tempted to go into the FOI conference next door but I thought, Angie's presentation on Drupal and I'm going to show you one example. Corporate politics doing more damage than the worst coder I've ever come across. PHP site, we're going to convert to Drupal. PHP site, we're going to convert to Drupal. The site that I've described as CRUD, created by many developers, all using their own little personal ways of doing things. It was unreadable code, none of the developers wrote code to be read by anybody else. A lot of the updates were done by someone taking a piece of code, copy and across. So, if you had a particular field, had some weird code around it and it was used in 12 places. They'd fix it in one place and they'd copy it to another nine places. We'd have to find the ones they missed and it was worth all the editing. That was about it. All right, so the politics stepped in. The bosses were battling to control the project to make it their own personal little project. We're mostly salespeople, niche market. It would have been an Airbnb. Five years ago, they would have had an Airbnb running as a website. All they needed to do was put on that. They chopped and changed the project so much that it dribbled away. So, if you want to look up exsanguation, it's a technical term for what the management did through politics to the project. So, the story they presented when they asked for someone to fix their site, enhance it, give a better theming and so on. One application, sitting in a website, one professional development team did it and there was a couple of trivial errors to fix before we got onto improving the theming and navigation and so on. There were two completely unrelated applications written by completely different contracting companies. Both applications have been hacked to death by multiple contractors who had come in, made changes, hated the work environment, hated the code, gave up and walked out. None of the errors were trivial. They were all non-trivial and there were just this endless run of them. And mostly, programs had decided to just add their little bit on the end of the previous code making this great big long bit of spaghetti code to know the people, to their customers, to the customers you might find out there are heaps of problems, not just a few. Find out about their financial situation. So, you're gonna quote 50 grand for a project and they only got 10 grand in the bank and they're spending of their $5,000 a week income, they're spending $6,000 a week, so they're going down the gurgle before they'll ever pay you. Look at the code. Go on there for three days, five days, fix your first problem, see what it's like. If you haven't seen the code and the database, don't go for a fixed price or even a 50% overhead. I would be doing a 300% overhead. And then don't commit to six months. So, do this little problem, commit to that. In the building industry, that's progress payments. It's a big thing, weekly progress payment. And if they don't pay within a certain number of days, walk away. So, start again when you catch up on your progress payments. There's the conversion to Drupal. It's supposed to be two days a week fixing problems, three days a week doing the conversion. We'd end up four days a week fixing problems, one day a week starting the conversion. Then the next week we'd do four days fixing problems, which would change the database to code, and we'd have to restart the conversion. So the conversion never happened. So the final requirement I would have put in is a separate time for the conversion. The conversion goes ahead completely independently because it's so much easier to fix everything, change the theme, do everything else. Can you guys hear me at the back? So, I guess the purpose of this presentation is to talk about war stories. But let's start by reviewing every project manager's idea of Futopia. We have a starting point, destination. We have a budget to finance us throughout the journey, a scope to guide us along. But I think anyone and everyone who's worked in this industry knows that a lot of time it's supposed to look something like, this was supposed to be a picture of a globe and sort of going around the world to get from your initial point to your destination. Not sure what happened there. But anyway, you can imagine. And when you ask the question why, you often get a whole bunch of externalizing excuses and reasons. It was the client's fault, this person's fault, that person's fault. And generally speaking, you can abstract these excuses and reasons and genuine facts into two broad groups. Client-inflicted and self-inflicted. And I guess the purpose of my talk today is to share with you two war stories that are the result of self-inflicted issues and things that I'm sure a lot of you here see in day-to-day project management. And the general theme is one to do with over-promising and under-delivering and expectation management more broadly. And so the first talking point is really to do with goal planning. And I actually have a story that I'd like to share from a previous experience. And this is actually a real case. Basically, the abstraction of the client's requirements was to migrate a website from its current CMS over to Drupal. A couple of things to bear in mind. This website was not responsive. So it was just a basic desktop website. And also the client had a hard deadline. A hard deadline they had to work towards. Beyond that they incurred extremely hefty hosting fees and even worse they'd probably have to double up on their hosting fees so the old environment and the new one. At the kickoff meeting, and I've seen this personally, everyone's sort of quite excited and euphoric about this project. And hey, let's do this instead. Heck, why not use Drupal's base responsive theme? And all of a sudden you get three websites for the price of one, your desktop, tablet, and mobile. And the client was quite excited at that point. But I thought it was an amazing idea. Why not? Everyone was on board this journey. But then a few months passed and all of a sudden we're two months late. Two months late. So it's two months of hosting fees. At very minimum the clients had to incur because of the delays. Obviously these things take time. The client's not thinking about them day on the project. Everyone's in love with each other, right? And then the other thing also was what made things worse was the clients looking at this and saying, hey, the tablet and the mobile version of the website don't reflect our brand. And what's worse, and I'm sure there's a few technical people in this audience, was that the grid system isn't working properly. And that's not a simple matter of just switching out for one grid system for another. And then the project manager at Chirp City says, oh, hey, by the way, if you look at the original requirements, we weren't expected to migrate this across in a responsive manner. So then the question is, okay, so are you going to sort of unmigrate and put it back to a one-for-one? And do you also know that's not an easy job to do either? And what's worse, and I think this is something that I'd really like to talk to you guys a bit more during the Q&A forum, is that the UAT backlog of issues all of a sudden triples, if not quadriples, because in the original scope, you would only have to deal with one list of issues to do with the desktop to desktop migration. But now we have issues with desktop, tablet and bloody mobile, right? And so what you end up with is an extremely unhappy client, extremely unhappy client. The second sort of war story I'd like to share is one to do with this comment. I hear it over and over again, and I'm sure a lot of you guys hear the same thing too. Yeah, it will just take us two hours, right? So you're a project manager delivering a project, plowing your head, and the client comes along one day to stand up and says, hey, we have a change, all right? And before you open your mouth, and sadly sometimes it's the project manager themselves. Hey, yeah, we can deal for you in two hours. Yeah, it will just take us a couple of hours and we'll be fine. The client's really excited. They think, hey, you know, I thought this was gonna cost me 10 grand, it's gonna cost me just a couple hundred bucks. But it wig passes, right? And then we're sitting around the table with the client and the client's saying, hey, what happened there? And then you have people coming and saying, oh, I didn't realize we were going to hold this literally to this requirement. Or, hey, you know, all these dependencies and this and that and the other. And the project manager's sitting there breaking the sweat, literally, right? And then at the end of the day, when the PM has their PMO call, claims all on developers. And, you know, sadly this happens more often than we'd like to think. And I'd really like to leave some discussion, discussing solutions with you guys. And I'm actually interested in learning from you as much as I am interested in sharing some of my ideas around these issues. But that's basically it for me, thank you. Lucas Hodge, and I'm the director of Media Insights. So I want to share it today with you. So I'm going to talk to you today about the art of war. And I suppose my philosophies and my approaches to project management that I've used over the last 10 years, I suppose, with working with universities, governments and other organizations. So basically this is what I'm trying to avoid. This is like an artist depiction of a meeting. And there's a few of the, you know, characters involved in here. There's generally been five characters that I've dealt with with working in the projects that I've been involved with. So there's, yeah, designers, developers, there's executives. There's the site moderators or site maintainers and also freelancers. So yeah, as a project manager, you're an expert of dealing with conflict and trying to resolve it. There's always going to be different expectations, competing personalities, different needs, goals, values, et cetera, whether they're personal or whether they're connected to the company or the organization involved. So yeah, basically we're all human and conflict is pretty easy. But as a project manager, my primary goal or my primary aim is to achieve victory without battle basically. So it's trying to not create a battle in the first place by sort of noticing small things before they come problems. I'm able to deal with things, plan for difficulty where it's still easy. So it means I can get the most done with at least a matter of effort. So that's the mindset that I'm trying to take in as a project manager to avoid the battles. But yeah, I've failed lots of times and I'm by no means a master of this year. It's just my goal. So I think as a project manager, as some of the traits like, yeah, you need to have authority and trust from the people that you're working with. They need to be able to trust your viewpoints. You need to harmonize a lot of different viewpoints. You need to pre-comprehend sometimes things before they happen as much as possible and translate between business speak, code and type forms and whatever it might be. So you've got to translate between the different camps. Sometimes that means you're going back and forth between the camps and they want this thing and then you've got to mediate it. So consensus is also good as well. I found that by trying to get consensus decisions, you can get away with a lot of documentation and legal contracts, so the more consensus, the better. And the more knowledge that I have across the multiple spaces, the more I'm able to have a meaningful conversation with people as well. So yeah, I'm just going to share a few things with like how I dealt with some of them. With designers, it's definitely good to specify constraints. Otherwise you can end up with them getting carried away, trying to design the most amazing thing and you try and build it and it's not going to really solve the client's needs or the user's needs. Modifications always are going to happen, so the client pretty warned them that their fancy designs may change once it gets to the developers. And I found don't let them see work in progress, let the developers actually finish stuff before showing them. Yeah, developers, you kind of want to have good plans before bothering them because they want good specifications. And they don't like things being changed. If you come back and go, the plans have changed, they don't really like that. And you probably wouldn't build a house without having plans first from an architect, so don't let developers build projects before you've got plans in place. With executives, you avoid details, but found that trying to make their staff look good is a good way as well. Obviously they've employed their staff, so if you make their staff look good, then they feel like they've made a good decision and then they can avoid the details because they trust their staff. And for fun, yeah, try and tell the bad news in a good way. With site moderators, these are probably the ones I deal with the most, so obviously trying to make everyone happy, but if you can make these guys happy and you can educate and empower them, then they're not going to bother your designers or your developers as much as well, they're not going to ask stupid questions, so eventually you'll be their trusted advisor. Freelancers, pretty simple, try and not get the try and only involve when necessary and sometimes they might try and take your project in a tangent, but yeah, it's pretty simple, so yeah, that's my key goal is just to try and avoid the problem in the first place. That works, nice. I'm timing this Murray. Alrighty, I'm not going to share any war stories today. Those bodies are staying buried. Hopefully where people can't find them, but I am going to give you five tips that I've picked up over the years doing project management with previous Next and with other agencies, other companies, and I've got five tips and five minutes, so I'm going to correct straight into it. Tip one, why are we here again? It's a deep existential question, really quite deep, much too deep for a Thursday afternoon. Basically, this tip is about making sure that you know the organizational context of the project that you are working on. So I'm sure we've all sat in kickoff meetings, basically sitting there, everyone's sitting around saying, okay, we've got to build this really awesome Drupal site. How are we going to do it? What I'm talking about here is taking a step backwards and just sort of thinking, okay, why are we using Drupal? As we know from our experiences, some organizations have Drupal thrust upon them, some organizations choose Drupal, some of them make a decision by default, and what I'm really kind of getting at here is just take a step back, look at the client, look at the organizational context. Tip two, communication, everyone loves communication, everyone loves planning, all project managers love planning. And to plan effectively, you need to communicate, and that means communicating obviously with your internal teams, with your client, with whoever it may be, whoever's involved in the project, just communicate. But there's one caveat here, communication takes a lot of time, so what you really need to do is, at the start of a project, make sure the team is aware of all the communication channels you're gonna be using, whether that's Skype, IRC, RedMind, Jira, whatever you use, just make sure the whole team is on the same page. And also quickly identify the person that likes to talk. Every project has one. Sometimes it's the client, sometimes it's not. And just keep an eye on them because every meeting that person calls, every hour they spend sitting in IRC will be hours logged to your project. So just keep an eye on that one. But yeah, that's not to say don't communicate because communication is vital. Tip three, why do developers think documentation is evil or my struggle with organic groups? Yeah, so the agile manifesto has a lot to answer for, in my opinion, just my opinion. Documentation is very, very valuable, especially if you're working on projects with multiple developers or with multiple different clients, multiple different project managers. So the organic groups part of this tip, this is a little bit of a wall story. We recently built an intranet for a client. It had a huge organic groups component. Organic groups is a bit of a beast, I'm sure some of you know. And what happened with this particular site that we built was that there was a little beast of configuration that wasn't quite right. So this was raised as a bug. I went in to try and sort of triage this bug, couldn't do it, spent a couple of hours looking at it. Had to assign it to another developer. Now this developer is a really good developer, but he hadn't particularly used organic groups before, hadn't been involved in the project. So this particular very small bug ended up taking around six or seven hours. And the worst thing was, did a bit of Googling. First thing I did actually was a bit of Googling, found this issue, placed an entity issue tracker. But I couldn't quite understand the thrust of this issue. But it turns out the very first thing I found and the very first link I posted was the actual solution. I just didn't know it. And that's because the way it was written in the issue wasn't in human language. It was pretty developer centric. So anyway, just a little story. This tip will blow your mind. It really will. Tip number four, best tip. Developers are not your slaves. As a project manager, you might like to think they are your slaves. They're not. They're actually human beings, believe it or not. They stay up late, they live in the dark, but still developers, human beings, best thing you can do to a developer, be their shoulder to cry on. When they want to complain, listen. Take them for a beer. Let them just empty it out. Let them cry it out to you. Because if you don't listen to it, chances are the client will, and you don't want that. It doesn't make you look very good. It's not that mind-blowing. Come to sense. Tip five, what to do if it goes wrong? I don't know, you guys are on your own there. That's pretty tough. I don't know, it does go wrong with all the will in the world. Start of a project, you know, you've got the rainbows, unicorns, bunnies, everyone's happy, it's all donuts and coffee, it's all good. It can go wrong. What's the best thing you can do if you can't commit ritual suicide? I guess, don't lie to the client. Be upfront, be honest. Yeah, that's pretty much it. Thank you very much. Good tips in there. So, hey everyone, let's just thank all our six speakers while they're all out there. Thanks guys. Do we have a fixed microphone here for questions from the audience? I don't think so. Maybe, yeah, we'll just share one of these mics down into the audience. Is there anyone out there who'd like to ask some questions of the speakers today? I suppose that was just a reference to Robin Hood, Men in Tights. Just threw that one in there. Yeah, I'm trying to think. Yeah, I suppose it's just, with the executives, you probably just wanna, sometimes you have to tell them about news, so yeah, just try and do it in a good way. I can't explain. Look, it's absolutely a tough one. And if I could share a real sort of example, a project I was referring to for a very large government organization, we initially set up this expectation. Well, not as a technocrat, but this organization that I worked for, we set the expectation that we'd migrate these websites over in a responsive fashion, right? And there were actually five of these websites that we had to migrate. And the first two, the first one we migrated to blow out the timelines, the second one blew out the timelines again, and the third, and the interesting thing about these five projects were they were for five different business units. So the third business unit came along, and I think by then the team had learned to listen. The issue though, was we had to communicate to this separate business unit that they weren't going to get a responsive migration. And you can imagine the look on their faces. And so the way you sort of, I guess, I was able to sell, I actually, I was actually in the tough position where I had to step in and support the manager at the PM throughout that, was to actually say, hey, we're actually doing this for your sake. Yes, you're not going to get a responsive migration, but it doesn't mean your timelines are saved. You're not going to have to incur sort of double the hosting expenses. There's always something in it for the counterpart. The issue of negotiations is when you go in and think it's us versus them, you always need to put yourself in the client shoes and think about how can I somehow frame this to suit their own needs? And yes, it was still, I'm not going to pretend that they walked away sort of loving life, but they understood and they saw the risk that they were going to face and the problems they were going to incur if this went on and on and on. So that might be one example of how you sort of frame something in a bit more of a positive life to a client. Unfortunately, we're running out of time really quickly, which really sucks. But is there any other people out there with questions? I have one more thing very quickly on the bad news thing. One thing to bear in mind about bad news is don't run from it and the actual reception to this from a client is much, well, is better, although it's still bad, if you're the one telling them, as opposed to if the other one's confronting you with this news, so the sooner you get onto it and have that uncomfortable discussion, you might actually get some mileage, especially if you're talking to the manager. If that person gets ambushed by their own team and says it's all broken, it's all bad, blah, blah, blah, and then calls you angrily, there's a big difference if you've already called that person and said there's some problems you should be aware of this, just in terms of the perception and the expectations and the general happiness of the outcome. Just quickly, can each one of you comment on what would be your preferred project management tool of choice? I usually use Trello as a project management tool and I actually found out recently there is a great extension, it's called the Trello Plus, and it's great for agile development, it gets you track estimates and the track time within Trello and it's just a Chrome extension and it's free, so that's pretty good stuff there. For us, it's often which one the client wants to use, but Trello is good, Giro is good, Redmine has its uses. Giro for agile, a principle tool box for waterfall. Yeah, we use Trello as well, yeah. We use Redmine, but out of choice, I'd use Excel, I like to roll old school. First of all, I want to thank you all for some really great information there. For a small company which is graduating into a larger company and encountering all of these growth pains that you're sort of referencing here, I'd like to know, because I've had lots of competing views on this, how you feel about fixed quotes and when, if ever, they should be engaged in? Never. But when you have to, when you have to, right, you just, some clients will not get it, they just look at you and go, but hey, you're the computer dude, what do you mean you don't know how long this takes to do? If I go to a car shop and I say change my tire, they know it's gonna take two hours, you know? So you just have to, and you have to mitigate that risk and you have to put processes in place and you have to keep talking to them about it and you have to be ready to go to them and say you gotta give us more money or not, right? Like, and it's a scary one. Of course you can understand from their point of view why they want a fixed price. Of course you can. But, you know, sometimes the challenge obviously is, is when they don't really know what they want and when they don't really know what, you know, how they're gonna change their mind. It just depends on the work. Please repeat the question. Sorry, do we have the view that if it's not, if it's fixed price, if it's not, or if it's fixed price, don't take the work? I mean, it just depends. I mean, the other option is you can take pieces out, you can do things incrementally. There's some things you're gonna be more comfortable doing as a fixed price quote. You start as a, you know, try and put things into MVP status, do proof of concepts, do pilots, use the word pilot, you know? Take pieces out and say this is time material because we don't know and, you know, have scoping bodies of work. But once again, you might still get to the end and write a big, pretty document and all they do is open to the last page and look at the number. So, you know, it's an unfortunate reality out there and to some degree, you get to a point where you decide, do I want this work or not? And we've certainly been hugely burnt. You know, more often than not, guess what, it takes longer than you think. You know, guess what? Whatever number you come up with, someone comes in, how long is that gonna take? And I hear this, how many days and I go, triple it. You know, and guess what? It took five times, you know, so. And so a lot of businesses will split a project up the way you'd split up a house. You pay an architect to design it and you pay a builder to build it, even if they're the same company. So what's wrong with saying, I'll come in for a week, I'll write out the plan, charge you 10 grand or whatever. And then these are the next phases. This is how much, how long will it take? Each one will take approximately this and I'll give you a firm price after I do the first phase. It's at the end of each phase. You give a firm price for the next phase and if things turned out, the way a certain project turned out that I was on, you might just walk away or you might double one of the later prices. But on time, I see James got the mic in his hand there, but maybe just one last question, I think. So it's actually just a comment. Maybe that's more efficient. On the subject of positive communication in potentially negative situations, if you look at organizations that get fanatical customer loyalty, they're usually the ones, when something goes wrong, they admit it and they work really, really hard with their customers to fix it. So if you actually stand up and say, I'm really sorry, we totally screwed this, but we're going to make it good no matter what. If you have that psychological effect of giving everybody on the same side of the table, that's often incredibly powerful. And I mean, not to say that you should try and screw up, but it's a way of getting positive outcomes out of potentially harmful situations. So you should come to that. That's in the same room at 345. All right, thanks, everyone. That's all I think about. Thank you.