 Okay, so Let's start Welcome everybody. Thank you for attending this session. It's a pleasure to be here in person in Prague with you After such a long time to know known faces and to discover new people so just a little background about me before to start so I Used to be a civil engineer working in a big international telecommunication companies where I gained some project manager experience And then I started in parallel in 2006 software development and we discovered repel with my friend Nicola on the picture also Back in 2007. I was then freelance backend developer and one of the best thing that happened in my professional career was to to be fired actually and to To gain full-time to to do what I love meaning software developer and Drupal And our first Drupal con was in 2013 in Amsterdam and we also discovered the community and we really liked it So that was a chance and We then started our own company, which is called web stands. We are located in Belgium in most in the south part of Belgium So we are now growing a fantastic team of 22 people This also means that since the last two or three years had less time to do real backend development But I had to focus on the management of the company and Because we like the community it also means that we like to contribute and to give back And this is also the philosophy of this talk today to share some some experience building ambitious Drupal project over the last few years So the title for this torque is mine the last 20% Because why we were building this ambitious website We come to the same situation over and over that the first 80% of the project are running quite smoothly Seamlessly we see good progress We are really convinced that we reach everything on time We even accept some change request from the customer and then all of a sudden We don't really know what happens, but to cover the last 20% Takes more time than expected and we see some overruns in budget or in timing So may I first ask in the audience? Who is familiar with this situation? Can you please raise your hands? Okay, so Squad reassuring so we also wanted to check if this was something inherent to our company to Drupal or to others So we also did a small survey in our network and we collected about 20 answers So the people who answered the survey they have about 70 years of experience in software development They have profiled like CEO CTO project manager funders lead dev bis dev 80% of them they are doing Drupal and For the people who are not doing Drupal. They're doing either WordPress angular node. Yes, Amber Java, etc So we have small companies and bigger companies when they have a 42 employees And the first trend is that already more than 90% are familiar with this situation But the good news is that two-thirds of the people they are not surprised anymore. So if you have experience you get used to it So today I would like to go over five different causes for hoverence and for each of this I would like to explain a bit what we're talking about to give some hints or tips from our experience and then to enrich the topic with Advices from the survey. So the first group of causes is the misalignment between the customer and the agency And you won't be surprised that everything is communication and setting the right expectations in the beginning It can be a problem if your customer is also not involved Completely during the project For instance, we see sometimes customer that are not available until the end of the project when they see some concrete deliverers That are ready to be tested And this can jeopardize your project. Also, of course, if they come with late approvers late provision of content This becomes more difficult to finish of course in time and if you budget so What we are doing to cope with that is we are trying to be very clear from the beginning of the project Explaining what will be the different phases of a digital project. So you may know this picture from the internet Not all of our customer are really always digitally mature. So we they have to learn also during the project and You have to tell them what you expect from them at which fades what kind of content When do they need to be more involved or less involved? So everything is communication also to align of course, we're doing kickoff meetings But it's also very good to to keep the alignments during the project. So we organize steering committee meetings every three or four weeks Eventually if you know that the customer won't be available during The project but they have more time at the end of the project It's not a bad idea to also foresee more time and resources at the very end of the project to to cope with this feedback So from the survey we asked the people do you think there is a first time effect? So that it's more difficult when you start working with a project With your customer for the first time and the answer is clearly Yes, more than 90% of the people do believe that there is a first time effect and it goes better with time So that's a good news But maybe the lesson from this is maybe that we should try to limit the scope of the first project with customers So that we learn to know each other better Also some other advice we collected from the survey We should not underestimate the time that is needed by the customer to to provide inputs even if these are Simple inputs that you are used to to get maybe that's not so easy for the customers We should clearly agree on the definition of done. What does that mean? Are we aligned on what you're expecting? We should invest in prototyping so we use clearly we use figma for this But there are also other tools It's very good to to show it concretely what it will look like and also another advice is to deliver Something on paper, which is very clear on your assumption of what you're going to do For the second group of causes, this is about specification and you can have incomplete scope Never details specification or how do you handle change management? So When we go over over detail specification Well, I think you've all seen that we receive another request for proposal and it looks more like a Christmas wishlist than really Explanation about the business needs of the customer. So there it's very important to To discuss and to align with the customer to tell him that we are doing tailor-made Software development and we are not delivering industrial products So they have to understand the impact of each and every request that is in their document And we have to to manage that and to answer Also, some of the customers sometimes they just try even to to detail too much up to the technical solution That you have to implement and that's also an issue when you have to to tell him What you need is more of the business needs and not what you are supposed to do That's more the whole of the solution architect When the scope is incomplete what we try to do So it can be incomplete but because the customer just don't know what he has to specify So what we try to do is to allocate a bit more time for analysis at the beginning of the project in this case This presentation should have been called mind the first 10 person because in the end everything has to be clearly specified from the from the start Finally we have to what we propose also is to learn from project to project and For instance, there are some features that are common and are coming back in every projects What's what you're doing is we are going trying to build some templates for specification Asking the same questions to the customer from one project to the other. So for instance for forms We may ask them what are the fees that are required should the answers be sent to third-party services Do we have to go to a thank you page or to send an email things like that? You can save a lot of time doing this So from the survey people also notice that the business requirements Sometimes expressed differently when the user really start testing So you have to cope to that and be able to to change and to adapt also People remind us that we are doing estimates. We are in a competitive market and estimates are difficult so what we Encourage you to do is to do the job after the project is finished to compare your initial estimates with the time that you have really spent You are not always doing this, but it's on my point of view That's the only way to learn and to do better estimates in the future Also, that's not easy of course, but they advise us to Not come back on the decision on scope. We thought having a formal change request That's not an easy one, but we should sometimes try to be more strict on that Okay, so the third group of causes is the pressure So at the end of the project we often see pressure from the customer or the different stakeholders You can also be internal pressure for instance from managers or even from colleagues and What we tend to do is to allocate more resources at the end of the project Which also means that you burn your budget faster than expected So to cope with that what we have done internally we have built Dynamic dashboards that are connected directly to the time sheets of the developers So that we can see directly in real time the the budget that is spent Of course, it requires that developers are completing the typesheets and the level of advancement with quite some accuracy But this gives the ability to project manager to give early visibility to the customer But the status and the the progress of the project Also what you're doing is To ease the the final steps of the project We used to build some checklist for the goal life the usual suspects the things you have to do always for each and every project For instance a CO checklist infrastructure or configuration of the website So we can go a bit faster and be sure we don't forget any of these details finally We also advise do not an easy one, but don't give into the customer pressure Someone told me a spoiled customer is the last customer So in the end it's true if you always say yes to each and every demand Sooner or later you will lose the customer because you will come to some point where you you cannot say yes anymore so from the survey people also Tell you that you should Evaluate the risk in real time and be transparent with your end customer about that and and share the risk. That's very important You should accept uncertainty and imperfection and we completely agree with that. We are not perfect. So we should We should tell that to the customer from the start that we are not perfect and that there will be difficulties But instead of being perfect We are flexible and we are responsive and we are ready to to be really there when we need it to For as they said for instance to response to drifts and to the implication Finally, we try also to learn and to optimize for the future and that also what what's we are doing now The fourth group is the details and the finishing touches so That's one of the problem that some of the things may may look very simple But in the end for instance if I take the example of just user registration or login There are many different ways to do that and if you go into the details you can spend quite some time There are a lot of Exceptional special cases and that that takes time. They are unpredictable and this is often difficult to anticipate So you should try to give more visibility with the details to the customer and to do that Of course, we try to use some tools for the prototyping like Figma Another advice would be to go for the MVP. I'm sure everybody does that but MVP should not be 100% of the customer budget An advice would be to speed the budget and maybe only have 80% of the budget for an MVP and be sure that you will have some More budget for second phase or third phase and that will help Finally I should have some testing strategy and quality assurance manager. We still don't have that internally the quality assurance manager, but I think it's a it's a must to To to optimize the the last 20% So from the survey it's interesting remarks that says, okay, we also use tool for prototyping This they are very nice But they also hide the complexity of what you're doing and from the lower layers and so people tend to simplify and So that's that's very easy and you should try to explain the customer where the complexity lies another interesting remarks is that Okay, it is just normal that we spend so much time and resources to perform the last 20% But it's just perception that it's an overrun In the end it isn't The quote from someone that I really liked I wanted to share the devil is in details Okay, the last one never ending sprints so don't know about you but Sometimes it comes difficult to finish the early sprints for many good reasons can be lack of resources lack of people dependencies with other sprints or your Customers not really with the content or they cannot validate it and so this just jeopardize the the next sprints and the The end of the project So if you have any idea on how you can help with that and just use the app and put your comments and we'll discuss that in a minute What I would say is maybe this scope some of the features from the sprint if you cannot do it Of course the definition of the print before and is very important try to avoid dependencies with things that are not ready Hope won't be ready in the sprint the last one is really To avoid testing too early if it's not finished if the quality is not there Don't try to spend time for testing because you will pay it in the end and you will lose too much time and too much budget Okay, the last one from the survey we asked the different companies how much percentage of The rules they allocate to the different jobs and you can see the result here So 70% on the average for the project management analysis a bit more than 10% and They have quality assurance 6% and test 6-7% So I would like to thank already the different people who have answered the survey some of the logos are there And also the people who didn't want to have the logo on slide We'd like to thank my colleague Joffrey for the support with the slides and the project managers For the discussion and the inspiration about this talk. That's it. Thank you everybody so if you have question you can come to the mic or raise your hand and I'm also available tomorrow during the contribution or after this session if you want to discuss it further Don't forget to fill in the survey of course anybody Thank you for presentation just about the last slide the question you combine together the front end and back end depth Time like it will be nice if you split to see how close each of them Okay, just Do you have this information? No, you can share. I don't have it, but next time we'll split it Thank you. Don't be shy Do you work mostly with time and material or fixed cost projects mostly time and material and All this topic are related as well like or what are the expectations in the beginning of The customer in terms of time and materials. Do they have this? limitation of the budget in mind or you go as you go and see what exactly is Deployed and how it should be changed. No, it's very difficult I think they have the global budget in mind and so they don't really look up at the different phases and you know, so That's important to to explain to the customer the rules of the game from the beginning and I think If you see that they want to spend too much time into the details and you don't have the global objective in mind It's your role. It's your duty to inform the customer and to tell him look if you are doing this We won't be able to do this other test that is maybe more important to your business Do you try to clarify it that like the top limit of the budget they say you have That's the question they don't like to answer of course So yeah, if you that's maybe sometimes difficult with the first Project and it's come easier with the second or third project And so that's why also encourage you to not put the full budget of the customer in the first project and maybe Try to work together to get to know each other and when you have confidence it becomes easier after impression. Thank you so one of the things I struggle with is convincing Customers that it's important to pay Money for project management or scrum master. How do you what has been your observation and how do you deal with that? Well, I think we have the same observation when we send our time sheets and they always look at the time or the ratio of the project management against the development and Yes, we meet the same difficulties, but we try to insist also what kind of mistakes that we did was to timesheet Project management and testing other the same umbrella because they were this was done by the same people So we tried to split that and to be really clear on what time is spent on functional analysis What I miss by the project management on testing so they understand a bit better why it takes so much time Okay. Thank you everyone