 All right, so good afternoon everybody. Thank you very much for coming along This is going to be a controversial topic. All right, so I Want you to keep an open mind with everything I'm about to say some things are going to be provocative And deliberately so but I also want you to remember that there are nuances that there are exceptions that everything that I say is general rather than specific For those of you who don't know me my name is Evan Leibond For those of you who met me last year. I have since joined IBM So I now work for big blue as part of their wider organizational transformation towards agile So big change, but these topics are still my own. I do not speak for IBM when I talk about this. So No projects. What is no projects? Well, let's start at the beginning What is the project? project managers in the room What is a project? Teams joining together to achieve a certain objective. That's a pretty good definition. Who else? Temporary that's actually the key It is a temporary structure in order to achieve a change in the status quo Whatever the status quo happens to be whether it is a product whether it is a bridge. It doesn't matter. So The issue at play here is the word temporary Now those of you who understand concepts like knephen Calling back to Shane what Shane was talking about who understand concepts of complexity and complexity theory know that Temporary is the problem we have a situation in an IT construct in a software construct where a software project is Complex it is chaotic things change all the time. So the ambiguity the potential for change the chaos that exists within a project structure is Quite great and of course project managers no offense are going to put in place all of these controls and rigor and structures All right risk management processors schedule management processors change management processors and agile in a large part has spent a lot of time over the last 15 20 years in order to Make that bureaucracy make that process simpler and easier and more able to handle or manage the Fundamental chaotic nature of software, but I'm gonna go one step further. Let's talk about a few things Why not projects? Not why no projects, but why shouldn't we use projects? So the temporary They are expensive All right, there's costs associated with doing a project Overhead costs. What is an overhead? Well, it's you it's the project managers It's the cost of actually running that project Overruns here is the most important question. I'm gonna ask you all right hands up anybody Who has run a project that has delivered on time? on budget and to scope Anybody Outside of my team. Yeah, yeah, but even to be fair even in even outside IT. It's sometimes very hard nobody Very very very small ones. All right, so Here's the point projects fail So if the definition of insanity is to repeat something and expect a different result Here's my question to you. Why do we keep running projects? If you try something and fail and try it again, and it fails and try it again, and it fails and it keeps failing Time scope budget. Those are the three metrics that all project managers are measured by the iron triangle All right, time cost code if we cannot get any of those we cannot get those right Then is the answer to do better projects? Well, that's what traditionally that's what's been happening There's all these practices and processes PMI and so forth to try and make better projects I'm proposing all right that we change the dynamic all together. Let's get rid of the problem the project Another problem with projects they focus on the wrong thing All right, anyone who's run a project, especially in a larger organization Even many of the smaller ones the project is about the output The deliver this widget in three weeks or six weeks deliver this function this piece of software That's not important What's important is well the business what happens to the business after the fact So for those of you who have actually followed the conversation that's occurring around no project We'll probably understand or think that we're talking about product delivery products not projects And whilst that is legitimate. We can actually go a step further and say outcomes not projects And we mentioned that projects of temporary. I want you to do that. So This is a bit busy. I know and and and I'm breaking the cardinal rule of slides I'm giving you something really really really busy, but I'm giving you this for a reason. This is a I'm gonna get this right this word right phylo memetic view of the history of projects Specifically actually the history of agile Going back into Taylorism going back to 1870s and 1900s all the way up to modern day All right, so I'm showing you that what we call the current project framework Prince to agile These are not new These have built fundamentally on all of this which has come before From 1870 through to really 1970 everything on that board related to engineering Taylorism was fundamentally about manufacturing and yet we apply this Rigger where we can predict an outcome where we can predict I put these five things together and a cake will emerge the car will roll off the production line There might be a failure rate of one and a half per cent, but that's within acceptable bounds We have lean have six sigma have all these multiple methods in order to actually clean up and provide efficiency in the process All right, and in the 80s in the 90s. There was an even to the 2000s. There was a big push in Parallel to agile to try and make Software delivery more like a production line All right, does it does does anyone remember this occur? Yeah Some of you so this push to make agile more like a production line was predicated on the assumption that a Software product Could be predicted All right that function points and all these wonderful things around estimation all came together and gave us a predictable model of Software delivery Who here is a developer? Couple of you. Yeah. Yeah software art or engineering art Combination combination is both, but there's a part art if I'm building a bridge I'm pouring that concrete five if I've got in the structural engineering There is no art in that Maybe from an architect and doing this from draw point a little bit of art But once that concrete starts pouring that's a science That's engineering the ability for chaos or for a chaotic change to occur is quite low so What I'm about to say is my theory all right and and I could be completely wrong because I'm extrapolating but I Think what this is what I think happened in about the 70s or the 80s there was a Movement by the software industry to be taken seriously there was a movement to take it out of the garages and the stereotype of the Guy with the big thick glasses Coding away and whatever else. I'm not looking me. I'm talking when the PCs are coming out and I think at that point in time Software struggled to be taken seriously. They wanted to be and science and engineering science All right, the term software engineer came out this concept of Yeah, we're like we might be an industry. That's only a decade old but take us seriously and That was fine at the time and that was legitimate, but they did that by Pretending to be an engineering science Pretending and going we can do all these things the engineers do predictability all these wonderful things at the same time as IT and software was trying to be taken seriously finance started getting involved All right, how long does a piece of software take to build? That is the question that everyone in this room has probably been asked at one point. How long will that take? Now finance know what finance loves predictability your finance division is built on the fact that you can predict a and b start and end and so when Software engineering started to wrap things up in projects finance went beautiful. We can do that All right, you can now tell me that this piece of software is going to cost one and a half million rupees It's going to take three months and it's going to be delivered this time cost scope beautiful They were always wrong. It never It was never accurate But it didn't matter to finance because they do their predictive forecasts 18 months in advance and then allows them to build their budgets So this is the problem these two things in conjunction as I said, this is my theory my hypothesis came to Create what we currently know as the IT project. All right. It is a finance construct that allows us to with a level of uncertainty predict how long something is going to take and deliver in that structure so Let's now talk about no projects Let's talk about getting rid of the fundamental construct of a project Now obviously we're not going to stop doing work. We still need to deliver a piece of software a piece of change but Here's the point It's Continuous now we no longer have this temporary structure with a team that Goes away when the work is done We now have a dedicated team who is accountable for a particular set of work a particular outcome Who works as a team and this could be big this could be a thousand people working together? All right, but here's the key. They don't stop All right. There is no Project end. There's no project wrap-up. There's no project. There might be initiation when you start something at the beginning And you form a team. All right. There's no handover to operations all right because We're building products. We're building something that has a fundamental value to our business And if we're building something that has value does the value Do we stop delivering values and no more value to deliver when we stop the project and that's the key question You run a project. It ends Can you honestly in your heart of hearts say we have delivered the maximum value possible? No Can anyone say that I don't think so. I I certainly couldn't all I can say is we've run out of budget All right, and the running out of budget is not the same as saying well We've delivered as much value as possible now. Maybe there are things that will deliver more value. Maybe there's other ways of Delivering something else that is better. Okay, so we're not saying that things last forever There is a natural end of life to a product But that natural end of life to a product is not the same as the end of a project and that's the point So what is no projects? Okay, I'm gonna break another card in the rule. I'm gonna read from the slide The alignment of activities or work to outcomes measured by value constrained by principles and Supported by the appropriate technologies to deliver change All right, this is Fundamentally what no projects is continuous delivery of value and I'm not gonna go a step forward and say that's irrelevant that goes beyond the product itself so The rest of this this talk is going to be about how How do you deliver? How do you change an organizational construct that is fundamentally built around delivering a project? into continuous change now I Will also caveat what I'm about to say. All right, this stuff is new Some organizations have been doing working in this way for years All right, other organizations are starting to do it now. I'm not just small organizations All right, I'm working with a bank at the moment a very very like a mid-sized bank and they're moving towards no projects so These are new these are new ideas, but you're also not going to be the first so This is part of what I call the Continuous culture now. I didn't come up with that name. I'm afraid I don't remember who did All right, I saw the word somewhere on the internet It's like that's pretty cool continuous culture and then I completely lost the link where I found that word All right, but that's the but that's actually a really good way of thinking about what we're doing All right, we've moved into this idea this space in the industry where Everything we do is continuous continuous delivery. Well, it started with continuous testing Automated unit testing continuous integration then continuous delivery continuous deployment All right, the the the Amazon models and so forth All right, and now we're starting to move into continuous business continuous legal continuous marketing continuous Well everything so our project construct doesn't operate in a continuous model All right, our project construct does not operate in a continuous culture environment now. Here's the question for you all All right Actually, let's do it slightly different everyone stand up There we go. I've got your attention so Think about your company your organization. All right, I want you to sit down if your company is not Moving towards a continuous culture in some way look around All right, I'm saying if it is sit down if it is not moving if you are staying with a non continuous culture All right, everyone around you All right is in some form going to this continuous culture. You can sit down again. All right now that's interesting All right because There are parts of your organization which aren't going to keep up now the topic of this talk is projects But your finance department needs to become continuous finance Continuous budgeting role that they're called rolling budgets. Okay, so there are other aspects of your organizations Which need to change to keep up with this continuous culture. All right So just keep that in the back of your head is that we're not going to talk about it But it is something that you will need to consider so where to begin I Want you to think about Outcomes not outputs Project deliver this widget in six weeks sure boss. I can do that I want you to reduce this set of reports in this business intelligence system. Here's the requirements beautiful Okay agile. Here's your set of user stories who what why okay? I know why that's good All right, but what they're still stuff to do But is that the right stuff to do I don't I'm just doing what I'm being told whether it's user stories or a BRS It doesn't really matter But we want people to become accountable We want them to own the work that they do So here's an example of what I call an outcome profile very simplistic All right, nothing really special about what's on here, but this shows you the idea of what I mean by an outcome All right, how many active subscribers have logged into our system? All right, so We have zero active subscribers right now Our target is to get 10,000 active subscribers in three months Now am I telling you what features to build? No I'm saying this team here You you are accountable to get this product from zero pre-launch to 10,000 active subscribers To be honest, I don't care how you do it All right, I don't care what features you build in Why because that's not important The business outcome we're trying to achieve is Gross now obviously we need the right people in the team Okay, we need users and we need different people who can actually have that conversation and no and the agile delivery model I'm not saying we don't do agile. I'm saying no project is a replacement for agile Okay, or for that matter any development framework. I'm just saying we get the right people We don't need to tell them what to do But there's and there's a big but there's a very very very big but okay. I cannot give you complete freedom. I Cannot say get us to 10,000 users by any means necessary Okay, you could go out and you could go down to the local train station say I will give you 10 bucks if you subscribe I'll get you to 10,000 users within a day. All right, but We still have to have constraints now budget is a constraint But we also have what I call operating principles or working principles these guide and constrain how we work Now you've got them already your branding guidelines your security guidelines All right, all right your your work and your code guidelines your coding standards these you've already got nothing special about them So we build them in now. I personally think that guidelines these principles should be prioritized I like the Moscow rating. Okay, Master should could won't Why because here's a list of principles these ones you must comply with these ones you should comply with These ones you could comply with because every time I tell you to comply with something. I increase the cost of what you're doing Agreed So I say these ones are absolutely mandatory. You must absolutely must unit test every single piece of code You must absolutely must comply with these security guidelines. Okay, or gap or Any other legislative guidelines these ones are should the branding guidelines? You should comply with these if you've got a reason not to okay fine And these ones these are nice to haves. These are the guidelines that that good, but not necessarily mandatory make sense All right, so I'm telling you to meet an outcome I'm telling you what constraints you have in order to meet the outcome and then letting you go and Then I'm letting you as a team work out how best to deliver that but let's understand value So first of all everything that you do is meant to produce value now The first point is value is not measured at a micro level value is measured in aggregate each individual activity that you do Will have a probably minuscule impact to value All right because each activity is a day's work All right, but over time everything that you do is going to get those subscribers into your system so Four points to understand about value the first is value degrades You build a feature it is valuable, but the value of that feature will degrade over time All right You don't work in value order all the time All right very often down here. You're gonna work on low value items before your high value items That's your iteration one and two that's where you're doing the foundational work Maybe getting some database structures in place getting some test data some stubs All right, so we may talk about we're focusing on the value, but you got to do your hygiene your groundwork first All right You may reach a point of maximum value where everything that you do Doesn't improve what you're trying to achieve So sometimes you actually have to slow down to speed up Reduce the value. All right, our target is 10,000 subscribers. We've got to 5,000 nothing We do gets us above 5,000. Okay, every new feature we add does not add more subscribers So what do we do? All right, let's delete half the features All right lose a thousand subscribers and take a different path Now we're at 10,000 great So understanding The value of work The other one is the so what everything that you do. I want you to ask so what? What if I don't do it if I do not do this piece of work what happens? There's a very good litmus test for how important how valuable something is now The last point I want to make on this macro level of outcomes is about what I'm calling value delivery teams. These are Cross-functional teams These are teams who deliver They it's a cross-functional team. It's everybody that you need in order to deliver something of value All right, does that make sense? but I Want you to start thinking of them not in the context of a project not in the context of a Product even but in the context of an outcome If I give you an outcome increase subscribers, who do you need in that team? Five people ten people 70 people We can break them down into sub teams of seven plus or minus two All right, but who do you need involved to deliver that outcome? UX BA's devs testers doesn't matter and we keep going It may also be non IT. We need an accountant All right, we need a management accountant on on we need a HR person We need a sales person to actually go. We need ten market people So glad to go out and actually get those subscribers in the first place We'll build the features, but we need marketing to actually sell it So I want to talk briefly then about delivering work So everything is working is at the macro level outcomes, but let's go down now to the micro level activities now activities are interesting because activities give us a Necessary they're the you the discrete units of work that allows to deliver change Right, we don't work all the time So this is an activity candidate and there are different models and there's different ways of doing it I'm really just talking about the concept of an activity. This is the one that I like, but that's just me personally Everything that we do adds value to the outcome. How much value? Oh, there we go. That's that axis Everything we do will take time. How long? Well, that's that axis High value low effort first. Okay, that's pretty standard stuff. That's the order. We should be working in oops, sorry Here's an example. All right need to do a financial plan investment proposal. This is for a startup All right calculate the customer acquisition costs to the dirt. All right TNC's we need to do we need a landing page down here video marketing automation. Yeah, that stuff we can do later All right, it's hard. It's not as valuable as we want All right, this gives us what we need but this is act. This isn't a planning tool This is active management. We have an outcome increase subscribers to ten thousand in three months. That is our outcome We're trying to achieve What do we need to do and what is the order and the value we need to do in order to achieve that outcome? All right, this value delivery team. We should have users in that team All right, we should have if we're a vendor our customers in that team. Absolutely If you're not a vendor if we're building something internally put our users in that team But someone who is actually going to be able to help us determine the value UX HDD Whatever you want to call it All right, and we measure all right. This is lean startup stuff as well This is the concept of we have an idea we pilot we prototype it we prove it and if it doesn't work We change we pivot this is exactly what this is talking about But this isn't a project. There's no end date to this piece of work Even the outcome if I achieve 10,000 users does that mean my team disbands probably not because the outcome of growth Is a continuous outcome whether it's one? That 10,000 now becomes 100,000. What can we do to grow to 100,000? At some point there's an end of life at some point we do stop Why do we stop because well we've finished what we've set out to do and there is no more value to be had We have reached the point of maximum value Beautiful then you can stop Then you can disband that team send them off to another value delivery team All right, and move on to something else of greater value greater value for the organization All right, but this is not the same as a project. This is not a six month piece of work And we stop all right. We don't decide Upfront when to stop based on budget. We decide when to stop when we stop adding value and That value is determined by the outcome that we're trying to achieve All right, so how much time do I have left someone? 15 minutes, okay, so I want to talk briefly about the technology of no projects Okay, so no projects does not exist in a vacuum This is not a concept that Evan dreamed up one night and went hey, this is pretty cool. Let's do this All right, this is and to go back to the concept of this continuous culture. This is a pushback against a Structure that doesn't work because of what has come Because of the concepts of automation continuous delivery continuous integration DevOps even agile. These are concepts which have Formed the foundation of a way of working which the traditional project no longer operates within All right So actually, let me take a step back and actually ask you a question Who here? Fundamentally disagrees with what I've said and I would like anyone who does please say so now because we're gonna have a great conversation No one that is very disappointing. All right, so let me ask you a question What is the role of the project manager in this model? Who so if you're a project manager stand up One stand up if you're a project manager stand up. I had some I saw some hands up over it stand up Who I? Saw hands earlier. No, you're all too shy. All right, so have I just fired you? Have I just fired you? All right, so I fired you. Do I think I fired you? Because you're doing a different role. Excellent. Am I fired you guys? Yeah, okay. No, I haven't you can sit down here. Thank you All right, there's a reason I haven't fired you and that is your skill set is still valuable. All right Have I gotten rid of risk management? No, have I gotten rid of stakeholder engagement? No, have I gotten rid of I've gotten rid of scheduling? Okay, because we don't have a Gantt chart But to be fair, we shouldn't be doing Gantt charts anyway. They're really rotten Actually, do you know sorry? Gantt charts There we go. Hey la 1880 something or rather. All right, we're using a hundred year old techno hundred and twenty year old technology All right in order to manage a an idea that didn't even exist at that point in time All right So anyway, we shouldn't be doing Gantt charts. So this is a laptop. So this is still going but do we have the projector? Not yet It's coming back. It's fine So Let's talk about another topic there. All right, so I haven't fired you because you still have valuable skills in the organization What do you think how how do you sit? How where do you sit in that organization that? Correct, you you are so good until that last statement making sure the requirements are clear And this is one of the problems that we are going to find This concept of projects has been baked so deeply into our psyche that finding alternate words is almost impossible All right, we don't have requirements. Okay, because we're working towards an outcome We're working towards something that we need to do we have activities things that we need to do All right, and there is a you could consider them to be a requirement in some form, but they are different Okay, but in fact that's actually a problem. So I Give you I create a new team I say you guys are gonna do some work. This is the work whatever it happens to be All right, what do I say that you do like the word project is so baked into what we do that even organizations like Amazon or a connects or whatever else out there who like they don't really do projects in the way that we think of projects They're not temporary they still use the word projects because we don't have a different word and I if anyone has an idea for a different word I'd love it Sometimes I use the word engagement if I'm talking about a vendor project. I'll say it's an engagement not a project But if I'm talking about something internally, I actually don't have the right word All right, so initiative. Yeah, but but even that sounds small. It's something you're gonna try it's initiative So it's endeavor There you go. So project. This is this is the idea projects have been with us for a hundred and fifty years in some form All right, that we've lost this idea of communicating about the this idea in any other way All right, so part of the reason I am so controversial in the way I talk about no projects is I'm trying to break through this collective concept of there's no other way of working and I didn't even have the words for half the things I'm trying to describe So the last point I want to talk about is about funding it So I started off by saying that a project. What was it a financial construct? All right, so if we have a project because Well, our finance department wants a project and you want to go back to your organization and go Let's try getting rid of projects. We'll keep the project managers from time being okay But we want to get rid of projects We want to go to this continuous delivery model Maybe we won't go all the way to outcome based teams We'll just go half the way and we'll go to Product-based teams. All right, that's good. That's a good step How do I go to my finance department and Convince them that you no longer have a project budget. You no longer have this line item All right, so who here has had ever to do a budget for finance? couple of you yeah, all right I'll try not to be too boring for the rest of you There are two concepts capitalization and CapEx and OPEX okay capital expenses and operational expenses finance wants those two the great thing about something like the activity canvas is That each activity can be class is an activity a capital activity or an operational activity All right, and that's important because if it's a capital It goes into one class if it's an operational goes into the other We can track that over a short amount of time to give us a ratio How much of our work is spent in capital? How much of our work is spent in operational activities? All right, the other beautiful thing about no projects is it's actually easier for finance Why because there is no variation projects fail Every single time over time over budget or under scope now finance doesn't care about under scope Okay, finance don't care what you deliver all right. They care about budget and they care about time All right, but put that to the side all right If we're gonna fail all the time if we're gonna tell finance it's a million dollars and take six months It's actually 1.3, and it took us a year and a half Well, okay finance is gonna be unhappy with us if we say it's a team of 17 forever Or at least for the foreseeable future because I don't know when it's gonna end That's the point. We have now a linear burn rate Our finance is happy because we are spending money in a very very very consistent way $10,000 every week for 12 months and then for another 12 months And then at some point there might be an end of life and we'll disperse and do something else But that's that's flagged and forecasted well in advance because we can see the value degrading We can see that we're not adding value to whatever it is that we're trying to achieve So from a financial perspective, we're actually in a very very strong perspective Position so you guys can go back to your finance division and say we want to get rid of projects But don't worry because I'm making your life easier And if you can go to finance and say I'm gonna make your life easier You will have a friend for life having friend in the finance department is always a good thing. All right, make sense All right, so That's no projects. All right, very very simply There's a lot to it There's some articles up on infuq if you want to have a read And there it's not just me. I should say all right There are others who are writing about these topics as well All right, so use the hashtag have a look see what people are writing about it's really interesting stuff And there's different ideas different ways of doing it banks are starting to do it And if a bank can who are usually the most traditional of organizations can try and change how they fund work initiatives this I don't have a word to replace projects. What does a What does finance fund if it's not a project? I still don't know the word, but they're funding something Okay, an anti-project and a continuous engagement It's easier for them and if a bank can do it pretty much all of you can as well questions So the question was is it too early? All right, and there's my answer. Okay. It's No Very simply it is not too early. All right Are we some of the first? Yes, absolutely Absolutely, I know because well no one else is doing this or very few organizations are doing this right now All right, but are we too early? No, because it's gonna happen anyway All right, there are organizations out there. They don't call it. No projects But they've already transitioned to this continuous delivery model. All right this continuous culture All right, and I've walked into organizations and Banks I use another bank as an example. They no longer consider their fellow banks to be competitors All right, they don't consider standard chartered to be a competitor or Westpac to be a competitor They consider Apple to be a competitor Amazon to be a competitor now How does how does a bank compete with Google has a bank compete with Apple? And that's this point of the continuous culture. It's not too early. It's just the right time Otherwise you will be left behind and the other organizations who are competing and who do have this continuous culture and the Structures in order to deliver continuously. They're the ones who are going to operate successfully Okay, so yeah question. Why do I think projects don't have outcomes? How many here who's written a project manager and plan most some of you? Yeah, all of you Okay, how many of you have written the benefits of a project? Yeah, how many of you have struggled hard to try and find a way of quantifying those benefits and Writing them in such a way that finance will accept. We know that finance is going to give us the money Finance knows they're going to give us the money. Okay, this project has been put on the Strategic plan, but we have to go through the process of finding benefits that Will justify the business case or the project plan in order for us to get the money to spend that they're going to give us Anyway, no matter what so we spend three to six months Twiddling our thumbs writing documents for money that we're going to get All right, the reason I say that projects don't have outcomes is because we start from an output in most cases We start from the we need to do X How do we get the money to do X and let's find the benefits to justify it? Now what I'm saying is rather than start from the benefits. Don't don't don't start I don't care about the product. I don't care anything about the technology all I care about is we need 10,000 more subscribers We need to increase customer satisfaction reduce staff retention. We need to Maintain operational security on our desktop environment. It doesn't actually matter what I do in order to deliver that That's the outcome. I want to achieve and so that's the difference. All right, we're starting from an outcome not starting from an output and Pushing a benefit into it because outcomes and benefits are sort of like that yes, and in fact the the concepts are cognitively some very very similar and Even if you look at things like the on budgeting or the agile accounting standards Or even if you go back like 30 years in the concept of rolling budgets Which have been around in the accounting standards for quite a long time these models still operate It's just that the de facto like finance departments are lazy, right? They want the IT department to actually Say here's how much it's going to cost and in fact actually that's a good point We're changing the question. The question is no longer. How much does it cost? The question is how much is it worth? What's how much does how much is it worth to you? All right, I'm not going to give you a project and say here's the requirements. How much does it cost? There'll be a million dollars. Can you do for 800,000? Yeah, okay. We can do that. All right, and you will get $800,000 worth of widgets. Okay. No the question changes In order to achieve this outcome How much is it worth to you? We are willing to spend or a million dollars to get that. All right, we will do a million dollars worth of work based on the Based on the principles that are constraining us that's based on the outcome. We're trying to achieve Okay, we will work to our best effort. There will be governance Okay, we'll make sure that no one's defrauding the system But we will do a million dollars worth of work in order to achieve or in order to deliver on that outcome Okay, we may not meet the target Because here's the other thing to remember about we have an outcome which is to increase growth We have a target which is a hundred thousand in three months. The target is a guess Okay, the outcome is growth Everything we do is going to increase growth whether we hit the target is a matter of estimation Okay, estimates can be wrong But yes, you are right. Okay. No estimates. No projects. These are things go in. Am I out of time? One more question. One more question No, because the funding doesn't come in chunks. Okay, the funding is This team of 17 people of 150 people will get x amount to deliver on this outcome All right, there's no smaller chunks of funding. Okay, there's it's a BAU fund Okay, it is effectively a BAU fund. There's not a project fund. So in terms of actually distributing work, right? Standard agile practices apply. Okay, we should be self-selecting. All right, self-organizing If I've got 150 people then I'm gonna have break them up into multiple teams unless you're men low Which apparently can do it with 70 people in one team. So I'm quite impressed about that from that's keynote this morning, but putting all that aside, it's Our team has an outcome. We are accountable for that outcome We're gonna have a combination of highly skilled and less skilled people doesn't matter because they're going to operate as a team All right, KPIs team-based bonuses team-based There is no individual at this point in time. Okay, the individual KPI the individual bonus Completely disappears because are you delivering value against the outcome as a team not as an individual? Unless you're a team of one which would be ridiculous, but that might be the case That's it. All right I'm here for the entire week come and have a chat with me I'm The guy in the three-piece suit there aren't many so I'm pretty easy to spot I also have another talk on Friday for those of you here on Friday to talk about communication skills. Thank you very much