 Good afternoon, everybody. How are you feeling? Lovely. Okay, so we're going to keep this one a little bit interactive, in fact, a lot interactive. I'm feeling a bit lazy, so I'm going to do as little as possible. This topic is part of a wider set of initiatives around what we call no projects. Moving away from project management, project managers. The good old Gantt chart. And moving towards this concept of continuous flow, continuous delivery, and continuous, in fact, everything. Now, I'm not going to talk about no projects. That's a much wider conversation. Today I'm going to talk about the most important part, the business goal or the outcome. And each of us here are going to create one or two or three outcomes for our teams or our organization. So let me just start with a little bit of a history. Project management, we can date modern project management back to about the 20s and the 30s. Its precursors date back to about the 1600s. Obviously, the pyramids were a project. But as a mechanism for delivering something in a structured way, some of the earliest references we have are about the 1600s. And we can see the fingerprint of the industrial or the pre-industrial times, the industrial revolution, scientific management, globalization. Each of these initiatives have left their fingerprint on what we now think of as project management. But the problem is we've actually reached in many ways a new way of working, a new way for organizations to think and deliver value. This focus on project management that we've had for 50 years at least is actually starting to damage our ability to deliver. So this is the technical definition of a project. This is my definition of what no projects is. And I will do the cardinal sin of presentations I'm going to read from the slide. No projects, the alignment of activities to outcomes. Work must always be aligned to an outcome, not to a statement of work, not to an idea but a business outcome, measured by value, not by cost but by value, constrained by principles and supported by continuous delivery technologies if you're talking about the IT space. But this works outside IT as well. So this is what no projects is. Now the only key here, outcomes measured by value because that's what we're going to focus on for the next 45 minutes. The reason we do this is that we've entered what I call this continuous culture. Everything that we do is continuous now. And not just in the technology, continuous integration we've been doing for 10 years. Continuous delivery for three or four. But continuous feedback, continuous measurement, continuous HR, continuous legal. This expectation that our clients and our customers and our users have of us of continuous value generation is actually starting to impact on many legacy organizations who are unable to adopt this continuous mindset. So this is why the change to this continuous culture is why everything we're talking about for the next 45 minutes is real. Got it? All right. Let's change the question. And this is where the crux of everything lies. Who here is a project manager? I'm very sorry. Okay. All right. Have you been asked the first question? How much will this cost? Yes? All the time. It's what the business case is for. All right. Forget it. It's the wrong question. How much does it cost? If you answer that question, you are propagating a fallacy. You're propagating that the work that I do has a cost, not a value. Now, I was a project manager once upon a time. I am still technically Prince II certified. In fact, I'm not actually agile certified. Just Prince II. So there you go. But how much does it cost was always the question we tried to answer. The business case had benefits, but more often than not, we knew what we were going to do, and then we invented benefits to convince finance to give us the money. And finance tech didn't care about the benefits. They knew we made them up. They just cared that how much does it cost, because that's going to go in their budget. And this constant focus on cost and cost drivers completely changes the way that we view the work that we do. It has led to this. How many of you have had project budgets or divisional budgets cut? Most of you? Yeah. Why? Because finance doesn't see value. They see cost. So we have to change the question. It is not, we're going to create a widget. And that widget is going to cost a million dollars. All right? We change it. What is that widget worth to the organization? Is it worth $500,000? Is it worth $10 million? If it's worth $10 million, how much are you willing to invest to achieve the widget? And if you're willing to invest, say, 10% of a potential profit, then a million dollars makes sense. If it is worth the organization $500,000, then spending a million dollars makes no sense. Now, all that matters in this equation is can we deliver value to achieve a meaningful material outcome within the investment envelope available to us? It doesn't matter how much it costs. All that matters is can we deliver something within the envelope, the funding that is available, something of value? If the answer is no, we don't start. That's a lie, regulation, legislative projects. There's all sorts of other rationales for doing work. But in principle, all right, we work because we're creating value. Does that make sense? Beautiful. So outcomes over outputs. I'm going through these slides pretty quickly because most of this session is going to be doing this. Understand that doing something is irrelevant. Creating value is what's important. What we do shouldn't matter. So who's the project manager over here? Hands up, you're a project manager. You're a project manager? That'll do. What are you working on right now? Can you tell me? Okay. But what's the product? Software for semiconductor equipment. Sounds fascinating. I have no idea about that domain, so you're going to have to forgive me. Some of the questions I ask you aren't relevant. Software for semiconductor. Okay. Why do you create that software? That's a good answer. So let's dig a bit deeper. Why? Why are you selling it in the first place? Unless the problem is solved for the customer, it would lose millions of dollars. Beautiful. All right. So we're saving the customer money. That's brilliant. That's a good answer. All right. Now keep that in mind for a second. Somebody else? What are you working on? Software that will help the customer reduce support time. Why? If there's need for support, they will have to go to different clients to get the answer. Now this is an interesting case. Now the outcome that you're trying to achieve is to reduce the need for support or reduce the time for support. Okay. Dig deeper. All right. Why? Time equals money. Yeah. I will say one thing here by the way. All right. Who here is selling software? Nobody? Okay. That's good. Now a lot of people when they define outcomes will define it around money. And they will say that we need to make a million dollars. All right. Our target, we're going to spend $100,000, I mean to make a million. That's our target. That's the business outcome that we're trying to achieve. Now that's rubbish. Why? Can someone tell me why that is the wrong outcome? Yes. I do tend to say the same thing again and again. It's because it's important because if you're focusing on the money, you're not focusing on the value. Now, you still need to make money. You still need to be profitable. All right. For those of you who were here yesterday, I'll repeat the quote. Profit is like air. You need to breathe to live, but we don't live to breathe. So if you go down and you're looking at why do we do this? Why do we do this? Why do we do this? Five wise. And you come to make money. You've gone too deep. You've abstracted it too far. That is now meaningless. Come up a level. All right. We don't. We are not in business to make money. We are in business to provide a product or a service to our customers to solve a need. All right. Making money is how we show that we are actually solving that need. It's a measure. It's an indicator, not the reason. Make sense? So let's look at a couple of these. We're going to create some outcome profiles. You're going to practice this because this is hard. All right. And unfortunately, the two examples I've called from the audience were actually pretty good. So I can't really complain. But defining outcomes is very difficult. I spend a lot of time with organizations trying to help them understand the value behind something. They've spent decades creating financial structures and processes that are entirely built around cost. They are entirely built around making money. And they've lost sight of value. Value is an afterthought. All right. And in fact, project managers is benefits realization in your remit? Or does that happen sometime in the future after you've delivered? Future? Yes? So even the concept of the benefits that we have convinced finance and community organization to fund us to deliver is outside our remit. All we care about is the work. And we're focusing on the wrong, bloody thing. So let me give you two examples. Then we're going to start to drill in and do these ourselves. So these are two examples from a startup. Active subscribers. We carry a little description that gives us some context because people who read this outcome profile should, without any prior knowledge, know what this is. Once again, I'm going to read the slide. I'm sorry. Subscribers who have logged into the CN app more than once and have completed 80% of their user profile. You'll notice certain characteristics of this. These are meaningful definitions. If we just said number of people who have downloaded the app, then that would actually not be representative of realizing the value. How many times you downloaded an app, opened it, and went, now this is crap, and deleted it? If your KPI is measured on downloads, great. But it's actually meaningless. If your KPI is measured on people who actually use it, then you see that 20, 30, 50% of your users don't actually reach this point. Then your job is to fix that, is to find ways to get those people who do download it to stay, to, in this case, complete their profile. Now, here we look at some characteristics of the outcome. An outcome needs to have a measure. It can be qualitative. It doesn't always have to be quantitative. I don't mind measures which are subjective, as long as we are very clear about that fact. In this case, the measure is the number of active subscribers based on this definition of what an active subscriber is. The baseline, how many do we have today? Zero. We haven't actually launched yet. How many, what's our target? Notice that the target is time-bound. We want 100,000 in about three months. If your target is a percentage, then you don't need to make it time-bound because that percentage remains true no matter what duration of time that you're in. If it is not, if it's an absolute number, then you should bound it by some physical time measure. Budget, how much are we willing to spend to achieve this outcome? And this is critical. This tells you how many team members we can afford. It tells us how quickly we can ramp up. It tells us what it's worth to the organization. This organization is willing to spend $6 million to achieve that outcome. Now, it doesn't mean they'll spend $6 million. It means that they plan to spend up to $6 million and every week or two weeks, they will actually measure the outcome. Have we achieved the results? And if we have not, then let's inspect a bit deeper. What can we do? Now, we can make mistakes. Perhaps our target was unrealistic and thus we only have two things we can do. We either say, you know what? That's impossible. So therefore, how much we can spend needs to go down. Or that we need to spend this to achieve this in a longer time period. So we can invest longer term. Dependency is none and the owner who actually owns this outcome. Who's accountable? It doesn't have to be the head. It's not going to be anyone in the organization, but someone remains accountable. Here's another example. Staff satisfaction. Happy staff are productive staff. We want people to be happy. Now, in this example, we've actually got two measures. We've got a retention measure, which is what we call an inferred measure. The retention doesn't tell us how happy staff are, but it is an indicator of how happy staff are. It is not direct and there are other factors, but it indicates. The second one, NPS, Net Promoter Score. How likely are you to promote this place of work to somebody else? Baseline, 94, Target, 98. Baseline for NPS, 6+, Target, 2+, Budget, Dependencies, owner. Same as before. Does that make sense? Yes? We're now about to do this. We're going to spend the next little bit creating these. In all of your bags, you've got pens and paper, so pull them out. Here's what I want you to do. I want you to think about the work that you're doing right now. What are you working on? Building customer hierarchies. I have no idea what that means. What are you working on? If you are sitting beside your colleagues, in fact, even if you're not sitting beside your colleagues, I want you to work in at least pairs. Use the knowledge of the crowd. Explain what you're working on if they don't know. Try and understand. Who here knows what the five Ys are? Most of you. Basically, you ask Y five times. It's as simple as that. This is a mechanism that we use to drill down from a requirement or an output or a project into the reason it exists. If you hit to make money, you've gone too far. Use your pair to talk about, why is this important to you? Dig as deep as you can until it makes no sense. Then come back up a level. You've got five minutes to start. How's it going? You can credit a group of three if you want. Come on. Dive deeper. Why is reducing those work products important? What are you doing by reducing those outputs? You got something? Five Ys. Come back up again. Money's too deep. You're not in business to make money. You're in business to help people, to improve people's lives. To save people's lives if you're a doctor. A doctor's not in business to make money. A doctor's in business to save lives. But they need to make money in order to continue to save lives. So what's your saving lives? Potatoes like going into the cloud. What do you get down a lot? Why do we need it? How do we get this sensitivity? There we go. So you've gone down now. What's your measure? How do you measure success of the outcome? Is it by number of breaches? How do you measure success? If you've got the outcome, I still need you to do the measure. What is the measure that you're going to actually prove success? For example, if I have an application, and I want to install that application, there should be some estimations for the program. Is that okay? I have to put that file here for the particular application. So we need to do a cost to the organization. Not necessarily. How would it be for, for example... No, no, no. Flip it around. How much is the application worth for the organization? Do you know? Yes. For here, 5 million is saved. Okay, so it saves 5 million. How much are you willing to spend? Save 5 million. 1 million? Alright. So it saves 5 million. You're willing to spend 1 million? So, there's one more question to ask. Can I achieve the outcomes with a million dollars? Not how much will it cost, but can I achieve the outcome with a million dollars? If the answer is no, we don't start. If the answer is yes, go for it. We don't need an estimate of all the work. We just, we need the first-order estimate of can we achieve the outcome? I'll give you guys two more minutes, and we're going to do this again. But I'm just going to give you two more minutes to finish. Why not? What's the measure of health care? Patient outcomes, life saved. How do you measure quality health care? Why do you need to go 2-5 times? Why do you need to be 2-5 times? Because why do you provide quality health care? This is about as deep as it goes. The whole point, most people, if they have a product, the product's too high. Why are you creating the product? It's a good enough outcome by itself. You don't need to go any deeper. But I do need to know the measure. Okay? The more we work, the more it captures the dependencies. Who will see the dependencies? Are you dependent on another outcome? Are you dependent on another part of the organization? So not everything you do can be wholly contained by you and your team. This is more to show that we cannot be successful without this other party. The turnover of the company, for example. Sorry, what? The turnover of the company. Okay? I have three days for this. Okay. Now, hold on. I'm going to call on you to talk. Okay. Let's call it. We'll come back to this. We have plenty of time. So what have people got? Who wants to Hugo kick off? Okay. We'll come back to you. Let's go with a few simple ones before we go to the complicated ones. So who's got one that they think is good? No, it's okay. Big voice. Is there a mic? Do we have a handheld mic? That's okay. He's standing right in front of the video camera. Okay. So audible now? Yeah. So I don't think I've got everything there, but yeah, the outcome title and probably the description also would be to make data centers hack-proof. Impressive. Yeah. And the measure is number of breaches over a given period of time. Baseline is competitor data. We probably, and our own data, but the target is zero breaches over a given period of time. Budget dependency and owners, I think. So budget and so forth. All right. So some comments on, does anyone want to give me some comments on that? So a few thoughts. So first of all, so your baseline is different to your measure. The baseline is meant to be the expression of the measure. So if the measure is a number, then the baseline is a number. All right. So you have to make sure that the baseline and the target are the same unit as whatever you're trying to measure. Otherwise, it's not a real measure. So number of breaches. Okay. Yeah. So the measure, number of breaches that might have had that line with the competitor solution. Okay. So it's a comparative measure. All right. It's a percentage or it's a ratio. Yours to theirs. So is a target of zero reasonable? It's reasonable in this domain. All right. Now, what happens if you don't hit the target? A little trust. Nothing. You just don't make the target. All right. It's an estimate. All right. Now, if you don't make the target, we have to make a decision as to, is the level of investment correct? Is the work that we're doing correct? All right. But the target in itself is not sacrosanct. It can change and it does change. All right. So can I get yours? Healthcare? We have not made much progress. The outcome is to provide quality healthcare to patients. The measurement criteria is number of patients and providers using the application. Because if the providers are using the application, then they are going to help more patients recover from their health. That's a good outcome, by the way. The question was having trouble with the budget. So who was talking to somebody here yourself? So read out yours and then I'll answer your question. The outcome title is process control optimization for plant assets and oil rigs. The benefits are productivity increase of 3 to 5%, which would result in 5 million savings per annum. And it also have a health safety and security benefits with respect to plant emergencies. And also it improves process, those of the benefits. Okay. So this was a situation where the measure was cost savings. Let's say 5 million dollars in cost savings. How much are you willing to spend to achieve 5 million dollars in cost savings? Are you willing to spend a million dollars? Great. Okay. We're willing to spend a million dollars to achieve 5. Would you be willing to spend 6 million to achieve 5 million? No. How about 4? Why not? Perfect. Yes. There's got to be a buffer in there because the target is an estimate. We don't spend 4 to save 5 because there's no guarantee. We spend 1 to save 5 because that is a reasonable measure. Now, you're going to create a piece of software that's costing a million dollars that will save you 5. Now, the estimate question, and this is the question that we had. Do you need to have an estimate of how much that piece of software is going to cost? Well, that's not quite true because it's not just about how much you're willing to invest because you need to know whether the million dollars is enough. Do you need an estimate? No. You need a high-level estimate. The only question you've got to answer is, is a million dollars enough? Can I create the outcome I'm intending within 1 million dollars, which is what I'm willing to spend to save 5? Because we know what we're going to save. We know the target, and as an organization, we choose how much we're going to spend in order to achieve that. Now, each organization is going to have different risk ratios. Some things might be an absolute dead set certain, in which case 4 million to save 5 is fine. Other organizations will go, we just don't know. So 1 to save 5, or 2 to save 5 is fine, but I wouldn't go above that. It just depends on what your profit margin and what your intended profit margin. Now, we're just talking financial here. When your outcome is to improve the health outcomes, health care outcomes of patients, how much is that worth? Can you put a dollar figure on someone's life? Yes, I'm afraid you can. And hospitals do it all the time. It's why we have health insurance. So for the intangible outcomes, the savings people's lives, the improving health outcomes, that is where we do need to use a little bit of common sense, a little bit of statistics, look in at the numbers and go, it costs us $1,000 per patient. How many patients can we see? What is reasonable? And we do need to do some planning around that, but we don't need to go too deep. Okay, so there was another question about money, which I'll just repeat as well. So the question was, or the comment was, they got down to money. And I should use the doctor example. Why do doctors work to make money? Okay, I'm not going to your doctor. To save lives. That's why they exist. Do doctors charge? Do they make money? Why do they make money? For their living. So they can continue to save lives. The same is true of all your software products. It may not be as noble as saving lives, but making money enables you to continue to do the outcome. It's not the reason for it. All right, so let's look at the timing. We've got 10 more minutes. So we're going to spend five more minutes. We're going to do this again. If you haven't finished the outcome that you started on, then finish it. If you have finished it, pick a different product, a different service, a different thing that you're doing. Dive into it. Figure out why. Work in pairs. Why do you exist? It can be arranged. Yeah? And saving money is reasonable. If money is the reason you exist, then that is the outcome. If the entire purpose of your existence is to make and or save money, then so be it. Well, for banks. Well, no, no. We're doing this with banks. And banks get to money more often than not, but a lot of their services, a lot of their products are about improving people's quality of life. It's about making their lives predictable, safer. The bank makes money out of making people's lives easier, safer. So why do I have a credit card? Why do I have a credit card? For convenience. So the bank is in the job of making people's lives more convenient. There's the answer. How do you make people's lives more convenient? Not necessarily. We just need to look at... It depends on the scale of the outcome. An outcome at an organizational level gets broken down. But at a team or division level, every month, every two weeks, we would look at the NPS, we would look at that retention rate and go, have we achieved, maintained, or are working towards the target? And if we are not, then we stop. Or change. And that's where we change the architecture. That's where we move towards DevOps and we move towards continuous delivery. We want to get value to the market as quickly as possible. If you release value every six months, and your measure can only be every six months. I've done data center migrations like this. It's server builds like this. Server builds as well, are we? AMS type work where you're improving some defects in a hardware space? Yes, absolutely. If I'm doing chip design, maybe not. If I'm building semiconductors, maybe not. But where there is a continuous stream of value to be generated, then we can work in this way. All right, one more minute. Okay, we'll spend the next amount to purchase what needs value. Now, I know what will be the benefit for these four engineers or platform engineers in terms of the time production or it should have taken one week and it's going to take only a day or two or it can come down to three hours. How do I convert this into numbers? Well, no, you just have. Thanks. If you need to convert it down to cost, it becomes a bit harder. One second. You can look at the average price or the average cost of an engineer if you need to convert it into cost. But it comes down to how much is that engineer's time worth? And if that engineer's time is worth X, then if it costs you less than X, you're good. All right. Okay, you've practiced this twice. It's hard and for most of you, some of you, it's quite straightforward. Let me give you three pieces of advice. Number one. When you know the outcome, the product or the project becomes irrelevant. So the next question you have to ask yourself is forget what I'm being paid to do. Forget the project that I'm working on. The outcome is to do X. Is there something better that I can do with that money that would achieve X? Faster, cheaper, or better? And this is where the whole what does it cost to what is it worth equation comes in. Because if I focus on what does it cost, I can deliver a project successfully and still fail at an organizational level. I've hit my KPIs. I've released on time. I'm on budget and yet no one's using it. I've not achieved the business objective or the business outcome. If I'm willing to spend a million dollars to save a hundred engineer man days, is there another way that I can save even more engineer man days with that money? Is that service or that product or that project the best use of those funds? And we can actually build teams who are dedicated to these outcomes. Whose entire job is to figure out what do I do next? Continuously measure, and my second point is we continuously measure the outcomes. Once a week, once every two weeks, no more than once a month. We look at how are we progressing against these outcomes? Are we achieving value? And if we are not, then we retrospect, we inspect, we adapt. We are agile fundamentally. And we go, what is a better or different way of achieving those business outcomes? Okay? Now, there's one final concept that I'm going to cover in the last, what do I have, five minutes? Two minutes. Working principles. Once you have outcomes, once you know why you're doing the work that you're doing, you need to understand that it's not just you. It's you, and it's you, and it's you, and it's all of you working in a single organization creating something of value. But you all have different outcomes that you're working towards. How does your outcome not conflict with yours? If yours is about growing the user base and yours is about security, how do you make sure that you make a secure environment, we do not fundamentally cripple the ability to grow the user base. And that's what these are for, working principles or constraints. Constraints are good. We define the constraints which allow us to be successful. They could be brand constraints. You must follow the brand guidelines. They could be operating constraints. We must release every day. They could be constraints around security. Every public-facing thing should go through web scarab to make sure that something is secure. Pen testing, automated pen testing, whatever. The constraints are unique to an organization. It depends on what's important to you. Now, the other thing to note about constraints is constraints have cost. Every constraint that you introduce adds cost. So who here has heard of the Moscow rating? Seriously? Okay, must have, should have, could have, won't have. Thank you. You do know it. It's generally used as a prioritization model, but I use it against constraints. I have a list of constraints. These, let's say, 10% of my constraints, of my principles, are must have. You cannot get an exemption from them. No exceptions. You must do this. These are the ones which impact legal, legislative requirements that we have. These are the ones that come to deep product brands. We cannot break these. Should have. Maybe 20, 30% of your constraints or working principles are ones which you can apply for an exemption. You can go to the owner of the outcome or the appropriate party and say, you know what? Comply with brand guidelines. We're doing an Apple Watch app. We can't comply with the brand guidelines. Can you give us an exemption? Yes, absolutely. That's a perfectly reasonable request and the exemption is granted. So constraints and principles which are should, if you have a good reason, you don't need to do it. Could. These are 60, 70% of your principles, your constraints. These are ones that you can choose not to do. No requests, no approvals, no authority. You just don't do it if you have a good reason. It's up to you as an empowered leader in the organization, as an individual who is trusted to make a reasonable decision not to do this. But it's considered to be at your discretion. You do it if you can, but if there's a good reason, you don't. Does this make sense? Once we know what the outcomes are at an organization, and sometimes we'll do this in like a design thinking type workshop where we actually go through the product base of an organization and the operating model of an organization and look at why does this organization exist? Because organizations forget. They get so hung up on profit and someone back here said their outcome was to double their revenue. Seriously, that's money once again. You're not in business to double your revenue. You're in business to achieve great results for your clients, a beautiful product. Doubling your revenue is a consequence of creating a great product. I think I've pretty much come to the end. Does that make sense to everybody? Any questions? No questions? It makes sense? Hang on. I'm over time. Thank you very much.