 Hi, everyone. I believe you've had lots of coffee, cos this is a... We're probably going to need it for this session. And thanks for inviting me, first of all, to my first World Camp ever, and to talk about one of my favourite subjects, which is projects. And some of the talks I've already seen this afternoon have been great, including Sabrina's, who her shout-out to the lean start-up was fantastic. But first and foremost, who am I? My name is Vicky Jakes. I am a project professional. I've been working on digital projects for over 10 years. Working in an agency setting, working with lots of different types of clients. Corporate, small business. And I'll talk you through some of my experiences working with those guys. I've never trained formally to be a project manager. I'm not Prince II certified or anything like that. But I have recently become a Scrum Master, which is terribly exciting. And I decided to stop working recently as a project professional and start working for myself freelance, helping small businesses kind of get sites online and get their digital marketing strategies sorted. So that's a little bit about me. So over to you guys. How many people here have worked on a project that went a little bit iffy at the end? Come on. You might not have been the developer or the project manager. You might have been the client or designer. Come on, let's have a proper look. Everyone here. Who hasn't worked on a project that went wrong? Lies, lies, lies. They're what I like to call dumpster fire projects, essentially. You know, like the type of project that just as you're about to hand it over to a client spontaneously combusts. And it's always in the last week, the last week where you're meant to go live on Monday and there's features that no one thought about that need to be added and some of the code breaks because you didn't have enough time to do testing. And the client decides to go away on holiday that week. So the project manager's doing design decisions and just everything goes wrong. You know the type of project, I mean. But it's good to know that we're not alone, friends, and that some of you have worked on projects like this. Maybe in the Q&A session afterwards you can tell me about some of those projects. Tom Cargill from Bell Labs famously expressed that the first 90% of the code accounts for the first 90% of the development time and the remaining 10% of the code accounts for the other 90% of the development time. It's a joke. But essentially what it's meant to say is that most of the work is done in that final 10%. And we wonder why. Because the project management institute with this lovely graph explained how projects really are meant to run. They're meant to be this lovely gentile start that kind of build up as you move into the development flow. The development all happens and then slowly tails off and then you hand the project over and it's all very calm. But actually I think that the reality of getting a project built these days is this meme from toothpaste for dinner which kind of explains in my experience how a lot of projects go. Works down in the final 10% and sometimes there's crying as well. So why have we all put our hands up saying we're still working on difficult projects? Why is that the case? Have we become the Snapchat generation? I'm not that old by the way, but have we become the Snapchat generation that can't focus long term? Can we only cope with briefings that are as long as an Instagram story? Well I'm a bit concerned because I think that the way that trends are going is that we're being encouraged especially from CEOs of big companies like Elon Musk here, famously telling Tesla employees if you're bored or you're not finding a meeting useful you can walk out. I'm really worried you guys about the commitment that we have to delivering projects these days. So I'll just refer to my notes here. An IDC improving IT project outcomes report back in 2009 looked at IT projects and that survey saw that a quarter of them failed and that definition was whether it went over budget or over time. Nearly a quarter of those had no return on investment and over half of those projects had to be reworked in some capacity so code had to be refactored, rebuilt, binned, started again. I get that right because back in 2009 when I was delivering projects it was kind of pre the Silicon Valley that Silicon Valley at Boom people weren't using agile as a phrase as they were back then and I get it. I get that projects would fail at that time. We were still kind of getting it right but looking at our friends at Project Management Institute again the pulse of the profession report that was released at the start this year that kind of looked at project successes nearly a third failed their goals and nearly half 43% went over budget and nearly half 48% over ran. That's nine years later. Why is this still happening, you guys? Why are projects still failing in some capacity? There should be an assumption here. Oh, that's a shame. I've basically highlighted and it's not shown up on the screen but the second two points are 43% over budget and 48% over running. Now when a project overruns it's likely that more build needs happen more testing needs happen and subsequently it's costing the project more money as well and you can assume that that is all happening in the final 10% of the project. So I've just picked a stock image here of people that work in an agency. You know, why are we working on projects that still fail? These guys, they look smart, they look happy, they work in an agency setting. They work with some really smart people over the years, developers, designers, UX specialists, clients as well and still we're working on failed projects. So what I'm going to do here quickly is just take you through some of the projects that I've worked on that have failed. I'm going to kind of see it as group therapy really so bear with me because I haven't always worked on bad projects but I'm going to share with you some of my own doozies. First and foremost, it's the pharma project as in pharmaceuticals. So this project was meant to be an innovation project for this particular pharma company. Adopting Drupal as a framework as opposed to .NET which pharma had traditionally gone for all in the past because it meant security but the idea behind using Drupal was very much that with WordPress it's a pre-existing framework, it's got a community, it's open source, so it doesn't cost anything and they were very attracted to that idea. Because the agency I worked for specialised in Drupal we could give a rough indication of how long that project should take and how much it should cost. The project was going to be connected to an external API, SAP in particular, and there were security needs as well so that API needed to run through the client's firewall and also if anyone here has ever worked with a pharmaceutical client you know that there needs to be a legal compliance to any content that goes out so that the pharma company can avoid millions of pounds worth of fines. This project failed. Failed. Why did it fail? Well, the scope and the strategy weren't really set at the beginning. I think we as an agency were so excited to win the business and it was a real game changer for us that we didn't really make that estimate into kind of a concrete scope and also because the deadline was fixed for when we had to deliver this another reason why we won the business we started kind of building and thinking that we would solve some of these problems that didn't get addressed in the scoping phase later on. And from the client's side the strategy wasn't really set and that was because there were so many stakeholders it's really common in the pharma world to deal with a brand manager who kind of works with a global brand manager who's got the legal team and the guy in the legal team doesn't understand what this internet thing is so there'll be another person connected with that there are IT guys, so lots and lots of stakeholders which meant getting decisions made was very difficult because when the decisions made by committee it takes a while. I remember we were in a fixed timeframe to deliver this project and so because we were in a fixed timeframe and the cost was also fixed any problems that we encountered like the big problem being the one that we encountered working with the API because there wasn't enough documentation so we had to do a lot of reverse engineering the process kind of got abandoned because some of the senior people at the agency thought that letting the client call whenever they wanted email whenever they wanted was showing value and actually sticking to the process would have meant we were dealing less with their emails and actually solving some of the problems so the project wasn't all bad it was covered in the end but over budget and probably about four months late but it just made people unhappy and that's not what we want when we come to our workplaces each day we don't want to be unhappy so the next project is a finance project specifically a health insurance company that we work with and this was a new concept, a new product that had been tested regularly with the market and when they came to us it was very much them being a start-up sponsored by the city and wanted us to quickly like build an MVP and bring that to market so that they could kind of test the concept and then get it rolled out to a kind of bigger client base again Drupal and a little bit of WordPress on the side as well this is kind of before it was either one or the other and with some custom code and lots of stakeholders once again so obviously this isn't about the projects that went well this is the projects that failed and this one failed it overran probably by about six months not because of us or anything that we did mainly because I think this project had too many stakeholders lots of people with lots of opinions and so that meant that the project started really before the scope was finalised because those stakeholders were kind of adding in new new feature requests a new request from the market as the project went on and again it was a fixed price project with a fixed deadline and so as we got to the end of that process there wasn't enough testing because we were so keen to get it delivered on time and of course for that enough testing it went out to market and then came back a code had to be rebuilt new features had to be added it was just a hot mess basically the final project I'm going to share with you is the agile project and I'll just do this agile like this this was a react web based mobile first platform and quite exciting because we were going to work with another agency an innovation project again and what was exciting about this is that there was a beta group of testers who were going to be able to provide us with feedback to then make changes to the features optimize it for those guys and then kind of keep releasing until they were happy and then go out to the wider market as agile should work this project failed again I think because the process failed agile was given a lot of lip service it was very fashionable at some point as I'm sure you guys can empathize to say a project was agile because the client loved that they thought it was very sexy very Silicon Valley and we didn't really get any communication from that beta group, not properly and in the end we were actually just giving a fixed deadline to deliver the project and so with all three of these projects kind of what happened was most of the work was done in the final 10% immensely stressful people weren't very happy and I think the first the first port of call in a project that's kind of failed just to blame the project manager or the lead developer or just blame, blame, blame or blame the client that's quite an easy one and I get that I get it's easy to lay the blame but it all depends if that scope was set at the beginning or not you see setting scope and then setting the parameters of how that scope can change in the beginning of the project is what means it won't fail as in overrun, over budget in that final 10% allowing a scope to have input from the experts at the beginning is vital to make sure a project doesn't fail if a sales person is selling something to a client and they're putting an estimation together and they've never actually signed that off with the tech team in-house or you might just be a one man bam working with a client working with one developer and if that kind of concept hasn't been fleshed out by the developer it's only been fleshed out by the client there's potential for the project to fail an agreement of what to do with the scope creeps also is fundamental for any project in order for it not to fail and that willing to be flexible can kind of be seen here in the old iron triangle which we've seen you can have all the features on time but it's going to cost you or you can have it on time and cheap but you can't have all the features and the willingness to be flexible with one of those points means that project won't fail on that final 10% because that final deadline can be moved or there'll be cash to allow for kind of features to be built leadership super important for any project not to fail I think that's a given isn't it our PMI report that I spoke about earlier details that executive sponsor engagement is the top driver of effective strategy delivery well what's all that corporate speak mean well essentially it means you need a gaffer on any project to see it through from beginning to end and that can't be the client and usually in house right it's either a project manager or a project director but there should be some level of kind of director level sponsorship happening for any project in house in agency I think because quite often project managers might think I'm just here to oversee the day to day process having a leader it could be even the MD of an agency but having a leader overseeing the project from beginning to end is vital because back to our PMI report they state that as stakeholder influence decreases projects cost more so it's really vital to kind of keep a sharp pair of eyes on a project from the beginning to the end and that's really hard when project fatigue sets in especially if a project's been going on for months in the pharmaceutical world we could be working on a project for up to a year there's a lot of project fatigue happening there especially if stuff's having to be rebuilt or you're putting it out to market and people aren't happy so you need to come back and test the concept again and great leadership is what enabled Gareth Southgate to take essentially what was a quite young inexperienced England team all the way to the semifinals but his project kind of failed in the last 10% as well so sorry Gareth the third point I want to talk about is process so we talk about process a lot in the project world we love process and process is vital for ensuring that a project doesn't fail at the end projects that fail at the end as the examples that I've given you guys just now have often failed because process got abandoned in some capacity because we were worried that the client might pass for their money back and we were worried about losing our reputations and we were worried that we weren't doing a good enough job so sticking with process is super important and agreeing that process for how a project should be delivered is done in that scoping phase and sticking to it well that's done by your leader and your leadership team and all of these things kind of link quite importantly together and why I've got your attention let's talk about agile as a process because it's given a lot of lip service but if a project is fixed price it's not agile it's never going to be agile if it's got a fixed deadline it's not going to be agile this hasn't got the impact but it should kind of come across as red but if your project won't allow you to iterate test and bring it back in and iterate it and test it it's not agile agile is all about allowing your project to be tested by the users like Sabrina was talking about earlier by the very end users that are going to be using the product taking that feedback bringing it back in, implementing it and bringing it back out and testing using the agile frame the agile framework using scrum methodology then you would never fail in the final 10% because you would always be improving that product so it's really worth thinking about how we can stop failing at our projects by maybe looking to agile and seeing taking the best ways of working for that for our own projects so one final nod to our report earlier which is the PMI's Pulsar professional report says that 83% of project managers report digital transformation has either moderately or dramatically impacted their work over the past 5 years which means that they found that implementing new ways of working a change in their strategy of how they work has impacted them greatly here who put their hand up I mean that's most of this room has noted that that they've worked on projects in some capacity I can say that change works it works and implementing that within your way of working whether you're a one-man band or whether you're in an agency setting or a freelancer implementing some type of digital change will work and it will stop these dumpster 5 projects because you might be thinking well I'm delivering fine Vicky great good for you you've delivered some bad projects in your time but mine are all fine guys over there but implementing just one or two ways of working improving would be it would be detrimental to your business if you didn't try that and I hear again and again and again from people within the agency setting client side as well if only we'd agreed this upfront if only we'd done this on the project if only we'd stuck to the process Vicky and I'll give you this kind of one last take away for how to improve your project process and stop all of the work the 90% of the work happening in the final 10% and that's all about accountability so we've talked a lot about teams and kind of the royal we the royal R as it were in terms of delivering our projects but ultimately delivering a project is all about the team members taking individual accountability now you might be thinking well I already do that I'm the developer, I do my development I'm the UX specialist, I do my UXing I'm the designer, I do that really well but it's kind of more than that it's all about ensuring that your team members are doing what they should do as well it's all about ensuring that you're raising questions if there's a problem if the client puts in another feature and no one's pushed back on it checking each other's work looking at the bigger picture for how the project should be delivered because ultimately we all want to do this at the end of a project we all want to look at memes on social media rather than get the rest of the project done and really we should be thinking individually as well as with the team about our own focus because if everyone's doing that then the project will move towards getting completed and making sure you've got the right tools as well and if you haven't raising your hand and saying so if you're worried about the project in any way shape or form is raising your hands and asking questions why? Is this the right way? Is this right more importantly for the end user? and making sure that you've got all of the information to be able to start your individual role is paramount so not starting the project before all of that scope is agreed will stop the project failing and then ensuring you've got inspiration looking to your gaffer looking to each other as well because then if you're asking questions your leader will listen to you if they're a good enough leader as well so just to kind of reiterate my kind of quick fix guys for how you should ensure that your projects don't fail in the final 10% is to make sure that you think about scope you've already been doing this but have a renewed thought about this when you go back to your offices on Monday and they're looking around for leadership if there's no leader could that be you? and asking enough of your project management professionals asking enough of your clients as well and then ensuring that there's a process and if the process fails in any way being the one to put your hand up and say what's going on and that's everyone on the project team should be doing that not just a project manager and that ultimately should lead to you having a dumpster project at the end of a rainbow instead of a dumpster fire project anyway thank you very much thank you Vicky kind of reminds me of being at school that 10, 90% sort of thing always the last night horrible memories any questions? no? does anyone want to share a bad project story with us? it's like group therapy yeah that guy over there I've got a question do you ever have problems defining the process of the process? in the agile world we're meant to not document too much and get going but I think if you stick to the framework of what you've all agreed as a team especially with Scrum I think you don't have to worry too much about the process and educate the client on that process as well I'm talking about the three things you mentioned defining what scope is defining what leadership is defining what the process is I can talk about this from an agile point of view when we're working in Scrum is that those things should be defined at the beginning of the project definitions should always be defined so I think that's a really important point is defining what that means for sure that's great you're talking about agile and you're saying it's iterative how do you define the scope and the deliverables when you don't know how long you're going to iterate do you understand what I'm saying? so what I'm talking about here is often when the project's fixed price and fixed deadline it'll often fail in the final 10% so moving to that is absolutely so moving a project to an agile style of delivery would mean that you'd avoid having that panic in the last 10% so it's not necessarily an advert for agile that I'm doing on stage here but I'm just saying it's much more beneficial to work properly with agile than paying it lip service okay on here no go on I'll let you steady okay that's on camera so you're talking about using agile as a way of avoiding the failure of waterfall projects how do we define failure because if agile's solution is to not have an end yes again is it dodging the yeah true and I think this is very top line and meant to be fun but defining failure at the start of a project is really important quite often in the agency setting which is what I'm talking about here failure is when something's gone over budget or over time and a client will often help define that as well but at the beginning of a project if we're all open to an iterative approach to delivering a project then there would be no failure potentially thanks anymore no last chance