 We will be talking about today's eating elephant. Managing a big Drupal project. First thing to do is just explain, first of all those of you who just had lunch, this is always the toughest slot the last day. Is that better can you hear me in the back? Anybody up the back or up the top who wants me to stand up, I already am. So, this is always the toughest slot, it's the last day, it's just off the lunch, everybody's ready to have a little snooze, that's fine, it's been a long week for everybody and just enjoyed the time. It's called eating the elephant but that's a metaphor, there are no elephants in this presentation, no elephants were harmed in making this presentation. My name is Colin Sweatman and this is Al Croslin from Access 12 and this is not a technical presentation. So, those of you that are here because you want to find out about the technical building of Big Drupal sites, this is not a presentation for you. This is about the project management and stakeholder management for Big Drupal projects. So, we've got that clear up front so if you think this isn't for you, that's absolutely fine, we can't understand, but I just wanted to be clear about that up front. Okay, what we'll cover, this is not a specific case study, it's an amalgamation of lessons that we've learned on Big Drupal projects. We're not here to teach you stuff, we're just trying to share some of our experiences and some of the lessons that we've learned. Just so that you can maybe take away some of the things we've learned, it might be useful for you. Everybody's projects and everybody's organisations are different, you need to adapt and there's no one-size-fits-all approach. We're just sharing some of our experiences. So, what we'll cover is scaling a Drupal team for an enterprise project, keeping agility but providing a waterfall wrapper for the customer. We'll go into that in quite a bit of detail. Finding and keeping superstars, building team cohesion. So, once you've built your team, trying to help that team work at its top performance and something that we got some feedback from a few months ago. We put up a blog post on our site and said, look, we're doing this session, let us know if there's anything you specifically want us to cover. One of the things that we got some feedback about is how do you sell Drupal to nervous clients. So, it's not exactly within the mainstream of this presentation, but people did ask for it. So, we'll just share how we approach it. Okay, so I'll just touch over to Al. He's going to set the scene. Thank you, Cole. So, this is a pretty dry topic. So, what we're going to try and do to put it into some context is set the scene. As Cole said, we've got a series of projects that we've amalgamated together to try and make this presentation work. So, picture this, you're quietly sitting at your desk. You're in a senior role in a team. You might be on your fourth coffee for the morning and your boss comes up and taps you on the shoulder and says, mate, I want you to do me a favour and I want you to take on this piece of work. It's really going to be great, quite a bit of work, but it's going to be really something very special in the end. So, what he starts with is, I'd like you to set up a team and you're thinking, okay, so far so good. Oh, and they're going to be all contractors. You start to think, okay, this is getting a little bit worrying, but on the stress levels it's all okay. You then start to hear a bit more. He then says, I want you to develop a new website. It's going to support a huge community of users, 100,000. They're all going to be active and it's going to have a whack of content, lots of content. You start to think, okay, this is getting better. You then hear the good news that you need to audit and migrate 65,000 content items from existing sites. They're not Drupal sites in any way, shape or form. Some of them are 10 years old. Some of them are really, really complicated stuff. You're starting to think now, okay, how can I get out of this? You then start to think, all right, it can't get much worse. You then hear that you've got nine months to do it. You do start to hear some good news in that you do have a budget that is pretty flexible. You'll be able to get the people you need to do the job and you will have some pretty good control over it. But when you start to do the planning, think about the maths, think about how many days there are in a month, you very quickly realise you're going to need a big team, 100 odd people, probably internal, then with some huge suppliers to back you up. You also start to think that to try and use the most of time, offshore is going to do you some favours. So, the challenge has been set. You're already thinking, my God, on my stress, this is going through the roof. How am I really going to get out of this? What we did was tackle this one step at a time or as the metaphor goes, one bite at a time. So, I set it on the goal and the project. Yes, so I always got his stress levels up through the roof so the first thing you'll do is come and share that with me as his project manager and the first thing I have to do is start thinking about the project fundamentals and any of you that have run projects, the fundamentals are the fundamentals which is the old classic project triangle of the scope, the time scales and the quality and obviously you've got that budgetary constraint within it and even though it's almost a cliché and it's a gross civilisation from a PM's perspective it's really, really interesting and very important to just go back to those basic fundamentals and think about what that's going to mean about how you're going to get the balance right because you've got to get the balance right of an acceptable level of quality, not gold-plated necessarily but it's clearly got to be an acceptable level of quality. Try not to build up too much technical debt because of the speed at which you're doing stuff and also get it out on time because we've got a set launch date. So, I'll pass you back to him. OK, we're going to try not to pass the baton all the time. So, on to what we think is easily the most important factor of any big project is the people. We've been lucky enough to work with some pretty amazing people. I can see a few of them here, so I had to say that really. No, but they really have been incredible. We've been really lucky to be able to use some incredible connections within the community to get the best people and as I'll say it again, they are easily the most important aspect. It doesn't really matter what you've got to do. If you've got the people who will help you do it there's a really good chance you'll get there. What we do is always hire the best. We've been fortunate in that our budgets have been pretty good. We've been able to recruit heavily, get some great people but when you were trying to build a team from scratch the size of 100 people, you really got to think carefully about how you build that up. Our approach has been in the past to start with the senior people get some senior people who've got some pretty good ideas about how to deliver, get those guys in on the ground and get them involved in doing that recruitment. They want to choose the people that they want to work with. They want to be comfortable with them. They want to be confident in them. You want to get the best that they can out of everybody. What we've always done in the past is spend the time on recruitment. Sorry, there's a T under that hand. What that really means in general day-to-day work is you do spend a lot of time on recruitment. I think we spent probably the first few weeks if not months in interviews. I think on average we saw 47 CVs or resumes on individual candidates that actually made it into the team. Which is a pretty incredible amount but you do get quick at looking at people and looking for their expertise. Of course there's an experience that they can put on paper but you really need to be able to work with them so we would often get them in and have a bit of a chat about things. Not a traditional interview in that sense it was a bit of a discussion about how they thought these sorts of projects could be run what they're interested in generally how they see themselves working in the future what they want to get into. What we also try to do is give our technical people code tests and we're really specific about the things that they needed to meet and it was surprising the people that particularly devs who could really talk the talk but when they got down to doing that real specific activity of code testing they really struggled. Or vice versa, some not surprising couldn't talk but were amazing at what they could do in terms of cutting code. What we also try to do in that sort of sense of building everybody up was to make sure that everybody knew what their deliverable was. The team down everybody knew what they were responsible for and the areas they weren't. You don't want a high performing team standing on each other's toes it gets really complicated to manage and everybody gets pretty upset. So it was very clear what people were responsible for and what they weren't. The key part of what we were trying to deliver relied on a team not a group of individuals a team we spent a lot of time working on team cohesion making sure that they were happy working together again making sure that everybody knew what they were responsible for and weren't getting worried because they'd missed something. Everybody knew what their deliverables were everybody knew what they were expected to do and when they were expected to do it. They worked hard at that. What we also tried to encourage was a bit of work hard play hard we had a monthly happy hour which often ended in a few late nights but was great because you got to know people outside of a work context. It wasn't quite mandatory but it was pretty close we got a lot of people who enjoyed coming along some people just wasn't in their cup of tea we just found that having a chance to sit down with people was really enjoyable to get to know people outside of that work sense. I think the key part of having such a high powerful team is that you empower them to deliver. We encouraged our senior leads to resolve those issues within their own teams or at that senior level and not look for a steer every time something came up and they became very good at it excellent at it actually they were able to resolve any of those big issues that came up just by having a chat that had that great set of experience so they could do that based on that experience and they were not worried about trying to do it. Some of the brainstorming sessions that happened after midnight on a Tuesday, Wednesday night were really incredible. Lots of great things came from that. What we tried to do was make sure that everybody knew who the management structure was we wanted to sort of make sure that everybody knew who they could go and talk to make sure that everybody knew that there was a structure in place in the end it got quite flat in a way that we would meet regularly with the senior management team got to voice their concerns ask questions about how things were going or not and got to really see how to control what was going on, knew where we were aiming and got to put their two cents in about how we'd get there. As we said right at the start we had a big internal team but we also needed a lot of internal sorry external supplier help and we engaged some companies in India to do that work for us. As I said that gave us a great almost 24 hour delivery we got to use the time difference and they were able to help us in terms of that delivery. What we did do is made sure that our communication lines with them were excellent we always made sure they understood what we were trying to achieve and when we were trying to do it we also made sure that they understood what context we were working in they came and visited the office we had here in the UK they came and sat with the team they rotated in and around made sure they understood who they were talking to they had a face to the name when they were in a Skype session or having a chat over the phone The thing you've got to do though with those companies is make it clear what sort of input you want from them you set the standards early you make sure they understand what a successful delivery means what you expect in terms of timeliness and quality I don't think there was any doubt that our standards were quite high but our suppliers really rose to the challenge and were able to deliver for us and I think we have benefited from what was some pretty crazy time scales in getting the work done they were able to improve their processes at the same time we were improving ours you've got the delivery team right everything seems to be going pretty well in terms of the team itself but don't forget the stakeholders you've really got to show those stakeholders some love the first thing we needed to do was convince our stakeholders that Drupal was the CMS and many of you that have gone through it will know that it is quite a complicated thing to do stakeholders often come from a historical background of IT projects being really horrific very bad experiences of budgets being blown before anything really comes on board so what we tried to do was pitch it along the lines of Drupal being one of a handful of new back then open source products and we compared those to what was available then those costs of commercially off the shelf products and said that really what you've got to think about is how strong these open source products are already and how strong they are going to be in the market a lot of the I guess the reasons we gave them everybody here will know if you didn't believe in them yourself in terms of Drupal we really focused on the stability it had been around for a long time several versions in and a huge amount of features thousands and thousands of features it's a bit hard for stakeholders to get that in context so we spent some time showing them individual features and talking to them about what that would mean in terms of how you get delivery done quicker Cole is going to talk to you a bit about agile in a minute but agile and Drupal go very neatly together in terms of the stakeholders mind they can see how modules stick together they can see how they fit in a sprint at that stage what we also started to talk to them about was who else was using Drupal there's some really obvious ones White House in the States Data.gov here is a relatively recent one they really started to get their head around that if those sorts of calibres of companies and organisations and governments are using Drupal it must be safe we also started to think about what else was being done within the UK and lots of other companies within the UK they were also starting to pick up Drupal Government generally had started to look at it Captain Gemini has obviously got a big stand here they've really helped the presence within the UK of using Drupal Stakeholders generally are now getting their head around what it means to be able to use such a powerful tool then interestingly I thought this might have been a bit of a nervous point for them but the community aspect was a real selling point having tens of thousands of active users who are really active in promoting the product help get their head around what a big community helps Drupal, drives it on makes it happen ok so we told them Drupals to go we sold them Drupal, they finally bought up to it then we spent a lot of time making sure they trusted us and we thought that was important so they would let us get on with things we tried to build that trust by showing them we wanted them to see how things were progressing and you get that different level of interest some stakeholders want to see things some don't really care problems there are, someone to know how much the budget has been used, how much you've got to go in terms of time scale what we focused on was showing them progress and we would do it all the time and to anybody who was interested anybody who asked we would show them some people were uninterested in the design piece some people wanted to see how many servers were in Iraq literally we would show them whatever we could and as often as we could what we also tried to do was make sure that we had a really strong reporting structure of our delivery and Cole will talk a bit about this again we made sure that there were traditional reports that were available to the stakeholders we made sure that they had the things that they used to see risk reports for example red amber green where are the problem areas, what are we worried about what do we think we're doing in terms of progress we're up in this area but down in that why is that and I think we ended up reporting on a weekly basis in some detail which is a bit of an overhead but really a good response from our stakeholders and they were able to trust us to get on with it you hear some horror stories about stakeholders being so hands on and really grinding a project to a whole because they can't get the head around what's being delivered and don't really trust what's going on we got in some ways quite fortunate that our stakeholders were able to let us get on with it okay yes so we talked a little bit about the project fundamentals a few slides back and I was just talking about the people both internally within the project team and also on the stakeholder side of things so now we're going to cover some of the slightly less glamorous but very important processes around running a project like that this isn't going to be a project management so now it's just an overview and it's just those lessons that we learn so the classic comparison you're always going to have about how you're going to deliver any kind of technology project that's agile versus waterfall but I think that most people here would say that waterfall is great for building things like bridges where you know what type of bridge it's going to be helping a gap you've got to get across what materials you're going to use how much weight does it have to carry you know everything up front waterfall's fine for that, it's really good but it's not so good for technology projects, particularly web projects where the business requirements emerge over time as you're working on the project and an agile is great for that kind of stuff, technology projects however big projects, the projects are the size that we're talking about by the very nature because there's so much money involved and they're so high profile we'll always be funded and governed in a kind of waterfall very structured world so the challenge that we've got in the business is how can we deliver our projects as agile projects but put that kind of waterfall wrapper around them so what I call this is kind of tactical agile so the kind of day to day, week by week internal team approach which I do it in an agile way but particularly the pms role is to try and apply a waterfall wrapper around it which goes out to the governance model and the stakeholders so that it's related to that trust and confidence thing the more trust and confidence that you can build in them the more freedom they will give you you know that you need a lot of freedom as a project team to be able to run agile really well because you have to be able to flex and adjust and inspect and adapt so I'm just going to have a quick word on evangelism because I know that project management methodologies people can get quite emotional about it so can I just ask is anybody here who's a Prince II practitioner or is Prince II qualified so there's a few hands up there are there any certified scrum professionals out there yet a few more hands out there so it's all good stuff but my personal opinion my advice to you is if you're a PM or if you're you have to deliver a project and you're thinking about methodologies just use what works try and do agile within the team Prince II star reporting and governance support outside the team don't get hung up on methodologies guys in this room there may be one or two exceptions but we're not actually paid to evangelize agile or scrum or kanban we're paid to deliver great websites and methodologies are just tools in our toolbox and just use the tools that work and adjust them and adapt them it doesn't matter if what you're doing is slightly different to the way Crenshweibo tells you you should do scroll it doesn't matter because Crenshweibo is not the guys going to get fired if your project doesn't get delivered so just use what works the job at a PM in a situation like this in my view is very different from a traditional PM role which is much more about controlling monitoring kind of being on top of things all the time in my view it's more about support for the team and support for the stakeholders so that's in terms of providing that visibility the reports, the really good quality business intelligence about how the project is going so that they feel completely in control so that you also have got information to the right people as far in advance as possible so they can make the right decisions about steering the project around so that's where you get into things like managing your risk portfolio really trying to look ahead of time about what roadblocks are coming up and also on a more day-to-day basis within the team my view is certainly on these projects that are very much lesser of a PM and almost kind of like like an agony auntie almost in some respects my job was to help the team right down to individual levels help them get their blockers out of the way just look around and slightly kind of adjust and nudge things back on track not step in with great big boots and stop people doing things the aim was to give the teams and the individuals within the teams as much freedom as possible for them to do what they're good at we put a lot of effort into picking superstars if you've got really good people you have to trust them and you have to give them as much freedom as possible to really shine so so within the team we ended up working mainly using 10 day sprints we tried 5 day sprints up to 20 day sprints and for us that project 10 day sprints worked best and a kind of typical kind of scrum thing but it was actually in some areas it started to evolve into Kanban we were doing some Kanban stuff which is kind of a slight flavour on the kind of standard sprint model where you measure how much capacity to go into the sprint and that was driven by team members themselves they came back to me and said actually you know we'd be thinking about this and some of us have been away and we've gone away and done some reading we've done some studying about Kanban and we think what we're doing will work better if we do it so I said yeah sure okay let's try it classic agile inspect and adapt we had cross functional scrum teams so you'd have your BA's, your devs, your testers you'd also have dev op support you'd have architect, solution architect, technical architect designers, UX guys all working together in some cases they were less embedded than others obviously people like BA's and devs and testers were really closely coupled in their cross functional teams were very deeply embedded in those cross functional teams whereas maybe the dev ops guys, assist admins and assistance engineers would just have a fairly light touch across those cross functional teams outside the team my responsibility as the PM was to make sure that outside the team the people that needed it the decision makers, the blokes and ladies with the checkbooks the traditional kind of highlight reports they got good risk management and great visibility of risks that were coming up so that they could make business decisions well in advance which obviously helped us as a team about how we mitigate those risks and obviously change control which is a bit tricky where you're trying to deliver agile because you know changes built in as we're doing it as agile but where change could start to get really big or potentially really big changes to what was required in the backlog we would have a mechanism so that we could stop the stakeholders who were going totally crazy and saying actually you know we know we wanted a port site but now we've decided we want to do an auction site something that big or really big changes to the components of the site we would have kind of threshold so that it would have to go into more formal change control so that way we mitigated a lot of kind of feature massive scope creep but all of that water falling wrapper part of my job is to shield that from the team as much as possible because they need to be able to work in the agile way not get hung up in all that kind of stuff and I'll talk about some of the tools and communications tools and stuff like that that we used to try and help that happen so I didn't have to go around micromanaging people and asking individuals and senior devs and some of the leadership guys on the delivery teams for status reports they naturally did their burn down charts we knew what a bug backlog was all that stuff was being delivered anyway just as part of their day-to-day thing and that day-to-day work and I could just look at those reports and consolidate them without bothering people so they could carry on in code and delivering great functionality so we had a product backlog and on a big project like this the way we worked is we sliced it up into what we called components and then within a component increments so a component would be a massive thing like search but within a big component like search you might have an increment which is to deliver one particular part of faceting we'd only work down to the detail level as stuff got closer in the backlog in terms of time there's no point over engineering it doing loads of really detailed user stories for things you're not going to be delivering for six months because there's a good chance that the business requirements would have changed and all that work would have been wasted anyway could you have to do it again so the stuff that was the highest priority stuff was the stuff that we defined in the most detail so it was defined and actually we got pretty good at it defining it and getting the user stories and all of the acceptance criteria nailed just before it went into it was ready to go into the full sprint and that worked really quite well broken down obviously product owners normally you typically have a product owner for an agile project something this big it's absolutely impossible to have a single product owner because no individual could get their head round the scope of it and have the level of engagement that you'd need also because of the waterfall way that the stakeholders wanted to work with us they didn't want to get involved on a day-to-day basis in the way that you really need a product owner to get involved so what we did was we agreed with them that some of our senior management team from within the project team would be specialised area product owners so there would be a technical product owner there would be user experience product owner there would be a content product owner for example of those big broad areas and there was very senior guys within the project team and we got a formal mandate, a sign-off from the stakeholders that they had the ability to make the kind of more day-to-day changes that you want from a product owner so that the product owners could get involved with the cross-functional teams the devs could come and say talk to a product owner and say look you know you said you wanted this pink well it's going to take us three days longer to do it pink are you happy if it's red and those area product owners had the power to be able to say yeah let's fine just do it that way the really big changes if we thought that's going to be really tricky it's a big change then we'd push it up it would go outside the team in the formal reporting that we talked about earlier on and then again that's something that the stakeholders would make the big decisions on but all the more minor ones the ones that can really slow a project down we got the sign-off to be able to make those changes because we had really experienced high performing senior management people in the project team that had enough trust to let us get on with it so building the trust up with the stakeholders is really really important if you want to deliver a big project quickly and they acted as I said they acted as proxies for the stakeholders so they were the guys they were in our team so it was great we had fantastic comms we could talk to them all day long day in day out a UX guy could talk to them about something the user testing guys that we had could talk to them about things our front end devs could say do you want this kind of JavaScript thing to look like this well you know it's kind of going to be a bit tricky can we do it like that and they can just make a decision on the spot so it's great okay so as well as the kind of project management processes we also had a big range of standards that we had to think about upfront to put in place across a whole range of things which are wrapped around the project and wrapped around making sure that the quality of the finished product is good enough so things like accessibility standards other non-functional requirements like security, performance load coding triple coding standards all those kind of things we had to make sure think up front about having those well documented or well available online team intranet which we built using open atrium of course and when you've got 100 people and you've got new devs starting almost every week you have to make sure that that information is easy to hand so they can learn really quickly about what the standards are to work to a whole bunch of stuff we had to do about testing massive amount of work we did on testing both automated and manual testing we learned a lot of lessons about the amount of work there is in setting up continuous integration environments for big projects like this I'm not going to go into technical details I'm not a technical guy but we learned some big lessons about that a couple of people were smiling because they've heard me say that about a thousand times usability user testing was a huge big deal we got a great mandate from clients to be able to go out and do loads and loads of user testing if you can get clients to let you do it and show them the value of it it pays massive dividends I'm sure most of you know that anyway and user testing and usability and user testing because you can build a great functional website but you may miss the target because it doesn't actually work the way your demographic wants it to work release management loads of stuff on that, the way we did code submission the branching and all that kind of stuff and then config management which obviously on a big site like this where you've got very big environments a big infrastructure footprint the config management side of things is really quite important I'm sure that will work well so we'll just pop it for that and again I'm going to go into details about that one either so that's about it on the processes and around the supporting activity and the operational readiness type stuff that we did around there and I'll push a record to that thank you so I counted Cole only five walked out then I won the bet we thought processors would be really tough after lunch we'd lose a few people couldn't handle it okay so we've talked a lot about the people the stakeholders managing those relationships with the suppliers Cole's talked a lot about processes which are crucial deathly boring but crucial the other thing that we think is hugely important is operations first thing I'm going to talk to you about is accommodation and this is really basic stuff but on a big project with a limited time it's really important it can open plan office we found that in our open plan office it was a lot easier for people to communicate you didn't have to guess if somebody was in their meeting room in their office to go and have a talk to them you just looked up and there they were you'd wander over and have a chat it's a really important piece to think about how often people are going to be sitting at that desk possibly on weekends, possibly long time make it open plan, make it bright comfortable I don't think I'd want to sit for a long time in an uncomfortable position or in a dark room the other thing we tried to do and this had some positives and some negatives is seat teams together some of our senior team wanted to try and mix that up a bit so we might have the front end dev sitting with the designers for example but we had some big teams particularly around content for example that needed to be sitting together so that as editorial standards changed they could easily talk about it they knew that everybody was on the same page and applying the same things the same way we also had a few interesting discussions that moved people around quite a bit within management it's a real conundrum I think you can find that if you're within your team and you can hear what's going on you can easily sort out any issues and answer questions really quickly on the flip side people are often concerned about voicing their ideas if the management are there so we ended up with a mix we ended up letting the senior lead or the team lead choose whether they sat there and it was different for some people some people for the development for example just wanted the devs to get on with it they knew what they were doing they had a really detailed spec in front of them that they could work to it wasn't as like there was as many questions to answer or ask about solutions architecture different story needed to talk amongst themselves get a steer from our senior technical lead make sure that they were following the plan what we also made sure and we were pretty lucky in that we got to choose what sort of accommodation we had we were able to leave some space for breakout areas and wherever we could we stuck whiteboards on the wall we even had some whiteboards on wheels that just literally moved around the office it's amazing what happens when there's a whiteboard there somebody will draw on it and get some ideas those ideas are easier to convey particular for people and I'll pick on devs again who are not great at communicating drawing the picture makes it a lot easier for people to understand visual representation really helps what as Colser we also had agile which meant that there were some very enthusiastic planning sessions lots of yelling and carrying on which is great and really helps camaraderie within the team but not so good if you're trying to sort out how you install module X so it works with module Y so we got lots of meeting rooms and encouraged people to use their space for those meetings and keep the discussions going and not worry about how loud or boisterous they are communications and again another crucial aspect I seem to be saying that a lot but if you think about what can happen with a high performing team they might go down the wrong path because they didn't understand what was told to them or what was said to them they get very quickly down that wrong path you want to make sure that they are very clear communication about what's going on what's expected if the plan changes make sure everybody knows that that plan's changed make sure that everybody knows what's expected of them and keep the communications informal but also formal we had weekly meetings we had some senior management meetings back on they did that in an informal way a lot of people prefer just a coffee with their guys have a chat we also had daily stand ups and daily scrum of scrums really short sessions but it was mandatory to attend and it made sure that everybody was on the same page if there was a problem that team A hadn't sorted out a blocker for team B it came very obvious that that needed to happen really quickly big blockers got tackled really quickly talked a bit about meetings already I think we struggled a bit with meetings actually in the end we had a lot of meetings we had a lot of different discussions going on that sort of turned into weekly meetings we tried to make sure that everybody knew what was going on, it often felt like a one way conversation people were really taking that away so what we ended up with was some short meetings and a few of them probably several a week but we made sure they were short and important if they weren't valuable it was a waste of time therefore money all I do without punching each other up was to be open and honest if there was some discussion about ideas and whether that idea was good or not it was encouraged that you'd be quite open about whether you thought that was a good idea or not and if not why not and often if not what's your idea in replacement come up with some suggestions keep the communication open I can't remember too many punch ups there might have been one or two but we got things going and it really improved communication you knew that you were going to get an honest answer to any suggestion you had you knew that you were going to have a good conversation about ideas and they really helped form solutions in a really quick way so use communication systems we've got IM and Twitter and a phone FAQ style and email we use lots of them Cole talked about internet site we've also used Jabba for IM we had Skype, lots of phone calls particularly important when you're using working with offshore teams to keep that communication open for people to see and share each other's screens just again visual so you can see what's going on instead of listen to what that person's told you and as we've said just keep the information going keep sharing, make sure everybody knows make sure it's there for everybody we didn't have secure areas on the internet that people couldn't get to everything was open everybody could see what other teams were up to everybody was able to go and talk to anybody about what they were doing but what it boils down to it's all about the water cooler if you're there, you want to know something catch the person in the kitchen have a chat to them just general discussion turn up to their desk have a chat about what you're worried about or whored about or any of those issues you'll quickly resolve any problems IT operations IT toolkit it's crucial we made sure that we had the kit for the role and by that I mean we had designers that had two monitors in a fast machine we had devs that had two monitors we didn't ever expect a dev to try and cut code on a little laptop if they wanted to, okay but we tried to encourage them to use the best that we could the other crucial point is to make support as easy as possible you'll quickly burn money in effort if the support piece for managing all of that kit for 100 people takes 5, 6 people to manage we made sure that the images that were set up were easily reusable that we made sure we were on top of patches we made sure that we used everything we could in terms of the latest infrastructure and we controlled it I think this is a really important piece in something as big as what we're talking about here wasn't unusual to have 26, 27 individual boxes in terms of the site infrastructure all sorts of environments across those individual boxes having to ask somebody to change something in there is going to grind things to a whole so it was key to us to control it we didn't really get on very well with the overall IT team but we eventually showed them that our way was the way and got to control what we were using and made sure that changes happened when they were required and made sure that we were able to speed things up another obvious one connections to the team and from the team must be as quick as possible nothing breaks a coder's spirit than having to watch the hourglass to go over they really, really hate it again another obvious one current versions of software should be used there's a reason they're there we've got to make the most of them and again open source we found in the end that I think we even went away from Outlook as the only proprietary system so there are plenty of open source products out there to do all that you need we found that everything that we wanted from a software product was available in open source we found that most of the time they were better so you've done all the hard work all the work's been done all the development's been done all the testing's been done you're now starting to think about how to get this thing live which is not as easy as it sounds in a site like this what we concentrated on along with that testing and the development's operational readiness which is not just are we ready with the server it's the M&C team ready are the sales team ready is the help desk ready have we done everything we need to around informing our users are the stakeholders signed off in the end it was less about technology in the end it was more about is everybody comfortable that the site is what they expected to do sure there were some things that we needed to resolve but are they critical to the launch we really pushed hard with stakeholders to make sure that they were happy and had done a formal signature on a piece of paper sign off and we spent quite a bit of time with our hosting provider we wanted to make sure that they understood that having to scale up the site really quickly because the user base to jump through the roof was a good problem be prepared for it make sure that we've got the right kit in place make sure that we are using the cloud get ready for it we told them it was going to happen they were prepared they worked hard to make sure they were ready and available and then when we did launch we tried to make it as easy as possible we have learnt that doing it at 3am after a full week of testing and development and bug fixing is not the best way to go we tried to give ourselves a bit of time do it perhaps early in the morning perhaps a beta launch make it as easy as possible and on a full night sleep ok so you will all be delighted to know that we have come to the end so a quick recap we have talked about the fundamental of the project triangle we have had Al talking about the human factors as I call it of the internal team getting the right people making sure you keep them make them top performing teams and also managing the stakeholder expectations building that confidence and trust we talked about the processes on delivery and support and we looked at aspects of operations around accommodation communications, IT toolkit et cetera and then ours just outlined some of the key factors to think about when you're getting ready to go live so that's what we covered thank you very much for staying with us and being so patient and thank you for not throwing any tomatoes at us and if anybody's got any questions I think we've got a few minutes to take some questions Hi, Maxime from Ajax well basically you didn't talk about one thing I think it's really important for everybody's estimation when the client arrives with a big project and says ok I have this, when it will be done how much it costs and once you said it cannot be changed or very difficultly so what is your rocket science technique to this project well some of these projects like this one of the things you do not you do know an outline of the budget so what you can do from that is you can make an educated guess at the percentages of different roles that you're going to need x% of the people on your team are going to be BA's y% are going to be devs, senior devs and you're going to need certain senior devs to lead those and guide those teams from that and from what you know is the current market cost of those people per day you can start to estimate how big is the bucket of capacity that you've got to fill that budget and built some contingency in from that bucket of capacity you can start to estimate very broadly not exactly as down to story point level but you can start to kind of t-shirt size what you could do in terms of the components that they've the clients have asked for in the scope of the project and basically that's the first you're starting to get the first view of the project backlog then because you're starting to see the prioritized backlog list you've done some t-shirt sizing you know how many people it's going to need to deliver those things and basically your capacity list your bucket of capacity will eventually have the equivalent of a red line somewhere down that product backlog and that's what you can do with the budget that's how you can estimate how much of the scope can be delivered and that's the first thing that you start to feed back to the clients and say based on the budget you provided and the estimates we've done on the skill sets and the numbers of people that we need to do this project of the scale this is how much of your desired functionality you will get is this still the priority that you want things delivered in because that red line doesn't move unless you give us more money and then we're saying what we found is they would then just above that red line start to shift things around pull something from below the line which currently wasn't being done and move it up so that list got shifted around and they could really focus on what they wanted then thank you chapter on the end of the t-shirt I thought you were going to say Drupal t-shirt then there's a few of them here I had two questions one you mentioned that you've got roughly 100 people in your team or whatever do you figure out what the breakdown of the different roles and responsibilities of that team was and I'm also kind of curious once you actually built up a team of 100 people would you do with them at the end that's a good question should I do that one so I think of the 100 people we had and Steve's here he'll nod about 25 content people 30 people for content okay sorry roughly about the same size for dev obviously a little bit smaller but dev in our world included front end devs sysads a mixture of dev ops too then we had a small solutions architecture team four or five I think who steered the overall technical direction of the project we had a UX team which handled user testing visual design wireframing we had a BA team who ended up being a sort of a mini scrum master if you like but also doing the work on producing the detail as Colt talked about for the product backlog and test so we had test that also worked closely with the development team so I think it was and Steve was right we ended up with a big content team we ended up with content team being the main 45 for them 20 dev and then the rest were broken down in that gap and roughly about the same in terms of the team we worked together for quite a few years and then in the end the team got disbanded so the team some of these people are here access 12 has been formed on the basis of some of those people but the rest are out there and I'm sure if they put their hand up they'll be available to have a chat to anybody who wants to try and recruit them and that just said that something on to there that's one of the reasons why clearly when this team was formed we had to go to contractors to end up to freelancers because if you're building a big team like that permanent team a massive HR overheads in doing it and also it takes a very long time to build up a team of permanent staff that fast so there are cost implications obviously yours pay more for contract staff but in terms of the speed of which you can build the team up and minimising the HR overhead is really the only way to go in a project like that just to follow up of those 20 odd technical people how many of them actually had significant Drupal experience? Dave I think most of them didn't I for those that didn't hear Dave who led our technical effort was saying that we we ended up using as much people or resources we could through the Drupal community and then going to people that had PHB experience to try and beef up their skills and we found that work quite well actually in the main we got good at trying to as Cole said set the standards to start give them some training in Drupal and PHP Dev is pretty quick in Drupal in the end Any more questions? They're down on the on So you mentioned you outsourced a portion of your development to India How did you vouch for the variable code quality from individual developers and suppliers as a whole in India and also the different design ideologies that you have out there compared with say the UK or the US? Well that's broadly speaking that worked okay because we didn't just farm a whole chunk of work out to India and then they go off and work in a kind of a an information vacuum that offshore resource was integrated into our teams so they would be working virtually with our UK devs every day and our development manager would be speaking to them and running stand-ups with them and with the UK devs every day so there wasn't really that kind of separation and because they were working very closely on a day-to-day basis there was a level of visibility and a level of kind of organizational cultural alignment with the rest of the team so there wasn't really significant risk of that happening how he said that there are challenges in working with an offshore team in terms of the communications can be quite tricky at times especially when you're working using you're working virtually you have to sometimes be very clear about what you're communicating and the way you're communicating it there's an overhead in that speaking it actually worked quite well and certainly I think it's a really valuable way of doing it and the quality of the work that we got from the guys that we had offshore was very, very good Having moved from .NET development into open source I've found getting a consistency of tool sets quite difficult for big teams Did you mandate a tool set for the developers that you brought on board and if so what was it? Yeah we did mandate we had an image that we came pre-installed on a developers machine it was quite flexible in the end though there were some specifics that they needed to comply with the details of which I'm probably not best place to tell you but there are a couple of guys here that will be able to give you the details of that after the session we tried to make it clear that there were some things like code submission that had to go through subversion for example some things you just had to do we also tried to without being too over the top about it monitor what people were up to in terms of what they were installing on their systems we didn't want a virus for example coming into the system to bring the whole lot down it was important that people were aware of that and in the main people were okay with that Okay any more or is the torture over Okay great I think we're done Thank you very much for staying such a long time really appreciate it Thank you If anybody's got any specific questions you want to ask anything or make us feel even more stupid we're up on booth 3 for the next couple of hours by all means come and have a chat with us we really like to talk to you I just just as you're going because I'll get told off by the Drupal Association if I don't do this please locate this session and take the survey feedback that they get on the sessions is really important and it helps them to design better Drupal cons moving forward okay so you can be brutally honest on there okay you don't have to tell me to my face because I'll just cry alright thanks