 OK, so Cura Coto, welcom to my talk everybody. Thank you very much for being here. Welcome to Drupal South as well. I'm going to be going through a couple of things today, so I'm going to be presenting a couple of New Zealand government websites for our client Toyota Femwyr land information New Zealand. So these are the flagship linz.gov.nz site, and also chart.linz.gov.nz. I'll be talking about them from a project management perspective as well. And before I get into that, a little bit about myself. So, hi there everyone. My name's Jack Kilbourne. I know a few of you here. I see some of the Sparks team who I see with only daily basis, but I'll give you a wave everywhere anyway. I see part of the Lynns team here, so I'll give you guys a wave as well. And everyone else, nice to meet you. My name's Jack, as I said. You might be able to tell from my accent that I'm not from around these ways. I'm from Liverpool, over in the UK originally, but I've been here in Wellington for about three and a half years or so. I love the place. I've been working with Sparks Interactive for that time as well, and also love that place. You might see that I'm just bouncing around here to a mix of probably nervous energy, but also I'm a recent father for the first time, and so it's just my natural stance. Now I always think I have a baby on me, so moving about from there. Anyway, enough about me. What I'm talking about today, as I said, from a project management perspective, when I started writing this, I thought, how do I actually approach this? What do I talk about from a project management perspective? So I thought, what were the key elements from my perspective that I worked on for these two projects? And I narrowed it down to four things, mainly because they are four really key elements, but also because I like alliteration, and so we're going to talk about discovery, design, development, and delivery. I think that works especially well at a truthful comfort. You might notice that a couple of these things here might not strictly be in the realm of project management, so designs and development are not things that I will have been doing myself. We have designers, we have developers, but what I want to talk about is how I can give our team and also the client, the platform, the tools to be able to work on that, to design and to develop. First things first, so discovery. What are we building? The very start of a project, what are we actually going to be doing? So we start to ask a few questions. First of all, what's in scope? Now when this came out as an RFP, and we were applying for the project, there was a lot of information around the current website, as it was, it was a Drupal 7 website, and Toy2Defano wanted a rebuild of it, and so we could see what content types were in that existing website, what mapping elements were in there, what styles were being used, and so we started to have a look at that and think, how would we do this? How would we rebuild this in Drupal 9? And primarily, how does this fit with sector? Now, if you don't know sector, it sparks interactive Drupal distribution. It's a collection of Drupal core content types and IA that we see used on a regular basis throughout our clients. We install it and it just means that with any website we're starting from step 20 because we have that collection of Drupal core of content types of IA rather than starting from step one, and so we start to have a look at what was in that Drupal 7 site and see, okay, how does this go into sector? I'll touch a little bit on our pricing model because I find it interesting personally. I'll tell you how you put a price on something like this, and then, just briefly, last thing on discovery is how do we put all these elements together to put a plan in place of how we're going to build? So, first of all, what's in scope? We could see the content types, as I mentioned, and we start to match these to what we have in sector out of the box. So, for example, we have content type one, two, and three. You see, okay, they're going to match with sector page, so we have home page, we have landing pages, we have entry pages. These will fit with our version of page. We know that that's a really good step for us. We start to do this with all the content types that we can see in Drupal 7 and just match it one by one, what fits into page, what fits into resource that we have, what fits into news, these kind of things. Now, you'll see on the right-hand side there that we have custom elements. So, these are things that existed in the Drupal 7 website that weren't necessary. We went on to one match with something we had in sector. We thought, okay, this is where we're going to have to get creative. We'll build custom content types and see how we go, a little bit more on how we manage that. So, yeah, we start to map it to sector and go from there. Now, coming to the pricing model, as I said, I find this very interesting. Some of yourselves might find it very boring, depending on whether you like numbers or not, I guess. Also, possibly if you're a developer, you might not like it if you're in the more project management side of things. You might find this really interesting. So, when you are pricing up a project, where do you start? How do you put a price on a project? And so, again, using content types as an example, what we do is we break it down. We have a look at example one. We know that this is a match to sector page as we have it. Then we start to think, okay, if we're building this, what do we need to do? There's going to be three elements here. There's going to be front-end theming. There's going to be Drupal site building, and there's going to be back-end coding. So, we go about doing some estimates based on that. I chat with the team who are going to be working on this. So, our front-end developers, our back-end developers, our Drupal site builders, and start to get an idea of, okay, if we're building this, how many days do we think it's going to take? We put those days into a sheet here, and we say, okay, each of these elements for page may take us one day, for example. That then gives us a low-end estimation for a build for this content type of three days, which is $6,000. Now, when we're working on projects, we want to be nice and agile. We don't want to just give a set price. We want to be flexible. How do we do that? Let's have a price range. So, we have our low-end estimation. How do we come about getting a high-end estimation? We have a look at the individual deliverable. In this case, it was sector page, and we start to think about what might come up. What don't we know? What's the risk or uncertainty here? Now, for something like page, it might be relatively straightforward. We say the risk here is 1.5. So, if our low-end estimation is three days of work, times that by 1.5, our high-end estimation is 4.5 days. There we go. We have a nice range for this individual deliverable. We do that right across the board. We need content types. We do that across menus, across blocks that we're going to be building, across things like building and mapping elements into content migration. Slowly, but surely, we come with an overall price that we can work with, and we say, okay, here's what we think we can build a website for you for somewhere between this gap. Enough on pricing. Next thing here that I want to talk about is when we're discovering the website, and we're talking about this plan that I mentioned, how are we actually going to go about this? So, the original scope for the website was to build one website. We were rebuilding linestockgov.nz. Now, I'm not sure if you caught Diba Dabour's talk earlier on how to build your own mailchimp using Amazon SES. That's very relevant to one of these things here. So, we were having a look at the scope, and two things jumped out as well. One of them was the online chart catalogue. This is a tool that mariners can use to view charts of the sea and use it to ensure their navigational safety when they're at New Zealand. The second part of that is the notice to mariners. That's a subscription service that said mariners are able to use. They can subscribe to charts of different waters around New Zealand and say, okay, every fortnight I'm going to be kept up to date with any chops and changes to these. We're looking at that, and we're thinking this is going to be heavily customised. There's a lot of work that needs to go into it. A couple more things here. There's a different content management team who's looking after that content. So, there's a different owner within the main linestockgov.nz website. It's the digital communications team who own a lot of the content. With the online chart catalogue, a notice to mariners, it was a hydrography team. So, two different teams working on it. Two different audiences as well. We have land information New Zealand, lots of audience focused around things that happen on the land. How to purchase land here, how to access maps of New Zealand. For charts, it's not the land you're focusing on the sea, so it's almost a different audience. When we're looking at this, we're thinking, okay, if we have complexity, that could be decoupled from the main website. We have a separate content management team, and we have a separate audience. Should we decouple this? Sure enough, we put a proposal together and said, rather than making one website, let's make two. We then had to go back to the drone board, put that into our plans. How's that going to work? Resorting wires, timing wires, budget wires. Eventually, I'll show you these two websites that we've built. Okay, enough on discovery. Next element I want to talk about here is design. I said, design isn't something I'm going to be doing, but what can I do to help our designer or our designer? Now, we were given access to Lin's brand guidelines to be able to go off, but we didn't quite think that that gave us the direction in where we wanted to go and what we wanted to design, and so what were our design objectives and what we wanted to design and so what were our design objectives and so I was speaking with our designer and I thought, how can I help here? What do we do? And so we thought, let's create a design brief. Let's ask some questions and then have something that we can actually reference back when we're designing. So the questions we wanted to ask were learning why are we redesigning. What do you like or what do you necessarily not like from the current design in Drupal 7? What can we do better from that? And who? So, who are Toyota Firmware, Land Information New Zealand? Who are the audience? Who should we be designing for? We can create an element and designs based on the audience and based on the client and defining what exactly are these objectives. We want things that we can reference back rather than just sending off a design and hoping that it's going to be approved and we can put it into build. Can we have things that we can actually relate back to and say, OK, we've ticked this box, we've ticked this box, shall we move forward? So, we spoke with the lens theme and we put together this design brief. Now this is only one snapshot of the overall document that we came back with, but it was a really fantastic process with us and it gave our designer the tools needed to actually go ahead. So a couple of things I wanted to point out here are that objectives that came through that really shone above others where they wanted a customer centric design, so they wanted it to be modern, reflect modern standards. Lot of rich content, so lots of use of images and interactive maps to land information in New Zealand after all. We definitely want to be doing that. Reduce visual clutter, clarity is everything to make it a lovely experience for the user and use information that is inclusive and accessible. The next thing here was a new art direction and so as our designer started to put some images into the design some of these were using aerial imagery and we got great feedback from that. Everyone at the client side loved this use of aerial imagery it really showed that they were the custodians of the land and of the waterways and that image was something that we wanted to do. From there what I'm going to do is actually going to show you some of these designs actually in practice, so this is lins.gov.nz and you'll see a couple of things that I've mentioned here and so first of all the hero image is of this aerial view looking down so this is showing Tauranga Harbour over up north from here but it's a lovely view showing both the land and seas here and you'll see that there's really nice clarity on the website as I scroll down here as well we have the introduction of Maori motifs something that we wanted to include within the website great use of imagery here again and then things like this bringing in nice shapes and curves to the website when we spoke about this it was really showing how this image is almost hugging the content within the website and it was just that relation that we wanted to create that a user could visually experience from here I'm just going to go to another tab here and just show you again more of this imagery that lins have been putting together it's really nice just having that directive that when we're adding images to the site this is what we want to include fantastic use of imagery in here again we're going to some of the motifs as I scroll down and I think it was just a really good practice us defining what we wanted to get from design and then being able to reference back to it and so as we work through designs and development have we done this have we done this yes we have that's a nice ok I mean this here ok enough on design and into development so how are we building this time again something that I can't do myself I'm not a developer I'm not that smart I'm not that dedicated to one specific thing it's too much for me these guys are geniuses magicians it's cool but something I can help out with is providing direction and where can I help on that in this case definitely on the accessibility front so right from the off from this project we said that we wanted to build this and we wanted to develop this when it was just going to be one product linds.gov.net we wanted it to make it as accessible as possible we really wanted to be inclusive and it's something that we like to do within every project that we work on on sector as we were talking about this in the early days there was fantastic buying from the team at linds themselves let's do that let's make it a real thing a real aim and goal project what can I do from my side so I said that we build in a in an accessible way and we use tools to check our own work but how do we actually measure that there are things that we don't know and so again we spoke with the linds team how can we do this better and again there was great buy-in from that and we partnered with a third party company called Intopia and during the build the idea was I'd speak with the team here perhaps we're working on element A of the website element A may be web forms or may be mapping we're creating it and we're building as accessible as possible but what don't we know and so we can send over our work in development to the team at Intopia along with any designs to accompany that and just get them to review it and we just went through an iterative process where we send things off to them they come back and say you're doing this great you're doing this great you could do this better or you could introduce this and it was a really great steep learning care for us lots of great things that we can put back into sector and so we've seen amazing result from this not only in the linds website but things that we can put back into the community and so again let me just jump into here show you a couple of these so here we have a map of New Zealand now if you're visiting Wellington maybe you hang around here for a few days and you want to go hiking so what do you want to check you want to check the topographic maps check out this map user this is really great and before I say this this is a really proud moment for me I've always loved maps as a kid and so being able to stand in front of you all here and present some maps it's pretty cool sell it and we can just see these lovely maps that are embedded into the website you have the option to download those and ensure your own safety as you're hiking around Wellington jump back as well and start to tab through you'll see the way that our front-end developers have done on just creating structural elements so as you're working through these maps it's nice and accessible it's very structurally ordered and some of the feedback that we got from Intopia as they were working on this that the mapping elements in particular were some of the best they've ever seen from and accessibility so from maps into charts so perhaps you're here in Wellington for a few days and you want to go out on a boat let's check the charts let's make sure we're nice and safe here's the point where I type and spell things wrong because that's what everybody does typing and here we go let's have a look at Wellington harbour here here but you can see all these overlays these are different charts within New Zealand and you're able to access these view actual charts of New Zealand there's lots of great work there and once again let's go back to view it and hit into this to tab through these elements again you'll see this great structural order that's been set up there nice and accessible so really proud of this product that's the way building it jump presentation again and now on to the fourth element delivery more of a focus on the project management side of things how did we get to where we want quite simply we did this through fortnightly sprints so we wanted to be agile sprints is a great way to do that so we'd use trello boards to manage tasks and topics before getting into a sprint we would do something called pre sprint planning which I'm glad I've said properly because the amount of times I've said spree sprint planning and things like that the project over a year and a half it was countless times good on me second time around to target pre sprint planning we would work with the team and we'd say okay from our side these are the priorities that we want to work on over this fortnightly it could be designing content type A it could be doing the front end development of content type B it could be doing these accessible elements of the mapping integration in the website we'd speak with the client as well what do we want to prioritize from their side perhaps there's a certain team at linds who have particular window for testing okay let's make sure that we can be on track with them and we can marry it all together we do this pre sprint planning it was really important that we'd have clearly defined so everyone knew their role within trello we would assign people to each card and then individual tasks within each we'd set it within manageable chunks as well we didn't want to over promise what we could do within a two week window and so we'd go about just formulating our plans we knew the overall scope how did we get there we put it into and what we did as well along the process was just having regular workshops perhaps in a month's time we knew that we were going to be building a certain element of the website that we didn't have complete clarity on from our side perhaps we were building part of the website that we were unsure of the audience or we were unsure of the team who was going to be managing the content and so what we'd do is ahead of time we'd have a workshop we'd get everyone in the room ask all the right questions in the hope that we get all that means that by the time it comes to the build in a month's time we know the audience, we know the content management team we can work through things we'd also have regular progress meetings whereby a couple of times a week we'd just jump on a call for 15 minutes and we'd say this is what we've been working on this is the progress here let's have a quick chat about this any news from this task just have regular chat next thing I want to talk about from a project management perspective is something called a rag report now if you're not aware of this it is essentially a breakdown of all the open deliverables and you assign them a colour be it red, amber or green now if something is green it means that we're working on it and everything's fine we know everything that we need to know everything's going well from a build perspective we don't need to focus any attention at the time being because we're happy with where we are if we assign something the colour amber it means that we're able to work on it but perhaps there's things that we still need to figure out if so let's have a workshop let's figure out what needs to be figured out if we've highlighted something to be red it means that we currently have a road block and we're unable to progress within that deliverable for whatever reason and if that's the case we just assign it the best way we make sure it's a priority so how can we turn it from red to amber or red to green and so again prioritise it and ask these questions get the right answers allow us to progress a couple of days ago I was doing this presentation at home with my partner and I ran through this that's really interesting actually but why do you use red amber and green and not red orange and green that's a good question and we both came to the conclusion that's probably because ROG report just sounds weird I think ROG report much better until let's go with amber okay so the end products I've touched on them a little bit here showing you the linds.gov.nz website and charts.gov.nz but I'd love for you all to go away whilst you're here check out those maps to ensure your safety whilst hiking check out those charts to ensure your safety while sailing around New Zealand waters have a good time on them we're really proud of the product and website that we built it was a really fun, excellent project and yeah please check them out but for the time being are there any questions at all thank you yeah good question so the question was around how we factored in the accessibility elements and the time that's going to be spent there so sending reports for the team and then away and so the answer is from a discovery perspective that was done rather loosely to be honest we ensured that for everything building we thought about accessibility and so when I talk about risk and saying how do we add that in we made sure that there was range for us to work on within there then when it came to the actual product sorry the actual time itself working on accessibility we would essentially review where we're up to we'd have a look at these deliverables if we're looking at mapping a web form we'd say okay we still have this allowance to work to here this is what we factored in for accessibility let's go for it if it meant spending more time on a certain deliverable so be it we wanted to be agile we wanted to be flexible we'd just make it work we'd know that if we spent more time there it just means that we may not be able to spend more time on other elements there were things that we needed help on from an accessibility perspective more than others and so we would focus on them okay so the first question there was around custom object models there was a lot within the website we see these mapping elements and how we went estimating that and it was true and so the answer is we received a lot of good information by two systems here so first of all when we were going through the documentation that was part of the RFP there was a breakdown of things that we were saying these mapping elements are used for example and then we would be able to go and do our own research and see the compatibility going from Drupal 7 to Drupal 9 the second element of this was that early on in the project we were given access to a dump of the previous website minus things that we shouldn't have access to and so we were able to just go in and really have a look at that ourselves and then to be honest hope that it matched with what we've done to a discovery perspective a lot of it was pretty on point and so it helped that we did that the second question that you asked there was how we factor in project management and so what we did for this project was we just gave it a percentage total so if we say overall budget is or overall estimation is such and such project management would be 15 of that take that as an overall figure and we think that's probably a reasonable figure that would cover everything so a question there was around accessibility and a review process from that and so what we did was we had certain goals almost that we wanted when we were going to prod when we were going live sorry with the websites now we know that accessibility is it's ever changing so you can always work on accessibility even beyond us going live what we said was we'll do a real audit and review of the website so that's something we've been continually working on with Intopia they go away do a report and come back to us saying these are all the things that you can do better and then the team here at Sparks we'd work with the team at Lins and say what do we want to prioritise and so we had that list of everything that we wanted to work on and go about prioritising it doing it beyond project go live but really making sure that we can get to where we want to be yes we did have that goal or goals and we've been working through it it's been a great process