 Okay. Some projects go good, some projects go bad, and some projects are just plain ugly. Hi there everyone. My name is Murray Woodman. I'm the managing director at Morf. And today I'm going to take you through some of the 150 sites that we've built over the last 10 years. I'm going to lift the lid on some of our successes and some of our failures and just hopefully come up with a few learnings that I can share with you all. It's getting ugly this one, Andre. Don't you worry about that. Yeah, so the title said it's a retrospective, but really I probably should have included the word burn-up chart in the title because this is the lens through which I'll be having a look at some of our projects. So yeah, an anatomy of a burn-up chart. It's got a few features that you should be aware of. Firstly, there's the progress. That's the green line that goes from the bottom left to the top right. You can think of that as the mountain you've got to climb. The gray line up the top, that's the total number of hours in the project and that will increase as new tickets are added to the backlog. And then we have that dotted line going from the bottom left to the top right. That's the ideal progress. That's the average velocity you want to have if you want to deliver the progress, the project on time. I find this chart has a number of advantages. Firstly, it's understandable for the project managers and the team and for nosy people like me that want to have a little peek to see how a project is getting on. We can also very quickly see the velocity of the team but more importantly, that ideal line tells you what the burn rate it needs to be over the project and that tells the project manager at the start how many developers per time period they need. So that's a very good thing for planning. You also have the concept of scope creep. You don't get this in a burn-down chart but in a burn-up chart you can see that gray line and as more stuff gets added towards the end of the project that can be a red flag as well. And finally, it's very adaptable. It can be done on a per sprint basis, a milestone if that's where you're working or even the whole project. So yeah, that's a quick anatomy of the burn-up chart. Let's go to the video tape and have a look at some of the good, the bad and the ugly. The first, I'm going to start off with something good because we've got to get the show on the road with a good one. This particular project, it has been referenced a few times in this conference. The great thing about this project is that we have a fairly steady outcome there in terms of the work that's been delivered. We were ahead of the curve. That means we're ahead of schedule and the little flat line you see there at the end, that's not such a problem in this case because it just means we've finished with time to spare. The client can do the UAT and the client can add their content. And all up this is sort of perfection in my eyes. But now that we've seen this, let's go on and have a look at some of the other projects we've done over the years. I'm just starting off with some bad things. Drupal wants to admit to being underskilled, but in this particular project was one of the first Drupal A projects we ever did, and we were really sort of learning on the job in a number of cases. You can see we got off to a really good start, but then we hit a lot of sort of flatlining periods there where the team really just wasn't delivering at a good rate at all. That could have been meant that we were learning or the client wasn't reviewing things, but certainly not a good situation. So we were jumping ahead and sort of flatlining a lot of the time there. The end result was that the project went over budget. The thing at the end there was really the difficulty in getting the client to come to the party as well, which is another feature. Another project a little bit similar. I'm calling this one FITS and STARS. You can see there at the start of the project we just had a lot of sort of flatlining periods. I mean this is basically a week goes by, no tickets get updated and the project manager will come in and kick the project along a little bit. That's not great. We want to see people updating the tickets as they go. It can be a sign that there's blockers or that the client is not sort of reviewing and accepting work as well. The little gaps up there means that the team is not really reporting on this progress and if you have bad data going in it's much harder to know where the whole thing's going. The most concerning thing here is that gap down. I mean it's very, very rare for us to have that, but in this case it did and this basically means we've had to pivot halfway through the project. We've delivered value and then it's been decided that that was not good value. Obviously not a good state of affairs. On this particular project it was a very sort of technologically demanding one and the client may have also changed their mind a little bit there as well. The great thing in here though is we were able to get the project back on track and continue the velocity. So yeah, all's well that ends well in this case. This particular chart here was another large project. I'm calling this the hockey stick. You can see around January the velocity picked up a lot and that's because another developer came on to the project to help it get some more velocity. As agencies we know that it can be difficult to resource projects adequately and we do our best but sometimes we can't get there. In this case we were able to bring more resources on but really having this sort of hockey stick kind of a chart is not a good look and certainly one to avoid. This is not really a problem with the project team. It's more the business owner or the person organising the resources. This one I've called the missing client. You could go back to the start of Morph really for this one. This is in our very early days and we really sort of had no clue on how to run projects. We delivered in our mind really really well and so the velocity was skyrocketing there but then I think the client went AWOL. They got sacked, they quit, whatever. No one ever told us. We then found another project owner and then another product owner and another product owner. I think we went through about four and each time they would come on and add another little bit of requirement there. It's basically a year of just living in limbo which was terrible. There was also content issues where they weren't able to do the content. The takeaway here is that you've got to have that great relationship with the product owner and also there is a difference between going live and actually delivering a project so we really learn our lesson there. The next one is the timid client. I know that sounds not so nice but it sort of was true in this case. This was a super massive project, three and a half thousand hours. I'm calling this the s-curve or the sigmoid for those of you into that kind of thing. You can see we started off slow. We hit some good progress and then we were just really slow at the end and this is because I think the project was so large that the client just sort of felt intimidated to get into it. It was like they were at base camp of Everest and they just didn't want to sort of set off on the journey. Once we got on the journey it was okay but you can see there towards the end we had scope creep and that's when the client really started becoming engaged at the end and I find this a lot in some government departments. People only really start to feel the pressure when the deadline's approaching and that was a hard one to get over the line there but we did get there. Another failure to launch. Okay, so good velocity on this one and in this case we were going to deliver on a certain date which we did but the client was going live three months later so in their mind they didn't have to worry about it until the last month and we were just in this terrible limbo of having this trickle of little bug reports and little feature ads and feature requests and we were kind of just not in a position where we can argue with that final sort of go live date. It's very hard to avoid this sometimes I think especially when you've got to conform to other people's timelines but certainly something you would like to avoid. And finally a good one. Here we have what I'm calling an exponential curve where our velocity is increasing. On this particular project the task is quite repetitive the developers are getting better and better each time they do it their velocity is improving so we're getting better skill, better efficiency but another awesome thing is we're working in total harmony with the clients on this one we've got visual regression tests that we run across a whole suite of pages the client's able to review that very easily and then approve and this is probably one of the smoothest projects we've ever had just because of that visual regression and that's been a really big learning for us and something we'll be doing more. Okay so what about the takeaways? Firstly it's a shared responsibility of course it comes down to the client and the delivery team we've seen that in some of the good and bad points there for the product owner they must be empowered, present and decisive I've put decisive there because they have to be courageous to make those hard decisions at the right time but they also have to be motivated to get to the finishing line as well for the project manager they have to be organized, attentive and encouraging they are the glue between the development team and the client they have to give encouragement to both sides give them a little nudge when it's time to get along and they also have to be motivated keep attentive to the progress of the project and get to the finishing line when it matters the delivery team have to be resourced, skilled and engaged the resourcing and skill is really up to the person allocating the resources but in terms of engagement the development team I really feel that they have to be communicative, alert to risk being able to report troubles as they're coming and keeping the issues up to date because the charts you get are only as good as the data that's going in so that's it, hopefully you've enjoyed seeing a little bit of the good, the bad and the ugly of project management and I look forward to your questions thank you, if you've got time A couple questions, thank you very much I've been in one of those situations before just to go back to one of the graphs I just didn't really understand how they work so the grey bar total budget and then green is spent so on this one here you can see towards the end oh no, the green is basically value delivered so hours delivered, it's not how much time you've done it's how many hours in your estimates that you've done so if you've got a five hour task and you spend ten hours, you're still only delivering the five hours so it really is the progress that you've made throughout but the grey line is how many of the total estimated hours for the project so if you had a lot of those ten hour in five hour estimates your green could be above the grey? no, no, the green should be below the grey because it's just on the estimated but just say here it may be three and a half thousand hours but if your team has had lower than expected velocity you may have delivered four thousand hours in time so if you're trying to work out profitability you'd still have to look at the total hours spent this is really just what you've delivered in terms of what are you used to pump those out? this is redmine, it's an open source issue tracking the old redmine, it's been a faithful tool of ours from the start how often do you look at those? when we have big projects going on if you always got them open in my tab I shouldn't ask this question but I'm going to that pocket stick curve please tell me that is something you classified as good because that would be me don't comment Jim ideally the grey line would be horizontal right from the start what do you think is the biggest factor in causing that to climb up? that's a good question some projects you got it locked in and you know but realistically the project for us we will sort of sketch out some of the core things and we have some flexibility in the issues that are coming in so we'll often leave a bit of time there for contingency or stuff that we know is going to come in so we would expect to go up a little bit if you know the project down then it should be horizontal in this case you definitely don't want to see that thing at the end because that means the client is coming in and throwing in curveballs and you've missed features that they really wanted that you couldn't really argue about that kind of thing at the end is not good is it because they haven't identified it at the start? yeah that's right but as you go through another point I made is it makes a big difference if there's an intermediary like often times we'll work with a design agency and they are the prime on the contract and there's that little gap between us and the client that does make it a bit harder to uncover some of those tricky little things which tend to come out in the wash at the end of the project I do like to have a bit of contingency there just to include those tricky ones